From nman64 at n-man.com Sat Apr 1 00:03:15 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 31 Mar 2006 18:03:15 -0600 Subject: Split-off package config from release note packages In-Reply-To: <442D6840.2020600@wowway.com> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com> Message-ID: <200603311803.19043.nman64@n-man.com> On Friday 31 March 2006 11:34, Demond James wrote: > Axel Thimm wrote: > > But then hell breaks loose and people accuse JoeBob of forking fedora, > > when all he wanted to do is either provide decent mirrors (local or > > not) for his users or additional repos. Having to replace > > fedora-release to do that results in for example: > > > > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning > > What would help stop the propaganda Axel is descriptions of the changes > that were made to these core packages. As it stands now I do not want > to replace the core packages with your packages simply because I don't > now what changes you made. Let me decided if I want that added > feature. Other than that great job and great repo. Thank you! > When you start changing packages from Core, it really is a fork by definition. Replacing Core packages is not and will never be considered a good or safe practice, and will never be supported by the Fedora Project. I'm not saying that providing alternative packages is a bad thing, but you must clearly tell users what they are getting. If you don't, then someone else has every right to try, as John did. As soon as you change one package from Core, the system isn't Fedora Core anymore, even if it is highly compatible. This is why the Trademark Guidelines are so restrictive about changing systems and continuing to call them Fedora Core. Providing alternatives to Core packages isn't providing a third-party mirror or repository, it is providing an *alternative* repository, and it is beyond the scope of the Fedora Project to support that or make it easier in any way. The fedora-release package is the single package that defines the installed release. Any file that is unique and critical to a particular release is not out of place in that package. The repository configurations are arguably release-agnostic, and could be reasonably split into a different package, but only for reasons of maintainability. If you want to change the existing files, tell users and give them the option. If you want to add new repositories, provide a separate package. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Apr 1 00:18:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Apr 2006 02:18:40 +0200 Subject: Split-off package config from release note packages In-Reply-To: <200603311803.19043.nman64@n-man.com> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com> <200603311803.19043.nman64@n-man.com> Message-ID: <20060401001840.GF5242@neu.nirvana> On Fri, Mar 31, 2006 at 06:03:15PM -0600, Patrick Barnes wrote: > On Friday 31 March 2006 11:34, Demond James wrote: > > Axel Thimm wrote: > > > But then hell breaks loose and people accuse JoeBob of forking > > > fedora, when all he wanted to do is either provide decent > > > mirrors (local or not) for his users or additional repos. Having > > > to replace fedora-release to do that results in for example: > > > > > > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning > > > > What would help stop the propaganda Axel is descriptions of the > > changes that were made to these core packages. As it stands now I > > do not want to replace the core packages with your packages simply > > because I don't now what changes you made. Let me decided if I > > want that added feature. Other than that great job and great > > repo. Thank you! > > > > When you start changing packages from Core, it really is a fork by > definition. Replacing Core packages is not and will never be > considered a good or safe practice, and will never be supported by > the Fedora Project. [...] Oh, no, not that thread again. Just to cut a long story short, please show me one 3rd party repo that doesn't have a package replaced. You'll find in the archives, that not only ATrpms, but freshrpms, dag, livna, kde-redhat (by definition), planetccrma, newrpms, have done so. So by your's and John's definition these repos should all be called forks of fedora. > The fedora-release package is the single package that defines the > installed release. Any file that is unique and critical to a > particular release is not out of place in that package. The > repository configurations are arguably release-agnostic, and could > be reasonably split into a different package, but only for reasons > of maintainability. > If you want to change the existing files, tell users and give them > the option. If you want to add new repositories, provide a separate > package. It's great that we agree, as this is exactly the mode ATrpms is working ... My personal view: ATrpms is trying to add value to fedora (and RHEL), and I wonder why there have to be so many alienations towards ATrpms. People of the fedora community complain about market loss to Ubuntu due to non-coherent community of fedora and semi-official statements like the one in the wiki just divide the fedora community further. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Apr 1 00:25:00 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Apr 2006 02:25:00 +0200 Subject: Split-off package config from release note packages In-Reply-To: <604aa7910603311120r561fe88dg227095e5ea84c0fd@mail.gmail.com> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <1143516515.3140.1.camel@aglarond.local> <20060328122303.GA19783@jadzia.bu.edu> <1143558013.3140.15.camel@aglarond.local> <20060329150226.GC13953@neu.nirvana> <442D776C.5090303@math.unl.edu> <604aa7910603311120r561fe88dg227095e5ea84c0fd@mail.gmail.com> Message-ID: <20060401002500.GG5242@neu.nirvana> On Fri, Mar 31, 2006 at 02:20:24PM -0500, Jeff Spaleta wrote: > On 3/31/06, Rex Dieter wrote: > > > But then hell breaks loose and people accuse JoeBob of forking fedora, > > ... > > > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning > > > > My $0.02: I think flamebait, err, personal opinion stuff like that has > > no place in fedoraproject's wiki. It should be removed. > > > Aren't there master wiki admins who can are tasked with policing the > wiki content and dealing with people who have stepped over the line? > > Just a little history about this page... this author of that page > originally had it as a top level page and not under his namespace. I > suggested that he move it to inside his accountname space to make it > clear that that page was in fact was personal opinion and not policy. > Without clear guidelines as to what is allowable content I wasn't > going to fight over whether or not the wiki can be used for opinion or > editorial content at the time i found out that page existed. I > totally forgot to follow up and open a discussion on -extras-list as > to whether or not opinion pieces were allowed. For the record: The current incarnation of this page is already the smooth version after I contacted John two weeks ago in private and asked him to review the page and preferably remove it altogether. I'm copying John, as he might want to say something about it. Instead of asking wiki admins to edit his page away I'd prefer if he would consider this himself. The least we really need is more dividing in the fedora community camps, and I hope we can move forward with cooperating parties instead of enforced policies. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From stickster at gmail.com Sat Apr 1 01:07:20 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 31 Mar 2006 20:07:20 -0500 Subject: Fedora's way forward In-Reply-To: <442CD714.2030504@hhs.nl> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com> <442C59A9.1010507@hhs.nl> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> Message-ID: <1143853640.14149.30.camel@localhost.localdomain> On Fri, 2006-03-31 at 09:15 +0200, Hans de Goede wrote: > Lets get back on track here, the problem ESR brought up was: Fedora > lacks good multimedia playback. The reaction was a mix of: > -unfortunatly we can't provide that > -we can't provide that and we don't want to unless we can in a 100% open > way > -we can provide that out of the box, and legally we can't ever provide > it 100% open (livna is not legal in the states), but we could come some > way using gratis propietary stuff which can be downloaded > > My stance is: > -yes better multimedia support would be good > -yes Fedora must stay 100% opensource and redistributable etc > -Fedore should not encourage use of propietary formats but it shouldn't > make it impossble either. That's my stance too. Do you think this is not happening now? Because I think this is *exactly* how Fedora works now, and I'm getting the sense you think that isn't so. Am I misunderstanding? > My Conclusion: > > We should provide a mechanism where if a user tries to play an > unsupported format, we look up the format in an ondisk (no phoning home > please) tabel and see if there is a gratis and legal (even in the > states!) downloadable codec in the tabel, if there is such a beast, then > _help_ the user install it. I don't want to see this in Core, but people are entitled to put this in any third party package they want. > Notting more and notting less, so we wont be telling them to use mp3, > nor will we be claiming support, but if a users tries it we help him, > now how can helping a user accomplish what he is trying todo ever be bad? This doesn't seem like good reasoning to me. In all honesty, there are plenty of things users might want to accomplish with Fedora that are bad... or, to be more objective, contrary to the goals of the Fedora Project. We don't stop people from doing those things, but we don't give them end-to-end support for it either. > Another take on this, I'm a big fan of free software because of the > freedom it gives me, thats what this is all about isn't it, freedom! > Doesn't that include the freedom to use proprietary software when I want > to? It seems that there are people here who would like to even forbid > the use of proprietary software if they could and since then can't they > atleast want to make it as hard to use as possible, this is BAD as it > hurts other peoples freedom! Absolutely this is about freedom. But Fedora doesn't forbid you from doing those things now. In fact, it goes to great lengths NOT to prevent you from doing them -- including incorporating GStreamer and other media products which feature excellent plugin architectures, and having packagers both in Core and Extras who try and make life easier for people who want to use free software most of the time but walk the wild side every once in a while. I don't think I've heard anyone here argue against the use of proprietary software. The main argument here has been against compromising the ideals of Fedora, which have led to an amazing release less than two weeks old, a vibrant and rapidly growing user community, and interest from my Mom, grandmother of eleven. (OK, the last part probably doesn't matter to most people, but I see it as a significant victory.) Nothing Fedora is doing now is restricting users' freedom. We're talking about whether, now that we've already given the user a fishing pole, fishing line, tackle box, bait, sinker, bob, and free fishing lessons, and then driven him to the public riverbank, we should point him to a nearby pond on private property, saying, "Hey! *That* looks like a good place to fish!" It's probably not illegal to say such a thing, but is it really the ethical thing to do? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From naheemzaffar at gmail.com Sat Apr 1 01:18:45 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 1 Apr 2006 02:18:45 +0100 Subject: 'Commercial Partners' In-Reply-To: References: <20060329145524.GB10714@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331201705.GH4133@redhat.com> <1143839593.2561.60.camel@rousalka.dyndns.org> Message-ID: <3adc77210603311718u204484d5v20ac049407972cf1@mail.gmail.com> Fedora has its goals, and sould stick to them. However there is (IMO) a usability case that ESR has identified. If someone tries to play a MP3 file or some other format that is not supported, there is a generic error. What IMO should be done is that the error should be in more detail, eg mentioning there is no MP3 support atm. Next there should be a link to Fedoraproject wiki page, where there is some information about propriety plugins, and their 'evil' in regards to FLOSS, and about legal floss alternatives (mention ogg etc). But underneath, there should be solutions for legally viable 'additions'. There should be the info about the mplug macromedia flash repository, as its legal, and has redistribution rights. There should also be a link to fluendo and its free commercial MP3 plugin for Gstreamer. There would be no need to add information about legally dubious (for the US anyway) repositories. There could be info for other legal software too. This way, fedora is always free, does not promote the proprietory software, but also gives the user a solution when needed. win/win? (should there be a BZ on this? or is it not feasible due to something I have missed out?) ftr, I use fedora because its not encumbered. I add a few bells and whistles, but not as much as I need to with a fresh Windows install. (even here it needs top be updated to get the latest wma multimedia support!, and then add quicktime, real, an anti-virus, anti-sam software, word processor, flash, java, 7zip or other file compressor/exrtractor, a proper email client, a bittorrent client, messenger software for each major IM network I use (I have moved to gaim on windows now. far easierthan having multiple softwares slowing everything down) and many many others. Its far quicker on Fedora.) I am sure if there was a fedora PC reseller, plugins would be added before it reaches the end user. Maybe we need some case studies here? give someone a fresh windows install, and a fresh fedora install. See which requires more effort to get to a certain point? could be good material for marketing purpoeses? All in all Fedora is far closer than people think. It has the first 99%, it just needs the last 99% ;) I think i have put enough jumbled thoughts into this email :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From seandarcy2 at gmail.com Sat Apr 1 02:24:52 2006 From: seandarcy2 at gmail.com (sean) Date: Fri, 31 Mar 2006 21:24:52 -0500 Subject: rawhide->fc5; X won't start In-Reply-To: <1143750758.3589.1.camel@halflap> References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> Message-ID: Ray Strode wrote: > Hi, > >> Ray Strode wrote: >>> Hi, >>> >>>> OK, so no one else sees this. >>>> >>>> Any suggestions as to how to diagnose this? Any way to get more verbose >>>> or clearer error messages? >>> If you run fc-cache -f from your user account does your problem go away? >>> >>> --Ray >>> >> Thanks for the suggestion, but...(: >> >> Here's the console message from trying kde. >> >>> (==) Using config file: "/etc/X11/xorg.conf" >>> xset: bad font path element (#76), possible causes are: >>> Directory does not exist or has wrong permissions >>> Directory missing fonts.dir >>> Incorrect font server address or syntax >>> startkde: Starting up... >>> DCOP aborting call from 'anonymous-2482' to 'kded' >>> startkde: Shutting down... >>> klauncher: Exiting on signal 1 >>> > What if you manually add some font paths to your Xorg.conf > Try adding some of the ones in > /usr/share/X11/fonts/ > and /usr/share/fonts > > --Ray > Great idea, but no joy. Same result. I changed xorg.conf to: > Section "Files" > > # > # FontPath "unix/:7100" > FontPath "/usr/share/X11/fonts/misc:unscaled" > FontPath "/usr/share/X11/fonts/75dpi:unscaled" > FontPath "/usr/share/X11/fonts/100dpi:unscaled" > > EndSection And, FWIW, > find /usr/share/X11/fonts -name fonts.dir > /usr/share/X11/fonts/misc/fonts.dir > /usr/share/X11/fonts/75dpi/fonts.dir > /usr/share/X11/fonts/100dpi/fonts.dir > /usr/share/X11/fonts/TTF/fonts.dir > /usr/share/X11/fonts/Type1/fonts.dir Xorg.0.log shows no errors. This is really frustrating. I no longer believe this a font issue. But I can't figure out how to get some log and error messages that show what's happening. sean From paul at permanentmail.com Sat Apr 1 04:16:04 2006 From: paul at permanentmail.com (Paul Dickson) Date: Fri, 31 Mar 2006 21:16:04 -0700 Subject: Why no development mirrors? Message-ID: <20060331211604.6c6c5c8a.paul@permanentmail.com> /etc/yum.repos.d/fedora-development.repo gives: [development] name=Fedora Core - Development #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide enabled=1 Yet a "curl http://fedora.redhat.com/download/mirrors/fedora-core-rawhide" only provides: http://download.fedoraproject.org/pub/fedora/linux/core/development/$ARCH/ Are there no other mirrors? -Paul From dax at gurulabs.com Sat Apr 1 04:40:04 2006 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 31 Mar 2006 21:40:04 -0700 Subject: Fedora's way forward In-Reply-To: <20060331173633.GC24571@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <20060329063345.GB6131@thyrsus.com> <1143657279.25616.11.camel@daxter.boston.redhat.com> <20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2> <20060331173633.GC24571@thyrsus.com> Message-ID: <6899-SnapperMsg827D11E1C053B4B0@[68.27.238.145]> ...... Original Message ....... On Fri, 31 Mar 2006 12:36:33 -0500 "Eric S. Raymond" wrote: >The user needs a button to push and a simple menu, and and interface >that *requires effectively no thought or decisions*. I disagree. Software installation that 'requires effectively no thought or decision' has left Windows a wasteland of spyware, rootkits and other malware. Humans could have left the solar system by now if we hadn't wasted billions of man hours and money on dealing with that one aspect of Windows' design. ___ Dax Kelson Sent with my Treo From skvidal at linux.duke.edu Sat Apr 1 04:43:38 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 31 Mar 2006 23:43:38 -0500 Subject: Why no development mirrors? In-Reply-To: <20060331211604.6c6c5c8a.paul@permanentmail.com> References: <20060331211604.6c6c5c8a.paul@permanentmail.com> Message-ID: <1143866618.22082.15.camel@cutter> On Fri, 2006-03-31 at 21:16 -0700, Paul Dickson wrote: > /etc/yum.repos.d/fedora-development.repo gives: > > [development] > name=Fedora Core - Development > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > enabled=1 > > Yet a "curl http://fedora.redhat.com/download/mirrors/fedora-core-rawhide" only > provides: > > http://download.fedoraproject.org/pub/fedora/linux/core/development/$ARCH/ > > Are there no other mirrors? > it uses an apache rewrite to redirect you to a different mirror each time. -sv From gilboad at gmail.com Sat Apr 1 05:13:55 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 01 Apr 2006 08:13:55 +0300 Subject: Fedora's way forward In-Reply-To: <6899-SnapperMsg827D11E1C053B4B0@[68.27.238.145]> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <20060329063345.GB6131@thyrsus.com> <1143657279.25616.11.camel@daxter.boston.redhat.com> <20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2> <20060331173633.GC24571@thyrsus.com> <6899-SnapperMsg827D11E1C053B4B0@[68.27.238.145]> Message-ID: <1143868435.17044.39.camel@gilboa-home-dev.localhost> On Fri, 2006-03-31 at 21:40 -0700, Dax Kelson wrote: > ...... Original Message ....... > On Fri, 31 Mar 2006 12:36:33 -0500 "Eric S. Raymond" > wrote: > >The user needs a button to push and a simple menu, and and interface > >that *requires effectively no thought or decisions*. > > I disagree. Software installation that 'requires effectively no thought or > decision' has left Windows a wasteland of spyware, rootkits and other > malware. > > Humans could have left the solar system by now if we hadn't wasted billions > of man hours and money on dealing with that one aspect of Windows' design. /+5 Funny ;) I second the above. Making Fedora (or Linux for that matter) idiot free will only create a second, semi-open-source, Windows. If a user can't be bothered to read a FAQ, google for help, or, heaven forbids, learn how to configure pirut/yum/rpm, he shouldn't be using Fedora (or Linux). Come to think about it, unless this user's computer is being actively administered by someone else, he shouldn't be using a computer to being with. (If it does, then his administrator is perfectly capable of installing nonfree codecs, nVidia/ATI drivers, etc on its own. No need to dumb down Fedora) I'm all for making Fedora easier to use. I just don't want Fedora to end up looking, behaving (and ultimately, crashing) like Windows. Gilboa From michael at knox.net.nz Sat Apr 1 07:13:09 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 01 Apr 2006 19:13:09 +1200 Subject: FC5 boot problems Message-ID: <442E2805.2020401@knox.net.nz> OK, this has (sort of) been covered else where, however, the solutions to other people's issues have not worked for me. Clean install of FC5 and on the first boot, the system appears to stop at "Starting udev:" I do not have pcmciautils installed, I have tried noacpi, single, removing rhgb and "quiet", I have updated my kernel to the latest one from updates. I have moved various udev rule files from /etc/udev/rules.d/ to see if any are causing me grief, but nothing. System runs FC4/FC3 fine. This is my first time installing FC5, I previously had installed test releases, which worked fine. I am at a loss as to what the issue is. RH bug #186164 covers this, but as I said, I don't have pcmciautils install. Any pointers? Michael From mharris at redhat.com Sat Apr 1 07:27:14 2006 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 01 Apr 2006 02:27:14 -0500 Subject: r300 driver in extras? In-Reply-To: <442D24FF.3060403@gmx.net> References: <442D24FF.3060403@gmx.net> Message-ID: <442E2B52.2040508@redhat.com> Jonathan Dieter wrote: > Mike, I've been following the fedora-devel mailing list, and I > understand why you removed r300 support in Mesa and the kernel. I was > working through a bug where OpenGL didn't work at all (even in indirect > mode), and, in the process, rebuilt both Mesa and the kernel after > removing your fixes. Apparently, I'm one of the lucky ones whose Radeon > 9600 works with the experimental driver because it all started working. > I'm now thinking of putting together a package (similar to the > proprietary one in livna) that would give accelerated 3D to any Radeon > users willing to take the risk. > > It seems that the only difference in Mesa when the r300 is enabled is > that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and > that the only difference in the kernel is the drm module is patched to > not recognize the r300 PCI ids. Correct. > It seems that the Mesa problem could be easily fixed, but what is the > easiest way to fix the kernel (aside from providing my own > (un)patched kernel)? The only way, is to unpatch the kernel and rebuild it, and modify Mesa and rebuild it. Mesa drivers are not buildable outside of Mesa currently. > Will X even try to load the DRM module if Mesa doesn't provide r300_dri.so > but the kernel does provide the PCI id's? Yep, the X server loads the DRM aparently, as long as Load "dri" is present, which is broken in theory at least, although I don't know if anyone has investigated if there is a good valid reason for that yet or not. Loading the radeon kernel module causes various R300 hardware to lock up, which is prevented when DRM does not get loaded, which is why we disabled R300 DRM support in the kernel. ;o) > If it doesn't, could we re-enable the r300 PCI ids in the > kernel and just ship Mesa without the r300 driver? "If it doesn't" is the key here. Once someone who can reproduce the failures figures out why and fixes the problem though, then we should be able to re-enable R300 bits in the kernel, unless there are further issues uncovered. > If it does, is there any other possible solution to the kernel that > I'm missing? Yeah, undo the kernel patch, add mesa r300 driver back, and then debug why it locks up for people, produce a patch that fixes it, and submit it to the kernel/dri/mesa/xorg projects as appropriate. ;o) > I've been using the fglrx driver in earlier version of Fedora for years > now and would love to take this chance to move off of it and helping > others move off in the process is a bonus. Indeed. I really hope that in X11R7.1 we'll have a much stabler 2D radeon driver. Right now the open source radeon driver's stability and reliability pretty much sucks rocks. The rate of bugs being added to the driver seems to be faster than the rate of bugs being fixed in the driver. Every time new hardware support is added, or new features are added for existing supported hardware, the driver seems to break in ways that don't get discovered early enough to get fixed. The radeon driver source is currently rather humongous and growing daily. It's really quite a horrendous mess right now. Shipping a 3D driver which works for some people but causes many other people's 2D desktops to break is very bad. Given the choice between buggy experimental 3D support and a broken 2D experience, and working 2D and no 3D, we'll probably always choose to ship the latter. benh's fixes in the stable radeon branch improve things for some people having certain problems. Once a new stable radeon driver is released, we will probably throw it into updates-testing for a week then FC5-updates. If someone wants to make unofficial unsupported Mesa packages and put them somewhere, that's fine IMHO. But Fedora Extras is no more of a broken-driver playground than Core is IMHO. Make an experimental repository somewhere and call it "Fedora unsupported R300 driver", with a web page that clearly informs people that while using the experimental driver, all bug reports should be filed to X.Org bugzilla directly. That will greatly help the X.Org/DRI/Mesa projects to get the driver in better shape sooner than later. Hope this helps! TTYL -- Mike A. Harris, Systems Engineer, X11 Development team, Red Hat Canada, Ltd. From buildsys at redhat.com Sat Apr 1 08:23:16 2006 From: buildsys at redhat.com (Build System) Date: Sat, 1 Apr 2006 03:23:16 -0500 Subject: rawhide report: 20060401 changes Message-ID: <200604010823.k318NGLB008336@porkchop.devel.redhat.com> Updated Packages: binutils-2.16.91.0.6-6 ---------------------- * Fri Mar 31 2006 Jakub Jelinek 2.16.91.0.6-6 - fix ld error message formatting, so that collect2 parser can parse it again for g++ -frepo (#187142) cups-1:1.2-0.2.rc1.4 -------------------- * Fri Mar 31 2006 Tim Waugh 1:1.2-0.2.rc1.4 - Fixed interaction with CUPS 1.1 servers (STR #1528). fetchmail-6.3.3-2 ----------------- * Fri Mar 31 2006 Miloslav Trmac - 6.3.3-2 - Fix some type mismatches on 64-bit architectures - Fix checking for res_* on architectures with newer glibc ABI * Fri Mar 31 2006 Miloslav Trmac - 6.3.3-1 - Update to fetchmail-6.3.3 gnome-screensaver-2.14.0-3 -------------------------- * Thu Mar 30 2006 Ray Strode 2.14.0-3 - refresh kerberos credentials when unlocking screen (bug 187341) kernel-2.6.16-1.2112_FC6 ------------------------ * Fri Mar 31 2006 Dave Jones - 2.6.16-git19 * Fri Mar 31 2006 David Woodhouse - Send standard WEXT events on softmac assoc/disassociation. - OFFB udpate ntp-4.2.0.a.20050816-12 ----------------------- * Fri Mar 31 2006 Miroslav Lichvar - 4.2.0.a.20050816-12 - fix initscript: - replace -U with -u in getopts (#187003) - don't pass group to ntpdate -U argument and ignore -i in options (#142926) - set ntpconf for -c - remove -p 8 from ntpdate arguments - don't call ntpdate when step-tickers doesn't contain anything useful and -x isn't in options - fix default keyfile for ntpdate (#183196) rpm-4.4.2-16 ------------ * Fri Mar 31 2006 Paul Nasrat - 4.4.2-16 - Skipdirs on erase again (#187308) - Make fcntl lock sensitive to --root (#151255) - Fix netshared path comparison (#52725) - Fix rpm vercmp (#178798) scim-1.4.4-11 ------------- * Fri Mar 31 2006 Jens Petersen - 1.4.4-11 - include experimental scim-bridge-0.1.2 by Ryo Dairiki (#185693) - make scim-bridge the default gtkimmodule for now - reenable qtimm module * Fri Mar 31 2006 Jens Petersen - 1.4.4-10 - build without libstdc++so7 for now - turn on scim by default for all locale: add xinput.d/default - drop the redundant module dirs in scim-1.0/ - add Alt-` to list of default hotkeys for Japanese users with us keyboard * Wed Mar 29 2006 Jens Petersen - make scim-libs prereq libstdc++so7 to avoid update-gtk-immodules error when installing on i386 (#186365) - setup xinput.d for some more locale (as_IN, or_IN, si_LK, vi_VN, and zh_HK) scim-anthy-1.0.0-2.fc6 ---------------------- * Fri Mar 31 2006 Jens Petersen - 1.0.0-2 - rebuild without libstdc++so7 scim-chewing-0.2.1-6 -------------------- * Fri Mar 31 2006 Jens Petersen - 0.2.1-6 - rebuild without libstdc++so7 scim-hangul-0.2.2-2.fc6 ----------------------- * Fri Mar 31 2006 Jens Petersen - 0.2.2-2.fc6 - rebuild without libstdc++so7 scim-m17n-0.2.0-3 ----------------- * Fri Mar 31 2006 Jens Petersen - 0.2.0-3 - rebuild without libstdc++so7 scim-pinyin-0.5.91-5 -------------------- * Fri Mar 31 2006 Jens Petersen - 0.5.91-5 - rebuild without libstdc++so7 scim-tables-0.5.6-4 ------------------- * Fri Mar 31 2006 Jens Petersen - 0.5.6-4 - rebuild without libstdc++so7 selinux-policy-2.2.29-1 ----------------------- * Thu Mar 30 2006 Dan Walsh 2.2.29-1 - Update to upstream system-config-securitylevel-1.6.17-1 ------------------------------------ * Fri Mar 31 2006 Chris Lumens 1.6.17-1 - Be smarter about if strings are valid ports (#183964). - Fix typo in firstboot (#186110). - Disable SELinux page if there's no policy installed (#186554). xorg-x11-xdm-1:1.0.3-1 ---------------------- * Fri Mar 31 2006 Adam Jackson 1:1.0.3-1 - Updated to version 1.0.3. Forcibly relibtoolize to avoid present and future bogons on libXdmGreet.so losing the .so extension. * Fri Feb 10 2006 Jesse Keating 1:1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1:1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 kdepim - 6:3.5.1-1.2.i386 requires libpisock.so.9 Broken deps for ia64 ---------------------------------------------------------- kdepim - 6:3.5.1-1.2.ia64 requires libpisock.so.9()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- kdepim - 6:3.5.1-1.2.ppc requires libpisock.so.9 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 kdepim - 6:3.5.1-1.2.ppc64 requires libpisock.so.9()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 kdepim - 6:3.5.1-1.2.x86_64 requires libpisock.so.9()(64bit) From pmatilai at laiskiainen.org Sat Apr 1 08:39:18 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 1 Apr 2006 00:39:18 -0800 (PST) Subject: rawhide report: 20060401 changes In-Reply-To: <200604010823.k318NGLB008336@porkchop.devel.redhat.com> References: <200604010823.k318NGLB008336@porkchop.devel.redhat.com> Message-ID: On Sat, 1 Apr 2006, Build System wrote: > rpm-4.4.2-16 > ------------ > * Fri Mar 31 2006 Paul Nasrat - 4.4.2-16 > - Skipdirs on erase again (#187308) > - Make fcntl lock sensitive to --root (#151255) > - Fix netshared path comparison (#52725) > - Fix rpm vercmp (#178798) This reminds me... can we please get a newer rpm version (4.4.4 or newer) in now that it's just the beginning of the development cycle: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg01713.html - Panu - From andy at warmcat.com Sat Apr 1 08:46:51 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 01 Apr 2006 09:46:51 +0100 Subject: 'Commercial Partners' In-Reply-To: <20060331194359.GB25535@thyrsus.com> References: <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> Message-ID: <442E3DFB.5020502@warmcat.com> Eric S. Raymond wrote: > wants the desktop and what it's prepared to do to get it. It ties > into a larger issue about what the Linux community needs to do to > thrive under competitive pressure, which *is* a question for Fedora. What does "competitive pressure" mean in the context of a Free OS? >> I don't see a single reason to accept your dramatic characterizations as >> accurate. > > Well, I've been right about this sort of thing before, and I've > continued to pay attention. You're living in an industry > significantly shaped by the fact that I got some key market analysis > right and then addressed the implied problem, and a lot of VCs and > CEOs and investment bankers listen *very* respectfully when I talk. > > This doesn't make me infallible, of course, but it does mean betting > that I'm wrong this time is not something to do casually. Well good for you, but it doesn't get you a free ride on your dramatic characterizations of "Death of Linux Unless Y'all Do As I Say". If you spoke of anything to explain the reasoning behind the proposition of Linux dying unless it gets on a large number of desktops quickly on this thread, I missed it. - Why shouldn't a dramatic growth of Linux on the Desktop have the opposite effect of triggering an apocalypse of attacks from MSFT on their various desktop-related patents? - Why will market share defend against that when it didn't help RIM one bit, in fact made matters worse come the damages? - Why is the current frog-boiling method while Linux and the Free apps improve and establish themselves deeper and deeper not good enough? - In your theory, is Linux in the embedded space going to die too because MSFT continue to have ~90% of desktops? -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sat Apr 1 12:33:41 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 01 Apr 2006 18:03:41 +0530 Subject: system-config-boot In-Reply-To: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com> References: <16de708d0603311341v756618e3ne9a4954f34114dfe@mail.gmail.com> Message-ID: <1143894821.3802.780.camel@sundaram.pnq.redhat.com> On Fri, 2006-03-31 at 15:41 -0600, Arthur Pemberton wrote: > I would like to submit for critique, suggests, etc. this program I > have made. It is the first GUI app I've made in Linux, and I would > appreciate some constructive criticism. > > I made this program because system-config-boot as it exists (in FC4 > and FC5Test3 at least) only allows for selecting of a default boot > entry and changing of the timeout. And FC tends to accumulate a large > list of boot entries during its release cycle. Who knows, maybe this > can be included in FC. Then submit that as a patch against the current application and file a RFE. installonlyn plugin already solves this problem without resorting to tweaking. Rahul From sundaram at fedoraproject.org Sat Apr 1 12:40:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 01 Apr 2006 18:10:11 +0530 Subject: Double dare ya, Fedora! And your art sucks! In-Reply-To: <442D6DD8.9070200@gmail.com> References: <20060331151502.GC13677@redhat.com> <20060331154113.9493.qmail@hm196.locaweb.com.br> <442D6DD8.9070200@gmail.com> Message-ID: <1143895211.3802.785.camel@sundaram.pnq.redhat.com> On Fri, 2006-03-31 at 14:58 -0300, Casimiro de Almeida Barreto wrote: > Excuses for all.. > > The current kernel (2.8.16-1.2083_FC6) issues a message that > the processor of my box is overheating, so speed is going > down... That's not true and I sent an e-mail... The answer > was: not enough data, but that was all the data recorded... > BTW, I'm not working in a morgue, but temperatures are around > 20C... Solution? Easy: download kernel source (not available > by default), fix it, recompile it... re-install it. And now I > work without the annoyance of "clock speed throttling down > and" until the computer gets stuck... BTW, if someone cares, > heat sensors get crazy whenever FPU is required like with > setiathome (BOINC). Processor: Pentium 4 @ 2.8GHz (not that > Ferrari). All coolers and fans working properly... > The solution described above is not easy by any means. You have to do it over and over again everytime there is a security fix. Try filing a bug report and providing as much information as you can. Developers need to be able to reproduce or atleast make an educated guess on what the problem is before attempting to fix it. > NVIDIA is a "recurrent" issue... and official position is that > people don't need NVIDA official drivers... There is no such official position. Rahul From fedora-devel at stefan-neufeind.de Sat Apr 1 13:12:25 2006 From: fedora-devel at stefan-neufeind.de (Stefan Neufeind) Date: Sat, 01 Apr 2006 15:12:25 +0200 Subject: Making /etc/localtime a symlink? Message-ID: <442E7C39.7000503@stefan-neufeind.de> Hi, I was wondering if, instead of currently making /etc/localtime a copy of the timezone to use, it would be a good idea to actually make it a symlink. In the (unlikely) event that information for a timezone would chance, updates would take effect automatically. initial /etc/localtime: part of glibc e.g. /usr/share/zoneinfo/Europe/Berlin: part of tzdata So imho this would involve bundling /etc/localtime as a symlink in glibc, a dep to tzdata (there is a dep from glibc-common to tzdata) and adjusting installer etc. to not make copies but create symlinks. What do others think? Regards, Stefan From jos at xos.nl Sat Apr 1 13:25:29 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 1 Apr 2006 15:25:29 +0200 Subject: Making /etc/localtime a symlink? In-Reply-To: <442E7C39.7000503@stefan-neufeind.de>; from fedora-devel@stefan-neufeind.de on Sat, Apr 01, 2006 at 03:12:25PM +0200 References: <442E7C39.7000503@stefan-neufeind.de> Message-ID: <20060401152529.A21382@xos037.xos.nl> On Sat, Apr 01, 2006 at 03:12:25PM +0200, Stefan Neufeind wrote: > So imho this would involve bundling /etc/localtime as a symlink in > glibc, a dep to tzdata (there is a dep from glibc-common to tzdata) and > adjusting installer etc. to not make copies but create symlinks. In the past it was a symlink, IIRC (RHL 7/8 or even older). But /usr may not be mounted, maybe that's the reason for a real file. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Lam at Lam.pl Sat Apr 1 13:28:47 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 01 Apr 2006 15:28:47 +0200 Subject: Making /etc/localtime a symlink? In-Reply-To: <442E7C39.7000503@stefan-neufeind.de> References: <442E7C39.7000503@stefan-neufeind.de> Message-ID: <1143898127.5089.3.camel@pensja.lam.pl> Dnia 01-04-2006, sob o godzinie 15:12 +0200, Stefan Neufeind napisa?(a): > What do others think? I think /usr/share/zoneinfo may be on another device and may not be mounted when /etc/localtime is accessed. The whole point of /usr is being the separate "user disk" from the early days of UNIX. If some program from outside of /usr (e. g. /bin/ls) needs any data, this data must not reside inside of /usr. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From seandarcy2 at gmail.com Sat Apr 1 13:40:11 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 01 Apr 2006 08:40:11 -0500 Subject: rawhide->fc5; X won't start In-Reply-To: References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> Message-ID: sean wrote: > Ray Strode wrote: >> Hi, >> >>> Ray Strode wrote: >>>> Hi, >>>>> OK, so no one else sees this. >>>>> >>>>> Any suggestions as to how to diagnose this? Any way to get more >>>>> verbose or clearer error messages? >>>> If you run fc-cache -f from your user account does your problem go >>>> away? >>>> >>>> --Ray >>>> >>> Thanks for the suggestion, but...(: >>> >>> Here's the console message from trying kde. >>> >>>> (==) Using config file: "/etc/X11/xorg.conf" >>>> xset: bad font path element (#76), possible causes are: >>>> Directory does not exist or has wrong permissions >>>> Directory missing fonts.dir >>>> Incorrect font server address or syntax >>>> startkde: Starting up... >>>> DCOP aborting call from 'anonymous-2482' to 'kded' >>>> startkde: Shutting down... >>>> klauncher: Exiting on signal 1 >>>> >> What if you manually add some font paths to your Xorg.conf >> Try adding some of the ones in /usr/share/X11/fonts/ >> and /usr/share/fonts >> >> --Ray >> > > Great idea, but no joy. > > Same result. > > I changed xorg.conf to: > >> Section "Files" >> >> # >> # FontPath "unix/:7100" >> FontPath "/usr/share/X11/fonts/misc:unscaled" FontPath >> "/usr/share/X11/fonts/75dpi:unscaled" >> FontPath "/usr/share/X11/fonts/100dpi:unscaled" >> EndSection > > And, FWIW, >> find /usr/share/X11/fonts -name fonts.dir >> /usr/share/X11/fonts/misc/fonts.dir >> /usr/share/X11/fonts/75dpi/fonts.dir >> /usr/share/X11/fonts/100dpi/fonts.dir >> /usr/share/X11/fonts/TTF/fonts.dir >> /usr/share/X11/fonts/Type1/fonts.dir > > Xorg.0.log shows no errors. > > This is really frustrating. I no longer believe this a font issue. But I > can't figure out how to get some log and error messages that show what's > happening. > > sean > I installed xfce to see if it was a gnome/kde problem. Here's what shows on the xfce console: > (==) Using config file: "/etc/X11/xorg.conf" > > /usr/bin/startxfce4: X server already running on display :0 > Agent pid 4100 > which: no xfce4-session in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/NX/bin:/root/bin) > > (xfce-mcs-manager:4103): libxfce4mcs-CRITICAL **: mcs_manager_add_channel_from_file: assertion `filename != NULL && strlen (filename) > 0' failed > /etc/xdg/xfce4/xinitrc: line 106: 4105 Segmentation fault xfwm4 --daemon > ** Message: Cannot connect to session manager > /etc/xdg/xfce4/xinitrc: line 123: 4108 Segmentation fault xfcalendar > /etc/xdg/xfce4/xinitrc: line 123: 4110 Segmentation fault $panel So X appears to start - Fedora logo comes up; no error on Xorg.0.log. But no gui's will start - not gnome,kde or xfce. Does this mean X isn't starting correctly so that the gui's can start? If not, what happens between X coming up and the gui's starting? metacity? Is there any way to cause metacity to do verbose logging? Again, is there any way to get more verbose and clearer logs. Or any other hints? sean From kevin-redhat-devel at scrye.com Sat Apr 1 17:40:56 2006 From: kevin-redhat-devel at scrye.com (Kevin Fenzi) Date: Sat, 01 Apr 2006 10:40:56 -0700 (MST) Subject: rawhide->fc5; X won't start References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> Message-ID: <20060401.104056.705159298.kevin@scrye.com> >>>>> "sean" == sean writes: sean> I installed xfce to see if it was a gnome/kde problem. Here's sean> what shows on the xfce console: >> (==) Using config file: "/etc/X11/xorg.conf" /usr/bin/startxfce4: X >> server already running on display :0 Agent pid 4100 which: no >> xfce4-session in >> (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/NX/bin:/root/bin) >> (xfce-mcs-manager:4103): libxfce4mcs-CRITICAL **: >> mcs_manager_add_channel_from_file: assertion `filename != NULL && >> strlen (filename) > 0' failed /etc/xdg/xfce4/xinitrc: line 106: >> 4105 Segmentation fault xfwm4 --daemon ** Message: Cannot connect >> to session manager /etc/xdg/xfce4/xinitrc: line 123: 4108 >> Segmentation fault xfcalendar /etc/xdg/xfce4/xinitrc: line 123: >> 4110 Segmentation fault $panel sean> So X appears to start - Fedora logo comes up; no error on sean> Xorg.0.log. sean> But no gui's will start - not gnome,kde or xfce. Does this mean sean> X isn't starting correctly so that the gui's can start? If not, sean> what happens between X coming up and the gui's starting? sean> metacity? Is there any way to cause metacity to do verbose sean> logging? sean> Again, is there any way to get more verbose and clearer logs. sean> Or any other hints? Well, not sure on gnome or KDE, but the above Xfce output looks like the problem is the Seg faults when trying to start up. :( Several other things to try: - If you create a new fresh user, can they login ok? (This would point to it being you users gtk theme, fonts setup or the like). - Could be some package leftover from your rawhide install causing issues, perhaps a 'yum list extras' to identify any packages that are not in repositories you have currently enabled? - Could you try and run xfwm4 under a debugger? 0) yum --enable-repo=core-debuginfo install xfwm4-debuginfo 1) Run X from a console, "xinit /usr/X11R6/bin/xterm &" 2) Switch to a console (Ctrl+Alt+F1) 3) Set the display "export DISPLAY=:0.0" 4) run "gdb /usr/bin/xfwm4" 5) if/when it crashes, run 'bt' and send me the backtrace. sean> sean sean> -- fedora-devel-list mailing list fedora-devel-list at redhat.com sean> https://www.redhat.com/mailman/listinfo/fedora-devel-list kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jspaleta at gmail.com Sat Apr 1 20:31:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 1 Apr 2006 15:31:10 -0500 Subject: rawhide->fc5; X won't start In-Reply-To: References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> Message-ID: <604aa7910604011231v18bbbd59g9fd43fdc06296e20@mail.gmail.com> On 4/1/06, sean wrote: > So X appears to start - Fedora logo comes up; no error on Xorg.0.log. > > But no gui's will start - not gnome,kde or xfce. Does this mean X isn't > starting correctly so that the gui's can start? If not, what happens > between X coming up and the gui's starting? Look in the xsession error files. Which should be in /tmp with filenames like xses-username.randomstring There may be noise in there that from applications that is unrealted with your current problem so don't freak out if you see gobs of error outputs in that file. -jef From rnicholsNOSPAM at comcast.net Sat Apr 1 21:22:35 2006 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Sat, 01 Apr 2006 15:22:35 -0600 Subject: Making /etc/localtime a symlink? In-Reply-To: <442E7C39.7000503@stefan-neufeind.de> References: <442E7C39.7000503@stefan-neufeind.de> Message-ID: Stefan Neufeind wrote: > Hi, > > I was wondering if, instead of currently making /etc/localtime a copy of > the timezone to use, it would be a good idea to actually make it a > symlink. In the (unlikely) event that information for a timezone would > chance, updates would take effect automatically. > > initial /etc/localtime: part of glibc > e.g. /usr/share/zoneinfo/Europe/Berlin: part of tzdata > > So imho this would involve bundling /etc/localtime as a symlink in > glibc, a dep to tzdata (there is a dep from glibc-common to tzdata) and > adjusting installer etc. to not make copies but create symlinks. > > What do others think? It means that the system's notion of time and date will be incorrect until /usr is mounted. The amount of confusion caused depends on how big your TZ's offset is from UTC and whether your hardware clock keeps local time or UTC. Usually it's just timestamps of bootup entries in the log files that are affected, but if you boot in emergency mode and try to patch up something that's wrong on your system, then you can get some bad timestamps there as well. Messages from tar like, "file in archive has timestamp in the future" are a common symptom. -- Bob Nichols Yes, "NOSPAM" is really part of my email address. From paul at permanentmail.com Sat Apr 1 23:07:59 2006 From: paul at permanentmail.com (Paul Dickson) Date: Sat, 1 Apr 2006 16:07:59 -0700 Subject: Why no development mirrors? In-Reply-To: <1143866618.22082.15.camel@cutter> References: <20060331211604.6c6c5c8a.paul@permanentmail.com> <1143866618.22082.15.camel@cutter> Message-ID: <20060401160759.b77ccde9.paul@permanentmail.com> On Fri, 31 Mar 2006 23:43:38 -0500, seth vidal wrote: > On Fri, 2006-03-31 at 21:16 -0700, Paul Dickson wrote: > > /etc/yum.repos.d/fedora-development.repo gives: > > > > [development] > > name=Fedora Core - Development > > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > > enabled=1 > > > > Yet a "curl http://fedora.redhat.com/download/mirrors/fedora-core-rawhide" only > > provides: > > > > http://download.fedoraproject.org/pub/fedora/linux/core/development/$ARCH/ > > > > Are there no other mirrors? > > > > it uses an apache rewrite to redirect you to a different mirror each > time. Great. There is no longer any error recovery if a mirror doesn't have have an rpm. I had to run yum eight times before it could sucessfully download everything and begin installing/updating. -Paul From skvidal at linux.duke.edu Sat Apr 1 23:17:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 01 Apr 2006 18:17:43 -0500 Subject: Why no development mirrors? In-Reply-To: <20060401160759.b77ccde9.paul@permanentmail.com> References: <20060331211604.6c6c5c8a.paul@permanentmail.com> <1143866618.22082.15.camel@cutter> <20060401160759.b77ccde9.paul@permanentmail.com> Message-ID: <1143933463.22082.19.camel@cutter> > Great. There is no longer any error recovery if a mirror doesn't have > have an rpm. I had to run yum eight times before it could sucessfully > download everything and begin installing/updating. we know and it is being worked on. :) -sv From seg at haxxed.com Sun Apr 2 02:34:50 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Apr 2006 20:34:50 -0600 Subject: Fedora's way forward In-Reply-To: <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <442AE298.9090300@knox.net.nz> <442AE4DF.700@hhs.nl> <20060330213538.GC14444@thyrsus.com> <442C59A9.1010507@hhs.nl> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> Message-ID: <1143945291.10632.75.camel@localhost> Only two things are needed: 1) A way to install RPMs from a web browser. (It seems we have this) 2) A way to tell pirut to install packages from a web browser. With these two things, a repo like Livna could easily make a page with links like "Click here first to set up the Livna repository on your system", and then a list of links like "Click here to install mp3 support" "Click here to install closed-source nVidia 3D support." "Click here to play DVDs". All you need is some kind of simple meta format, like the common WinAmp .pls format, that tells pirut to install xorg-x11-drv-nvidia and kmod-nvidia and whatnot. And perhaps include an ability to set a "--enablerepo=livna" flag too, so if you don't have the livna repo installed pirut can maybe give you some sane error like "Could not find packages xxxx yyy, perhaps you should install the zzz repository." Then when someone gets on IRC and asks for nVidia support or MP3, you can just point them at a URL that will tell them everything. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 02:44:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Apr 2006 20:44:06 -0600 Subject: Split-off package config from release note packages In-Reply-To: <20060401001840.GF5242@neu.nirvana> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com> <200603311803.19043.nman64@n-man.com> <20060401001840.GF5242@neu.nirvana> Message-ID: <1143945847.10632.79.camel@localhost> On Sat, 2006-04-01 at 02:18 +0200, Axel Thimm wrote: > My personal view: ATrpms is trying to add value to fedora (and RHEL), > and I wonder why there have to be so many alienations towards > ATrpms. People of the fedora community complain about market loss to > Ubuntu due to non-coherent community of fedora and semi-official > statements like the one in the wiki just divide the fedora community > further. Stop replacing core packages. That's all you have to to. If you have a problem with a core package, file a bug report. Don't replace it. And move what you can into Extras. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From naheemzaffar at gmail.com Sun Apr 2 02:45:19 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 2 Apr 2006 03:45:19 +0100 Subject: Fedora's way forward In-Reply-To: <1143945291.10632.75.camel@localhost> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <442C59A9.1010507@hhs.nl> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> Message-ID: <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> and that could be very very dangerous... a single web browser flaw could open up the full system to attack... ...Imagine visiting a page that installs a repository, and then subsequently replaces core packages with compromised ones? (there are a couple of security hurdles such as root password... but never rely on the user to easily make the corrent judgement...) All that should be needed is for a way to get pirut to get a repo file (disabled by default... and clear to the user with a message: 'repo foo added. go to repo's to activate') and then after that, the normal package install method (commandline/pirut/yumex/other) to actually install the files. Its not too far off the current method though... as current the repo files are distributed in rpm files. pirut installs the rpm file which adds the repo. then the normal method is used to add files... so not too much to do really... -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Sun Apr 2 02:58:42 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Apr 2006 20:58:42 -0600 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> Message-ID: <1143946723.10632.82.camel@localhost> On Tue, 2006-03-28 at 14:43 -0800, Shane Stixrud wrote: > Please don't imply I give one wit if elektra is the correct solution or > not, because I don't. My only interest is in discovering why this problem > hasn't already been solved and if anyone has a clue as to what the correct > solution would look like. I'm still not convinced that there's a problem in need of solving here. (XML is like violence, if it doesn't help, use more) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun Apr 2 02:52:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 02 Apr 2006 08:22:48 +0530 Subject: Fedora's way forward In-Reply-To: <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <442C59A9.1010507@hhs.nl> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> Message-ID: <1143946368.3783.47.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-02 at 03:45 +0100, Naheem Zaffar wrote: > and that could be very very dangerous... a single web browser flaw > could open up the full system to attack... How? > > ...Imagine visiting a page that installs a repository, and then > subsequently replaces core packages with compromised ones? The browser automatically installing packages just because you visited the page. You will have confirm to something and supply the root password and there is GPG keys to verify the source and there is SELinux to confine the amount of permissions that a browser has. > (there are a couple of security hurdles such as root password... but > never rely on the user to easily make the corrent judgement...) Making it harder to install packages is security through obscurity. In the near future, we are looking at a design for a system to get the least amount of permissions possible and automatically get and drop privileges Network Manager style. http://searchopensource.techtarget.com/tip/1,289483,sid39_gci1173575,00.html http://www.osnews.com/story.php?news_id=13904 Rahul From jspaleta at gmail.com Sun Apr 2 02:58:39 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 1 Apr 2006 21:58:39 -0500 Subject: Fedora's way forward In-Reply-To: <1143946368.3783.47.camel@sundaram.pnq.redhat.com> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> <1143946368.3783.47.camel@sundaram.pnq.redhat.com> Message-ID: <604aa7910604011858p1a89676bg77dcc64d892d52c1@mail.gmail.com> On 4/1/06, Rahul Sundaram wrote: > The browser automatically installing packages just because you visited > the page. You will have confirm to something and supply the root > password and there is GPG keys to verify the source and there is SELinux > to confine the amount of permissions that a browser has. Uhm... i think the nature of package installation pretty much requires a very very loose selinux policy associated with it because the rpm process which must be spawned software could concievable modifiy pretty much any system file as part of a perfect valid package install/update. -jef From sundaram at fedoraproject.org Sun Apr 2 03:02:40 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 02 Apr 2006 08:32:40 +0530 Subject: Fedora's way forward In-Reply-To: <604aa7910604011858p1a89676bg77dcc64d892d52c1@mail.gmail.com> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> <1143946368.3783.47.camel@sundaram.pnq.redhat.com> <604aa7910604011858p1a89676bg77dcc64d892d52c1@mail.gmail.com> Message-ID: <1143946960.3783.50.camel@sundaram.pnq.redhat.com> On Sat, 2006-04-01 at 21:58 -0500, Jeff Spaleta wrote: > On 4/1/06, Rahul Sundaram wrote: > > The browser automatically installing packages just because you visited > > the page. You will have confirm to something and supply the root > > password and there is GPG keys to verify the source and there is SELinux > > to confine the amount of permissions that a browser has. > > Uhm... i think the nature of package installation pretty much requires > a very very loose selinux policy associated with it because the rpm > process which must be spawned software could concievable modifiy > pretty much any system file as part of a perfect valid package > install/update. As I understand it what the OP claimed was that a exploited browser would automatically be able to install packages silently which is something SELinux should be able to prevent with appropriate policies in place. Making it easier for users to install packages is not a security issue at all as long as the privileges required to complete the operation doesnt change arbitrarily. Rahul From shane at geeklords.org Sun Apr 2 03:29:24 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sat, 1 Apr 2006 19:29:24 -0800 (PST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143946723.10632.82.camel@localhost> References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> Message-ID: On Sat, 1 Apr 2006, Callum Lerwick wrote: > On Tue, 2006-03-28 at 14:43 -0800, Shane Stixrud wrote: >> Please don't imply I give one wit if elektra is the correct solution or >> not, because I don't. My only interest is in discovering why this problem >> hasn't already been solved and if anyone has a clue as to what the correct >> solution would look like. > > I'm still not convinced that there's a problem in need of solving here. What would it take to convince you? The limitations around automating/scripting system changes without replacing whole config files is one problem. How about the differing syntax between most applications without a technical need, some of which have horrid syntax. The impracticality of programs sharing configuration elements with each other without each application being aware of every other applications magic syntax. The impossibility of having an automated system for saving and reverting changes without saving whole config files after every change and then figuring out what changed and why. Or how about the fact developing configuration guis/tools is many orders of magnitude more difficult when their is no consistent config file standard? Shane. From kevinverma at gmail.com Sun Apr 2 05:14:54 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 2 Apr 2006 10:44:54 +0530 Subject: Should'nt Yum report no space left on device ? Message-ID: I have just been installing few of the RPMs using yum to my already installed FC5 system, while that /usr went hundred 100% of which I was unware about. I've been running yumex and then yum again to ensure what is going wrong at that and why I don't have the packages installed finally. Till the time I made out that disk is full, yum would download the packages, will show the install progress completing as normal, but in the end none of the subjected packages have any trace on the system or even rpmdb. Some one will like to test the same and file a report on bugzilla or else I'll try to do it at my ease (I am traveling) {yum-2.6.0-1} Cheers, Kevin From esr at thyrsus.com Sun Apr 2 05:36:47 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Apr 2006 00:36:47 -0500 Subject: Fedora's way forward In-Reply-To: <1143945291.10632.75.camel@localhost> References: <20060330213538.GC14444@thyrsus.com> <442C59A9.1010507@hhs.nl> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> Message-ID: <20060402053647.GB6796@thyrsus.com> Callum Lerwick : > Only two things are needed: > > 1) A way to install RPMs from a web browser. (It seems we have this) > > 2) A way to tell pirut to install packages from a web browser. > > With these two things, a repo like Livna could easily make a page with > links like "Click here first to set up the Livna repository on your > system", and then a list of links like "Click here to install mp3 > support" "Click here to install closed-source nVidia 3D support." "Click > here to play DVDs". > > All you need is some kind of simple meta format, like the common > WinAmp .pls format, that tells pirut to install xorg-x11-drv-nvidia and > kmod-nvidia and whatnot. And perhaps include an ability to set a > "--enablerepo=livna" flag too, so if you don't have the livna repo > installed pirut can maybe give you some sane error like "Could not find > packages xxxx yyy, perhaps you should install the zzz repository." > > Then when someone gets on IRC and asks for nVidia support or MP3, you > can just point them at a URL that will tell them everything. This is the right direction to be thinking. Go, go, go! -- Eric S. Raymond From esr at thyrsus.com Sun Apr 2 05:38:54 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Apr 2006 00:38:54 -0500 Subject: Fedora's way forward In-Reply-To: <1143868435.17044.39.camel@gilboa-home-dev.localhost> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <20060329063345.GB6131@thyrsus.com> <1143657279.25616.11.camel@daxter.boston.redhat.com> <20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2> <20060331173633.GC24571@thyrsus.com> <6899-SnapperMsg827D11E1C053B4B0@[68.27.238.145]> <1143868435.17044.39.camel@gilboa-home-dev.localhost> Message-ID: <20060402053854.GC6796@thyrsus.com> Gilboa Davara : > If a user can't be bothered to read a FAQ, google for help, or, heaven > forbids, learn how to configure pirut/yum/rpm, he shouldn't be using > Fedora (or Linux). That's a horrible, elitist attitude thast will lose us the market-share war. -- Eric S. Raymond From esr at thyrsus.com Sun Apr 2 05:48:28 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 2 Apr 2006 00:48:28 -0500 Subject: 'Commercial Partners' In-Reply-To: <442E3DFB.5020502@warmcat.com> References: <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> Message-ID: <20060402054828.GD6796@thyrsus.com> Andy Green : > >wants the desktop and what it's prepared to do to get it. It ties > >into a larger issue about what the Linux community needs to do to > >thrive under competitive pressure, which *is* a question for Fedora. > > What does "competitive pressure" mean in the context of a Free OS? Competitive pressure for market share from Windows and MacOS, of course. > >This doesn't make me infallible, of course, but it does mean betting > >that I'm wrong this time is not something to do casually. > > Well good for you, but it doesn't get you a free ride on your dramatic > characterizations of "Death of Linux Unless Y'all Do As I Say". If you > spoke of anything to explain the reasoning behind the proposition of > Linux dying unless it gets on a large number of desktops quickly on this > thread, I missed it. I think I explained this in some datail earlier. We need market power in order to stave off a future where we get DRMed and EULAed to death because hardware manufacturers figure all they have to do is serve the Windows & Intel Mac markets. Down that road lie video cards we can't use and on-the-mobo TPM to lock us out. > - Why shouldn't a dramatic growth of Linux on the Desktop have the > opposite effect of triggering an apocalypse of attacks from MSFT on > their various desktop-related patents? That will happen once we do *anything* to piss off Microsoft enough, whether it's the fast-growth scenario I want to see or the boil-the-frog- slowly scenario you think is good enough. So it's kind of a wash. > - Why is the current frog-boiling method while Linux and the Free apps > improve and establish themselves deeper and deeper not good enough? Because it's not getting us any desktop penetration to speak of. > - In your theory, is Linux in the embedded space going to die too > because MSFT continue to have ~90% of desktops? No, but lots of Linux in the embedded space doesn't solve our problem either. Puts no pressure on the video-card makers, for one thing. -- Eric S. Raymond From dragoran at feuerpokemon.de Sun Apr 2 06:28:27 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 02 Apr 2006 08:28:27 +0200 Subject: yum + mulitarch + updates Message-ID: <442F6F0B.2040706@feuerpokemon.de> I have noticed that when I have package foo-1.0.i386 installed and some other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the i386 one. (livna mplayerplug-in was it here). Updates should not be crossarch a i386 package should only be updated to a i386 one (same for x86_64). Any reason for doing this? Or is this a bug thats needs to be filled? From nmiell at comcast.net Sun Apr 2 07:10:01 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 01 Apr 2006 23:10:01 -0800 Subject: yum + mulitarch + updates In-Reply-To: <442F6F0B.2040706@feuerpokemon.de> References: <442F6F0B.2040706@feuerpokemon.de> Message-ID: <1143961801.2352.3.camel@entropy> On Sun, 2006-04-02 at 08:28 +0200, dragoran wrote: > I have noticed that when I have package foo-1.0.i386 installed and some > other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the > i386 one. > (livna mplayerplug-in was it here). > Updates should not be crossarch a i386 package should only be updated to > a i386 one (same for x86_64). > Any reason for doing this? Or is this a bug thats needs to be filled? > And when OpenOffice finally gets a working AMD64 version, I fully expect the AMD64 packages to replace the i386 packages when I do a yum update. Packaging is hard; let's go shopping! -- Nicholas Miell From dragoran at feuerpokemon.de Sun Apr 2 07:13:24 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 02 Apr 2006 09:13:24 +0200 Subject: yum + mulitarch + updates In-Reply-To: <1143961801.2352.3.camel@entropy> References: <442F6F0B.2040706@feuerpokemon.de> <1143961801.2352.3.camel@entropy> Message-ID: <442F7994.1060004@feuerpokemon.de> Nicholas Miell wrote: > On Sun, 2006-04-02 at 08:28 +0200, dragoran wrote: > >> I have noticed that when I have package foo-1.0.i386 installed and some >> other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the >> i386 one. >> (livna mplayerplug-in was it here). >> Updates should not be crossarch a i386 package should only be updated to >> a i386 one (same for x86_64). >> Any reason for doing this? Or is this a bug thats needs to be filled? >> >> > > And when OpenOffice finally gets a working AMD64 version, I fully expect > the AMD64 packages to replace the i386 packages when I do a yum update. > > Packaging is hard; let's go shopping! > > thats a special case... but updating crossarch without even tell the user may break working setups very easy From n0dalus+redhat at gmail.com Sun Apr 2 07:14:43 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 2 Apr 2006 17:44:43 +1030 Subject: Fedora's way forward In-Reply-To: <20060402053854.GC6796@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <20060329063345.GB6131@thyrsus.com> <1143657279.25616.11.camel@daxter.boston.redhat.com> <20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2> <20060331173633.GC24571@thyrsus.com> <6899-SnapperMsg827D11E1C053B4B0@68.27.238.145> <1143868435.17044.39.camel@gilboa-home-dev.localhost> <20060402053854.GC6796@thyrsus.com> Message-ID: <6280325c0604012314s27873c34he1ca85943fe6c659@mail.gmail.com> On 4/2/06, Eric S. Raymond wrote: > Gilboa Davara : > > If a user can't be bothered to read a FAQ, google for help, or, heaven > > forbids, learn how to configure pirut/yum/rpm, he shouldn't be using > > Fedora (or Linux). > > That's a horrible, elitist attitude thast will lose us the market-share war. If Linux is going to win any perceived market share war, it won't be because it has mp3 support. It will be because it reaches a critical mass after which exponential growth is easy. Windows will still probably have the majority of the market share once the mp3 patents expire, and once we have reverse engineered all the 3d drivers, etc. If you think Linux can take over Microsoft in a shorter time frame than that you are delusional. In this "war" we actually have a better position. That is, to maintain the low market share we already have is much easier than it is for Microsoft to maintain its huge market share it has. If we don't provide mp3 support today in Fedora, the market share linux holds is not going to fall like a stone -- it will stay the same. Lets just concentrate on making a fundamentally better operating system, and the rest will fall into place. We don't need to go against our morals, ethics and project goals (supporting mp3 in Fedora) in order to achieve this. If you feel like continuing this discussion, please do it off the list, as I'm sure everyone is very tired of it. n0dalus. From vonbrand at inf.utfsm.cl Sun Apr 2 06:39:59 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 02 Apr 2006 02:39:59 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Fri, 31 Mar 2006 13:30:12 -0300." Message-ID: <200604020640.k326dxO8020766@pincoya.inf.utfsm.cl> Avi Alkalay wrote: > Bill Crawford wrote: > > Dunno where you got this obsession, but just because you can represent > > data as "key/value pairs" doesn't mean that's always the best layout. > Maybe not for your or my eyes. The best layout is the one accessible > by the broadest range of ways. Currently, human-readable files are > accessible by human-beings only, or by configuration file "compilers", > that are difficult, unique, that nobody wants to write or maintain > except for the original software writer (e.g. the Samba developer with > the smb.conf file). That they do anyway (hell, it is the /only/ way to get the configuration for the application!) there must be some reason... [...] > > There's a reason why programs aren't written for the old Turing > > Machine, and that's that however well it might be able to represent any > > possible program, it's incredibly verbose. > The only reason I can see is historical. As they asy around here, there is no worse blind than the one who doesn't want to see... > Since there is now projects > integration efforts in the OSS world, everybody uses its own format. Non sequitur. > So you may think there is a reason, lost in time, but there is > actually no reason why BIND named.conf file look that way, ... which is /totally/ different from the format used not that far back... > which is > different from /etc/passwd, ... which has to describe /completely/ different sorts of things... > which is different from smb.conf, ... which is yet different... > which is > different from httpd.conf. ... and again something else completely. > Well, the real reason I can see is selfish > developers that enjoy rewriting config file parsing code and invent > configuration file layouts that seems best suited for their apps. Sure, there are wheel-reinventation-worshippers around, but it is not as bad as you paint it. > But > when you strip the syntax fat, they all are not more than key and > value pairs on a hierarchy. Really? Or ist it just that everything can be described that way (even if that is not at all convenient, just as Turing machines aren't nice to program)? > So to make the discussion productive, please enlighten us with the > reasons you think exists somewhere, or please don't speculate. Please do show you do understand the differences between configurations syntaxes, and how to overcome them, before you expect us to believe you are on to something useful... > > The examples which have appeared in this thread have all made things *less* > > clear afaics. > Again, maybe for our human eyes, but are 100% clear for software. System administrators aren't software. 99% of the problem is understanding /what/ you want to do, and /how/ to do it with very complex tools subject to all class of non-intuitive environmental conditions. Finding out how to read and write the configuration files is usually trivial in comparison. Making complex stuff driven by nice "simplified for normal user" GUIs doesn't make it simple, it just makes it look simple (and the ensuing breakage isn't nice to contemplate). > And > the end-goal is leverage better software integration between > themselves, so we, human-beings, will have to look at configuration > element everyday less. This has been the holy grail of system administration from day one. Doesn't look that much closer today, as the job is getting every day more complex while the tools desperately play catch-up. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Sat Apr 1 02:18:02 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 31 Mar 2006 22:18:02 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Tue, 28 Mar 2006 19:58:28 PST." Message-ID: <200604010218.k312I25K006297@pincoya.inf.utfsm.cl> Shane Stixrud wrote: > On Wed, 29 Mar 2006, Bill Crawford wrote: [...] > > Ah. The "it must all be integrated" straw man. (sigh) > There is no straw man, real advantages and features become available > when configuration data is unified. If you mean "single format", I might agree (but that is /much/ harder than it looks, the needs range from a handful of variables to complex structured "programs" in specialized languages). If you also mean "single repository", you are way off the deep end (Hint: Single point of failure, no way to handle alternative configurations, no way to chroot the config, ...) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From gmaxwell at gmail.com Sun Apr 2 08:35:17 2006 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 2 Apr 2006 04:35:17 -0400 Subject: 'Commercial Partners' In-Reply-To: <20060402054828.GD6796@thyrsus.com> References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> Message-ID: On 4/2/06, Eric S. Raymond wrote: [snip] > I think I explained this in some datail earlier. We need market power > in order to stave off a future where we get DRMed and EULAed to death > because hardware manufacturers figure all they have to do is serve the > Windows & Intel Mac markets. Down that road lie video cards we can't > use and on-the-mobo TPM to lock us out. [snip] So what you are saying is that we need to endorse and distribute (potentially illegally) technologies which reduce the users freedom (by being obviously patent encumbered or otherwise proprietary) in order to protect ourselves from technologies which reduce the users freedom and which we could only use illegally? Something just doesn't feel right about that argument. There are already excellent open and free alternatives for the encumbered formats, but they need wider support. Content houses don't feel the need to support them because they aren't available out of the box on mainstream desktop OSes, and because the production tools on those OSes are rather rough around the corners. This is not an insurmountable problem. It wasn't that long ago that the mainstream desktop OSes didn't come with any usable players and codecs... and it's still the case that a large amount of content is still distributed formats which require some form of download by the user... and you're telling me that 'Linux' is in peril because Fedora is taking legally safe, a freedom conscious path of avoiding encumbered software? Oh please! If half the effort that goes into whining about this were put into educating users, improving the tools for open formats on mainstream desktop platforms (i.e. http://www.flumotion.net/cortado/, http://ffdshow.sourceforge.net/tikiwiki/tiki-view_articles.php), and advocacy with content providers (for example, why the #@$ is archive.org not offering Theora as a option on all content?), then we'd be a lot closer to a real solution. If you think you can help out Linux by offering a distro laden with encumbered software, then by all means.. we've given you the freedom to do so. But please realize that just because someone else doesn't agree with your give-up-freedom-to-protect-ourselves argument, it doesn't mean that they are wrong. From shane at geeklords.org Sun Apr 2 08:55:59 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 00:55:59 -0800 (PST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <200604010218.k312I25K006297@pincoya.inf.utfsm.cl> References: <200604010218.k312I25K006297@pincoya.inf.utfsm.cl> Message-ID: On Fri, 31 Mar 2006, Horst von Brand wrote: > Shane Stixrud wrote: >> On Wed, 29 Mar 2006, Bill Crawford wrote: > > [...] > >>> Ah. The "it must all be integrated" straw man. (sigh) > >> There is no straw man, real advantages and features become available >> when configuration data is unified. > > If you mean "single format", I might agree (but that is /much/ harder than > it looks, the needs range from a handful of variables to complex structured > "programs" in specialized languages). If you also mean "single repository", > you are way off the deep end (Hint: Single point of failure, no way to > handle alternative configurations, no way to chroot the config, ...) By unified I mean all configuration syntax is predictable, hierarchical and standardized. I also mean multi-repository i.e. Elektra like filesys, dbm etc... My preferred "repository" would be an on-disk hierarchical directory/file structure (filesys) where each application/subsystem has a its own root directory and optional sub-directories. Read the rest of this thread and you will see all of your concerns have already been addressed i.e. chroot, alternate configs. Cheers, Shane From seg at haxxed.com Sun Apr 2 09:04:14 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 04:04:14 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <200603290444.20942.billcrawford1970@googlemail.com> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> Message-ID: <1143968655.10632.87.camel@localhost> On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote: > Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic > ideas are similar, the directory structure allowing split files is a big > improvement over the single .conf file). Apache, squid, Xorg, gdm. > Bad: almost anything using .ini ;) *please note the ALMOST* if the data set > basically only has one or two dimensions, .ini will work fine. It will limit > you in the future, maybe. fontconfig. Bind. Sendmail. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 09:11:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 04:11:06 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> Message-ID: <1143969066.10632.93.camel@localhost> On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote: > What would it take to convince you? > > The limitations around automating/scripting system changes without > replacing whole config files is one problem. How about the differing > syntax between most applications without a technical need, some of which > have horrid syntax. The impracticality of programs sharing configuration > elements with each other without each application being aware of every > other applications magic syntax. The impossibility of having an automated > system for saving and reverting changes without saving whole config files > after every change and then figuring out what changed and why. Or how > about the fact developing configuration guis/tools is many orders of > magnitude more difficult when their is no consistent config file standard? Look at Debian if you want to see how config files should be handled. Judicious use of conf.d type directories goes a long way. Fedora's own /etc/sysconfig hierarchy is a good example of how config files can be brain dead simple, hand editable and GUI configurable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 09:23:57 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 04:23:57 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <200603301650.10065.billcrawford1970@googlemail.com> References: <1143597074.3608.44.camel@currant.watzmann.net> <200603301650.10065.billcrawford1970@googlemail.com> Message-ID: <1143969838.10632.95.camel@localhost> On Thu, 2006-03-30 at 16:50 +0100, Bill Crawford wrote: > Bill"somewhat sick of this thread but suspecting if people don't reply the > lunatics will end up running the asylum"Crawford. +1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From shane at geeklords.org Sun Apr 2 09:21:02 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 01:21:02 -0800 (PST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143969066.10632.93.camel@localhost> References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143969066.10632.93.camel@localhost> Message-ID: On Sun, 2 Apr 2006, Callum Lerwick wrote: > On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote: >> What would it take to convince you? >> >> The limitations around automating/scripting system changes without >> replacing whole config files is one problem. How about the differing >> syntax between most applications without a technical need, some of which >> have horrid syntax. The impracticality of programs sharing configuration >> elements with each other without each application being aware of every >> other applications magic syntax. The impossibility of having an automated >> system for saving and reverting changes without saving whole config files >> after every change and then figuring out what changed and why. Or how >> about the fact developing configuration guis/tools is many orders of >> magnitude more difficult when their is no consistent config file standard? > > Look at Debian if you want to see how config files should be handled. > > Judicious use of conf.d type directories goes a long way. Does not address any of the above in any significant way... in other words I fail to see your point. > Fedora's own /etc/sysconfig hierarchy is a good example of how config > files can be brain dead simple, hand editable and GUI configurable. Awww we agree! Considering that ALL of RedHat's sysconfig config files are basically KEYS with values how could I not? If you give sysconfig a bit more structure (directories), have the directory names themselves be part of the syntax/semantics and standardized the creation/removal/modification/searching and querying of these files in the form of a library we end up with....... Elektra .... Shane From seg at haxxed.com Sun Apr 2 09:41:58 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 04:41:58 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> Message-ID: <1143970919.10632.101.camel@localhost> On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote: > What would it take to convince you? What would convince me is, as they say in XP, is some detailed UserStories explaining what exactly it is you want to do, and why you can't do it now. Instead of vague handwaving. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From shane at geeklords.org Sun Apr 2 09:37:23 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 01:37:23 -0800 (PST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143968655.10632.87.camel@localhost> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> Message-ID: On Sun, 2 Apr 2006, Callum Lerwick wrote: > On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote: >> Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic >> ideas are similar, the directory structure allowing split files is a big >> improvement over the single .conf file). > Apache, squid, Xorg, gdm. Interesting. Tell me what is the best way to enable XDMCP in gdm via a configuration script? I'll give ya a hint Enable=false is often defined in multiple places within gdm.conf and the line numbers for these statements have and will change. Configuration files that require either a) manual editing or b) complex error prone scripting are _NOT_ "Good". Cheers, Shane From shane at geeklords.org Sun Apr 2 09:40:49 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 01:40:49 -0800 (PST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143970919.10632.101.camel@localhost> References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143970919.10632.101.camel@localhost> Message-ID: On Sun, 2 Apr 2006, Callum Lerwick wrote: > On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote: >> What would it take to convince you? > > What would convince me is, as they say in XP, is some detailed > UserStories explaining what exactly it is you want to do, and why you > can't do it now. Instead of vague handwaving. Have you not been paying attention then? They have been outlined in multiple posts, in multiple ways. If you want a more detailed outlined E-mail me off list so others don't have to see the same ground being covered yet again. Shane From seg at haxxed.com Sun Apr 2 10:01:54 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 05:01:54 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> Message-ID: <1143972115.10632.116.camel@localhost> On Sun, 2006-04-02 at 01:37 -0800, Shane Stixrud wrote: > Interesting. Tell me what is the best way to enable XDMCP in gdm via a > configuration script? I'll give ya a hint Enable=false is often defined > in multiple places within gdm.conf and the line numbers for these > statements have and will change. For FC5 gdm, plop down a gdm.conf-custom with whatever settings you need in it. Bam, you're done. Yes, previous versions of gdm were brain damaged in this regard. Its better now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 10:14:10 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 05:14:10 -0500 Subject: Fedora's way forward In-Reply-To: <1143946960.3783.50.camel@sundaram.pnq.redhat.com> References: <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <442C5FA1.5050506@knox.net.nz> <442C9C15.1090601@knox.net.nz> <20060331044520.GA18191@thyrsus.com> <442CD714.2030504@hhs.nl> <6BF9FEFF-0C9C-475D-91F2-AA6E7483CD30@fubar.dk> <1143945291.10632.75.camel@localhost> <3adc77210604011845n5c08e71dg2c9d4f462a308c94@mail.gmail.com> <1143946368.3783.47.camel@sundaram.pnq.redhat.com> <604aa7910604011858p1a89676bg77dcc64d892d52c1@mail.gmail.com> <1143946960.3783.50.camel@sundaram.pnq.redhat.com> Message-ID: <1143972851.10632.126.camel@localhost> On Sun, 2006-04-02 at 08:32 +0530, Rahul Sundaram wrote: > As I understand it what the OP claimed was that a exploited browser > would automatically be able to install packages silently which is > something SELinux should be able to prevent with appropriate policies in > place. Making it easier for users to install packages is not a security > issue at all as long as the privileges required to complete the > operation doesnt change arbitrarily. The way to deal with this is to check GPG keys. Don't install a package unless the key checks out. This leads to a chicken and egg problem. The GPG keys is typically installed by the repo release file. How do you get the repo RPM installed? Put up a big fat warning before installing RPMs with untrusted signatures? This is kind of like what windows does these days... Or just sign third party repo's keys with the Fedora key. I don't know what Red Hat legal would think of that though. Or just not install repos with an RPM. Do something special. (Just some brainstorming) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 10:18:41 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 05:18:41 -0500 Subject: 'Commercial Partners' In-Reply-To: References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> Message-ID: <1143973122.10632.129.camel@localhost> The real solution is not to encumber Linux with closed source software, it is to encumber Windows with open source software. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 2 10:29:03 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 05:29:03 -0500 Subject: Package names in FC5 In-Reply-To: <1143660641.18075.35.camel@vroomfondel.internal.datastacks.com> References: <200603281356.17155.rkwasny@aurox.org> <20060328144218.92792ab4.fedora@wir-sind-cool.org> <1143582471.3095.33.camel@vroomfondel.internal.datastacks.com> <20060329153748.3ef7bab3.fedora@wir-sind-cool.org> <1143660641.18075.35.camel@vroomfondel.internal.datastacks.com> Message-ID: <1143973744.10632.131.camel@localhost> On Wed, 2006-03-29 at 14:30 -0500, Peter Jones wrote: > Ok, but there's a more serious problem there. If you're moving the > package from core to extras or vice versa, start with the same spec file > and only change the parts you actually have to. > > If our naming policy for extras says we have to use one particular > capitalization for a "release" field, then we should fix it. That's > just a rule for the sake of having more rules. It doesn't buy us > anything. In extras, we use a %{dist} macro in the spec, that's automatically set by the build system. And the build system uses lowercase. That's the rule. What does this rule buy us? The same spec can be used to build for multiple distro versions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Sun Apr 2 10:41:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 12:41:53 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> Message-ID: <1143974516.8941.18.camel@rousalka.dyndns.org> Le samedi 01 avril 2006 ? 19:29 -0800, Shane Stixrud a ?crit : > The limitations around automating/scripting system changes without > replacing whole config files is one problem. > How about the differing > syntax between most applications without a technical need, some of which > have horrid syntax. The impracticality of programs sharing configuration > elements with each other without each application being aware of every > other applications magic syntax. The impossibility of having an automated > system for saving and reverting changes without saving whole config files > after every change and then figuring out what changed and why. Or how > about the fact developing configuration guis/tools is many orders of > magnitude more difficult when their is no consistent config file standard? Shane, I'm not saying all your points are not a problem. But in the big picture they're not *the* problem. Software design is a balance between the needs of the software writer, and the needs of the software user. Configuration files are already used to transfer some of the work from the software writer to the software user (if the software was perfect and the software writer omnicient there would be no need for config files). You propose to make the transfer even easier with some new infrastructure. (easier on the software writer that is). But the current configuration pains stem not because this transfer is painful (adding a conf entry has always been less work for a software writer than figuring the right value or autodetect algorithm). They stem from software writers dumping ill-though keys on users. And here you'll make the situation even worse, by promoting a no-need-to-think configuration system (see the post on the new printing admin tool in the archives - problem not the conf file syntax but that key values/names are inconsistent). A case in point is gconf where the work is already so little on the software writer part some apps have been known to dump serialized structures in conf files, and the Gnome people insistence on hiding most of the keys from users has led on a pile of crapload files (why bother thinking if users never see the keys ? except problems happen and user need to salvage systems). Sendmail is another perfect example where configuration has been optimized for the software, not the humans and that's the #1 sendmail rejection factor today -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora-devel at stefan-neufeind.de Sun Apr 2 10:43:14 2006 From: fedora-devel at stefan-neufeind.de (Stefan Neufeind) Date: Sun, 02 Apr 2006 12:43:14 +0200 Subject: Rights for /var/named in latest FC4-bind-Update "incorrect"? Message-ID: <442FAAC2.5070701@stefan-neufeind.de> Hi, the latest bind-updates to bind i386 24:9.3.1-18.FC4 updates-released bind-libs i386 24:9.3.1-18.FC4 updates-released bind-utils i386 24:9.3.1-18.FC4 updates-released triggered a problem here that we've had in the past as well :-) The rights for /var/named are drwxr-x--- 5 root named 266240 Apr 2 12:30 named On a secondary-DNS zones are being written to /var/named. However bind does not have the right to write files there. A chown to named or chmod g+w help. But I'd like to know what others think about this "issue". Is this due to an error in the package, or a misusage on my side? Regards, Stefan From nicolas.mailhot at laposte.net Sun Apr 2 10:47:13 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 12:47:13 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> Message-ID: <1143974836.8941.23.camel@rousalka.dyndns.org> Le dimanche 02 avril 2006 ? 01:37 -0800, Shane Stixrud a ?crit : > On Sun, 2 Apr 2006, Callum Lerwick wrote: > > > On Wed, 2006-03-29 at 04:44 +0100, Bill Crawford wrote: > >> Good: Exim; dhcp; xinetd (as opposed to original inetd although the basic > >> ideas are similar, the directory structure allowing split files is a big > >> improvement over the single .conf file). > > Apache, squid, Xorg, gdm. > > Interesting. Tell me what is the best way to enable XDMCP in gdm via a > configuration script? I'll give ya a hint Enable=false is often defined > in multiple places within gdm.conf and the line numbers for these > statements have and will change. > > Configuration files that require either a) manual editing or b) complex > error prone scripting are _NOT_ "Good". But why is the gdm conf file such crap ? Is this because gdm writers had not lots of advanced configuration file libs at their disposition ? No It's because they consider : 1. the conf file is none of the user business 2. as a result little thought went in key naming 3. and even worse the keys themselves are not stable from release to release How is elektra going to help with this ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From shane at geeklords.org Sun Apr 2 10:57:17 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 03:57:17 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143974516.8941.18.camel@rousalka.dyndns.org> References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > writers dumping ill-though keys on users. And here you'll make the > situation even worse, by promoting a no-need-to-think configuration > system (see the post on the new printing admin tool in the archives - > problem not the conf file syntax but that key values/names are > inconsistent). This is just not true. Nothing about standardizing configuration data makes the system a "no-need-to-think configuration system". It's just the opposite in fact, the user is is now free to THINK and FOCUS on the FUNCTION they wish to perform with less needless distraction. Cheers, Shane From shane at geeklords.org Sun Apr 2 11:04:12 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 04:04:12 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143974836.8941.23.camel@rousalka.dyndns.org> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143974836.8941.23.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > But why is the gdm conf file such crap ? Is this because gdm writers had > not lots of advanced configuration file libs at their disposition ? > > No > > It's because they consider : > 1. the conf file is none of the user business > 2. as a result little thought went in key naming > 3. and even worse the keys themselves are not stable from release to > release > > How is elektra going to help with this ? It should be obvious having read http://www.libelektra.org. Anyways with a hierarchical key/value system like Elektra the solution is simple. echo "true" >/$CONFIGDIR/system/sw/gdm/xdmcp/enable Cheers, Shane From nicolas.mailhot at laposte.net Sun Apr 2 11:06:57 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 13:06:57 +0200 Subject: 'Commercial Partners' In-Reply-To: <1143973122.10632.129.camel@localhost> References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <1143973122.10632.129.camel@localhost> Message-ID: <1143976022.8941.37.camel@rousalka.dyndns.org> Le dimanche 02 avril 2006 ? 05:18 -0500, Callum Lerwick a ?crit : > The real solution is not to encumber Linux with closed source software, > it is to encumber Windows with open source software. +1 1. Take a survey of windows/osx mp3/avi producers 2. Setup a site that promotes ogg/flac/theora tools for the same tasks, and makes them easier to use than the mp3 tools (with howtos, walkthroughs, deployment examples) 3. produce ogg/flac/theora windows/osx codec packages which are easy to install, find and link to (*not* standalone players - lets not link formats to applications like the dark side) And you'll have done more for the unpatented formats than all this nonsense (and would have relieved pressure on Fedora at the same time) In France the public radio added ogg streams some time ago under massive user pressure. The *only* reasons it had considered switching to wma-only in the first place were : 1. real is too expensive 2. MS promised them a no-pain solution 3. setting up ogg streams was perceived as a black art on the client and server side The *same* arguments could have been advanced to justify IIS intead of Apache if Apache didn't have extensive and well known documentation and support communities. Help anyone setup its own ogg webradio in 30 min max, and hardware makers *will* take note. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sun Apr 2 11:10:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 13:10:45 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> Message-ID: <1143976248.8941.41.camel@rousalka.dyndns.org> Le dimanche 02 avril 2006 ? 03:57 -0700, Shane Stixrud a ?crit : > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > > > writers dumping ill-though keys on users. And here you'll make the > > situation even worse, by promoting a no-need-to-think configuration > > system (see the post on the new printing admin tool in the archives - > > problem not the conf file syntax but that key values/names are > > inconsistent). > > This is just not true. Nothing about standardizing configuration data > makes the system a "no-need-to-think configuration system". That's just sooo untrue. A software writer will just spend more time on features which he considers expensive in developer time. You need to take the human factor into account. FOSS like many other software changes relied heavily on social not technical factors. > It's just > the opposite in fact, the user is is now free to THINK > and FOCUS on the FUNCTION they wish to perform with less needless > distraction. Again, if you think the problem is on the user side you've already lost it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sun Apr 2 11:12:49 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 13:12:49 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143974836.8941.23.camel@rousalka.dyndns.org> Message-ID: <1143976372.8941.44.camel@rousalka.dyndns.org> Le dimanche 02 avril 2006 ? 04:04 -0700, Shane Stixrud a ?crit : > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > > > But why is the gdm conf file such crap ? Is this because gdm writers had > > not lots of advanced configuration file libs at their disposition ? > > > > No > > > > It's because they consider : > > 1. the conf file is none of the user business > > 2. as a result little thought went in key naming > > 3. and even worse the keys themselves are not stable from release to > > release > > > > How is elektra going to help with this ? > > It should be obvious having read http://www.libelektra.org. Anyways with > a hierarchical key/value system like Elektra the solution is simple. bzzt. hierarchical was already available when gconf was written (either by using XML of java-like hierarchical properties) That is was not used is not a conf lib problem -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From shane at geeklords.org Sun Apr 2 11:20:07 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 04:20:07 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143974836.8941.23.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Shane Stixrud wrote: > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > >> But why is the gdm conf file such crap ? Is this because gdm writers had >> not lots of advanced configuration file libs at their disposition ? >> >> No Yes, arbitrary key names and value types do not limit the programmability or user intractability in _ANY_ way what so ever. Poor key names and values are SUBJECTIVE and thus can only be judged good or bad by their tendency to cause understanding or confusion. >> >> It's because they consider : >> 1. the conf file is none of the user business >> 2. as a result little thought went in key naming >> 3. and even worse the keys themselves are not stable from release to >> release No, it is because naming is subjective in nature and what seems like a good name to an author might not be statistically a good choice for the masses. Btw the same holds true for configuration syntax and it is for this reason that a simple syntax that maintains all of the depth and functionality is superior to a complex custom syntax. Cheers, Shane From shane at geeklords.org Sun Apr 2 11:28:28 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 04:28:28 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143976372.8941.44.camel@rousalka.dyndns.org> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143974836.8941.23.camel@rousalka.dyndns.org> <1143976372.8941.44.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > Le dimanche 02 avril 2006 ? 04:04 -0700, Shane Stixrud a ?crit : >> >> It should be obvious having read http://www.libelektra.org. Anyways with >> a hierarchical key/value system like Elektra the solution is simple. > > bzzt. hierarchical was already available when gconf was written (either > by using XML of java-like hierarchical properties) > > That is was not used is not a conf lib problem This ground as already been covered, gconf was not designed with the whole system in mind. XML has its own complexity especially if we want to be able to use UNIX applications to easily edit them. I am not interested in debating. I am interested in working on solutions. From shane at geeklords.org Sun Apr 2 11:34:07 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 04:34:07 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143976248.8941.41.camel@rousalka.dyndns.org> References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > Again, if you think the problem is on the user side you've already lost > it. That's interesting.... others said the problem was on the user side... and you are saying its on the programmers side... In truth its a win for both, it is just counter to our UNIX traditions, ourunix history and our unix emotional^H^H^H^H^H^H^H^H^H social attachments. Cheers, Shane From kevacm at gmail.com Sun Apr 2 11:45:27 2006 From: kevacm at gmail.com (Kevac Marko) Date: Sun, 2 Apr 2006 15:45:27 +0400 Subject: FC5 boot problems In-Reply-To: <442E2805.2020401@knox.net.nz> References: <442E2805.2020401@knox.net.nz> Message-ID: <4fb2cbe00604020445j5fc28517se3989fe933ad5bd0@mail.gmail.com> Hi. I had such problem. Solution was to turn off kudzu (chkconfig kudzu off). Kevac Marko From mike at miketc.com Sun Apr 2 12:03:33 2006 From: mike at miketc.com (Mike Chambers) Date: Sun, 02 Apr 2006 07:03:33 -0500 Subject: Bootsplash? In-Reply-To: <1143713330.2967.0.camel@scrappy.miketc.com> References: <1143030630.2327.10.camel@localhost.localdomain> <1143042269.23468.6.camel@orodruin.boston.redhat.com> <1143059186.28627.6.camel@localhost.localdomain> <20060324012515.66d801f4@alkaid.a.lan> <1143220662.3500.1.camel@localhost> <1143302775.2605.41.camel@dimi> <20060328114818.4024f4c6@alkaid.a.lan> <20060328214417.730ccc2d@alkaid.a.lan> <1143599135.2192.1.camel@scrappy.miketc.com> <20060330105525.42e65b9e@alkaid.a.lan> <1143713330.2967.0.camel@scrappy.miketc.com> Message-ID: <1143979413.5385.0.camel@scrappy.miketc.com> On Thu, 2006-03-30 at 04:08 -0600, Mike Chambers wrote: > On Thu, 2006-03-30 at 10:55 +0200, Andreas Bierfert wrote: > > > Hm, thats strange... so I never tried that... does it work during bootup? > > > > I think tomorrow after my exam I will package up latest svn to see where we > > go... seems like lots of work has already been put in since this release. > > Nope, doesn't work on boot neither. Has 0.1.8 been released yet, or at least a fix to the latest problem for Fedora Core 5? -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From emeric.maschino at jouy.inra.fr Sun Apr 2 12:07:45 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sun, 2 Apr 2006 14:07:45 +0200 Subject: How to debug Fedora mono applications? Message-ID: <1143979665.442fbe9187b7e@www.jouy.inra.fr> Hi, Is there a HOWTO explaining how to debug Fedora mono applications? For example, in current Rawhide, beagle-search segfaults and I would like to obtain a callstack. Since beagle-search isn't an ELF executable, beagle-debuginfo and gdb are of no help. Many thanks, ?meric From emeric.maschino at jouy.inra.fr Sun Apr 2 12:14:15 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sun, 2 Apr 2006 14:14:15 +0200 Subject: Where's eclipse-cdt? Message-ID: <1143980055.442fc017d841b@www.jouy.inra.fr> Hi, The Fedora Core 5 release notes say: 13.3. Eclipse Development Environment * Eclipse 3.1M6 is compiled as a native application. * The C Development Tool (CDT) has been included. But I can't find the CDT related components :-( Cheers, ?meric From paul at all-the-johnsons.co.uk Sun Apr 2 12:20:48 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 02 Apr 2006 13:20:48 +0100 Subject: How to debug Fedora mono applications? In-Reply-To: <1143979665.442fbe9187b7e@www.jouy.inra.fr> References: <1143979665.442fbe9187b7e@www.jouy.inra.fr> Message-ID: <1143980448.3476.23.camel@T7.Linux> Hi, > Is there a HOWTO explaining how to debug Fedora mono applications? For example, > in current Rawhide, beagle-search segfaults and I would like to obtain a > callstack. Since beagle-search isn't an ELF executable, beagle-debuginfo and > gdb are of no help. You need the mono-debuginfo and mono-devel packages, the throwback should then be visible. They are with the build-from-source versions. TTFN Paul -- "ein zu starker starker Anblick kann Sie toten. Sie gegen gerade uber den Rand mit dem festen Wissen des Wege vor Ihnen" - Linus Tordvals -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sun Apr 2 12:36:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 2 Apr 2006 14:36:02 +0200 Subject: Split-off package config from release note packages In-Reply-To: <1143945847.10632.79.camel@localhost> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com> <200603311803.19043.nman64@n-man.com> <20060401001840.GF5242@neu.nirvana> <1143945847.10632.79.camel@localhost> Message-ID: <20060402123602.GJ28911@neu.nirvana> On Sat, Apr 01, 2006 at 08:44:06PM -0600, Callum Lerwick wrote: > On Sat, 2006-04-01 at 02:18 +0200, Axel Thimm wrote: > > My personal view: ATrpms is trying to add value to fedora (and RHEL), > > and I wonder why there have to be so many alienations towards > > ATrpms. People of the fedora community complain about market loss to > > Ubuntu due to non-coherent community of fedora and semi-official > > statements like the one in the wiki just divide the fedora community > > further. > > Stop replacing core packages. That's all you have to to. If you have a > problem with a core package, file a bug report. Don't replace it. Why can't some people read the whole thread before hitting the reply button? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From avi at unix.sh Sun Apr 2 13:22:30 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 10:22:30 -0300 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143969066.10632.93.camel@localhost> Message-ID: On 4/2/06, Shane Stixrud wrote: > On Sun, 2 Apr 2006, Callum Lerwick wrote: > > Fedora's own /etc/sysconfig hierarchy is a good example of how config > > files can be brain dead simple, hand editable and GUI configurable. > > Awww we agree! Considering that ALL of RedHat's sysconfig config > files are basically KEYS with values how could I not? If you give sysconfig > a bit more structure (directories), have the directory names themselves be > part of the syntax/semantics and standardized the > creation/removal/modification/searching and querying of these files in the > form of a library we end up with....... Elektra And /etc/sysconfig is RH-specific only, as far as I know. At least the semantics inside each /etc/sysconfig file. And they imply spliting the configurations of some programs in two parts. For example, ntpd has the /etc/ntp.conf and the /etc/sysconfig/ntpd files. This happens precisely because is very difficult to change these software configurations directly on their files, so distros were forced to create a secondary file and a separate whole scripting system to handle them too. From green at redhat.com Sun Apr 2 13:23:09 2006 From: green at redhat.com (Anthony Green) Date: Sun, 02 Apr 2006 06:23:09 -0700 Subject: Where's eclipse-cdt? In-Reply-To: <1143980055.442fc017d841b@www.jouy.inra.fr> References: <1143980055.442fc017d841b@www.jouy.inra.fr> Message-ID: <1143984189.17730.1.camel@localhost.localdomain> On Sun, 2006-04-02 at 14:14 +0200, ?meric Maschino wrote: > The Fedora Core 5 release notes say: > > 13.3. Eclipse Development Environment > > * Eclipse 3.1M6 is compiled as a native application. > * The C Development Tool (CDT) has been included. > > But I can't find the CDT related components :-( # rpm -qa eclipse-cdt eclipse-cdt-3.0.2-1jpp_2fc Have you tried "yum install eclipse-cdt"? AG From avi at unix.sh Sun Apr 2 13:41:14 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 10:41:14 -0300 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1143972115.10632.116.camel@localhost> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143972115.10632.116.camel@localhost> Message-ID: On 4/2/06, Callum Lerwick wrote: > On Sun, 2006-04-02 at 01:37 -0800, Shane Stixrud wrote: > > Interesting. Tell me what is the best way to enable XDMCP in gdm via a > > configuration script? I'll give ya a hint Enable=false is often defined > > in multiple places within gdm.conf and the line numbers for these > > statements have and will change. > > For FC5 gdm, plop down a gdm.conf-custom with whatever settings you need > in it. Bam, you're done. > > Yes, previous versions of gdm were brain damaged in this regard. Its > better now. Really!? Oh thank you! I didn't know it was so simple! Ok, lets shutdown this whole Elektra Iniative after you give us same simple solution for Shane's simple requirement for script-handling these configurations: /etc/named.conf, /etc/dhcpd.conf, /etc/X11/xorg.conf, /etc/wvdial.conf, /etc/wgetrc, /etc/hosts.[conf|allow|deny], /etc/nsswitch.conf, /etc/ldap.conf, /etc/lisarc, /etc/samba/*.conf /etc/ntp.conf /etc/xinetd.conf /etc/xinetd.d/* /etc/modprobe.conf /etc/prelink.conf /etc/resolv.conf /etc/sysconfig/* /etc/sysconfig/network-scripts/ifcfg-* /etc/issue* /etc/yum.conf /etc/pam.d/* /etc/openldap/ldap.conf /etc/enscript.cfg /etc/fstab /etc/filesystems /etc/{any new thing that may appear} Remember: your solution must be homogeneous, like, people are not interested in hundred different solution for each of these hundreds files. Oh, and please provide a solutions that is distribution agnostic (remember that these files can be located in other places in other distros). I'm desperately just waiting for your e-mail. Thank you, Avi From emeric.maschino at jouy.inra.fr Sun Apr 2 14:13:57 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sun, 2 Apr 2006 16:13:57 +0200 Subject: Where's eclipse-cdt? In-Reply-To: <1143984189.17730.1.camel@localhost.localdomain> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> Message-ID: <1143987237.442fdc2517606@www.jouy.inra.fr> Antony, > Have you tried "yum install eclipse-cdt"? > > AG [root at zx6000 emeric]# yum install eclipse-cdt Loading "installonlyn" plugin Setting up Install Process Setting up repositories development [1/2] development 100% |=========================| 1.1 kB 00:00 development-debuginfo [2/2] development-debuginfo 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Parsing package install arguments No Match for argument: eclipse-cdt Nothing to do This is on an Itanium workstation (ia64) running up-to-date Rawhide. Has this package been removed? Currently, eclipse packages are numbered 3.1.2-1jpp_13fc. ?meric From emeric.maschino at jouy.inra.fr Sun Apr 2 14:15:34 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sun, 2 Apr 2006 16:15:34 +0200 Subject: How to debug Fedora mono applications? In-Reply-To: <1143980448.3476.23.camel@T7.Linux> References: <1143979665.442fbe9187b7e@www.jouy.inra.fr> <1143980448.3476.23.camel@T7.Linux> Message-ID: <1143987334.442fdc86b3a34@www.jouy.inra.fr> Paul, > You need the mono-debuginfo and mono-devel packages, the throwback > should then be visible. > > They are with the build-from-source versions. > > TTFN > > Paul Many thanks. Then, should the bug reports be sent against the mono runtime or the mono applications? ?meric From emeric.maschino at jouy.inra.fr Sun Apr 2 14:24:00 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sun, 2 Apr 2006 16:24:00 +0200 Subject: How to debug Fedora mono applications? In-Reply-To: <1143980448.3476.23.camel@T7.Linux> References: <1143979665.442fbe9187b7e@www.jouy.inra.fr> <1143980448.3476.23.camel@T7.Linux> Message-ID: <1143987840.442fde802d605@www.jouy.inra.fr> Paul > You need the mono-debuginfo and mono-devel packages, the throwback > should then be visible. > > They are with the build-from-source versions. > > TTFN > > Paul Even with mono-debuginfo and mono-devel installed, I'm still getting this poor output when invoking beagle-search from the CLI: [emeric at zx6000 ~]$ beagle-search GC Warning: GC_register_stackbottom should be set with GC_stackbottom ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Stacktrace: Native stacktrace: mono(mono_handle_native_sigsegv+0x1ffffffff90008a0) [0x4000000000297e20] mono [0x400000000021e8d0] [0xa0000000000107e0] [0x210010019800] Is there a particular way to execute a mono application in order to debug it? I mean, when you debug ELF executables, you don't simply invoke the executable, you execute it inside gdb. Is there a similar scheme for a mono application? ?meric From green at redhat.com Sun Apr 2 14:58:05 2006 From: green at redhat.com (Anthony Green) Date: Sun, 02 Apr 2006 07:58:05 -0700 Subject: Where's eclipse-cdt? In-Reply-To: <1143987237.442fdc2517606@www.jouy.inra.fr> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> <1143987237.442fdc2517606@www.jouy.inra.fr> Message-ID: <1143989885.17730.4.camel@localhost.localdomain> On Sun, 2006-04-02 at 16:13 +0200, ?meric Maschino wrote: > This is on an Itanium workstation (ia64) running up-to-date Rawhide. Has this > package been removed? Currently, eclipse packages are numbered 3.1.2-1jpp_13fc. Sorry - I don't know anything about Itanium. Maybe things are different there. I suggest following up on fedora-devel-java-list at redhat.com. AG From gilboad at gmail.com Sun Apr 2 15:44:05 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 02 Apr 2006 18:44:05 +0300 Subject: Fedora's way forward In-Reply-To: <20060402053854.GC6796@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <1143609087.3683.14.camel@c-67-164-203-75.hsd1.ut.comcast.net> <1143609370.3802.598.camel@sundaram.pnq.redhat.com> <20060329063345.GB6131@thyrsus.com> <1143657279.25616.11.camel@daxter.boston.redhat.com> <20060330213042.GB14444@thyrsus.com> <20060331172306.753d187a@python2> <20060331173633.GC24571@thyrsus.com> <6899-SnapperMsg827D11E1C053B4B0@[68.27.238.145]> <1143868435.17044.39.camel@gilboa-home-dev.localhost> <20060402053854.GC6796@thyrsus.com> Message-ID: <1143992645.6708.28.camel@gilboa-work-dev> On Sun, 2006-04-02 at 00:38 -0500, Eric S. Raymond wrote: > Gilboa Davara : > > If a user can't be bothered to read a FAQ, google for help, or, heaven > > forbids, learn how to configure pirut/yum/rpm, he shouldn't be using > > Fedora (or Linux). > > That's a horrible, elitist attitude thast will lose us the market-share war. The Fedora project is looking for create the best -free- semi-bleeding-edge Linux platform while -you- seek to create an OS that will be a "better Windows then Windows" and will draw users from Microsoft. Ignoring for a second the huge security ramifications of integrating the browser into the OS management layer (read: IE + XP nightmare), you are simply using the wrong OS (or distributions). I'd suggest you re-read the Fedora mission statement: (http://fedoraproject.org/wiki/) "Fedora Core is an operating system and platform, based on Linux, that is always free for anyone to use, modify and distribute, now and forever. It is developed by a large community of people who strive to provide and maintain the very best in free, open source software and standards. Fedora Core is part of the Fedora Project, sponsored by Red Hat, Inc." Correct me if I'm wrong... but AFAICS, it doesn't say anything about winning market share from Microsoft. Gilboa From thuforuk at yahoo.co.uk Sun Apr 2 16:12:00 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Sun, 02 Apr 2006 17:12:00 +0100 Subject: GUI controls for instrumentation In-Reply-To: References: <132A9F5E12B8828DA6ED8E85@10.169.6.226> <200603242033.03945.lamont@gurulabs.com> <1cef3e950603241959y762f3afdrf772e3d866cb143b@mail.gmail.com> <1143281498.4018.6.camel@rousalka.dyndns.org> <44251FC4.3070207@yahoo.co.uk> <1143284362.4018.14.camel@rousalka.dyndns.org> <442529EB.2040004@yahoo.co.uk> Message-ID: <442FF7D0.101@yahoo.co.uk> On 03/28/2006 04:46 PM, Kenneth Porter wrote: > --On Tuesday, March 28, 2006 11:31 AM +0200 Rudolf Kastl > wrote: > >> why would a linux user make his source dependendant on >> non free things? > > Sometimes the functionality you need isn't available for free. Sorry for late answer (I went for holidays) but Kenneth answered for me ;-) In any case I'm looking forward to being able to run any Java code on free stack without trying to figure out where the problem is and being able to tell that it's most likely an application issue (eg. the app using com.sun.* packages). Regards, Dariusz ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From jkeating at redhat.com Sun Apr 2 16:21:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 02 Apr 2006 09:21:50 -0700 Subject: Where's eclipse-cdt? In-Reply-To: <1143987237.442fdc2517606@www.jouy.inra.fr> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> <1143987237.442fdc2517606@www.jouy.inra.fr> Message-ID: <1143994910.18098.5.camel@ender> On Sun, 2006-04-02 at 16:13 +0200, ?meric Maschino wrote: > This is on an Itanium workstation (ia64) running up-to-date Rawhide. Has this > package been removed? Currently, eclipse packages are numbered 3.1.2-1jpp_13fc. We may not be building all the java components on all the arches currently. I do recall some arches proving problematic as we were trying to get a release out and were excluded from the final builds. During this development cycle we should try and re-enable all the arches and spend some time trying to fix things so that they'll build on all arches. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sun Apr 2 16:36:36 2006 From: selinux at gmail.com (Tom London) Date: Sun, 2 Apr 2006 09:36:36 -0700 Subject: Header file 'ordering' issue? Message-ID: <4c4ba1530604020936q7bd257a1xabaa9b65974ba551@mail.gmail.com> Vmware has some difficulties with the latest few kernel packages that appear to be related to some changes in the kernel build headers. Described here: http://www.vmware.com/community/message.jspa?messageID=375839#375839 Here's the gist: asm-i386/bitops.h includes asm-i386/alternatives.h, and asm-i386/alternatives.h uses type 'u8' although it does not include asm-i386/types.h. Right fix is either replace all 'u8' with 'unsigned char' in asm/alternatives.h, or include asm/types.h in alternatives.h. Appears that bitops.h/alternatives.h now assumes types.h was previously included. Is this a known feature/change? tom -- Tom London From arjan at fenrus.demon.nl Sun Apr 2 17:07:22 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 02 Apr 2006 19:07:22 +0200 Subject: Header file 'ordering' issue? In-Reply-To: <4c4ba1530604020936q7bd257a1xabaa9b65974ba551@mail.gmail.com> References: <4c4ba1530604020936q7bd257a1xabaa9b65974ba551@mail.gmail.com> Message-ID: <1143997642.3066.11.camel@laptopd505.fenrus.org> On Sun, 2006-04-02 at 09:36 -0700, Tom London wrote: > Vmware has some difficulties with the latest few kernel packages that > appear to be related to some changes in the kernel build headers. > Appears that bitops.h/alternatives.h now assumes types.h was > previously included. and that is a problem... where in the kernel exactly? > > Is this a known feature/change? sounds like you have to get an updated vmware module.... From pato.lukaz at gmail.com Sun Apr 2 18:17:29 2006 From: pato.lukaz at gmail.com (Alberto Patino) Date: Sun, 2 Apr 2006 12:17:29 -0600 Subject: Where is the kernel source package for FC5 GA? In-Reply-To: <1143651074.5136.5.camel@localhost.localdomain> References: <75EC4D5486CAC247B84AAAA6F96AA55807059F38@orsmsx402.amr.corp.intel.com> <4429C65C.3070600@comcast.net> <200603281709.38816.lamont@gurulabs.com> <4429D3FF.4050904@comcast.net> <1143592383.3802.578.camel@sundaram.pnq.redhat.com> <4429DBA3.1020605@comcast.net> <1143594150.3802.582.camel@sundaram.pnq.redhat.com> <1143651074.5136.5.camel@localhost.localdomain> Message-ID: <4489a22a0604021117u236875fal2af436e2cfc91b6f@mail.gmail.com> On 3/29/06, Paul W. Frields wrote: > Don't be silly, Rahul, everybody knows we Americans can't read. :-) > > In all seriousness, I'm betting your question is rhetorical and stems > from the frustration of putting so much work into the process only to > see endless questions like this. (Your work is very much appreciated, > by the way.) In case it's not rhetorical, perhaps we could put a big > modal dialog at the opening of Anaconda saying something like, > > "Hidden in the release notes is a secret key to enabling MP3, DVD, and > Shockwave in your new Fedora system. To find it, you'll have to read > them to find the secret. Click 'OK' to open the Release Notes window." > Excellent idea :) From nicolas.mailhot at laposte.net Sun Apr 2 18:26:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Apr 2006 20:26:14 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <31248.192.54.193.25.1143532756.squirrel@rousalka.dyndns.org> <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> Message-ID: <1144002377.2775.1.camel@rousalka.dyndns.org> Le dimanche 02 avril 2006 ? 04:34 -0700, Shane Stixrud a ?crit : > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > > > Again, if you think the problem is on the user side you've already lost > > it. > > That's interesting.... others said the problem was on the user side... and > you are saying its on the programmers side... The problem is on the user side The solution is on the programmers side. Which is why analysing the problem from the software writer POW (generic API) won't get us anywhere -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From seg at haxxed.com Sun Apr 2 18:46:17 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 13:46:17 -0500 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143972115.10632.116.camel@localhost> Message-ID: <1144003577.10632.135.camel@localhost> On Sun, 2006-04-02 at 10:41 -0300, Avi Alkalay wrote: > Really!? Oh thank you! I didn't know it was so simple! > Ok, lets shutdown this whole Elektra Iniative after you give us same > simple solution for Shane's simple requirement for script-handling > these configurations: [long list cut] > Remember: your solution must be homogeneous, like, people are not > interested in hundred different solution for each of these hundreds > files. > Oh, and please provide a solutions that is distribution agnostic > (remember that these files can be located in other places in other > distros). > > I'm desperately just waiting for your e-mail. > > Thank you, > Avi No, thank you. Now we're getting somewhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seandarcy2 at gmail.com Sun Apr 2 18:42:23 2006 From: seandarcy2 at gmail.com (sean) Date: Sun, 02 Apr 2006 14:42:23 -0400 Subject: rawhide->fc5; X won't start In-Reply-To: <604aa7910604011231v18bbbd59g9fd43fdc06296e20@mail.gmail.com> References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <604aa7910604011231v18bbbd59g9fd43fdc06296e20@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 4/1/06, sean wrote: >> So X appears to start - Fedora logo comes up; no error on Xorg.0.log. >> >> But no gui's will start - not gnome,kde or xfce. Does this mean X isn't >> starting correctly so that the gui's can start? If not, what happens >> between X coming up and the gui's starting? > > Look in the xsession error files. Which should be in /tmp with filenames like > xses-username.randomstring > > There may be noise in there that from applications that is unrealted > with your current problem so don't freak out if you see gobs of error > outputs in that file. > I've been looking for the xsession error files, but I can't find them. They aren't in /tmp ( I looked, I tried find /tmp -name "xse*" and find /tmp -name ".xse*" ) or in /root. locate doesn't find them. Is there some switch that causes them to be generated? sean From dedourek at unb.ca Sun Apr 2 18:42:58 2006 From: dedourek at unb.ca (John DeDourek) Date: Sun, 02 Apr 2006 15:42:58 -0300 Subject: 'Commercial Partners' In-Reply-To: <1143976022.8941.37.camel@rousalka.dyndns.org> References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <1143973122.10632.129.camel@localhost> <1143976022.8941.37.camel@rousalka.dyndns.org> Message-ID: <44301B32.2010908@unb.ca> Nicolas Mailhot wrote: >In France the public radio added ogg streams some time ago under massive >user pressure. > On the other hand: http://support.bbc.co.uk/ogg/ Win some, lose some. From shane at geeklords.org Sun Apr 2 18:50:35 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 11:50:35 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1144002377.2775.1.camel@rousalka.dyndns.org> References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> Message-ID: On Sun, 2 Apr 2006, Nicolas Mailhot wrote: >>> Again, if you think the problem is on the user side you've already lost >>> it. >> >> That's interesting.... others said the problem was on the user side... and >> you are saying its on the programmers side... > > The problem is on the user side > The solution is on the programmers side. > > Which is why analysing the problem from the software writer POW (generic > API) won't get us anywhere Now you are just talking double talk. What is YOUR solution for a unversal process for managing / editing configuration files programatically? (Let me guess, hand over eyes... what problem??) How can we improve revision control for system config changes (Let me guess, isn't that what tape backups are for?). How can we improve the documentation of what configuration changes have been made and why. i.e. the "receipy" for a given systems functionality. (Let me guess, isn't that what tape backups and 3 ring binders are for?). Can we have a Linux configuration system that predictable and editable with simple methods/tools where these methods/tools do not need to change based on how applications decide to layout their config data (Let me guess, NO, that is crazy talk.....) Cheers, Shane From seg at haxxed.com Sun Apr 2 19:04:19 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 02 Apr 2006 14:04:19 -0500 Subject: 'Commercial Partners' In-Reply-To: <1143976022.8941.37.camel@rousalka.dyndns.org> References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <1143973122.10632.129.camel@localhost> <1143976022.8941.37.camel@rousalka.dyndns.org> Message-ID: <1144004660.10632.151.camel@localhost> On Sun, 2006-04-02 at 13:06 +0200, Nicolas Mailhot wrote: > Le dimanche 02 avril 2006 ? 05:18 -0500, Callum Lerwick a ?crit : > > The real solution is not to encumber Linux with closed source software, > > it is to encumber Windows with open source software. > > +1 Great inroads have been made popularizing Firefox on Windows. GAIM is an easy sell, no ads. Casual users tend to prefer OpenOffice to pirating or actually spending money on MS Office. WinAmp has supported ogg for some time. I'm told there's ogg-vorbis codecs for DirectShow that actually work well. Apache and bind are widely used on Windows servers. I kind of ment to put OSX in there too. Though its already half-"encumbered" with open source. I've found the state of ogg support on OSX is sad. There's a quicktime codec around, allowing you to play ogg in iTunes, but it was slow and buggy as hell when I tried it. There's VLC but its not really oriented for music playing. I ended up just installing X11 and xmms from fink to play music on my iMac. Outside the scope of Fedora, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sun Apr 2 20:24:08 2006 From: selinux at gmail.com (Tom London) Date: Sun, 2 Apr 2006 13:24:08 -0700 Subject: Header file 'ordering' issue? In-Reply-To: <1143997642.3066.11.camel@laptopd505.fenrus.org> References: <4c4ba1530604020936q7bd257a1xabaa9b65974ba551@mail.gmail.com> <1143997642.3066.11.camel@laptopd505.fenrus.org> Message-ID: <4c4ba1530604021324m4d25b4fctc4dae794685ad1d3@mail.gmail.com> On 4/2/06, Arjan van de Ven wrote: > On Sun, 2006-04-02 at 09:36 -0700, Tom London wrote: > > Vmware has some difficulties with the latest few kernel packages that > > appear to be related to some changes in the kernel build headers. > > > Appears that bitops.h/alternatives.h now assumes types.h was > > previously included. > > and that is a problem... where in the kernel exactly? > > > > > Is this a known feature/change? > > sounds like you have to get an updated vmware module.... > Arjan, No problems compiling the vmware modules before about a week ago, so its likely something changed. Believe it was also mentioned that there were no similar issues with 64bit kernel. Just wondering if this is 'planned' or not. tom -- Tom London From bigjoe1008 at gmail.com Sun Apr 2 20:24:29 2006 From: bigjoe1008 at gmail.com (Joseph Harnish) Date: Sun, 02 Apr 2006 16:24:29 -0400 Subject: Samba 4 Message-ID: <1144009469.2981.5.camel@wks1.myhost.net> I am not sure what the road map looks like for Samba 4 but I would be interested in testing that. Is this something that we need to wait for it to be closer to production ready? Or can we get it in the dev tree? Thanks Joe From avi at unix.sh Sun Apr 2 20:56:04 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 17:56:04 -0300 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <1144003577.10632.135.camel@localhost> References: <1cef3e950603281452i2cd83410sc371bea254fb9ce5@mail.gmail.com> <200603290444.20942.billcrawford1970@googlemail.com> <1143968655.10632.87.camel@localhost> <1143972115.10632.116.camel@localhost> <1144003577.10632.135.camel@localhost> Message-ID: On 4/2/06, Callum Lerwick wrote: > No, thank you. Now we're getting somewhere. Where ? From nutello at sweetness.com Sun Apr 2 21:08:13 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Sun, 2 Apr 2006 23:08:13 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> Message-ID: <20060402210813.GB2827@plain.rackshack.net> On Sun, Apr 02, 2006 at 11:50:35AM -0700, Shane Stixrud wrote: > What is YOUR solution for a unversal process for managing / editing > configuration files programatically? (Let me guess, hand over eyes... > what problem??) Cfengine does that, but it's crude. Puppet is going to go one step further and hide some of the details. There is simply no silver bullet. -- Rudi From shane at geeklords.org Sun Apr 2 21:36:38 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 14:36:38 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <20060402210813.GB2827@plain.rackshack.net> References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> Message-ID: On Sun, 2 Apr 2006, Rudi Chiarito wrote: > On Sun, Apr 02, 2006 at 11:50:35AM -0700, Shane Stixrud wrote: >> What is YOUR solution for a unversal process for managing / editing >> configuration files programatically? (Let me guess, hand over eyes... >> what problem??) > > Cfengine does that, but it's crude. Puppet is going to go one step > further and hide some of the details. My reading of puppet suggested it still deals in config file replacement. If thats so its usefulness is largely offset by the overhead of managing and documenting the puppet backend. When all is said and done any system that merely pushes files to managed devices, oblivious of the changes within those files is kludgey at best. > There is simply no silver bullet. Of course not, but there solid approaches to shooting this problem dead. It is just not east to get there from here. Cheers, Shane From avi at unix.sh Sun Apr 2 21:43:50 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 18:43:50 -0300 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> Message-ID: http://www.libelektra.org/Gnome_and_KDE_Integration From ianburrell at gmail.com Sun Apr 2 21:55:29 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Sun, 2 Apr 2006 14:55:29 -0700 Subject: yum + mulitarch + updates In-Reply-To: <442F6F0B.2040706@feuerpokemon.de> References: <442F6F0B.2040706@feuerpokemon.de> Message-ID: On 4/1/06, dragoran wrote: > I have noticed that when I have package foo-1.0.i386 installed and some > other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the > i386 one. > (livna mplayerplug-in was it here). > Updates should not be crossarch a i386 package should only be updated to > a i386 one (same for x86_64). > Any reason for doing this? Or is this a bug thats needs to be filled? > Can you give an actual example? Also, did you change your /etc/yum.conf file? There is a setting, exactarch, which controls whether yum will upgrade to across architectures. The default is exactarch=1. It is even more strict than x86_64/i386; it won't upgrade between glibc.i386 and glibc.i686 for exampe. - Ian From shane at geeklords.org Sun Apr 2 22:34:36 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 15:34:36 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> Message-ID: On Sun, 2 Apr 2006, Avi Alkalay wrote: > http://www.libelektra.org/Gnome_and_KDE_Integration > This thread has gotten off track IMO. Does anyone care to critique Elektra from a technical stand point on its suitability as a Fedora configuration engine? So far the technical critiques have been based on invalid assumptions. Cheers, Shane From seandarcy2 at gmail.com Sun Apr 2 22:55:30 2006 From: seandarcy2 at gmail.com (sean) Date: Sun, 02 Apr 2006 18:55:30 -0400 Subject: rawhide->fc5; X won't start In-Reply-To: <20060401.104056.705159298.kevin@scrye.com> References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <20060401.104056.705159298.kevin@scrye.com> Message-ID: Kevin Fenzi wrote: >>>>>> "sean" == sean writes: > > sean> I installed xfce to see if it was a gnome/kde problem. Here's > sean> what shows on the xfce console: > >>> (==) Using config file: "/etc/X11/xorg.conf" /usr/bin/startxfce4: X >>> server already running on display :0 Agent pid 4100 which: no >>> xfce4-session in >>> (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/NX/bin:/root/bin) >>> (xfce-mcs-manager:4103): libxfce4mcs-CRITICAL **: >>> mcs_manager_add_channel_from_file: assertion `filename != NULL && >>> strlen (filename) > 0' failed /etc/xdg/xfce4/xinitrc: line 106: >>> 4105 Segmentation fault xfwm4 --daemon ** Message: Cannot connect >>> to session manager /etc/xdg/xfce4/xinitrc: line 123: 4108 >>> Segmentation fault xfcalendar /etc/xdg/xfce4/xinitrc: line 123: >>> 4110 Segmentation fault $panel > > sean> So X appears to start - Fedora logo comes up; no error on > sean> Xorg.0.log. > > sean> But no gui's will start - not gnome,kde or xfce. Does this mean > sean> X isn't starting correctly so that the gui's can start? If not, > sean> what happens between X coming up and the gui's starting? > > sean> metacity? Is there any way to cause metacity to do verbose > sean> logging? > > sean> Again, is there any way to get more verbose and clearer logs. > > sean> Or any other hints? > > Well, not sure on gnome or KDE, but the above Xfce output looks like > the problem is the Seg faults when trying to start up. :( > > Several other things to try: > > - If you create a new fresh user, can they login ok? > (This would point to it being you users gtk theme, fonts setup or the > like). > Yes! I can login as a new user. Switched xorg.conf back to using xfs, and that worked to. ( Oddly, when I logout as the new user, I'm left at console 7 with a black screen and a blinking cursor at top left. console 1, witch I have to manually switch to, shows the usual X shutdown stuff.) > - Could be some package leftover from your rawhide install causing > issues, perhaps a 'yum list extras' to identify any packages that are > not in repositories you have currently enabled? > > - Could you try and run xfwm4 under a debugger? > 0) yum --enable-repo=core-debuginfo install xfwm4-debuginfo yum --enablerepo=extras-debuginfo ........ :) > 1) Run X from a console, "xinit /usr/X11R6/bin/xterm &" > 2) Switch to a console (Ctrl+Alt+F1) > 3) Set the display "export DISPLAY=:0.0" > 4) run "gdb /usr/bin/xfwm4" > 5) if/when it crashes, run 'bt' and send me the backtrace. > Well, it appears to be font related. I hope you can figure out what the font problems is though. Here's the backtrace: gdb /usr/bin/xfwm4 GNU gdb Red Hat Linux (6.3.0.0-1.122rh) ................... (gdb) run Starting program: /usr/bin/xfwm4 Program received signal SIGSEGV, Segmentation fault. 0x0000003fa28233ff in FcPatternUnserialize () from /usr/lib64/libfontconfig.so.1 (gdb) (gdb) bt #0 0x0000003fa28233ff in FcPatternUnserialize () from /usr/lib64/libfontconfig.so.1 #1 0x0000003fa282344e in FcPatternFindElt () from /usr/lib64/libfontconfig.so.1 #2 0x0000003fa2824b76 in FcPatternGet () from /usr/lib64/libfontconfig.so.1 #3 0x0000003fa2824e73 in FcPatternGetString () from /usr/lib64/libfontconfig.so.1 #4 0x0000003fa28136d1 in FcConfigBuildFonts () from /usr/lib64/libfontconfig.so.1 #5 0x0000003fa281b8bb in FcInitLoadConfigAndFonts () from /usr/lib64/libfontconfig.so.1 #6 0x0000003fa281b975 in FcInit () from /usr/lib64/libfontconfig.so.1 #7 0x0000003fa2812cab in FcConfigGetCurrent () from /usr/lib64/libfontconfig.so.1 #8 0x0000003fa2814d2b in FcConfigSubstituteWithPat () from /usr/lib64/libfontconfig.so.1 #9 0x0000003fa4f067d0 in pango_cairo_fc_font_map_get_type () from /usr/lib64/libpangocairo-1.0.so.0 #10 0x0000003fa4b098ea in pango_fc_font_map_get_type () from /usr/lib64/libpangoft2-1.0.so.0 #11 0x0000003fa4d14c1d in pango_context_get_font_description () from /usr/lib64/libpango-1.0.so.0 #12 0x0000003fa4d14f3d in pango_itemize_with_base_dir () from /usr/lib64/libpango-1.0.so.0 #13 0x0000003fa4d1c0e0 in pango_layout_iter_get_char_extents () from /usr/lib64/libpango-1.0.so.0 #14 0x0000003fa4d1cc28 in pango_layout_iter_get_char_extents () from /usr/lib64/libpango-1.0.so.0 #15 0x0000003fa4d1db66 in pango_layout_get_pixel_extents () from /usr/lib64/libpango-1.0.so.0 #16 0x00000000004203c2 in myScreenInit (display_info=0x560400, gscr=0x558120, event_mask=7995436) at screen.c:79 #17 0x000000000041a368 in main (argc=Variable "argc" is not available. ) at main.c:404 #18 0x0000003fa0f1d084 in __libc_start_main () from /lib64/libc.so.6 #19 0x0000000000408819 in _start () #20 0x00007fffffbdee78 in ?? () #21 0x0000000000000000 in ?? () (gdb) I really appreciate all this help. I'd never have figured out how to get this far. sean From jdesbonnet at gmail.com Sun Apr 2 22:57:43 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Sun, 2 Apr 2006 23:57:43 +0100 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> Message-ID: <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> As far as I can tell Elektra does not support configuration schemas. For me that would be an important *option* that an application developer can avail of. The schema can make sure that silly errors are reduced (ie that integers are integers, IP addresses are IP addresses, etc). The schema can also incorporate hits to a GUI editor (eg appropriate widget to use, help text in various languages etc). With a schema you get a user friendly and robust GUI configuration tool for free (ok -- that may not apply to complex applications, but it would cover at least 80% of applications I think). Joe. On 4/2/06, Shane Stixrud wrote: > On Sun, 2 Apr 2006, Avi Alkalay wrote: > > > http://www.libelektra.org/Gnome_and_KDE_Integration > > > > This thread has gotten off track IMO. Does anyone care to critique > Elektra from a technical stand point on its suitability as a Fedora > configuration engine? > > So far the technical critiques have been based on invalid assumptions. > > Cheers, > Shane > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dwmw2 at infradead.org Sun Apr 2 23:31:16 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 03 Apr 2006 00:31:16 +0100 Subject: Where's eclipse-cdt? In-Reply-To: <1143994910.18098.5.camel@ender> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> <1143987237.442fdc2517606@www.jouy.inra.fr> <1143994910.18098.5.camel@ender> Message-ID: <1144020676.31660.20.camel@localhost.localdomain> On Sun, 2006-04-02 at 09:21 -0700, Jesse Keating wrote: > We may not be building all the java components on all the arches > currently. I do recall some arches proving problematic as we were > trying to get a release out and were excluded from the final builds. > During this development cycle we should try and re-enable all the > arches and spend some time trying to fix things so that they'll build > on all arches. We should have bugs filed for any arch exclusion to keep track of such things. -- dwmw2 From rstrode at redhat.com Sun Apr 2 23:48:23 2006 From: rstrode at redhat.com (Ray Strode) Date: Sun, 02 Apr 2006 19:48:23 -0400 Subject: rawhide->fc5; X won't start In-Reply-To: References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <20060401.104056.705159298.kevin@scrye.com> Message-ID: <1144021704.5901.4.camel@halflap> Hi, > " == sean writes: > > > > sean> I installed xfce to see if it was a gnome/kde problem. Here's > > sean> what shows on the xfce console: > > > >>> (==) Using config file: "/etc/X11/xorg.conf" /usr/bin/startxfce4: X > >>> server already running on display :0 Agent pid 4100 which: no > >>> xfce4-session in > >>> (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/NX/bin:/root/bin) > >>> (xfce-mcs-manager:4103): libxfce4mcs-CRITICAL **: > >>> mcs_manager_add_channel_from_file: assertion `filename != NULL && > >>> strlen (filename) > 0' failed /etc/xdg/xfce4/xinitrc: line 106: > >>> 4105 Segmentation fault xfwm4 --daemon ** Message: Cannot connect > >>> to session manager /etc/xdg/xfce4/xinitrc: line 123: 4108 > >>> Segmentation fault xfcalendar /etc/xdg/xfce4/xinitrc: line 123: > >>> 4110 Segmentation fault $panel > > > > sean> So X appears to start - Fedora logo comes up; no error on > > sean> Xorg.0.log. > > > > sean> But no gui's will start - not gnome,kde or xfce. Does this mean > > sean> X isn't starting correctly so that the gui's can start? If not, > > sean> what happens between X coming up and the gui's starting? > > > > sean> metacity? Is there any way to cause metacity to do verbose > > sean> logging? > > > > sean> Again, is there any way to get more verbose and clearer logs. > > > > sean> Or any other hints? > > > > Well, not sure on gnome or KDE, but the above Xfce output looks like > > the problem is the Seg faults when trying to start up. :( > > > > Several other things to try: > > > > - If you create a new fresh user, can they login ok? > > (This would point to it being you users gtk theme, fonts setup or the > > like). > > > > Yes! I can login as a new user. Switched xorg.conf back to using xfs, > and that worked to. > > ( Oddly, when I logout as the new user, I'm left at console 7 with a > black screen and a blinking cursor at top left. console 1, witch I have > to manually switch to, shows the usual X shutdown stuff.) > > > - Could be some package leftover from your rawhide install causing > > issues, perhaps a 'yum list extras' to identify any packages that are > > not in repositories you have currently enabled? > > > > - Could you try and run xfwm4 under a debugger? > > 0) yum --enable-repo=core-debuginfo install xfwm4-debuginfo > yum --enablerepo=extras-debuginfo ........ :) > > > 1) Run X from a console, "xinit /usr/X11R6/bin/xterm &" > > 2) Switch to a console (Ctrl+Alt+F1) > > 3) Set the display "export DISPLAY=:0.0" > > 4) run "gdb /usr/bin/xfwm4" > > 5) if/when it crashes, run 'bt' and send me the backtrace. > > > > Well, it appears to be font related. I hope you can figure out what the > font problems is though. Does rm -f ~/.fonts.cache-2 \ ~/.rh-fontconfig/.fonts.cache-2 \ ~/.fonts/fonts.cache-2 fix things up? --Ray From shane at geeklords.org Mon Apr 3 01:04:05 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 18:04:05 -0700 (PDT) Subject: Elektra's technical suitablity In-Reply-To: <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> Message-ID: On Sun, 2 Apr 2006, Joe Desbonnet wrote: > As far as I can tell Elektra does not support configuration schemas. If I am not mistaken Elektra currently treats all plain text key values as strings. I think this is a feature and not a limitation. Elektra is friendly towards existing application configuration schemes. If it enforced key types (Integers, floats, strings etc...) things get a lot more complicated and it is not clear this is the right place to enforce it. Perhaps enforcing the input types at a configuration builder API makes more sense, keeping libelektra free of the added complexity? Cheers, Shane > > On 4/2/06, Shane Stixrud wrote: >> On Sun, 2 Apr 2006, Avi Alkalay wrote: >> >>> http://www.libelektra.org/Gnome_and_KDE_Integration >>> >> >> This thread has gotten off track IMO. Does anyone care to critique >> Elektra from a technical stand point on its suitability as a Fedora >> configuration engine? >> >> So far the technical critiques have been based on invalid assumptions. From avi at unix.sh Mon Apr 3 01:27:46 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 22:27:46 -0300 Subject: Elektra's technical suitablity In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> Message-ID: Exactly. Since Elektra was designed to absolutely any type of software, even to no-software, we tryed to keep it as simple as possible. The more we optimize it for some specific need, we deoptimize it for some other. However, you can put some layer of schematics on top of it. This is exactly what GConf with Elektra as its backend is: use GConf API, GConf namespaces, GConf semantics, GConf schemas, and Elektra only for the storage and sharing with everybody else (KDE, etc). I personally think schemas add too much complexity to the application programmer, make his life more difficult, and inhibits him to interact with other softwares configurations. But this is my opinion and we don't have to discuss that.... Avi On 4/2/06, Shane Stixrud wrote: > On Sun, 2 Apr 2006, Joe Desbonnet wrote: > > > As far as I can tell Elektra does not support configuration schemas. > > If I am not mistaken Elektra currently treats all plain text key values as > strings. I think this is a feature and not a limitation. Elektra is > friendly towards existing application configuration schemes. If it > enforced key types (Integers, floats, strings etc...) things get a lot more > complicated and it is not clear this is the right place to enforce it. > > Perhaps enforcing the input types at a configuration builder > API makes more sense, keeping libelektra free of the added complexity? > > Cheers, > Shane From avi at unix.sh Mon Apr 3 01:31:07 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 22:31:07 -0300 Subject: Elektra's technical suitablity In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> Message-ID: Oh, and for anybody that wants to try Elektra, Fedora/RHEL/CentOS RPMs are available here: http://sourceforge.net/project/showfiles.php?group_id=117521 (There are some patches to X.org and /sbin/init there too. Patches to other softwares can be found in Elektra source tree) Don't forget to download kdbedit too, for a GUI experience: http://sourceforge.net/project/showfiles.php?group_id=117521&package_id=177718 Avi From jdesbonnet at gmail.com Mon Apr 3 01:38:00 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Mon, 3 Apr 2006 02:38:00 +0100 Subject: Elektra's technical suitablity In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> Message-ID: <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> Strings would be a sensible default in the absense of a schema, but I think you could do so much more if you had the *option* to have a schema in the infrastructure. For each field the schema would define the data type (string, integer, date, ip, username, enum etc), constrains on the values (eg "must be integer between 1-5"), a help text or hyperlink to help, and GUI hints (eg widget preferences: pulldown menu vs radio buttons, tab groupings etc). So instead of a system-config-blah for each application, you just have one system-config tool that autogenerates a GUI based on schema. Joe. On 4/3/06, Shane Stixrud wrote: > If I am not mistaken Elektra currently treats all plain text key values as > strings. I think this is a feature and not a limitation. Elektra is > friendly towards existing application configuration schemes. If it From avi at unix.sh Mon Apr 3 01:43:26 2006 From: avi at unix.sh (Avi Alkalay) Date: Sun, 2 Apr 2006 22:43:26 -0300 Subject: Elektra's technical suitablity In-Reply-To: <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> Message-ID: I understand the value and importance of that, but I'm afraid this is out of the Elektra scope. Such semantics and functionality should go in a GConf or KConfig XT layer. Avi On 4/2/06, Joe Desbonnet wrote: > Strings would be a sensible default in the absense of a schema, but I > think you could do so much more if you had the *option* to have a > schema in the infrastructure. > > For each field the schema would define the data type (string, integer, > date, ip, username, enum etc), constrains on the values (eg "must be > integer between 1-5"), a help text or hyperlink to help, and GUI hints > (eg widget preferences: pulldown menu vs radio buttons, tab groupings > etc). > > So instead of a system-config-blah for each application, you just have > one system-config tool that autogenerates a GUI based on schema. > > Joe. From shane at geeklords.org Mon Apr 3 01:48:06 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 18:48:06 -0700 (PDT) Subject: Elektra's technical suitablity In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> Message-ID: On Sun, 2 Apr 2006, Avi Alkalay wrote: > I understand the value and importance of that, but I'm afraid this is > out of the Elektra scope. > Such semantics and functionality should go in a GConf or KConfig XT layer. > I can see value in a schema library that is optional and elektra aware for non kde/gnome applications. Something that encourages good semantics, but I agree that should be separate. Cheers, Shane From jdesbonnet at gmail.com Mon Apr 3 01:59:11 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Mon, 3 Apr 2006 02:59:11 +0100 Subject: Elektra's technical suitablity In-Reply-To: References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> Message-ID: <1cef3e950604021859y246e6c90nac23974dc610b5d9@mail.gmail.com> Has anyone done work on configuration schemas before (eg white paper document or code)? Joe. On 4/3/06, Shane Stixrud wrote: > I can see value in a schema library that is optional and elektra aware for > non kde/gnome applications. Something that encourages good semantics, but > I agree that should be separate. > > Cheers, > Shane > From seandarcy2 at gmail.com Mon Apr 3 01:59:25 2006 From: seandarcy2 at gmail.com (sean) Date: Sun, 02 Apr 2006 21:59:25 -0400 Subject: rawhide->fc5; X won't start In-Reply-To: <1144021704.5901.4.camel@halflap> References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <20060401.104056.705159298.kevin@scrye.com> <1144021704.5901.4.camel@halflap> Message-ID: Ray Strode wrote: > Hi, >> " == sean writes: >>> sean> I installed xfce to see if it was a gnome/kde problem. Here's >>> sean> what shows on the xfce console: >>> >>>>> (==) Using config file: "/etc/X11/xorg.conf" /usr/bin/startxfce4: X >>>>> server already running on display :0 Agent pid 4100 which: no >>>>> xfce4-session in >>>>> (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/NX/bin:/root/bin) >>>>> (xfce-mcs-manager:4103): libxfce4mcs-CRITICAL **: >>>>> mcs_manager_add_channel_from_file: assertion `filename != NULL && >>>>> strlen (filename) > 0' failed /etc/xdg/xfce4/xinitrc: line 106: >>>>> 4105 Segmentation fault xfwm4 --daemon ** Message: Cannot connect >>>>> to session manager /etc/xdg/xfce4/xinitrc: line 123: 4108 >>>>> Segmentation fault xfcalendar /etc/xdg/xfce4/xinitrc: line 123: >>>>> 4110 Segmentation fault $panel >>> sean> So X appears to start - Fedora logo comes up; no error on >>> sean> Xorg.0.log. >>> >>> sean> But no gui's will start - not gnome,kde or xfce. Does this mean >>> sean> X isn't starting correctly so that the gui's can start? If not, >>> sean> what happens between X coming up and the gui's starting? >>> >>> sean> metacity? Is there any way to cause metacity to do verbose >>> sean> logging? >>> >>> sean> Again, is there any way to get more verbose and clearer logs. >>> >>> sean> Or any other hints? >>> >>> Well, not sure on gnome or KDE, but the above Xfce output looks like >>> the problem is the Seg faults when trying to start up. :( >>> >>> Several other things to try: >>> >>> - If you create a new fresh user, can they login ok? >>> (This would point to it being you users gtk theme, fonts setup or the >>> like). >>> >> Yes! I can login as a new user. Switched xorg.conf back to using xfs, >> and that worked to. >> >> ( Oddly, when I logout as the new user, I'm left at console 7 with a >> black screen and a blinking cursor at top left. console 1, witch I have >> to manually switch to, shows the usual X shutdown stuff.) >> >>> - Could be some package leftover from your rawhide install causing >>> issues, perhaps a 'yum list extras' to identify any packages that are >>> not in repositories you have currently enabled? >>> >>> - Could you try and run xfwm4 under a debugger? >>> 0) yum --enable-repo=core-debuginfo install xfwm4-debuginfo >> yum --enablerepo=extras-debuginfo ........ :) >> >>> 1) Run X from a console, "xinit /usr/X11R6/bin/xterm &" >>> 2) Switch to a console (Ctrl+Alt+F1) >>> 3) Set the display "export DISPLAY=:0.0" >>> 4) run "gdb /usr/bin/xfwm4" >>> 5) if/when it crashes, run 'bt' and send me the backtrace. >>> >> Well, it appears to be font related. I hope you can figure out what the >> font problems is though. > > Does > rm -f ~/.fonts.cache-2 \ > ~/.rh-fontconfig/.fonts.cache-2 \ > ~/.fonts/fonts.cache-2 > > fix things up? > I'll do that, but shouldn't fc-cache -f ( which I've done) do he same thing? In any case, I do NOT have a ~/.fonts dir. should I? If so, what do I install to get it, or is it just user fonts. sean From rdieter at math.unl.edu Mon Apr 3 02:33:35 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 02 Apr 2006 21:33:35 -0500 Subject: Samba 4 In-Reply-To: <1144009469.2981.5.camel@wks1.myhost.net> References: <1144009469.2981.5.camel@wks1.myhost.net> Message-ID: <4430897F.6020100@math.unl.edu> Joseph Harnish wrote: > I am not sure what the road map looks like for Samba 4 but I would be > interested in testing that. Is this something that we need to wait for > it to be closer to production ready? Or can we get it in the dev tree? AFAICT, samba4 is still nowhere near ready for even rawhide/devel. -- Rex From rstrode at redhat.com Mon Apr 3 02:29:42 2006 From: rstrode at redhat.com (Ray Strode) Date: Sun, 02 Apr 2006 22:29:42 -0400 Subject: rawhide->fc5; X won't start In-Reply-To: References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <20060401.104056.705159298.kevin@scrye.com> <1144021704.5901.4.camel@halflap> Message-ID: <1144031382.31042.3.camel@halflap> Hi, > I'll do that, but shouldn't fc-cache -f ( which I've done) do he same > thing? You'd think, but there might be a bug somewhere. I'm really just guessing at this point. The thing is, for a while in rawhide fontconfig was really broken and generated broken font cache files. It seems like you might be hitting that. > In any case, I do NOT have a ~/.fonts dir. should I? If so, what do I > install to get it, or is it just user fonts. it's just for user fonts, if you don't have it no big deal. --Ray From brads at redhat.com Mon Apr 3 04:26:14 2006 From: brads at redhat.com (Brad Smith) Date: Mon, 03 Apr 2006 00:26:14 -0400 Subject: Suspend problems on a thinkpad? Message-ID: <4430A3E6.3070109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has anyone found a trick for (or even had a problem) getting suspend to work properly under FC5 on a Thinkpad T30? Under FC4 everything worked fine on mine, I just had to include "apm=on acpi=off" in the kernel args. After a fresh install of FC5, with or without the kernel args, it is a no go. When I close the laptop it goes into suspend, but when I open it again I experience varying levels of freezing up. I say varying because sometimes it's locked completely, sometimes the mouse moves but the cursor does not change, clicks are unresponsive and the keyboard does nothing. One time things seemed to work but when I moved my mouse over the gnome panel it disappeared. I switched to a VC and back, which somehow fixed the problem. Needless to say this is a major obstacle for me. Can anyone help? Thanks in advance! - --Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEMKPmDvp49DvQ8kcRAn4uAJwMooj3hzAq1KCDAFfVNi5uThrdnwCfSrS+ 1KKWUO4Z9uuL+Ec93l94OFs= =5LOx -----END PGP SIGNATURE----- From shane at geeklords.org Mon Apr 3 04:44:20 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 21:44:20 -0700 (PDT) Subject: Suspend problems on a thinkpad? In-Reply-To: <4430A3E6.3070109@redhat.com> References: <4430A3E6.3070109@redhat.com> Message-ID: On Mon, 3 Apr 2006, Brad Smith wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Has anyone found a trick for (or even had a problem) getting suspend to work properly under FC5 on a > Thinkpad T30? Under FC4 everything worked fine on mine, I just had to include "apm=on acpi=off" > in the kernel args. After a fresh install of FC5, with or without the kernel args, it is a no go. > When I close the laptop it goes into suspend, but when I open it again I experience varying levels > of freezing up. I say varying because sometimes it's locked completely, sometimes the mouse moves > but the cursor does not change, clicks are unresponsive and the keyboard does nothing. One time > things seemed to work but when I moved my mouse over the gnome panel it disappeared. I switched to a > VC and back, which somehow fixed the problem. Well suspend works fine on my T41 thinkpad, it is resume that kills my system ;). In my case it resumes fine everything works for a few seconds to a minute and then I get major disk errors in dmesg, disk mounts read-only then system crashes, but not before I get disk corruption :(. Sounds like your problem might be a bit different? I opened a bugzilla on my issue here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187633 Cheers, Shane From bojan at rexursive.com Mon Apr 3 04:55:21 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 03 Apr 2006 14:55:21 +1000 Subject: 'Commercial Partners' Message-ID: <20060403145521.wx0j1z1fk0ssk8gg@www.rexursive.com> Quoting "Eric S. Raymond" : > I think I explained this in some datail earlier. We need market power > in order to stave off a future where we get DRMed and EULAed to death > because hardware manufacturers figure all they have to do is serve the > Windows & Intel Mac markets. Down that road lie video cards we can't > use and on-the-mobo TPM to lock us out. A little bit too late for that, IMHO. "Content providers" already know that: 1. They can do this legally (ie. patents/DRM are reality) 2. They have widespread platforms to do it (Mac/Win+PC/iPod etc.) 3. They will come up with new patents/laws to prevent us from entering This is a game of catch-up that we'll never win. Once "content providers" tasted consumer blood with patents/DRM, I'm willing to bet they'll want more of it, not less. Any attempt to wedge anything "free" (in whichever sense of the word) right smack in the middle, will be met with (threats of) lawsuits. It's just a matter of time before we see this happen. And my bet is that making it easier to install an MP3 player on Fedora is going make about zero difference. I'm afraid most of us don't have access to boardrooms in which decisions about the future of copyright, patents, "content" and hardware is made. If all desktop/notebook/consumer hardware went DRM/TPM tomorrow, hardware manufacturers would stand to lose such small percentage of sales that they wouldn't think twice about cutting us off. Call me cynical if you wish... -- Bojan From wtogami at redhat.com Mon Apr 3 05:03:54 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 03 Apr 2006 01:03:54 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> Message-ID: <4430ACBA.9040204@redhat.com> Eric S. Raymond wrote: > I know at least one fairly influential kernel developer who threw out > Red Hat/Fedora in disgust over this. When he asked me straight up how > I could defend what he bluntly called 'corporate cowardice', I didn't > feel like I had a good answer. And I still don't. In return for all > the free development work they get, it does seem to me that it's part > of Red Hat's job to shoulder risks like these -- and that Red Hat > hasn't held up its end. > > AVI. Quicktime. ASF. MPEG. DVD playback. Flash. Java. These are *not > optional* in 2006, any more than the ability to read Microsoft Word > files in a word processor is optional; if we try to treat them that > way, consumers will blow Linux off. Eric, you are completely divorced from reality if you truly think this is safe and prudent. You are essentially asking Red Hat to become a martyr and destroy itself. Would that really be good for the community? What you advocate will not win this war in the long-run. These are not technical or community growth problems, but tough political and legal issues that we cannot simply ignore because it would be convenient. Red Hat instead uses *REALISTIC* means with its relatively small resources (compared to the big pro-patent industry players) to slowly maneuver in long-term strategic actions against software patents on a global scale. http://gregdek.livejournal.com/4008.html Red Hat made progress with the OIN patent alliance in this one way. OIN through mutual assured destruction creates some level of patent defense for certain Open Source Software from attack from companies like Microsoft. Search Google for "Red Hat Software Patents" and see how Red Hat fights on many fronts in both politics and business ways worldwide. Unfortunately OIN is not a defense against "IP only" companies that are plaguing traditional software companies with big pockets like Microsoft. (Search for "Microsoft Eolas" for an example.) Due to the threat of "IP only" companies where traditional companies are not able to retaliate using their patent portfolios, the biggest patent holder IBM is calling for reforms in the way patents are granted. Hopefully this signals the beginning of a backwards slide against bad patents. I'd call this the beginning of progress. Red Hat spends resources worldwide to fight software patents being ratified (like in Europe), and protects some OSS today within the current broken system through these business alliances. Red Hat itself files for its own patents, but by our "Patent Promise", these patents are used in defense of OSS. Any OSS has a perpetual, irrevocable royalty free right to use it. The patent submission process is not cheap. The actions and resources Red Hat uses to fight software patents and protect the future of FOSS is "corporate cowardice"? Red Hat engages in substantive actions to fight software patents. Do you? > > 2. We can put real resources into developing a decoder implementation > the blocking patents don't cover, and accept the risk that the > patent-holders will launch harassment lawsuits anyway as a cost of > doing business. The real problem here is not technology but politics and law. You are proposing that we simply ignore the actual problem and *HOPE* that nothing bad happens. > > 3. We can buy the rights to the technologies we want as a straight > commercial transaction from the patent-holder. > Fedora distributes only 100% Free and Open Source Software. FOSS requires software to be freely modifiable and freely redistributable. Paying a royalty for Fedora to distribute something like MPEG for DVD capability would make it not Free, because that removes the ability for others to redistribute the software. > Let's start with the basics. For a consumer OS to be unable to play > MP3s and handle podcasts is just plain not acceptable, not in the > world after iTunes. Red Hat/Fedora's duck-and-cover on this would be > understandable if the Fraunhofer patents blocked decoders, but > Fraunhofer itself has only dunned for royalties on *encoders* -- thus > Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed. Get Fraunhofer to put into writing a perpetual and irrevocable royal free license for FOSS to utilizes their algorithm. I challenge you to make this happen. Come back when you've made some progress like this. Meanwhile, please stop claiming that Red Hat is being a "coward" by not fighting in the global software patent war, because this assertion is blatantly incorrect. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Apr 3 05:10:24 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 03 Apr 2006 01:10:24 -0400 Subject: Fedora Art Team Now Open In-Reply-To: <200603280950.k2S9oqre022074@snark.thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> Message-ID: <4430AE40.3080108@redhat.com> Eric S. Raymond wrote: > First, a relatively minor issue that is nevertheless quite annoying. > It's the Fedora distribution art, the images in Anaconda and the > Fedora-customized graphics in the admin tools and elsewhere. It has > never been much better than mediocre, and in FC5 it hits a new low > with backgrounds that look like a Teletubby hocked loogies into a > dish full of soap scum. And whose bright idea, I have to wonder, was > it to abandon the attractive and recognizable Fedora icon for > something that's...not a fedora? > > Cripes. By comparison, even the original BlueCurve was superior. And > original BlueCurve wasn't much to cheer about compared to the > decorative art on a Windows or (especially) a Mac -- acceptable, but > not a competitive plus, not something that would actually attract > users. The FedoraBubbles stuff is bland and tacky goo that I expect > will repel them. It didn't become terrible, but I personally believe that the artwork in FC5 was a small step backwards. I think maybe we could improve this situation in the future by treating artwork as a community project with feedback and (maybe) voting, rather than impose it on the community. Perhaps the FC6 desktop background could be made into an art contest with judging and prizes. http://www.redhat.com/mailman/listinfo/fedora-art-list fedora-art-list is now open, where hobbyists and professionals can work together in order to create some kind of organization around Fedora Artwork. There are already several goals in place like writing down specifications and the color palette of the Bluecurve theme and creating a process to contribute art. Join the team, figure out what the goals are and who is interested to work on them, and we can have a community meeting on IRC sometime soon to form some kind of organization. Warren Togami wtogami at redhat.com From david at fubar.dk Mon Apr 3 05:27:00 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 3 Apr 2006 01:27:00 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> Message-ID: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote: > In addition to the words bellow, the "D" on D-Conf comes from the > "Desktop" word, which means D-Conf is a desktop-oriented wannabe- > project. You won?t be able to standarize configuration for say > named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network > configurations, etc etc etc with it. Speaking of wanna-be. I think one fundamental problem with the LinuxRegistry/Elektra approach is that you try to fix the symptoms of the problem instead of the root problems. I've written about this before and I will do it again and again as apparently people are still trying to fix the symptoms of our problem: Configuration of software in a mainstream distribution is a mess. Most of this mail is about the desktop, but really, if you look at it, desktop is _a lot harder_ than server (there is just so much more code and so much more functionality) so my view is that if we solve it for desktop then the server bits will pan out mostly by itself. It seems that Elektra simply wants to remap the configuration file for a piece "software" into a hierarchical key/value database and I think that's missing the point entirely. First of all you got to ask yourself whether there should be a configuration of said piece of software in the first place. If you think really hard about it you will find that for most pieces of software this is false - you really don't want any configuration files... Hence you really don't want nor need Elektra. Let us look at what "configuration" really means; I've seen it being used in the following ways - The programmer is lazy and makes the user look up configuration values he could have determined programmatically - for example this includes the laptop_mode scripts where you can configure what IDE drives to put to sleep. The poor user will have to put in arcane values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe the laptop_mode developer wasn't that lazy, maybe the kernel people was just sleeping and gave him no easy way to find out what drives to put to sleep when he wants.. or maybe what the kernel said was unreliable and the kernel never got fixed.... Does this justify bothering the poor end user with crap like this? I think not. - Configuration can be system-wide, for example mail and web servers... Sure, my web server needs to know where to serve files from, my mail server needs to know what domain it serves and so forth - When developers write a daemon and decide to make it system-wide, then most of the time they either really want it to be site-wide or session-wide instead. Most of the time they don't even know this... I will argue that system-wide is just plain wrong for most things; continue reading... - Site-wide software: This includes for example a cluster of web servers. The user experience if I'm an administrator is that I can just plug in another physical server box, PXE-boot it and it reads all "web server configuration" from LDAP. If it blows up I can replace it. Hence, no need at all for having some httpd.conf file. For the (terribly uninteresting) case of only having one machine as a web server it reads settings from the local LDAP server. Ditto with mail servers, name servers etc. - Session-wide software: Just so we're all on the same page, "session-wide" means something that runs in a user desktop session. Historically, the desktop wasn't very advanced and didn't integrate well with the system. Back then things that really was session-wide would run as a system-wide daemon mostly also because it required root to enforce policy. Things like acpid for power management event handling, updfstab for removable media, ifplugd for handling network cable removable, networking scripts etc. comes to mind. As you can see with Fedora Core 5 this is radically starting to change; acpid is obsoleted by gnome-power-manager, updfstab (and fstab-sync for that matter) is obsoleted by gnome-volume-manager / gnome-mount, the networking scripts is starting to be completely obsoleted by NetworkManager. We have more things on out "hit list"... - You really really want session-wide daemons to run in the session and not as the system because it's much easier for the user to configure it.. in fact, you get per-user settings for removable media handling and power management in FC5. And since all this is backed by gconf it's easy for the OS vendor _and_ the administrator to set sane defaults, lock things down and so forth. It's just a lot better - Look at the terrible and insecure hacks for writing out configuration files for system-wide daemons that ought to be session- wide. See also my rant on fedora-maintainers last week why consolehelper (that these tools rely on) is fundamentally flawed. - Things like smb.conf is really not interesting for the desktop case as it's the wrong solution to the problem of sharing files and using files other systems wants to share. The right answer here is obviously things like Nautilus and gnome-user-share and other things that run in your session and is easy to configure. - X.org having a configuration is completely broken too; obviously the X.org server should be able to configure itself (and it can but X.org itself has bugs so it doesn't always work) and it should offer a D-BUS interface for reconfiguration so some per-session piece of software can program it with the users setting when your session starts. Yes, display configuration is also per-user although the brain dead design of X.org doesn't reflect this. I don't have a good answer to KDE and GNOME sharing configuration; I personally think that as this point it's impossible to get developers of both camp to agree on a scheme for even simple things like desktop backgrounds and HTTP proxies. And should the day come when gconf depends on KConfig, vice versa, or when there is D-Conf I'm sure this will get solved by itself. It sure as hell doesn't need Elektra for this. So my message is that I think it's a waste of time trying to shoehorn a configuration file format onto all kinds of software because said software is likely to be already broken for at least desktop use. My stance is simply that it's unacceptable in a desktop system to ever ever have to touch a configuration file and I think some people (*cough* Apple *cough* Microsoft *cough*) take the same stance even for the server. So we shouldn't ship software that rely on them. Hence, there is zero need for Elektra. It's really that simple if you think about it. I wish that people working on the server bits (e.g. Apache, Postfix) would take a similar stance and only make their software read settings from LDAP (or whatever) for the site-wide case. I think it would be great if you could change Elektra into something that would fix this. But please back off trying to pretend you solve problems for the desktop because you're not. The design of gconf is pretty nice (implementation might be another matter but, you know, that's totally fixable) and it's more than sufficient for desktop use, thank you very much. Hope this clarifies why Elektra is simply the wrong answer. I'm sorry for sounding harsh and saying most of our software in the distribution is broken, but it's kinda this conclusion I've arrived at. We could do so much better if we all tried to solve the root problems and look at what the user experience should be. Have a nice day. David Disclaimer : this mail doesn't necessarily reflect the views of Red Hat, Inc. From sundaram at fedoraproject.org Mon Apr 3 05:42:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 03 Apr 2006 11:12:11 +0530 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <1144042932.3783.112.camel@sundaram.pnq.redhat.com> On Mon, 2006-04-03 at 01:27 -0400, David Zeuthen wrote: > > - Session-wide software: Just so we're all on the same page, > "session-wide" means something that runs in a user desktop session. > Historically, the desktop wasn't very advanced and didn't integrate > well with the system. Back then things that really was session-wide > would run as a system-wide daemon mostly also because it required > root to enforce policy. Things like acpid for power management event > handling, updfstab for removable media, ifplugd for handling network > cable removable, networking scripts etc. comes to mind. As you can > see with Fedora Core 5 this is radically starting to change; acpid is > obsoleted by gnome-power-manager, updfstab (and fstab-sync for that > matter) is obsoleted by gnome-volume-manager / gnome-mount, the > networking scripts is starting to be completely obsoleted by > NetworkManager. We have more things on out "hit list"... Are these grand plans written down somewhere? Any pointers? It would be good to let the rest of us know what is happening in advance. For example. fstab-sync being replaced gnome-mount might have been good in the longer term but the policy was changed to not show fixed disks by default (http://fedoraproject.org/wiki/Docs/Beats/PackageNotes). We didn't know about this and we only included this information after the ISO freeze for the release notes. Now that information has been to be pushed out as an errata and meanwhile it has been a FAQ and confused many end users. It would have been good to send the docs team a short note with rationale. Writing down publicly the development plans is just The Right Thing To Do(TM). Rahul From shane at geeklords.org Mon Apr 3 06:17:12 2006 From: shane at geeklords.org (Shane Stixrud) Date: Sun, 2 Apr 2006 23:17:12 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: On Mon, 3 Apr 2006, David Zeuthen wrote: > It seems that Elektra simply wants to remap the configuration file for a > piece "software" into a hierarchical key/value database and I think that's > missing the point entirely. First of all you got to ask yourself whether > there should be a configuration of said piece of software in the first place. > If you think really hard about it you will find that for most pieces of > software this is false - you really don't want any configuration files... > Hence you really don't want nor need Elektra. Software without configuration options what a novel idea... In all seriousness that day will come long after the paperless bathroom.... Cheers, Shane From david at fubar.dk Mon Apr 3 06:25:14 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 3 Apr 2006 02:25:14 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <2DC5B6B2-97A6-4CA2-B6B7-453CBCA0D48F@fubar.dk> On Apr 3, 2006, at 2:17 AM, Shane Stixrud wrote: > On Mon, 3 Apr 2006, David Zeuthen wrote: > >> It seems that Elektra simply wants to remap the configuration file >> for a piece "software" into a hierarchical key/value database and >> I think that's missing the point entirely. First of all you got to >> ask yourself whether there should be a configuration of said piece >> of software in the first place. If you think really hard about it >> you will find that for most pieces of software this is false - you >> really don't want any configuration files... Hence you really >> don't want nor need Elektra. > > Software without configuration options what a novel idea... In all > seriousness that day will come long after the paperless bathroom.... My point was that you don't want _configuration files_, of course you need configuration for some, even most, pieces of software. Another point was that this configuration should be read from either the desktop session _or_ some remote LDAP server. Maybe if you read my whole mail before replying this would have been clear. David From tla-ml at rasmil.dk Mon Apr 3 07:11:51 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 03 Apr 2006 09:11:51 +0200 Subject: Suspend problems on a thinkpad? In-Reply-To: <4430A3E6.3070109@redhat.com> References: <4430A3E6.3070109@redhat.com> Message-ID: <4430CAB7.5010603@rasmil.dk> Brad Smith wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Has anyone found a trick for (or even had a problem) getting suspend to work properly under FC5 on a > Thinkpad T30? Under FC4 everything worked fine on mine, I just had to include "apm=on acpi=off" > in the kernel args. After a fresh install of FC5, with or without the kernel args, it is a no go. > When I close the laptop it goes into suspend, but when I open it again I experience varying levels > of freezing up. I say varying because sometimes it's locked completely, sometimes the mouse moves > but the cursor does not change, clicks are unresponsive and the keyboard does nothing. One time > things seemed to work but when I moved my mouse over the gnome panel it disappeared. I switched to a > VC and back, which somehow fixed the problem. > > Needless to say this is a major obstacle for me. Can anyone help? > > Thanks in advance! > - --Brad > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFEMKPmDvp49DvQ8kcRAn4uAJwMooj3hzAq1KCDAFfVNi5uThrdnwCfSrS+ > 1KKWUO4Z9uuL+Ec93l94OFs= > =5LOx > -----END PGP SIGNATURE----- > > My T30 suspends/resumes without any problems in FC5, It takes a little time to wakeup, but is works great. I have not done any modification. Tim From buildsys at redhat.com Mon Apr 3 07:19:03 2006 From: buildsys at redhat.com (Build System) Date: Mon, 3 Apr 2006 03:19:03 -0400 Subject: rawhide report: 20060403 changes Message-ID: <200604030719.k337J3pU012123@porkchop.devel.redhat.com> Updated Packages: cups-1:1.2-0.2.rc1.5 -------------------- * Sun Apr 02 2006 Tim Waugh 1:1.2-0.2.rc1.5 - Backported svn 5365:5366 change for mutex-protected stringpool. * Sat Apr 01 2006 Tim Waugh - Fixed _cupsStrFree() (STR #1529). fetchmail-6.3.3-3 ----------------- * Sat Apr 01 2006 Miloslav Trmac - 6.3.3-3 - Fix fetchmail-6.3.3-resolv.patch kernel-2.6.16-1.2114_FC6 ------------------------ * Sat Apr 01 2006 Dave Jones - 2.6.16-git20 libXfont-1.1.0-1 ---------------- * Sat Apr 01 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 for crash fix and new headers scim-1.4.4-12 ------------- * Mon Apr 03 2006 Jens Petersen - 1.4.4-12 - update to scim-bridge-0.1.3 - no longer need to bootstrap wpa_supplicant-1:0.4.8-7.fc6 ---------------------------- * Sun Apr 02 2006 Dan Williams - 0.4.8-7 - Work around older & incorrect drivers that return null-terminated SSIDs xfsprogs-2.7.11-1 ----------------- * Sun Mar 12 2006 Robert Scheck 2.7.11-1 - Upgrade to 2.7.11 and spec file cleanup (#185234) xorg-x11-proto-devel-7.0-9 -------------------------- * Sat Apr 01 2006 Adam Jackson 7.0-9 - Update to scrnsaverproto-1.1 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 kdepim - 6:3.5.1-1.2.i386 requires libpisock.so.9 Broken deps for ia64 ---------------------------------------------------------- kdepim - 6:3.5.1-1.2.ia64 requires libpisock.so.9()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- kdepim - 6:3.5.1-1.2.ppc requires libpisock.so.9 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 kdepim - 6:3.5.1-1.2.ppc64 requires libpisock.so.9()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 kdepim - 6:3.5.1-1.2.x86_64 requires libpisock.so.9()(64bit) From db-fedora at 3di.it Mon Apr 3 07:39:58 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Mon, 03 Apr 2006 09:39:58 +0200 Subject: 'Commercial Partners' In-Reply-To: References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com> <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331201705.GH4133@redhat.com> <1143839593.2561.60.camel@rousalka.dyndns.org> Message-ID: <4430D14E.6060006@3di.it> sean wrote: > Right now some great work is going into open source drivers for some > high end ATI hardware. Not there yet, but coming along nicely. > As well, there is a BeOS open source driver for some pretty recent > nVidia hardware, with a chance that it will be ported over to Linux. A breath of fresh air. Could you provide links for either ? Davide Bolcioni -- There is no place like /home. From andy at warmcat.com Mon Apr 3 07:45:39 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 03 Apr 2006 08:45:39 +0100 Subject: Closed OSes exist for Closed content In-Reply-To: <20060402054828.GD6796@thyrsus.com> References: <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> Message-ID: <4430D2A3.4060408@warmcat.com> Eric S. Raymond wrote: > Andy Green : >>> wants the desktop and what it's prepared to do to get it. It ties >>> into a larger issue about what the Linux community needs to do to >>> thrive under competitive pressure, which *is* a question for Fedora. >> What does "competitive pressure" mean in the context of a Free OS? > > Competitive pressure for market share from Windows and MacOS, of course. I'm no wiser after hearing that "competitive pressure" means "competitive pressure". The Free OSes don't really compete for seats in the same way that a commercial OS does, because the model allows one copy of the install media to bleed into and dupe itself wherever it is wanted. If that is one seat or 1,000 it makes little difference to a Free OS like Fedora since it has no per-seat income. > I think I explained this in some datail earlier. We need market power > in order to stave off a future where we get DRMed and EULAed to death Patent law and content protection laws like the DMCA and EUCD give huge punitive powers to the folks that originate "technological protection measures" and Copyright law itself totally gives copyrightholders the power to license content only to non-Free OSes or devices and to cut out Free solutions. They are motivated to do so because they hope to restrict unauthorized copying. Therefore the content that the lumpenprolitariat people want, to watch DVDs, HDTV media content, HDTV downloads is definitively out of the reach of Free OSes unless fashion changes and en clar content like CD Audio or VHS is the norm. (I see Bojan Smojver has made my points on this already). Vista will have it all at a cost as will OSX and you can say then "that is what they are for". For all other usage that does not require it -- that's quite a lot, like your standard Office PC, Linux is getting really quite ready to leak into and then floodfill that space. The content IS DRM'd going on and it is hard to see legit players for it licensed on Linux other than highly exotic ones with signed binary drivers, a signed kernel coming up from TPM, basically making your box un-Free. It's clear that traditional restrictively licensed media is inherently anti-Free, since the last thing you can do with it is copy it around, but the crypto goes one step further and makes it actively evil, since it tries to pervert people away from Free OSes on to platforms controlled by the originators to actually play it. "Market power" in the form of a lot of Free boxes will only harden the crypto-locked media providers against allowing decode on that 'dangerous' 'widespread' 'out of their control' platform, not strongarm them into it. > because hardware manufacturers figure all they have to do is serve the > Windows & Intel Mac markets. Down that road lie video cards we can't > use and on-the-mobo TPM to lock us out. "serving Windows + Intel Mac" is not the same as "video cards we can't use", and that is not the same as "linux dying". Still, advanced features of video cards are closed even today, it is a sore point in an otherwise pretty decent driver landscape. TPM to bind the OS-at-the-time-of-sale to the motherboard is possible. As things stand though all PC motherboards, excluding the Xbox 1, are pretty much agnostic about OS. Only Apple seems to want to change that. If it catches on there are serious and obvious Antitrust problems. BTW: https://www.trustedcomputinggroup.org/downloads/background_docs/TCGBackgrounder_revised_012605.pdf '' ... 4. Initialization and management functions that allow the owner to turn functionality on and off, reset the chip, and take ownership, with strong controls to protect privacy. The system owner is trusted and must opt-in. The user, if different from the owner, may opt-out if desired. ...'' (p6) >> - Why shouldn't a dramatic growth of Linux on the Desktop have the >> opposite effect of triggering an apocalypse of attacks from MSFT on >> their various desktop-related patents? > > That will happen once we do *anything* to piss off Microsoft enough, > whether it's the fast-growth scenario I want to see or the boil-the-frog- > slowly scenario you think is good enough. So it's kind of a wash. They have to be able to show damages to launch a painful attack, showing that say 10% of their market share was lost to Linux due as they might claim to unlawful use of the patented stuff will serve for that. It's harder if a lost-in-the-noise 0.5% is bleeding away year by year. So it's not all the same. >> - Why is the current frog-boiling method while Linux and the Free apps >> improve and establish themselves deeper and deeper not good enough? > > Because it's not getting us any desktop penetration to speak of. > >> - In your theory, is Linux in the embedded space going to die too >> because MSFT continue to have ~90% of desktops? > > No, but lots of Linux in the embedded space doesn't solve our problem either. > Puts no pressure on the video-card makers, for one thing. Summary: - "Linux" will go on regardless, there is no 'die'. "Linux" is a very broad thing: patent attacks may chop bits out case by case. The urgency and level of threat you have been talking about are false propositions, probably brought on by Vista-angst - You raise video cards becoming more closed as the other cost of not getting enough marketshare, it's certainly possible. It's not obvious what kind of lost market would prompt action. So far there is support for the mass market video cards one way or another. - You raise DRM as the cost of failure to get marketshare, but DRM is not sensitive to Free OS Marketshare because it will not target it, only closed platforms by definition. Therefore there is no possibility to legally compete with modern media playback, even DVD. Therefore this whole stack of capability is ceded to paid-for, closed OSes. - Closed OSes are given a role and meaning in the world by the above. If you don't like it then Copyright and Patent law are the enemies. You can fight it by encouraging liberally licensed media, donations at Jamendo.com made me feel better about it. - Cracked, quite possibly illegal solutions exist for nonpermitted media playback: as a project, aside from what we do as individuals, if Fedora stands for encouraging that in order to get "market share" we will have become MSFT. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From uraeus at gnome.org Mon Apr 3 08:14:18 2006 From: uraeus at gnome.org (Christian Fredrik Kalager Schaller) Date: Mon, 03 Apr 2006 10:14:18 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <1144052058.2303.2.camel@localhost.localdomain> On Sun, 2006-04-02 at 23:17 -0700, Shane Stixrud wrote: > On Mon, 3 Apr 2006, David Zeuthen wrote: > > > It seems that Elektra simply wants to remap the configuration file for a > > piece "software" into a hierarchical key/value database and I think that's > > missing the point entirely. First of all you got to ask yourself whether > > there should be a configuration of said piece of software in the first place. > > If you think really hard about it you will find that for most pieces of > > software this is false - you really don't want any configuration files... > > Hence you really don't want nor need Elektra. > > Software without configuration options what a novel idea... In all > seriousness that day will come long after the paperless bathroom.... Well paperless bathrooms with a bidet has been around for over 300 years now. Christian From nicolas.mailhot at laposte.net Mon Apr 3 08:18:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Apr 2006 10:18:40 +0200 (CEST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <16de708d0603280043x13e34051k74009dc7f6604b1f@mail.gmail.com> <20060328040953.17819ad1.seanlkml@sympatico.ca> <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> Message-ID: <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> Le Dim 2 avril 2006 20:50, Shane Stixrud a ?crit : > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > >>>> Again, if you think the problem is on the user side you've already >>>> lost >>>> it. >>> >>> That's interesting.... others said the problem was on the user side... >>> and >>> you are saying its on the programmers side... >> >> The problem is on the user side >> The solution is on the programmers side. >> >> Which is why analysing the problem from the software writer POW (generic >> API) won't get us anywhere > > Now you are just talking double talk. No. What you absolutely do not want to hear is that system with consistent configuration system APIs are just as bad on the user than Unix configuration files. In fact they are often *worse* because thay make conf file manipulation so transparent for the sotware writer files are cluttered with bad keys and key values. To the point that the *only* way of recovering apps is locate their conf and zap it. As for versionning ROTFL the only sane approach to conf file versionning is thinking *long* before adding a key and not changing its name or semantics every other version. You can add as many software versionning tools as you want the simple fact is if your syntax changes every release no one will be able to keep up with you. Even if you have a massive expert system at your disposal. This is not to say something like elektra wouldn't help a bit, but you're massively overhyping its benefits and underestimating the transition costs. And the fact you're refusing to hear what people tell you does not help you build a solid case. Who cares if elektra is slightly faster than competitors. Who cares is backup is slightly easier. Hardware is getting faster and faster. Humans are not - and right now given none of the pro-elektra arguments is about making human job easier, my feeling is you're massively micro-optimising the wrong place. GConf started much the same way as elektra. I didn't notice it making user or admin life easier. I could be wrong of course. This had been known to happen. -- Nicolas Mailhot From shane at geeklords.org Mon Apr 3 08:29:45 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 01:29:45 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144052058.2303.2.camel@localhost.localdomain> References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <1144052058.2303.2.camel@localhost.localdomain> Message-ID: On Mon, 3 Apr 2006, Christian Fredrik Kalager Schaller wrote: >> Software without configuration options what a novel idea... In all >> seriousness that day will come long after the paperless bathroom.... > > Well paperless bathrooms with a bidet has been around for over 300 years > now. Lol, well then self configuration strong AI desktop applications must be right around the corner then ;) Cheers, Shane From shane at geeklords.org Mon Apr 3 08:45:04 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 01:45:04 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> References: <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> Message-ID: On Mon, 3 Apr 2006, Nicolas Mailhot wrote: > GConf started much the same way as elektra. I didn't notice it making user > or admin life easier. > > I could be wrong of course. This had been known to happen. Many features that you apparently take for granted in gnome are ONLY DOABLE due to gconf's unified configuration system. Similar features and functionality for administrators and programmers is non-existent / impractical to create for the remainder of the Linux operation system as it lacks this same functionality. Do you have a technical argument to make on this subject? If not I will kindly refrain from continuing in this discussion with you. Cheers, Shane From fedora at camperquake.de Mon Apr 3 08:59:57 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 3 Apr 2006 10:59:57 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <20060403105957.79b360ba@soran.addix.net> Hi. On Sun, 2 Apr 2006 23:17:12 -0700 (PDT), Shane Stixrud wrote: > Software without configuration options what a novel idea... Gnome is working hard on that, I hear. From nicolas.mailhot at laposte.net Mon Apr 3 09:18:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Apr 2006 11:18:33 +0200 (CEST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <1143565978.2523.3.camel@rousalka.dyndns.org> <20060328123043.3d40cdf3.seanlkml@sympatico.ca> <20060328180838.GE24725@devserv.devel.redhat.com> <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> Message-ID: <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> Le Lun 3 avril 2006 10:45, Shane Stixrud a ?crit : > On Mon, 3 Apr 2006, Nicolas Mailhot wrote: > >> GConf started much the same way as elektra. I didn't notice it making >> user >> or admin life easier. >> >> I could be wrong of course. This had been known to happen. > > > Many features that you apparently take for granted in gnome are ONLY > DOABLE due to gconf's unified configuration system. I fear you overstate the technical part (gconf) and understate the social part (an umbrella project getting its members to agree on key namings, values and location) > Similar features > and functionality for administrators and programmers is non-existent / > impractical to create for the remainder of the Linux operation system as > it lacks this same functionality. Do you have a technical argument to > make on this subject? If not I will kindly refrain from continuing in > this discussion with you. Java, SOAP, etc. Projects that have focused on the technical plumbing like you, and already have an homogenous technical specification. Now try to make two java or SOAP apps to talk and you'd better get ready for a boatload of work getting them agree on common semantics (what the REST people have pointed out) Even if you manage to elektrify Gnome and KDE do you think you'll have more luck getting them agree on common keys than getting them agree on common filesystem objects *now* ? (oh, right semantics is not your problem, you don't even do typing/schemas but I'm sorry 90% of unix conf woes are semantics only). Every conf bit is an elektra key. Fine goal. Everything in Unix is a file. Now does it get you much closer to app interoperability? -- Nicolas Mailhot From Lam at Lam.pl Mon Apr 3 09:29:47 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 03 Apr 2006 11:29:47 +0200 Subject: Closed OSes exist for Closed content In-Reply-To: <4430D2A3.4060408@warmcat.com> References: <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <4430D2A3.4060408@warmcat.com> Message-ID: <1144056587.2803.8.camel@pensja.lam.pl> Dnia 03-04-2006, pon o godzinie 08:45 +0100, Andy Green napisa?(a): > the model allows one > copy of the install media to bleed into and dupe itself wherever it is > wanted. If that is one seat or 1,000 it makes little difference to a > Free OS like Fedora since it has no per-seat income. Yes it has. Firstly, companies like our sponsor Red Hat get money from sold copies and donate some part of it to 1. OSS projects development, 2. fight software patents. Secondly, for any OSS project every user means 1. bigger chance to find a bug, 2. bigger chance to gain more developers. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From laroche at redhat.com Mon Apr 3 09:31:58 2006 From: laroche at redhat.com (Florian La Roche) Date: Mon, 3 Apr 2006 11:31:58 +0200 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> References: <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> Message-ID: <20060403093158.GA9314@dudweiler.stuttgart.redhat.com> > (oh, right semantics is not your problem, you don't even do typing/schemas > but I'm sorry 90% of unix conf woes are semantics only). I think this is pointing at a key item: apps apply too much semantics on how they read config settings. Maybe common ways could be worked out if bigger projects would cooperate on a common lib/infrastructure for this? I still agree that this would be a very good goal to aim at, but also know much much work it is to get there. And we already see in this thread on how hard it is to agree on common/acknowledged things. ;-) regards, Florian La Roche P.S.: So while the french are used to bedins and bathrooms without paper, it might take us until development is done by robots to get sane and easy to use config files that support updates. They might also not be needed anymore by that time. ;-) From alan at redhat.com Mon Apr 3 09:39:00 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 3 Apr 2006 05:39:00 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144052058.2303.2.camel@localhost.localdomain> References: <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <1144052058.2303.2.camel@localhost.localdomain> Message-ID: <20060403093900.GB14751@devserv.devel.redhat.com> On Mon, Apr 03, 2006 at 10:14:18AM +0200, Christian Fredrik Kalager Schaller wrote: > Well paperless bathrooms with a bidet has been around for over 300 years > now. And with a jug for rather longer... From che666 at gmail.com Mon Apr 3 09:43:20 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 3 Apr 2006 11:43:20 +0200 Subject: Split-off package config from release note packages In-Reply-To: <200603311803.19043.nman64@n-man.com> References: <1143503822.13193.18.camel@cbcclt02.cbcchome.cbccgroup.com> <20060329150226.GC13953@neu.nirvana> <442D6840.2020600@wowway.com> <200603311803.19043.nman64@n-man.com> Message-ID: 2006/4/1, Patrick Barnes : > On Friday 31 March 2006 11:34, Demond James wrote: > > Axel Thimm wrote: > > > But then hell breaks loose and people accuse JoeBob of forking fedora, > > > when all he wanted to do is either provide decent mirrors (local or > > > not) for his users or additional repos. Having to replace > > > fedora-release to do that results in for example: > > > > > > http://fedoraproject.org/wiki/JohnMahowald/ATrpmsWarning > > > > What would help stop the propaganda Axel is descriptions of the changes > > that were made to these core packages. As it stands now I do not want > > to replace the core packages with your packages simply because I don't > > now what changes you made. Let me decided if I want that added > > feature. Other than that great job and great repo. Thank you! > > > > When you start changing packages from Core, it really is a fork by definition. > Replacing Core packages is not and will never be considered a good or safe > practice, and will never be supported by the Fedora Project. I'm not saying > that providing alternative packages is a bad thing, but you must clearly tell > users what they are getting. If you don't, then someone else has every right > to try, as John did. As soon as you change one package from Core, the system > isn't Fedora Core anymore, even if it is highly compatible. This is why the > Trademark Guidelines are so restrictive about changing systems and continuing > to call them Fedora Core. Providing alternatives to Core packages isn't > providing a third-party mirror or repository, it is providing an > *alternative* repository, and it is beyond the scope of the Fedora Project to > support that or make it easier in any way. > > The fedora-release package is the single package that defines the installed > release. Any file that is unique and critical to a particular release is not > out of place in that package. The repository configurations are arguably > release-agnostic, and could be reasonably split into a different package, but > only for reasons of maintainability. If you want to change the existing > files, tell users and give them the option. If you want to add new > repositories, provide a separate package. > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > > http://www.n-man.com/ > > Have I been helpful? Rate my assistance! > http://rate.affero.net/nman64/ > -- > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > no 3rd party repo is supported by fedora including all the others... regards, Rudolf Kastl > From benjy.grogan at gmail.com Mon Apr 3 10:14:13 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Mon, 3 Apr 2006 06:14:13 -0400 Subject: Fedora Looks Fresh and Functions Well In-Reply-To: <1143717142.3802.673.camel@sundaram.pnq.redhat.com> References: <1143717142.3802.673.camel@sundaram.pnq.redhat.com> Message-ID: On 3/30/06, Rahul Sundaram wrote: > On Thu, 2006-03-30 at 04:28 -0500, Benjy Grogan wrote: > > Hello, > > > > I'm really enjoying using FC5. Tomboy is a great tool for jotting > > down ideas. I actually put together this email using a few tomboy > > notes. I have a few suggestions -- that you can take or leave -- that > > I wanted to share to help out with 'Fedora's way forward'. :) Here > > they are: > > > > > > 1) A welcome to Fedora (or RHEL) tutorial for new accounts and even > > maybe a tips section everytime you log in. DAC would be a really good > > topic for new users. > > Do you want to help with that? . Docs project has a number of people who > introduce themselves but then dont contribute. So the actual > contributors are extremely low now. > > http://fedoraproject.org/wiki/DocsProject Perhaps, later on during the Summer. I can't commit to anything now but that would interest me. > > > > 2) Have a place in Preferences set up for the two or three available > > Javas (Sun's and the OSS ones). Then when you have installed Sun's > > Java you have a place to switch back to the old one, and vice versa. > > (Question: Is a compiled Azureus the same if it's based on Sun or > > GCJ?) > > > > Fedora wouldnt ship Sun Java. Azureus is GCJ compiled. > > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Java > > The alternatives mechanism already allows you to switch between any > implementation of Java as long as it is appropriately packaged. Check > out the third question in > > http://www.redhat.com/magazine/001nov04/departments/tips_tricks/ It would be nice to have an Alternatives menu in System->Administration, but either way a useful command. > > 3) I have a question on codecs. Is it possible to get all OSS codecs > > these days based on the GStreamer plugin system? I think the whole > > audio/video codec problem would go away if there was a GStreamer Codec > > management system where OSS codecs would be there by default and then > > the user would go out and get all the proprietary GStreamer codecs > > he/she is missing. It should be simple to look at a Fedora system, > > and say "alright, got those ones, but missing these ones (like > > mp3/avi). And I can figure out where to get them." And this > > presupposes a future where there are only Gstreamer codecs. > > Thats exactly how it is supposed to be working. We are almost there at > this point. > > > > > 4) Since Firefox is one of the most important pieces of the Linux OS > > these days, it would be great to have all of the alphas, betas and RCs > > available in update-testing. That would allow some users to test > > Firefox for bugs over an extended period of time before 2.0 or 3.0 > > comes out. Obviously, under some guidance from Fedora with all the > > patches they put into it. > > fedora updates-testing repository is just for testing updates that would > almost always be later pushed out as actual updates. Having a > experimental repository might be a good idea but the current usage of > updates-testing repository is low enough to not deviate into that. Something like the aiglx repository for Firefox test releases would be good. Aiglx was incredibly easy to install. I figured it would be like installing Beagle back when that project was first starting, but nope it was almost too easy to install Aiglx. Perhaps the Aiglx repository could be generalized to include other test software? Steve From rhl-devel-list at lnx.ro Mon Apr 3 10:25:01 2006 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Mon, 03 Apr 2006 13:25:01 +0300 Subject: rawhide report: 20060403 changes In-Reply-To: <200604030719.k337J3pU012123@porkchop.devel.redhat.com> References: <200604030719.k337J3pU012123@porkchop.devel.redhat.com> Message-ID: <1144059901.2787.9.camel@localhost> ?n data de Lu, 03-04-2006 la 03:19 -0400, Build System a scris: > wpa_supplicant-1:0.4.8-7.fc6 > ---------------------------- > * Sun Apr 02 2006 Dan Williams - 0.4.8-7 > - Work around older & incorrect drivers that return null-terminated SSIDs This should really hit FC5-updates also, I've rebuilt it on FC5 and it finnaly fixed NetworkManager for me (orinoco_cs). Thanks! -- Cioby From avi at unix.sh Mon Apr 3 10:32:00 2006 From: avi at unix.sh (Avi Alkalay) Date: Mon, 3 Apr 2006 07:32:00 -0300 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> References: <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> Message-ID: On 4/3/06, Nicolas Mailhot wrote: > Even if you manage to elektrify Gnome and KDE do you think you'll have > more luck getting them agree on common keys than getting them agree on > common filesystem objects *now* ? Yes, this will be the next challenge. But at least will be a social challenge only. Currently nobody talks about any agreenment because the technical plumbing does not allow you to even think about it. Elektra is not the turn key solution. Its impossible to have one in this bazar. It takes time. Elektra at least makes it possible to start thinking about it, but to solve the end problem requires a lot of discussions like this, which is good. > Every conf bit is an elektra key. Fine goal. > Everything in Unix is a file. Now does it get you much closer to app > interoperability? It is a step forward in a long walk. And in my opinion its very non-intuitive why converting it in keys makes this walk start. This is normal, and this is why we need a lot of discussions. Avi From dragoran at feuerpokemon.de Mon Apr 3 11:09:35 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 03 Apr 2006 13:09:35 +0200 Subject: yum + mulitarch + updates In-Reply-To: References: <442F6F0B.2040706@feuerpokemon.de> Message-ID: <4431026F.7050603@feuerpokemon.de> Ian Burrell schrieb: > On 4/1/06, dragoran wrote: > >> I have noticed that when I have package foo-1.0.i386 installed and some >> other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the >> i386 one. >> (livna mplayerplug-in was it here). >> Updates should not be crossarch a i386 package should only be updated to >> a i386 one (same for x86_64). >> Any reason for doing this? Or is this a bug thats needs to be filled? >> >> > > Can you give an actual example? > > Also, did you change your /etc/yum.conf file? There is a setting, > exactarch, which controls whether yum will upgrade to across > architectures. The default is exactarch=1. It is even more strict > than x86_64/i386; it won't upgrade between glibc.i386 and glibc.i686 > for exampe. > > - Ian > > no yum.conf is stock (checked) here is the output of yum check-update azureus.x86_64 2.4.0.3-0.20060328cvs_ extras ffmpeg.x86_64 0.4.9-0.21.20051228.lv livna gwget.x86_64 0.97-3.fc5 extras mplayerplug-in.x86_64 3.21-1.lvn5 livna xine-lib.x86_64 1.1.1-5.lvn5 livna xine-lib-devel.x86_64 1.1.1-5.lvn5 livna ---- rpm -q mplayerplug-in mplayerplug-in-3.21-fc4 rpm -q mplayerplug-in --queryformat %{ARCH} i386 so this is a bug? From andy at warmcat.com Mon Apr 3 11:27:26 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 03 Apr 2006 12:27:26 +0100 Subject: Closed OSes exist for Closed content In-Reply-To: <1144056587.2803.8.camel@pensja.lam.pl> References: <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <4430D2A3.4060408@warmcat.com> <1144056587.2803.8.camel@pensja.lam.pl> Message-ID: <4431069E.9080902@warmcat.com> Leszek Matok wrote: > Dnia 03-04-2006, pon o godzinie 08:45 +0100, Andy Green napisa?(a): >> the model allows one >> copy of the install media to bleed into and dupe itself wherever it is >> wanted. If that is one seat or 1,000 it makes little difference to a >> Free OS like Fedora since it has no per-seat income. > Yes it has. Firstly, companies like our sponsor Red Hat get money from > sold copies and donate some part of it to 1. OSS projects development, I was speaking about specifically Fedora. RHAT get $0 from "sold copies" of Fedora AFAIK. RHEL is sold, and the Redhat Desktop thing seems to be sold, or maybe just the support contracts are sold. > 2. fight software patents. Secondly, for any OSS project every user > means 1. bigger chance to find a bug, 2. bigger chance to gain more > developers. Right, but the proposal was that Linux must operate under "competitive pressure". It seems like that could mean something, but it doesn't mean for Fedora what it means for, say, a traditional Unix vendor. If they make $100 per seat per year then 1000 seats means something important to them and if some other OS gets it instead it hurts. Presumably everyone here is happy if those 1000 seats go to Fedora, but if it does not, something less than a $100,000 loss has happened to a Free OS, since they would not have seen the money anyway: the less tangible losses you describe take place. "Competition" for users would seem to mean something different where a Free OS is concerned then. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Mon Apr 3 12:19:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Apr 2006 14:19:12 +0200 (CEST) Subject: 'Commercial Partners' In-Reply-To: <1144004660.10632.151.camel@localhost> References: <20060331085130.GB19993@thyrsus.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331173030.GB24571@thyrsus.com> <442D80B1.20902@warmcat.com> <20060331194359.GB25535@thyrsus.com> <442E3DFB.5020502@warmcat.com> <20060402054828.GD6796@thyrsus.com> <1143973122.10632.129.camel@localhost> <1143976022.8941.37.camel@rousalka.dyndns.org> <1144004660.10632.151.camel@localhost> Message-ID: <33739.192.54.193.25.1144066752.squirrel@rousalka.dyndns.org> Le Dim 2 avril 2006 21:04, Callum Lerwick a ?crit : > I'm told there's ogg-vorbis codecs for DirectShow that actually > work well. They may exist, but last time I looked finding the right windows ogg implementation was a challenge. Which is why you can't blame content producers (those who haven't sold off to the DRM camp) for going mp3 wma or real, where you do have end-to-end offerings with documentation printed on glazed paper. (pretty sad that OSS people argue for paying lumps of money to TMM instead of getting FOSS offerings into marching order) -- Nicolas Mailhot From paul at dishone.st Mon Apr 3 13:05:05 2006 From: paul at dishone.st (Paul Jakma) Date: Mon, 3 Apr 2006 14:05:05 +0100 (IST) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: References: <604aa7910603281335v5630ea65h3ea0db04190221d2@mail.gmail.com> <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1143946723.10632.82.camel@localhost> <1143969066.10632.93.camel@localhost> Message-ID: On Sun, 2 Apr 2006, Avi Alkalay wrote: > And /etc/sysconfig is RH-specific only, as far as I know. It's from IRIX (just called /etc/default?). Solaris has it too. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: There is no delight the equal of dread. As long as it is somebody else's. --Clive Barker From paul at city-fan.org Mon Apr 3 14:45:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 03 Apr 2006 15:45:28 +0100 Subject: FC5 boot problems In-Reply-To: <4fb2cbe00604020445j5fc28517se3989fe933ad5bd0@mail.gmail.com> References: <442E2805.2020401@knox.net.nz> <4fb2cbe00604020445j5fc28517se3989fe933ad5bd0@mail.gmail.com> Message-ID: <44313508.5080906@city-fan.org> Kevac Marko wrote: > Michael J Knox wrote: >> OK, this has (sort of) been covered else where, however, the solutions >> to other people's issues have not worked for me. >> >> Clean install of FC5 and on the first boot, the system appears to stop >> at "Starting udev:" >> >> I do not have pcmciautils installed, I have tried noacpi, single, >> removing rhgb and "quiet", I have updated my kernel to the latest one >> from updates. I have moved various udev rule files from >> /etc/udev/rules.d/ to see if any are causing me grief, but nothing. >> >> System runs FC4/FC3 fine. This is my first time installing FC5, I >> previously had installed test releases, which worked fine. >> >> I am at a loss as to what the issue is. RH bug #186164 covers this, but >> as I said, I don't have pcmciautils install. > > I had such problem. Solution was to turn off kudzu (chkconfig kudzu off). How can that help when the hang is *much* earlier in the boot process than kudzu startup? I'm having a similar issue on a Celeron desktop box (not a laptop, no pcmciautils installed) upgraded FC4->FC5. It's not actually hanging but udev startup is so slow that it appears to be hung. Eventually it comes back saying "Wait timeout, continuing in background" or something like that. Many other things seem to be slow too, but I can't quite put my finger on it. Paul. From vonbrand at inf.utfsm.cl Mon Apr 3 06:48:39 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 02:48:39 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: Your message of "Mon, 03 Apr 2006 01:27:00 -0400." <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> David Zeuthen wrote: > On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote: > > In addition to the words bellow, the "D" on D-Conf comes from the > > "Desktop" word, which means D-Conf is a desktop-oriented wannabe- > > project. You won??t be able to standarize configuration for say > > named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network > > configurations, etc etc etc with it. > Speaking of wanna-be. I think one fundamental problem with the > LinuxRegistry/Elektra approach is that you try to fix the symptoms of > the problem instead of the root problems. I've written about this > before and I will do it again and again as apparently people are > still trying to fix the symptoms of our problem: > > Configuration of software in a mainstream distribution is a mess. > > Most of this mail is about the desktop, but really, if you look at > it, desktop is _a lot harder_ than server (there is just so much more > code and so much more functionality) so my view is that if we solve > it for desktop then the server bits will pan out mostly by itself. No, the problem spaces are different. > It seems that Elektra simply wants to remap the configuration file > for a piece "software" into a hierarchical key/value database and I > think that's missing the point entirely. First of all you got to ask > yourself whether there should be a configuration of said piece of > software in the first place. If you think really hard about it you > will find that for most pieces of software this is false - you really > don't want any configuration files... Hence you really don't want nor > need Elektra. ;-) > Let us look at what "configuration" really means; I've seen it being > used in the following ways > > - The programmer is lazy and makes the user look up configuration > values he could have determined programmatically - for example this > includes the laptop_mode scripts where you can configure what IDE > drives to put to sleep. The poor user will have to put in arcane > values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe > the laptop_mode developer wasn't that lazy, maybe the kernel people > was just sleeping and gave him no easy way to find out what drives > to put to sleep when he wants.. or maybe what the kernel said was > unreliable and the kernel never got fixed.... Does this justify > bothering the poor end user with crap like this? I think not. I don't know about this specific case, but if so, I heartily agree. > - Configuration can be system-wide, for example mail and web > servers... Sure, my web server needs to know where to serve files > from, my mail server needs to know what domain it serves and so forth Bingo! I.e., configuration /is/ needed... > - When developers write a daemon and decide to make it system-wide, > then most of the time they either really want it to be site-wide or > session-wide instead. Most of the time they don't even know > this... I will argue that system-wide is just plain wrong for most > things; continue reading... > > - Site-wide software: This includes for example a cluster of web > servers. The user experience if I'm an administrator is that I can > just plug in another physical server box, PXE-boot it and it reads > all "web server configuration" from LDAP. If it blows up I can > replace it. Hence, no need at all for having some httpd.conf file. > For the (terribly uninteresting) case of only having one machine as > a web server it reads settings from the local LDAP server. Ditto > with mail servers, name servers etc. So you advocate not configuring the web server via files, but remotely via LDAP? How is that different from "configuration files"? In any case, this is system-wide, just that your system is larger than one box. > - Session-wide software: Just so we're all on the same page, > "session-wide" means something that runs in a user desktop session. > Historically, the desktop wasn't very advanced and didn't integrate > well with the system. Back then things that really was session-wide > would run as a system-wide daemon mostly also because it required > root to enforce policy. Things like acpid for power management event > handling, updfstab for removable media, ifplugd for handling network > cable removable, networking scripts etc. comes to mind. As you can > see with Fedora Core 5 this is radically starting to change; acpid > is obsoleted by gnome-power-manager, updfstab (and fstab-sync for > that matter) is obsoleted by gnome-volume-manager / gnome-mount, > the networking scripts is starting to be completely obsoleted by > NetworkManager. We have more things on out "hit list"... Great. But that does mean that someone, somewhere has to tweak the configuration (files) with all those desktop settings that the machine gets over the net. Plus I'd bet the number of single-machine setups vastly outnumber the multi-client setting you describe, and will for a long time to come. By pushing the problem into the site-wide system administrations hands you have solved nothing. > - You really really want session-wide daemons to run in the session > and not as the system because it's much easier for the user to > configure it.. in fact, you get per-user settings for removable > media handling and power management in FC5. And since all this is > backed by gconf it's easy for the OS vendor _and_ the administrator > to set sane defaults, lock things down and so forth. It's just a > lot better That is, as long as gconf is used... > - Look at the terrible and insecure hacks for writing out > configuration files for system-wide daemons that ought to be > session- > wide. That some people don't know how to do it right doesn't mean it is the wrong approach. > See also my rant on fedora-maintainers last week why > consolehelper (that these tools rely on) is fundamentally flawed. > - Things like smb.conf is really not interesting for the desktop > case as it's the wrong solution to the problem of sharing files and > using files other systems wants to share. The right answer here is > obviously things like Nautilus and gnome-user-share and other things > that run in your session and is easy to configure. Destop has no business in deciding what system-wide resources to share. > - X.org having a configuration is completely broken too; obviously > the X.org server should be able to configure itself (and it can but > X.org itself has bugs so it doesn't always work) and it should offer > a D-BUS interface for reconfiguration so some per-session piece of > software can program it with the users setting when your session > starts. Pray tell, where would the user settings come from? Not from a configuration file?! > Yes, display configuration is also per-user although the > brain dead design of X.org doesn't reflect this. I'm not so sure. The display is a system resource. > I don't have a good answer to KDE and GNOME sharing configuration; I > personally think that as this point it's impossible to get developers > of both camp to agree on a scheme for even simple things like desktop > backgrounds and HTTP proxies. And should the day come when gconf > depends on KConfig, vice versa, or when there is D-Conf I'm sure this > will get solved by itself. It sure as hell doesn't need Elektra for > this. That is the crux of the matter: Glorious schemes for world domination "if only everybody will agree on the same configuration file syntax" are thrown around here, but the ones in charge of adopting said syntax have historically shown very, very little desire to agree on a syntax. And (assuming people aren't completely irrational), the very existence of the wildly differing syntaxes tells me there are different needs behind them. > So my message is that I think it's a waste of time trying to shoehorn > a configuration file format onto all kinds of software because said > software is likely to be already broken for at least desktop use. My > stance is simply that it's unacceptable in a desktop system to ever > ever have to touch a configuration file and I think some people > (*cough* Apple *cough* Microsoft *cough*) take the same stance even > for the server. So we shouldn't ship software that rely on them. > Hence, there is zero need for Elektra. It's really that simple if you > think about it. > I wish that people working on the server bits (e.g. Apache, Postfix) > would take a similar stance and only make their software read > settings from LDAP (or whatever) for the site-wide case. I think it > would be great if you could change Elektra into something that would > fix this. But please back off trying to pretend you solve problems > for the desktop because you're not. The design of gconf is pretty > nice (implementation might be another matter but, you know, that's > totally fixable) and it's more than sufficient for desktop use, thank > you very much. So your idea is getting rid of configuration files and push everything into LDAP? What if the LDAP server is down? Who says LDAP is the right framework, i.e., is rich enough for the needs? Who says the result won't be just shoveling the garbage into another opaque junkyard? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Apr 3 05:31:42 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 01:31:42 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Sun, 02 Apr 2006 01:40:49 PST." Message-ID: <200604030531.k335VgCV019048@laptop11.inf.utfsm.cl> Shane Stixrud wrote: > On Sun, 2 Apr 2006, Callum Lerwick wrote: > > On Sat, 2006-04-01 at 19:29 -0800, Shane Stixrud wrote: > >> What would it take to convince you? > > What would convince me is, as they say in XP, is some detailed > > UserStories explaining what exactly it is you want to do, and why you > > can't do it now. Instead of vague handwaving. > Have you not been paying attention then? I sure have. > They have been outlined The operating word being _outlined_... in vague terms, like complaining about formats in general (no examples!), that some (unspecified!) automatic handling isn't done today, that people have a hard time reading configuration files (with no details on which ones, exactly, and who/why/for what). > in > multiple posts, in multiple ways. If you want a more detailed > outlined E-mail me off list so others don't have to see the same > ground being covered yet again. Please don't. This clearly goes nowhere. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Apr 3 06:51:22 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 02:51:22 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: Message from David Zeuthen of "Mon, 03 Apr 2006 02:25:14 -0400." <2DC5B6B2-97A6-4CA2-B6B7-453CBCA0D48F@fubar.dk> Message-ID: <200604030651.k336pMZ2019813@laptop11.inf.utfsm.cl> David Zeuthen wrote: > On Apr 3, 2006, at 2:17 AM, Shane Stixrud wrote: > > On Mon, 3 Apr 2006, David Zeuthen wrote: > > > >> It seems that Elektra simply wants to remap the configuration file > >> for a piece "software" into a hierarchical key/value database and > >> I think that's missing the point entirely. First of all you got to > >> ask yourself whether there should be a configuration of said piece > >> of software in the first place. If you think really hard about it > >> you will find that for most pieces of software this is false - you > >> really don't want any configuration files... Hence you really > >> don't want nor need Elektra. > > > > Software without configuration options what a novel idea... In all > > seriousness that day will come long after the paperless bathroom.... > > My point was that you don't want _configuration files_, of course you > need configuration for some, even most, pieces of software. Another > point was that this configuration should be read from either the > desktop session _or_ some remote LDAP server. Maybe if you read my > whole mail before replying this would have been clear. Unless the configuration is gotten by telepathy, it is in a file somewhere... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From avi at unix.sh Mon Apr 3 14:50:33 2006 From: avi at unix.sh (Avi Alkalay) Date: Mon, 3 Apr 2006 11:50:33 -0300 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> References: <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: In my opinion what you write is currently, unfortunately, plain utopia. I think you got a lot of inspiration about your site-wide writings from MS-AD. As far as I know, AD is not an LDAP. It is a proprietary configuration container which parts of it, not all, can be exported as an LDAP directory. But I'm not a specialist in this subject. About LDAP being a configuration containter, check this, which I'm not sure also if it is accurate: http://www.libelektra.org/LDAP_and_Other#LDAP Generaly, you can't get rid of configurations completely. But you can make them so marginal and easy to handle that softwares will interoperate with them by themselves, without asking you many questions. See, Elektra or any similar thing, is far from being a solution for the configuration problem, but at least it unlocks our current static position of zero-interoperability. If, in a dream, Elektra or any similar thing gets adopted, the day after will be filled with debates and a lot of work about the better way to define a semantical tree of system parameters. In the second day after, we'll start see programs integrating themselves alone, and higher value being added in the stack. Lack of automatic configuration will be a shadow from the past. While today we are stuck in "proprietary" configuration silos from Apache, Samba, X.org, network, Gnome, KDE, /etc/* , and can't move forward thowards this higher value stack. We are loosing a lot of time dealing with OS internal interoperability, while the rest of the world is making huge steps in the business (higher) value space. We need to take a lof of steps to achieve the desired utopia you outlined. Elektra is a small first one. Thank you, Avi On 4/3/06, David Zeuthen wrote: > > On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote: > > > In addition to the words bellow, the "D" on D-Conf comes from the > > "Desktop" word, which means D-Conf is a desktop-oriented wannabe- > > project. You won?t be able to standarize configuration for say > > named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network > > configurations, etc etc etc with it. > > Speaking of wanna-be. I think one fundamental problem with the > LinuxRegistry/Elektra approach is that you try to fix the symptoms of > the problem instead of the root problems. I've written about this > before and I will do it again and again as apparently people are > still trying to fix the symptoms of our problem: > > Configuration of software in a mainstream distribution is a mess. > > Most of this mail is about the desktop, but really, if you look at > it, desktop is _a lot harder_ than server (there is just so much more > code and so much more functionality) so my view is that if we solve > it for desktop then the server bits will pan out mostly by itself. > > It seems that Elektra simply wants to remap the configuration file > for a piece "software" into a hierarchical key/value database and I > think that's missing the point entirely. First of all you got to ask > yourself whether there should be a configuration of said piece of > software in the first place. If you think really hard about it you > will find that for most pieces of software this is false - you really > don't want any configuration files... Hence you really don't want nor > need Elektra. > > Let us look at what "configuration" really means; I've seen it being > used in the following ways > > - The programmer is lazy and makes the user look up configuration > values he could have determined programmatically - for example this > includes the laptop_mode scripts where you can configure what IDE > drives to put to sleep. The poor user will have to put in arcane > values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe > the laptop_mode developer wasn't that lazy, maybe the kernel people > was just sleeping and gave him no easy way to find out what drives to > put to sleep when he wants.. or maybe what the kernel said was > unreliable and the kernel never got fixed.... Does this justify > bothering the poor end user with crap like this? I think not. > > - Configuration can be system-wide, for example mail and web > servers... Sure, my web server needs to know where to serve files > from, my mail server needs to know what domain it serves and so forth > > - When developers write a daemon and decide to make it system-wide, > then most of the time they either really want it to be site-wide or > session-wide instead. Most of the time they don't even know this... I > will argue that system-wide is just plain wrong for most things; > continue reading... > > - Site-wide software: This includes for example a cluster of web > servers. The user experience if I'm an administrator is that I can > just plug in another physical server box, PXE-boot it and it reads > all "web server configuration" from LDAP. If it blows up I can > replace it. Hence, no need at all for having some httpd.conf file. > For the (terribly uninteresting) case of only having one machine as a > web server it reads settings from the local LDAP server. Ditto with > mail servers, name servers etc. > > - Session-wide software: Just so we're all on the same page, > "session-wide" means something that runs in a user desktop session. > Historically, the desktop wasn't very advanced and didn't integrate > well with the system. Back then things that really was session-wide > would run as a system-wide daemon mostly also because it required > root to enforce policy. Things like acpid for power management event > handling, updfstab for removable media, ifplugd for handling network > cable removable, networking scripts etc. comes to mind. As you can > see with Fedora Core 5 this is radically starting to change; acpid is > obsoleted by gnome-power-manager, updfstab (and fstab-sync for that > matter) is obsoleted by gnome-volume-manager / gnome-mount, the > networking scripts is starting to be completely obsoleted by > NetworkManager. We have more things on out "hit list"... > > - You really really want session-wide daemons to run in the session > and not as the system because it's much easier for the user to > configure it.. in fact, you get per-user settings for removable media > handling and power management in FC5. And since all this is backed by > gconf it's easy for the OS vendor _and_ the administrator to set sane > defaults, lock things down and so forth. It's just a lot better > > - Look at the terrible and insecure hacks for writing out > configuration files for system-wide daemons that ought to be session- > wide. See also my rant on fedora-maintainers last week why > consolehelper (that these tools rely on) is fundamentally flawed. > > - Things like smb.conf is really not interesting for the desktop > case as it's the wrong solution to the problem of sharing files and > using files other systems wants to share. The right answer here is > obviously things like Nautilus and gnome-user-share and other things > that run in your session and is easy to configure. > > - X.org having a configuration is completely broken too; obviously > the X.org server should be able to configure itself (and it can but > X.org itself has bugs so it doesn't always work) and it should offer > a D-BUS interface for reconfiguration so some per-session piece of > software can program it with the users setting when your session > starts. Yes, display configuration is also per-user although the > brain dead design of X.org doesn't reflect this. > > I don't have a good answer to KDE and GNOME sharing configuration; I > personally think that as this point it's impossible to get developers > of both camp to agree on a scheme for even simple things like desktop > backgrounds and HTTP proxies. And should the day come when gconf > depends on KConfig, vice versa, or when there is D-Conf I'm sure this > will get solved by itself. It sure as hell doesn't need Elektra for > this. > > So my message is that I think it's a waste of time trying to shoehorn > a configuration file format onto all kinds of software because said > software is likely to be already broken for at least desktop use. My > stance is simply that it's unacceptable in a desktop system to ever > ever have to touch a configuration file and I think some people > (*cough* Apple *cough* Microsoft *cough*) take the same stance even > for the server. So we shouldn't ship software that rely on them. > Hence, there is zero need for Elektra. It's really that simple if you > think about it. > > I wish that people working on the server bits (e.g. Apache, Postfix) > would take a similar stance and only make their software read > settings from LDAP (or whatever) for the site-wide case. I think it > would be great if you could change Elektra into something that would > fix this. But please back off trying to pretend you solve problems > for the desktop because you're not. The design of gconf is pretty > nice (implementation might be another matter but, you know, that's > totally fixable) and it's more than sufficient for desktop use, thank > you very much. > > Hope this clarifies why Elektra is simply the wrong answer. I'm sorry > for sounding harsh and saying most of our software in the > distribution is broken, but it's kinda this conclusion I've arrived > at. We could do so much better if we all tried to solve the root > problems and look at what the user experience should be. > > Have a nice day. > > David > > Disclaimer : this mail doesn't necessarily reflect the views of Red > Hat, Inc. > From avi at unix.sh Mon Apr 3 15:11:10 2006 From: avi at unix.sh (Avi Alkalay) Date: Mon, 3 Apr 2006 12:11:10 -0300 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> Message-ID: On 4/3/06, Horst von Brand wrote: > That is the crux of the matter: Glorious schemes for world domination "if > only everybody will agree on the same configuration file syntax" are thrown > around here, but the ones in charge of adopting said syntax have > historically shown very, very little desire to agree on a syntax. Here comes the role of distributions as the integrator. This is why I say each of these projects (Apache, Samba, everything on /etc/*, Gnome, KDE, etc) are a sort of "selfish" and "proprietary" when it comes to overall integration architecture. > So your idea is getting rid of configuration files and push everything into > LDAP? What if the LDAP server is down? What if you don't have/want a network? What if my mother only wants to install a new multimedia keyboard in her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or wait for the distribution's HW detection tool to know how to handle that? Clearly the best solutions is to let the HW provider know that X.org configurations are pretty predictable in any distribution, and it just have to provide some scripts to precisely integrate itself in X.org configuration schema, instead of having to "compile", understand and regenerate /etc/X11/xorg.conf only to install itself. Being so difficult, this HW provider will simply, obviously, declare they do not support Linux. Avi From seandarcy2 at gmail.com Mon Apr 3 15:11:22 2006 From: seandarcy2 at gmail.com (sean) Date: Mon, 03 Apr 2006 11:11:22 -0400 Subject: rawhide->fc5; X won't start : Solved In-Reply-To: <1144031382.31042.3.camel@halflap> References: <1143699226.8963.1.camel@halflap> <1143750758.3589.1.camel@halflap> <20060401.104056.705159298.kevin@scrye.com> <1144021704.5901.4.camel@halflap> <1144031382.31042.3.camel@halflap> Message-ID: Ray Strode wrote: > Hi, > > >>I'll do that, but shouldn't fc-cache -f ( which I've done) do he same >>thing? > > You'd think, but there might be a bug somewhere. I'm really just > guessing at this point. The thing is, for a while in rawhide fontconfig > was really broken and generated broken font cache files. It seems like > you might be hitting that. > > Great guess. You're my vote for Fedora Man of the Year. Thanks a lot to all who helped me with this. sean >>In any case, I do NOT have a ~/.fonts dir. should I? If so, what do I >>install to get it, or is it just user fonts. > > it's just for user fonts, if you don't have it no big deal. > > --Ray > From nicolas.mailhot at laposte.net Mon Apr 3 15:25:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Apr 2006 17:25:46 +0200 (CEST) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> Message-ID: <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> Le Lun 3 avril 2006 17:11, Avi Alkalay a ?crit : > What if my mother only wants to install a new multimedia keyboard in > her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or > wait for the distribution's HW detection tool to know how to handle > that? Clearly the best solutions is to let the HW provider know that > X.org configurations are pretty predictable in any distribution, and > it just have to provide some scripts to precisely integrate itself in > X.org configuration schema, instead of having to "compile", understand > and regenerate /etc/X11/xorg.conf only to install itself. Avi, I agree with much of what you've written lately but here you're back in lala-lala land. You can't have several entities sharing the same object (here entities are xorg and your mythical keyboard manufacturer). It *always* ends bad because the first reflex of the keyboard manufacturer will be to "canonalize" the conf to something it tested (and testing is expensive so don't count on a complex canonic setup), lower various tuneables to workaround its product bugs, and generally destroy the settings the mythical mouse manufacturer put in the configuration. Having central clearinghouses that mediate between actors (LKML, xorg, distributions) is a very powerful feature of Linux distributions (you'll note ms has been increasingly centralising driver handling in the last years for this very same reason). Your manufacturer should push its changes upstream instead of expending resources trying to workaround the system. In other words, your "fix" is worse than the "problem". Regards, -- Nicolas Mailho From mihamina.rakotomandimby at etu.univ-orleans.fr Mon Apr 3 15:43:30 2006 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Mon, 03 Apr 2006 17:43:30 +0200 Subject: compile a kernel to include a module Message-ID: <1144079010.5919.31.camel@localhost.localdomain> Hi, I have to copile my own kernel in order to have some options hard-included (not as modules) and some to modules to be activated. I do want to make it "the fedora way" (not the generic method) by using a src.rpm. I thus need to edit the kernel compilation configuration file in order to include my stuff. What tutorial do you recommend me? I already tried in the old times and as far as I remember, the command line to launch is not a simple "rpmbuild": I have to specify the target architecture and some things. Would you have a link to recommend? Thank you. -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads & documentation. From shane at geeklords.org Mon Apr 3 16:15:33 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 09:15:33 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> Message-ID: On Mon, 3 Apr 2006, Nicolas Mailhot wrote: > You can't have several entities sharing the same object (here entities are > xorg and your mythical keyboard manufacturer). It *always* ends bad .... and why is that? If an application is designed to allow an end user to update something then why not a vendor on the users behalf?? Microsoft got MANY things wrong, but I dare say keyboard vendors and their users have little to worry about on this front. Please give TECHNICAL reasons why this functionality is a bad idea, so far you have relied on subjective conjecture centered around how you THINK others will behave. It is not your or my place to limit functionality based on our opinions on if it will be used poorly or not. The fact is all of this cane be done today it is just very hard to do, this argument that making it easier for the user, programmer and vendor will some how create a social disaster rings hollow to me. Cheers, Shane From shane at geeklords.org Mon Apr 3 16:38:30 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 09:38:30 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <20060403093158.GA9314@dudweiler.stuttgart.redhat.com> References: <1143974516.8941.18.camel@rousalka.dyndns.org> <1143976248.8941.41.camel@rousalka.dyndns.org> <1144002377.2775.1.camel@rousalka.dyndns.org> <64925.192.54.193.25.1144052320.squirrel@rousalka.dyndns.org> <63201.192.54.193.35.1144055913.squirrel@rousalka.dyndns.org> <20060403093158.GA9314@dudweiler.stuttgart.redhat.com> Message-ID: On Mon, 3 Apr 2006, Florian La Roche wrote: >> (oh, right semantics is not your problem, you don't even do typing/schemas >> but I'm sorry 90% of unix conf woes are semantics only). > > I think this is pointing at a key item: apps apply too much semantics > on how they read config settings. Maybe common ways could be worked out > if bigger projects would cooperate on a common lib/infrastructure for this? So true. I think the key (pun intended) point the semantic argument is missing is that application configuration semantics by their very nature is easily changed/fixed. So while syntax is a pita to fix due to its functional elements, semantic problems can be identified and patches subjected by novices in many cases. I note that in same cases changing semantics may be more difficult say for example changing dhcpd.conf's subnets directive from using "10.0.0.0 255.255.255.0" to 10.0.0.0-24 but this is the exception not the rule. > > I still agree that this would be a very good goal to aim at, but also know > much much work it is to get there. And we already see in this thread on > how hard it is to agree on common/acknowledged things. ;-) That I am afraid is an established fact, I do have "faith" that as a community we are capable of moving this in the right direction though... I think the blood bath may be unavoidable however :) > P.S.: So while the french are used to bedins and bathrooms without paper, > it might take us until development is done by robots to get sane > and easy to use config files that support updates. They might also > not be needed anymore by that time. ;-) Leave it to the french to spoil and otherwise good analogy *sigh* Cheers, Shane From vonbrand at inf.utfsm.cl Mon Apr 3 17:05:56 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 13:05:56 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Mon, 03 Apr 2006 11:31:58 +0200." <20060403093158.GA9314@dudweiler.stuttgart.redhat.com> Message-ID: <200604031705.k33H5uVi013220@laptop11.inf.utfsm.cl> Florian La Roche wrote: > > (oh, right semantics is not your problem, you don't even do typing/schemas > > but I'm sorry 90% of unix conf woes are semantics only). > I think this is pointing at a key item: apps apply too much semantics > on how they read config settings. Maybe common ways could be worked out > if bigger projects would cooperate on a common lib/infrastructure for > this? The whole idea of configuration /is/ to provide semantics. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Apr 3 17:23:41 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 13:23:41 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Mon, 03 Apr 2006 07:32:00 -0300." Message-ID: <200604031723.k33HNfV2013339@laptop11.inf.utfsm.cl> Avi Alkalay wrote: > On 4/3/06, Nicolas Mailhot wrote: > > Even if you manage to elektrify Gnome and KDE do you think you'll have > > more luck getting them agree on common keys than getting them agree on > > common filesystem objects *now* ? > Yes, this will be the next challenge. But at least will be a social > challenge only. Good luck with that. Everybody who has had to handle people knows (from bitter experience, mostly) that technical changes are extremely easy to bring about, social changes very hard to impossible. Mostly you have to wait until the older generation has died out, together with its ways of doing things. > Currently nobody talks about any agreenment because the technical > plumbing does not allow you to even think about it. The other way around: If people don't /want/ to talk about it, the existence (or not) of the techical means is utterly irrelevant. > Elektra is not the > turn key solution. Its impossible to have one in this bazar. It takes > time. Elektra at least makes it possible to start thinking about it, > but to solve the end problem requires a lot of discussions like this, > which is good. This flamew^Wdiscussion is going nowhere, it is only wasting everybody's time. > > Every conf bit is an elektra key. Fine goal. > > Everything in Unix is a file. Now does it get you much closer to app > > interoperability? > It is a step forward in a long walk. And in my opinion its very > non-intuitive why converting it in keys makes this walk start. This is > normal, and this is why we need a lot of discussions. If it is, why isn't the "each byte in the configuration file stands for itself" a step forward? Some (simple) configurations can be described by a bunch of "Variable FOO gets the value BAR", others just cannot (sanely, at least). There is stuff like DNS, a web server for several domains, or the setup of a DHCP server for multiple nets, where you just can't pretend everything is one flat, uniform space. Configuration spaces have structure, and the whole idea of a configuration file with a non-trivial syntax is to be able to mirror said structure. The spaces aren't shaped equal, so either you end up squashing everything into some (unnatural) flat representation or you end up with the sum total of all (possible) diferent shapes (which is completely impossible for a mere human to handle). Sure, you can decree that configuration files are written in XML, which is expressive enough to create its own syntax on a file-by-file basis, but even that doesn't help one bit with the mapping of syntax to semantics (which /is/ the whole point, after all). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From shane at geeklords.org Mon Apr 3 17:36:36 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 10:36:36 -0700 (PDT) Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: <200604031723.k33HNfV2013339@laptop11.inf.utfsm.cl> References: <200604031723.k33HNfV2013339@laptop11.inf.utfsm.cl> Message-ID: On Mon, 3 Apr 2006, Horst von Brand wrote: > Some (simple) configurations can be described by a bunch of "Variable FOO > gets the value BAR", others just cannot (sanely, at least). There is stuff > like DNS, a web server for several domains, or the setup of a DHCP server > for multiple nets, where you just can't pretend everything is one flat, > uniform space. Configuration spaces have structure, and the whole idea of a > configuration file with a non-trivial syntax is to be able to mirror said > structure. The spaces aren't shaped equal, so either you end up squashing > everything into some (unnatural) flat representation or you end up with the > sum total of all (possible) diferent shapes (which is completely impossible > for a mere human to handle). Sure, you can decree that configuration files > are written in XML, which is expressive enough to create its own syntax on > a file-by-file basis, but even that doesn't help one bit with the mapping > of syntax to semantics (which /is/ the whole point, after all). Have you even read how Elektra works or looked at the earlier multi-subnet dhcpd.conf examples? There is nothing about Elektra that is flat nor does structure have anything to do with semantics! Elektra's format contains all of the functional elements required to EASILY generate dhcpd.conf in its entirety... this has been stated previously... I am trying to decide if you are purposely being obtuse or just operating on pre-conceived notions... I am trying to give you the benefit of the doubt. IF this thread has low value I dare say it is because of posts like the above that leads to distract and confuse the actual discussion. Cheers, Shane From seg at haxxed.com Mon Apr 3 17:50:47 2006 From: seg at haxxed.com (seg at haxxed.com) Date: Mon, 3 Apr 2006 12:50:47 -0500 (CDT) Subject: 'Commercial Partners' In-Reply-To: <4430D14E.6060006@3di.it> References: <20060329145524.GB10714@thyrsus.com> <442AAFA0.1010608@warmcat.com> <20060330215934.GE14444@thyrsus.com> <442CE669.2020107@warmcat.com> <20060331085130.GB19993@thyrsus.com> <442CF57B.9000001@warmcat.com> <20060331103536.GA21302@thyrsus.com> <442D0FB6.3080600@warmcat.com> <20060331114643.GA22130@thyrsus.com> <442D2C71.7070809@warmcat.com> <20060331201705.GH4133@redhat.com> <1143839593.2561.60.camel@rousalka.dyndns.org> <4430D14E.6060006@3di.it> Message-ID: <53290.199.17.4.107.1144086647.squirrel@artdragon.mine.nu> > sean wrote: > >> Right now some great work is going into open source drivers for some >> high end ATI hardware. Not there yet, but coming along nicely. >> As well, there is a BeOS open source driver for some pretty recent >> nVidia hardware, with a chance that it will be ported over to Linux. > > A breath of fresh air. Could you provide links for either ? http://nouveau.sourceforge.net/ http://r300.sourceforge.net/ From avi at unix.sh Mon Apr 3 17:51:31 2006 From: avi at unix.sh (Avi Alkalay) Date: Mon, 3 Apr 2006 14:51:31 -0300 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> Message-ID: Nicolas, is very hard to discuss opinions and that was your opinion. I respect that, even if I can't understand in what you based this opinion. In my opinion, if you provide an environment where softwares can cooperate in the configuration layer (which is software's personality) and define some standards and policies for chaos minimization (which is reflected by this driver handling centralization from your example; we are not talking only about HW drivers), the ecosystem of integrated applications and ways to work will increase everyday, leveraging richer user experience and friendliness. You may have even tools that help you clean the chaos. My opinion is based mostly in observable evidence on what happened in the Windows world (the good parts), and a bit of intuition. Thank you, Avi On 4/3/06, Nicolas Mailhot wrote: > > Le Lun 3 avril 2006 17:11, Avi Alkalay a ?crit : > > > What if my mother only wants to install a new multimedia keyboard in > > her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or > > wait for the distribution's HW detection tool to know how to handle > > that? Clearly the best solutions is to let the HW provider know that > > X.org configurations are pretty predictable in any distribution, and > > it just have to provide some scripts to precisely integrate itself in > > X.org configuration schema, instead of having to "compile", understand > > and regenerate /etc/X11/xorg.conf only to install itself. > > Avi, > > I agree with much of what you've written lately but here you're back in > lala-lala land. > > You can't have several entities sharing the same object (here entities are > xorg and your mythical keyboard manufacturer). It *always* ends bad > because the first reflex of the keyboard manufacturer will be to > "canonalize" the conf to something it tested (and testing is expensive so > don't count on a complex canonic setup), lower various tuneables to > workaround its product bugs, and generally destroy the settings the > mythical mouse manufacturer put in the configuration. > > Having central clearinghouses that mediate between actors (LKML, xorg, > distributions) is a very powerful feature of Linux distributions (you'll > note ms has been increasingly centralising driver handling in the last > years for this very same reason). Your manufacturer should push its > changes upstream instead of expending resources trying to workaround the > system. > > In other words, your "fix" is worse than the "problem". > > Regards, > > -- > Nicolas Mailho From david at fubar.dk Mon Apr 3 17:52:14 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Apr 2006 13:52:14 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <1144086734.2270.33.camel@daxter.boston.redhat.com> On Mon, 2006-04-03 at 11:50 -0300, Avi Alkalay wrote: > In my opinion what you write is currently, unfortunately, plain utopia. Not at all, we're doing this for the desktop already! This effort is actually called "Project Utopia" :-). Developers love it (both GNOME and KDE adopted the base technology). End users love. Admins tend to somewhat hate it sometimes because "It's new. It's different. And we're always angry." :-) And for the 1% to 2% use cases we're not there yet so some people with also hate it. We're getting there and, hey, this is open source and we take patches. > We need to take a lof of steps to achieve the desired utopia you > outlined. Elektra is a small first one. I just tend to think Elektra is way too generic to be really useful IMHO. What I think you want to do is to engage in a discussion with each upstream project and try to work out the use-cases on how their software is used. As a matter of fact, I believe that for e.g. Apache a lot of "vertical software" exists (both as proprietary and in-house solutions) for managing clusters of web servers for example. Wouldn't it be nice if Apache adopted one true way of doing this and we could all focus on an UI configuration optimized for this instead of some random Registry Editor? It's not utopia, it just requires a lot of hard work and effort to do things right. I tend to believe that if you don't do things right the first time you will never get it right because "good enough is the enemy of perfect" or something. There is no such thing as a free lunch. David From david at fubar.dk Mon Apr 3 18:33:23 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Apr 2006 14:33:23 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> References: <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> Message-ID: <1144089204.2270.60.camel@daxter.boston.redhat.com> On Mon, 2006-04-03 at 02:48 -0400, Horst von Brand wrote: > David Zeuthen wrote: > my view is that if we solve > > it for desktop then the server bits will pan out mostly by itself. > > No, the problem spaces are different. Doesn't have to be. > Bingo! I.e., configuration /is/ needed... Certainly. > So you advocate not configuring the web server via files, but remotely via > LDAP? How is that different from "configuration files"? It's different insofar that since you already serve configuration from the LDAP server it's next-to-trivial to use the same mechanism to actually change the configuration. Hence, it's a lot easier to write a single configuration UI (or whatever) that all distros can use. In particular we don't need a all-generic system like Elektra here. And you really want your web server process (e.g. httpd) to know that it reads configuration from the remote end to fix all the corner cases in a nice way. > In any case, this is system-wide, just that your system is larger than one > box. Terminology. That's what I call site-wide. > Great. But that does mean that someone, somewhere has to tweak the > configuration (files) with all those desktop settings that the machine gets > over the net. Just add an LDAP backend to gconf and you can control all desktop policy from a central repository. Also look at other approaches for this e.g. Sabayon. Like it or not but gconf is pretty well designed and the "implementation detail" of reading from /etc/gconf or LDAP is just that: an implementation detail. Hell, once you add LDAP you can go on and refine our UI tools to edit default settings and lock-down from the standard dialogs like for instance the power management dialog http://www.gnome.org/projects/gnome-power-manager/gpp.html Maybe this tool would look like this http://people.freedesktop.org/~david/davidz-evil-admin-console.png (historical note: this mock was done about a year ago) > Plus I'd bet the number of single-machine setups vastly > outnumber the multi-client setting you describe, and will for a long time > to come. By pushing the problem into the site-wide system administrations > hands you have solved nothing. Site-wide implies something like LDAP to read configuration. Hence, configuration utilities (should they be desirable) can use the same protocol to write settings. > > - Things like smb.conf is really not interesting for the desktop > > case as it's the wrong solution to the problem of sharing files and > > using files other systems wants to share. The right answer here is > > obviously things like Nautilus and gnome-user-share and other things > > that run in your session and is easy to configure. > > Destop has no business in deciding what system-wide resources to share. Of course it has. Do you expect admins migrating from Windows or Mac OS X to sit down and learn the horror of all the configuration files? Of course not. My stance is that you want a system where this is configurable from the UI. Even if you want share system wide stuff, maybe this just requires the user to auth in order to allow this. > > > - X.org having a configuration is completely broken too; obviously > > the X.org server should be able to configure itself (and it can but > > X.org itself has bugs so it doesn't always work) and it should offer > > a D-BUS interface for reconfiguration so some per-session piece of > > software can program it with the users setting when your session > > starts. > > Pray tell, where would the user settings come from? Not from a > configuration file?! For GNOME it would of course come from gconf. > I'm not so sure. The display is a system resource. No, it's per user. Do not pass start. Do not collect $200. > > I don't have a good answer to KDE and GNOME sharing configuration; I > > personally think that as this point it's impossible to get developers > > of both camp to agree on a scheme for even simple things like desktop > > backgrounds and HTTP proxies. And should the day come when gconf > > depends on KConfig, vice versa, or when there is D-Conf I'm sure this > > will get solved by itself. It sure as hell doesn't need Elektra for > > this. > > That is the crux of the matter: Glorious schemes for world domination "if > only everybody will agree on the same configuration file syntax" are thrown > around here, but the ones in charge of adopting said syntax have > historically shown very, very little desire to agree on a syntax. And > (assuming people aren't completely irrational), the very existence of the > wildly differing syntaxes tells me there are different needs behind them. Yes, that's true, however I don't think it's totally important that GNOME and KDE share the setting for e.g. wallpaper. Mostly, I just stick to GNOME apps anyway. But I'm sure someday there will be some desktop settings that GNOME and KDE will share. > So your idea is getting rid of configuration files and push everything into > LDAP? What if the LDAP server is down? And you need to cache stuff for disconnect operation e.g. laptops. I think Microsoft showed this was possible with AD. > Who says LDAP is the right framework, i.e., is rich enough for the needs? > Who says the result won't be just shoveling the garbage into another opaque > junkyard? I'm not saying this is easy. But I am saying we need to be a lot more ambitious than e.g. Elektra. I agree this is a very difficult problem space to navigate in, especially because of the very bazaar nature of open source. It's definitely fixable if we get the right architecture hashed out to begin with. David From david at fubar.dk Mon Apr 3 18:43:33 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 03 Apr 2006 14:43:33 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> Message-ID: <1144089814.2270.69.camel@daxter.boston.redhat.com> On Mon, 2006-04-03 at 12:11 -0300, Avi Alkalay wrote: > On 4/3/06, Horst von Brand wrote: > > That is the crux of the matter: Glorious schemes for world domination "if > > only everybody will agree on the same configuration file syntax" are thrown > > around here, but the ones in charge of adopting said syntax have > > historically shown very, very little desire to agree on a syntax. > > Here comes the role of distributions as the integrator. > This is why I say each of these projects (Apache, Samba, everything on > /etc/*, Gnome, KDE, etc) are a sort of "selfish" and "proprietary" > when it comes to overall integration architecture. Maybe these projects wants something more than just a simple replacement for their configuration file parser? Maybe parts of their configuration is marked as private and they don't want to make it easy for wanna-be administrators to change it? Maybe they want to offer an interactive configuration interface based on D-BUS with asynchronous notifications when state in the server changes? > > So your idea is getting rid of configuration files and push everything into > > LDAP? What if the LDAP server is down? > > What if you don't have/want a network? Just run the LDAP server locally. You want some caching LDAP server anyway for disconnected operation. > What if my mother only wants to install a new multimedia keyboard in > her standalone Linux box? She'll have to edit /etc/X11/xorg.conf? Or > wait for the distribution's HW detection tool to know how to handle > that? Clearly the best solutions is to let the HW provider know that > X.org configurations are pretty predictable in any distribution, and > it just have to provide some scripts to precisely integrate itself in > X.org configuration schema, instead of having to "compile", understand > and regenerate /etc/X11/xorg.conf only to install itself. Being so > difficult, this HW provider will simply, obviously, declare they do > not support Linux. Maybe I'm repeating myself but here goes: X.org should require no configuration file and should autodetect the software. It should also provide a D-BUS interface to desktop apps can configure the server and it can emit useful asynchronous notifications when e.g. a new monitor is attached. Hence, all display configuration is done per-desktop and settings are read from e.g. gconf. We can do similar tricks of reconfiguring the server on the fly when new hardware is hotplugged. For example you can disable the internal trackpad on a laptop when an external mouse is attached. Btw, system admins can lock this down if they want and it's trivial to write a display configuration applet that is the same across all distros just like e.g. removable media handling is now the same across all distributions. For the record, many of (influential) X.org developers with whom I've discussed this agrees this is the road ahead. It's just a lot of work and the people with these skills are busy with other things. David From shane at geeklords.org Mon Apr 3 18:47:02 2006 From: shane at geeklords.org (Shane Stixrud) Date: Mon, 3 Apr 2006 11:47:02 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144089204.2270.60.camel@daxter.boston.redhat.com> References: <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <1144089204.2270.60.camel@daxter.boston.redhat.com> Message-ID: On Mon, 3 Apr 2006, David Zeuthen wrote: > In particular we don't need a all-generic system like Elektra here. And > you really want your web server process (e.g. httpd) to know that it > reads configuration from the remote end to fix all the corner cases in a > nice way. Here is where we disagree. What you are proposing is a network configuration database which in certain cases I can certainly see the benefit. However it makes much more sense to standardize / unify configuration at the system level and then using a backend to export/import this data to LDAP. This eliminates the single point of failure, less over head, less complexity for normal case and only one program needs to be LDAP configuration aware. > I'm not saying this is easy. But I am saying we need to be a lot more > ambitious than e.g. Elektra. I agree this is a very difficult problem > space to navigate in, especially because of the very bazaar nature of > open source. It's definitely fixable if we get the right architecture > hashed out to begin with. Here is where I think the disconnect is, I agree that a network configuration database is a good idea in theory. I just think the implementation you describe could be better. Elektra and any system designed to be a generic system level configuration engine shouldn't be any more ambitious then it needs to be. It would be easy to add the functionality you are talking about if fedora was 100% elektra enabled. Cheers, Shane From avi at unix.sh Mon Apr 3 18:51:31 2006 From: avi at unix.sh (Avi Alkalay) Date: Mon, 3 Apr 2006 15:51:31 -0300 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144086734.2270.33.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <1144086734.2270.33.camel@daxter.boston.redhat.com> Message-ID: On 4/3/06, David Zeuthen wrote: > On Mon, 2006-04-03 at 11:50 -0300, Avi Alkalay wrote: > > In my opinion what you write is currently, unfortunately, plain utopia. > > Not at all, we're doing this for the desktop already! Good to know ! > As a matter of fact, I believe that for e.g. Apache a lot of "vertical > software" exists (both as proprietary and in-house solutions) for > managing clusters of web servers for example. Wouldn't it be nice if > Apache adopted one true way of doing this and we could all focus on an > UI configuration optimized for this instead of some random Registry > Editor? This is mostly the same problem, being attacked by different fronts. While Elektra tries to do it in a more general fashion in the base of the problem, looks like you guys are trying to improve the Apache silo. Going further in your way seems we are going to have many different improved silos, which will be again not integrated and suitable only for datacenters. > It's not utopia, it just requires a lot of hard work and effort to do > things right. I tend to believe that if you don't do things right the > first time you will never get it right because "good enough is the enemy > of perfect" or something. Cool, but just take care to create a lot of impenetrable configuration silos, in a model useful only in datacenters. Regards, Avi From benjy.grogan at gmail.com Mon Apr 3 19:34:17 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Mon, 3 Apr 2006 15:34:17 -0400 Subject: Fedora Art Team Now Open In-Reply-To: <4430AE40.3080108@redhat.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> Message-ID: On 4/3/06, Warren Togami wrote: > Eric S. Raymond wrote: > > First, a relatively minor issue that is nevertheless quite annoying. > > It's the Fedora distribution art, the images in Anaconda and the > > Fedora-customized graphics in the admin tools and elsewhere. It has > > never been much better than mediocre, and in FC5 it hits a new low > > with backgrounds that look like a Teletubby hocked loogies into a > > dish full of soap scum. And whose bright idea, I have to wonder, was > > it to abandon the attractive and recognizable Fedora icon for > > something that's...not a fedora? > > > > Cripes. By comparison, even the original BlueCurve was superior. And > > original BlueCurve wasn't much to cheer about compared to the > > decorative art on a Windows or (especially) a Mac -- acceptable, but > > not a competitive plus, not something that would actually attract > > users. The FedoraBubbles stuff is bland and tacky goo that I expect > > will repel them. > > It didn't become terrible, but I personally believe that the artwork in > FC5 was a small step backwards. I think maybe we could improve this > situation in the future by treating artwork as a community project with > feedback and (maybe) voting, rather than impose it on the community. > Perhaps the FC6 desktop background could be made into an art contest > with judging and prizes. I completely disagree. I think the artwork in FC5 is a step forward. I didn't hate the artwork in FC4 but it was kind of dark and cold looking. The bubbles are a little weird but there is a brightness to the desktop now that wasn't there before. A step forward, but room for improvement. Benjy From nicolas.mailhot at laposte.net Mon Apr 3 19:38:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Apr 2006 21:38:31 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> Message-ID: <1144093114.2656.20.camel@rousalka.dyndns.org> Le lundi 03 avril 2006 ? 14:51 -0300, Avi Alkalay a ?crit : > Nicolas, is very hard to discuss opinions and that was your opinion. I > respect that, even if I can't understand in what you based this > opinion. Avi, Let's just most software I've seen on the Linux and Windows side (as part of a closed software editor, as a FOSS and closed software integrator) cares very little about the rest of the system. It's oh-so-much easier and cheaper to dump safe (for your bit of software) values in common config files than test values which won't badly affect other parts of the system (as a bonus you can crash your competitors apps sometimes). By being dumb and blind you can save money to implement crucial bits like putting the company logo on every window of your configuration app, paint it in company colors, etc (always a wining point with your PHB, and another reason *not* to integrate with everyone else) Sanity happens when it's forced top-down by a coordination point, either (in the windows case) MS menacing to retire some crucial support bit (logo, program participation) or (in the FOSS case) some central software clearinghouse (LKML, xorg, fedora) refusing to include some bits before things have been fixed up. The fact every single closed software offering for Linux lags one or two generations behind in the software integration front (utf-8, selinux, core fonts -> fontconfig, oss -> alsa...) should tell you pretty clearly how high playing nice with the rest of the system is on traditional hardware/software corps agendas. And your want to give these people the keys to the system conf? Please. I'm sure you can find saner examples than this. The only companies I've seen in the business that genuinely cared about the system picture are infrastructure companies (OS suppliers, tools vendors like BEA). And they don't need elektra because they already know the system well enough to patch it as need. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Apr 3 18:26:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Apr 2006 20:26:55 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> Message-ID: <1144088818.9138.20.camel@rousalka.dyndns.org> Le lundi 03 avril 2006 ? 14:51 -0300, Avi Alkalay a ?crit : > Nicolas, is very hard to discuss opinions and that was your opinion. I > respect that, even if I can't understand in what you based this > opinion. Actual shipping software which already behaves like this (server-side, where closed app vendors are already investing in integration), some years working in a software editor etc... It's way cheaper to write blindly "safe" parameters in a conf file (safe for your part of the system that is) than try to behave nicely with the rest of the system (which may more often than not include the products of your competitors). Especially on the desktop if your bit works and other don't the user will blame the other bits. The way all existing proprietary software for Linux systematically lags two or three generations behind the FOSS offerings on the integration front (core libs used, oss->alsa migration, core fonts -> fontconfig migration, ia32 -> amd64 transition, selinux...) should tell you where the keyboard manufacturer priorities will be. > My opinion is based mostly in observable > evidence on what happened in the Windows world (the good parts), and a > bit of intuition. My opinion is based mostly in observable evidence on what happened in the Windows world (the bad parts), and the fact a lot of the good parts only materialised after MS waving a big stick before app vendors. Plus all I've seen on the Linux front. Your example adds the windows-like "liberty" to fool around and removes the current big stick (clearinghouses). If elektra succeeds I predict this will be because big organised projects like Gnome or KDE adopt it and force some centralized decisions, not because various app vendors use it to poke holes in settings they shouldn't be allowed to change in the first place. And I'll freely admit there is demand from app vendors to get the means to fool around like this, except the world in general and my desktop in particular will be a better place if this stays denied to them. upstream, upstream, upstream as Fedora decided, you should listen to the people at Red Hat which actually have experience on the Linux integration front and take the long term view. Short-circuiting the integration process like you propose is a bad proposition for everyone (including your vendor). Even if its windows habits make it lean this way. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Mon Apr 3 19:46:27 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Apr 2006 15:46:27 -0400 Subject: rawhide report: 20060328 changes In-Reply-To: <1143583434.3595.5.camel@localhost.localdomain> References: <200603280837.k2S8bEZR024955@porkchop.devel.redhat.com> <1143583434.3595.5.camel@localhost.localdomain> Message-ID: <20060403194627.GS27229@devserv.devel.redhat.com> Rodd Clarkson (rodd at clarkson.id.au) said: > On Tue, 2006-03-28 at 03:37 -0500, Build System wrote: > > gnucash-1.9.3-1 > > --------------- > > * Mon Mar 27 2006 Bill Nottingham - 1.9.3-1 > > - update to 1.9.x > > the old gnucash had a whole stack of dependencies to gtk1 stuff. Can > this now be removed from core? Sure, just need to get around to enumerating them (was out last week.) Bill From j.w.r.degoede at hhs.nl Mon Apr 3 19:46:33 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 03 Apr 2006 21:46:33 +0200 Subject: rawhide report: 20060328 changes In-Reply-To: <20060403194627.GS27229@devserv.devel.redhat.com> References: <200603280837.k2S8bEZR024955@porkchop.devel.redhat.com> <1143583434.3595.5.camel@localhost.localdomain> <20060403194627.GS27229@devserv.devel.redhat.com> Message-ID: <44317B99.3010908@hhs.nl> Bill Nottingham wrote: > Rodd Clarkson (rodd at clarkson.id.au) said: >> On Tue, 2006-03-28 at 03:37 -0500, Build System wrote: >>> gnucash-1.9.3-1 >>> --------------- >>> * Mon Mar 27 2006 Bill Nottingham - 1.9.3-1 >>> - update to 1.9.x >> the old gnucash had a whole stack of dependencies to gtk1 stuff. Can >> this now be removed from core? > > Sure, just need to get around to enumerating them (was out last week.) > Erm, Please coordinate this with extras which still has gtk1 dependencies. Just removing them from Rawhide will break Extras Development, it would be nice to give FE a chance to pick them up first. Regards, Hans From nicolas.mailhot at laposte.net Mon Apr 3 20:02:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 03 Apr 2006 22:02:14 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144093114.2656.20.camel@rousalka.dyndns.org> References: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <200604030648.k336mdAh019766@laptop11.inf.utfsm.cl> <61856.192.54.193.25.1144077946.squirrel@rousalka.dyndns.org> <1144093114.2656.20.camel@rousalka.dyndns.org> Message-ID: <1144094540.2656.21.camel@rousalka.dyndns.org> (sorry about the duplicate answer, I though my rawhide evo had eaten the previous message when crashing) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From vonbrand at inf.utfsm.cl Mon Apr 3 20:40:06 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 16:40:06 -0400 Subject: The Strengths and Weakness of Fedora/RHEL OS management In-Reply-To: Your message of "Mon, 03 Apr 2006 10:36:36 MST." Message-ID: <200604032040.k33Ke6bX001480@laptop11.inf.utfsm.cl> Shane Stixrud wrote: > On Mon, 3 Apr 2006, Horst von Brand wrote: > > Some (simple) configurations can be described by a bunch of "Variable FOO > > gets the value BAR", others just cannot (sanely, at least). There is stuff > > like DNS, a web server for several domains, or the setup of a DHCP server > > for multiple nets, where you just can't pretend everything is one flat, > > uniform space. Configuration spaces have structure, and the whole idea of a > > configuration file with a non-trivial syntax is to be able to mirror said > > structure. The spaces aren't shaped equal, so either you end up squashing > > everything into some (unnatural) flat representation or you end up with the > > sum total of all (possible) diferent shapes (which is completely impossible > > for a mere human to handle). Sure, you can decree that configuration files > > are written in XML, which is expressive enough to create its own syntax on > > a file-by-file basis, but even that doesn't help one bit with the mapping > > of syntax to semantics (which /is/ the whole point, after all). > Have you even read how Elektra works or looked at the earlier > multi-subnet dhcpd.conf examples? There is nothing about Elektra that > is flat nor does structure have anything to do with semantics! There is the central problem: Semantics /is/ structure, can't get rid of the one without losing the other. > Elektra's format contains all of the functional elements required to > EASILY generate dhcpd.conf in its entirety... this has been stated > previously... Isn't useful at all unless everybody shares the same configuration variables. And getting everybody to use the same configuration variables is a nightmare... Having everybody use their own namespace is exactly the mess we are in today, just with the same syntax all over. This is a very minor (if any) step forward; I'd say it is more of a sizeable step backwards. That there are several backends (plain files, filesystems, gconf, Win registry, ...) just adds a (useless) translation layer that can (and thus will) break when the underlying "real" syntax changes. Plus it goes haywire all the same when some bright mind decides to change the meaning of some configuration construct... Pray tell, how does adding just another (pretty-printed, I'll grant you) mess to the mix disentangle the whole? Again, Turing machines have all the elements to construct the kernel in them. Why doesn't somebody do so? > I am trying to decide if you are purposely being obtuse or just > operating on pre-conceived notions... I am trying to give you the > benefit of the doubt. IF this thread has low value I dare say it is > because of posts like the above that leads to distract and confuse the > actual discussion. There is nothing useful to discuss: Elektra is just the Windows registry, done for Unix, /over/ the existing configuration system. It failed miserably there (where they /do/ have the advantage of a rather thight central control point, and no underlying configuration schema that could change under their feet), it can only do much worse here. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Apr 3 20:49:16 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 03 Apr 2006 16:49:16 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: Message from David Zeuthen of "Mon, 03 Apr 2006 14:33:23 -0400." <1144089204.2270.60.camel@daxter.boston.redhat.com> Message-ID: <200604032049.k33KnGJH001545@laptop11.inf.utfsm.cl> David Zeuthen wrote: > On Mon, 2006-04-03 at 02:48 -0400, Horst von Brand wrote: > > David Zeuthen wrote: > > my view is that if we solve > > > it for desktop then the server bits will pan out mostly by itself. > > > > No, the problem spaces are different. > > Doesn't have to be. OK, so configuring a DNS server has to look exactly the same as setting up the theme for my window manager... [...] > > So you advocate not configuring the web server via files, but remotely via > > LDAP? How is that different from "configuration files"? > It's different insofar that since you already serve configuration from > the LDAP server it's next-to-trivial to use the same mechanism to > actually change the configuration. Hence, it's a lot easier to write a > single configuration UI (or whatever) that all distros can use. OK, so you use a generic LDAP browser/editor to change configurations. What makes that better than using $EDITOR on text files? I see massive disadvantages (LDAP becomes a requirement to even start the machine usefully, network breakdowns make everything freeze, one more service to worry about on a server type machine, ...) and the only advantages I see are a single configuration syntax (but the underlying semantics stay as messed up as today (if it doesn't get even worse), so this doesn't help that much) and the possibility to distribute configurations all over the place (which normally is jut a single machine, so not too much of a gain). > In particular we don't need a all-generic system like Elektra here. And > you really want your web server process (e.g. httpd) to know that it > reads configuration from the remote end to fix all the corner cases in a > nice way. I /don't/ want any more complexity in a web server process, it has to remain auditable (and as independent of external sources as possible, for paranoia's sake). > > In any case, this is system-wide, just that your system is larger than one > > box. > Terminology. That's what I call site-wide. Then I really don't get it. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From overholt at redhat.com Mon Apr 3 21:01:37 2006 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 3 Apr 2006 17:01:37 -0400 Subject: Where's eclipse-cdt? In-Reply-To: <1144020676.31660.20.camel@localhost.localdomain> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> <1143987237.442fdc2517606@www.jouy.inra.fr> <1143994910.18098.5.camel@ender> <1144020676.31660.20.camel@localhost.localdomain> Message-ID: <20060403210137.GL18954@redhat.com> * David Woodhouse [2006-04-02 19:32]: > On Sun, 2006-04-02 at 09:21 -0700, Jesse Keating wrote: > > We may not be building all the java components on all the arches > > currently. I do recall some arches proving problematic as we were > > trying to get a release out and were excluded from the final builds. > > During this development cycle we should try and re-enable all the > > arches and spend some time trying to fix things so that they'll build > > on all arches. > > We should have bugs filed for any arch exclusion to keep track of such > things. We do for this particular one (well, the SDK which was the blocker on this). I'll build the CDT on ia64 now. Andrew From wtogami at redhat.com Mon Apr 3 21:52:20 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 03 Apr 2006 17:52:20 -0400 Subject: Fedora Art Team Now Open In-Reply-To: References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> Message-ID: <44319914.1070001@redhat.com> Benjy Grogan wrote: >> It didn't become terrible, but I personally believe that the artwork in >> FC5 was a small step backwards. I think maybe we could improve this >> situation in the future by treating artwork as a community project with >> feedback and (maybe) voting, rather than impose it on the community. >> Perhaps the FC6 desktop background could be made into an art contest >> with judging and prizes. > > I completely disagree. I think the artwork in FC5 is a step forward. > I didn't hate the artwork in FC4 but it was kind of dark and cold > looking. The bubbles are a little weird but there is a brightness to > the desktop now that wasn't there before. A step forward, but room > for improvement. > > Benjy > OK right, whether FC5 was an improvement or not is subjective and doesn't matter. What does matter is that we should be building a community around art. The community should be submitting candidates for the Fedora background, and the community should (somehow) decide which we choose for the release. Warren Togami wtogami at redhat.com From fedora at nodata.co.uk Mon Apr 3 22:04:59 2006 From: fedora at nodata.co.uk (nodata) Date: Tue, 04 Apr 2006 00:04:59 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) Message-ID: <1144101899.2821.26.camel@sb-home.lan> > - Session-wide software: Just so we're all on the same page, > "session-wide" means something that runs in a user desktop session. > Historically, the desktop wasn't very advanced and didn't integrate well > with the system. Back then things that really was session-wide would run > as a system-wide daemon mostly also because it required root to enforce > policy. Things like acpid for power management event handling, updfstab > for removable media, ifplugd for handling network cable removable, > networking scripts etc. comes to mind. As you can see with Fedora Core 5 > this is radically starting to change; acpid is obsoleted by > gnome-power-manager, updfstab (and fstab-sync for that matter) is > obsoleted by gnome-volume-manager / gnome-mount, the networking scripts > is starting to be completely obsoleted by NetworkManager. We have more > things on out "hit list"... > I hope the hit list doesn't get much longer, you're moving all of the command-line power of Linux into guis, exactly the opposite of why pretty much everyone I work with uses it. I'm sure it's tucked away in the gconf registry somewhere. Anyway.. I haven't been following this closely, so apologies if I overlap with something already said. I'd like to ask a few questions about how system-wide configuration is being replaced by session-wide configuration. It is as if the desktop is being assumed to have a single user. These questions come from someone used to doing command-line configuration, not the gui stuff. There seem to be a lot of new programs that replicate functionality that you might expect a system-wide daemon to perform, plus perhaps a fancy (tiny) *optional* gui to interface with the end-user. But I don't really know how pup or NetworkManager work, which is why I'm sending this e-mail. I'm sure other people (probably not on this list) might have made similar assumptions. For example, pup checks for updates, notifies the user if there are any, then lets them choose to install them. What if there is more than one user? Does everyone get to decide? Why isn't some yum updater daemon downloading the updates automatically, and pup then springing the question on the user about whether they want to update? Is this not as good? Networking with NetworkManager - is this per-user too? Can all users on a system decide which networking connection they want to take preference? Is there a scoring system to decide who wins? Gnome power manager - why does each user get an icon in the notification area? Can they all decide when the computer goes to sleep? Thanks, nd From hughsient at gmail.com Mon Apr 3 22:22:44 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 03 Apr 2006 23:22:44 +0100 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144101899.2821.26.camel@sb-home.lan> References: <1144101899.2821.26.camel@sb-home.lan> Message-ID: <1144102965.20723.15.camel@localhost.localdomain> On Tue, 2006-04-04 at 00:04 +0200, nodata wrote: > Gnome power manager - why does each user get an icon in the > notification area? Because they are the ones wanting to know the battery status or change preferences. It's really only a tiny (as in memory and CPU) session daemon, all the heavy lifting is done in HAL. > Can they all decide when the computer goes to sleep? Only root, or the person physically sitting in front of the computer with the active login (called at_console in DBUS-speak). Richard. From dimi at lattica.com Mon Apr 3 22:51:11 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 3 Apr 2006 18:51:11 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths andWeakness of Fedora/RHEL OS management) References: <1144101899.2821.26.camel@sb-home.lan> <1144102965.20723.15.camel@localhost.localdomain> Message-ID: <00e701c65771$1bf01e40$b6491b31@td612671> From: "Richard Hughes" > Only root, or the person physically sitting in front of the computer > with the active login (called at_console in DBUS-speak). BTW, does it allow for multiple people at_console (for multi-head boxes)? -- Dimi Paun Lattica, Inc. From hughsient at gmail.com Mon Apr 3 23:05:33 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 04 Apr 2006 00:05:33 +0100 Subject: Why Elektra is the wrong approach (Was Re: The Strengths andWeakness of Fedora/RHEL OS management) In-Reply-To: <00e701c65771$1bf01e40$b6491b31@td612671> References: <1144101899.2821.26.camel@sb-home.lan> <1144102965.20723.15.camel@localhost.localdomain> <00e701c65771$1bf01e40$b6491b31@td612671> Message-ID: <1144105534.20723.22.camel@localhost.localdomain> On Mon, 2006-04-03 at 18:51 -0400, Dimi Paun wrote: > From: "Richard Hughes" > > Only root, or the person physically sitting in front of the computer > > with the active login (called at_console in DBUS-speak). > > BTW, does it allow for multiple people at_console (for multi-head boxes)? Never tested it with multi-head, so I don't know. If it doesn't work as expected then you should probably post to the dbus-devel list. Richard. From seg at haxxed.com Tue Apr 4 05:01:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 04 Apr 2006 00:01:02 -0500 Subject: Why Elektra is the wrong approach (Was Re: The Strengths andWeakness of Fedora/RHEL OS management) In-Reply-To: <00e701c65771$1bf01e40$b6491b31@td612671> References: <1144101899.2821.26.camel@sb-home.lan> <1144102965.20723.15.camel@localhost.localdomain> <00e701c65771$1bf01e40$b6491b31@td612671> Message-ID: <1144126863.10632.153.camel@localhost> On Mon, 2006-04-03 at 18:51 -0400, Dimi Paun wrote: > From: "Richard Hughes" > > Only root, or the person physically sitting in front of the computer > > with the active login (called at_console in DBUS-speak). > > BTW, does it allow for multiple people at_console (for multi-head boxes)? You mean multi-seat. http://linuxgazette.net/124/smith.html Personally I have a two-seat system for me and my wife. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dimi at lattica.com Tue Apr 4 05:18:52 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 04 Apr 2006 01:18:52 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths andWeakness of Fedora/RHEL OS management) In-Reply-To: <1144126863.10632.153.camel@localhost> References: <1144101899.2821.26.camel@sb-home.lan> <1144102965.20723.15.camel@localhost.localdomain> <00e701c65771$1bf01e40$b6491b31@td612671> <1144126863.10632.153.camel@localhost> Message-ID: <1144127932.2808.75.camel@dimi> On Tue, 2006-04-04 at 00:01 -0500, Callum Lerwick wrote: > You mean multi-seat. http://linuxgazette.net/124/smith.html Right. I was just wondering if all this special handling for console users works correctly in a multi-seat configuration. -- Dimi Paun Lattica, Inc. From kevacm at gmail.com Tue Apr 4 06:06:08 2006 From: kevacm at gmail.com (Kevac Marko) Date: Tue, 4 Apr 2006 10:06:08 +0400 Subject: FC5 boot problems In-Reply-To: <44313508.5080906@city-fan.org> References: <442E2805.2020401@knox.net.nz> <4fb2cbe00604020445j5fc28517se3989fe933ad5bd0@mail.gmail.com> <44313508.5080906@city-fan.org> Message-ID: <4fb2cbe00604032306n626834e5w3253a5e8fb93a2d6@mail.gmail.com> On 4/3/06, Paul Howarth wrote: > How can that help when the hang is *much* earlier in the boot process > than kudzu startup? Well, i am talking about my situation. For me turning off the kudzu was solution. I tried to turn it on again - FC freezes. From 777tahder at schlaegel.com Tue Apr 4 06:10:55 2006 From: 777tahder at schlaegel.com (Schlaegel) Date: Mon, 3 Apr 2006 23:10:55 -0700 Subject: Fedora Art Team Now Open In-Reply-To: <4430AE40.3080108@redhat.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> Message-ID: <4e1f5c1a0604032310o5a769347qe583b8b2c5ed2c35@mail.gmail.com> On 4/2/06, Warren Togami wrote: > It didn't become terrible, but I personally believe that the artwork in > FC5 was a small step backwards. I think maybe we could improve this > situation in the future by treating artwork as a community project with > feedback and (maybe) voting, rather than impose it on the community. > Perhaps the FC6 desktop background could be made into an art contest > with judging and prizes. > Join the team, figure out what the goals are and who is interested to > work on them, and we can have a community meeting on IRC sometime soon > to form some kind of organization. Might I suggest that building (or adopting) a consistent icon theme across all packages including oo.org is more important than choosing a default background. I think the last two FC releases have been a big step down from the Bluecurve days for this very reason. PS. I like the FC5 bubbles. From buildsys at redhat.com Tue Apr 4 07:27:12 2006 From: buildsys at redhat.com (Build System) Date: Tue, 4 Apr 2006 03:27:12 -0400 Subject: rawhide report: 20060404 changes Message-ID: <200604040727.k347RCCe029877@porkchop.devel.redhat.com> Updated Packages: bind-30:9.3.2-18.FC6 -------------------- * Mon Apr 03 2006 Jason Vas Dias - 30:9.3.2-18 - fix bug 187529: make bind-chroot-admin deal with subdirectories properly eclipse-cdt-1:3.0.2-1jpp_3fc ---------------------------- * Mon Apr 03 2006 Andrew Overholt 3.0.2-1jpp_3fc - Add ia64. gkrellm-2.2.9-1 --------------- * Mon Apr 03 2006 Karsten Hopp 2.2.9-1 - update to 2.2.9 - remove explicit UID/GUIs from useradd/groupadd (#186974) gnome-screensaver-2.14.0-4 -------------------------- * Tue Apr 04 2006 Ray Strode 2.14.0-4 - don't ignore idle timers after long suspend (bug 183668) gnupg-1.4.3-1 ------------- * Fri Mar 10 2006 Nalin Dahyabhai - 1.4.3 - update to 1.4.3 irda-utils-0.9.16-8 ------------------- * Mon Apr 03 2006 Karsten Hopp 0.9.16-8 - don't use asm/io.h directly (Bastien Nocera #186875) k3b-0:0.12.14-0.FC5.2 --------------------- * Tue Mar 21 2006 Harald Hoyer 0:0.12.14-0.FC5.2 - version 0.12.14 kdebase-6:3.5.2-2 ----------------- * Mon Apr 03 2006 Than Ngo 6:3.5.2-2 - update dbus patch kdepim-6:3.5.2-0.1.fc5 ---------------------- * Fri Mar 31 2006 Than Ngo 6:3.5.2-0.1.fc5 - update to 3.5.2 kernel-2.6.16-1.2118_FC6 ------------------------ * Mon Apr 03 2006 Dave Jones - Disable 'quiet' mode. * Sun Apr 02 2006 Dave Jones - 2.6.17rc1 * Sun Apr 02 2006 James Morris - Rework dom0 sedf scheduler defaults patch, bz # 181856 libXcomposite-0.3-1 ------------------- * Mon Apr 03 2006 Adam Jackson - 0.3-1 - Update to 0.3 from upstream. mesa-6.5-1 ---------- * Sat Apr 01 2006 Kristian H??gsberg 6.5-1 - Update to mesa 6.5 snapshot. - Use -MG for generating deps and some files aren't yet symlinked at make depend time. - Drop mesa-6.4.2-dprintf-to-debugprintf-for-bug180122.patch and mesa-6.4.2-xorg-server-uses-bad-datatypes-breaking-AMD64-fdo5835.patch as these are upstream now. - Drop mesa-6.4.1-texture-from-drawable.patch and add mesa-6.5-texture-from-pixmap-fixes.patch. - Update mesa-modular-dri-dir.patch to apply. - Widen libGLU glob. - Reenable r300 driver install. - Widen libOSMesa glob. - Go back to patching config/linux-dri, add mesa-6.5-build-config.patch, drop mesa-6.3.2-build-configuration-v4.patch. - Disable sis dri driver for now, only builds on x86 and x86-64. * Fri Mar 24 2006 Kristian H??gsberg 6.4.2-7 - Set ARCH_FLAGS=-DGLX_USE_TLS to enable TLS for GL contexts. metacity-2.15.0-2 ----------------- * Mon Apr 03 2006 Soren Sandmann - 2.15.0-2 - Fix leftover libcm-snapshot-date, buildrequire libXcomposite-devel >= 0.3 * Fri Mar 31 2006 Soren Sandmann - 2.15.0 - Update to 2.15.0 netpbm-10.32-2 -------------- * Mon Apr 03 2006 Jindrich Novy 10.32-2 - fix broken symlink in upstream: pnmsdepth -> pamdepth (#187667) newt-0.52.2-6 ------------- * Wed Mar 29 2006 Petr Rockai - 0.52.2-6 - fix #185950 by applying tmraz's patch (thanks) * Fri Feb 10 2006 Jesse Keating - 0.52.2-5.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0.52.2-5.1 - rebuilt for new gcc4.1 snapshot and glibc changes pcmciautils-012-0.FC5.2 ----------------------- * Thu Mar 23 2006 Harald Hoyer 012-0.FC5.2 - version 012 fixes #186164 selinux-policy-2.2.29-2 ----------------------- * Thu Mar 30 2006 Dan Walsh 2.2.29-2 - Add mono dbus support - Lots of file_context fixes for textrel_shlib_t in FC5 - Turn off execmem auditallow since they are filling log files shadow-utils-2:4.0.15-1 ----------------------- * Mon Apr 03 2006 Peter Vrabec 2:4.0.15-1 - upgrade * Fri Mar 10 2006 Peter Vrabec 2:4.0.14-4 - fix lrename() function to handle relative symlinks too * Tue Mar 07 2006 Peter Vrabec 2:4.0.14-3 - set default umask to 077 in login.defs tix-1:8.4.0-7 ------------- * Mon Apr 03 2006 David Cantrell - 1:8.4.0-7 - libTix8.4.so shared lib placement fixup (#187739) valgrind-1:3.1.1-1 ------------------ * Mon Apr 03 2006 Jakub Jelinek 3.1.1-1 - upgrade to 3.1.1 - many bugfixes valgrind-callgrind-0.10.1-2 --------------------------- * Mon Apr 03 2006 Jakub Jelinek 0.10.1-2 - require valgrind 3.1.1 * Tue Feb 07 2006 Jesse Keating 0.10.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Mon Jan 16 2006 Jakub Jelinek 0.10.1-1 - update to 0.10.1 (#176551) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 From j.w.r.degoede at hhs.nl Tue Apr 4 07:41:47 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 04 Apr 2006 09:41:47 +0200 Subject: rawhide report: 20060404 changes In-Reply-To: <200604040727.k347RCCe029877@porkchop.devel.redhat.com> References: <200604040727.k347RCCe029877@porkchop.devel.redhat.com> Message-ID: <4432233B.5060304@hhs.nl> Build System wrote: > > mesa-6.5-1 > ---------- > * Sat Apr 01 2006 Kristian H??gsberg 6.5-1 > - Disable sis dri driver for now, only builds on x86 and x86-64. > Erm and thats a problem how? Aren't most SIS chips integrated on x86 motherboards? I know SIS has made a few videocards, but I wouldn't expect on in a PPC machine, can't you make this disabling arch dependent? Regards, Hans From j.rink at freenet.de Tue Apr 4 07:58:44 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Tue, 4 Apr 2006 09:58:44 +0200 Subject: Suspend problems on a thinkpad? In-Reply-To: <4430A3E6.3070109@redhat.com> References: <4430A3E6.3070109@redhat.com> Message-ID: <20060404095844.ba0d3dcf.j.rink@freenet.de> Am Mon, 03 Apr 2006 00:26:14 -0400 hat Brad Smith (Brad Smith) folgendes geschrieben: Hi, i tested it here on a T23. It is a fresh install without any kernel parameter. It works while pressing Fn + F4. One problem here while resuming, X is fine, but the console is corrupt, you see nothing than garbage. But the console itself seems to work, because compiling wine still runs ;-) CU, J?rn Rink From pbrobinson at gmail.com Tue Apr 4 10:30:54 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 4 Apr 2006 11:30:54 +0100 Subject: gnome/gtk v1 in rawhide Message-ID: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> I seem to remember I've asked this before... and the answer was because gnucash needs it. So now that the gnucash version in rawhide is 1.9.x and hence finally (yay) heading for gtk/gnome2 support can all the gtk1/gnome1 stuff finally be shunted off to extras for some core-size-reduction-love? Peter From sdl.web at gmail.com Tue Apr 4 11:09:57 2006 From: sdl.web at gmail.com (Leon) Date: Tue, 04 Apr 2006 12:09:57 +0100 Subject: gnome/gtk v1 in rawhide References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> Message-ID: "Peter Robinson" writes: > I seem to remember I've asked this before... and the answer was > because gnucash needs it. So now that the gnucash version in rawhide > is 1.9.x and hence finally (yay) heading for gtk/gnome2 support can > all the gtk1/gnome1 stuff finally be shunted off to extras for some > core-size-reduction-love? > > Peter That's a great idea. I second this. The ugly interface of gtk1 has nowhere to fit into modern gnome desktop. -- Leon From fedora at camperquake.de Tue Apr 4 11:32:38 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Apr 2006 13:32:38 +0200 Subject: gnome/gtk v1 in rawhide In-Reply-To: References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> Message-ID: <20060404133238.72875b12@soran.addix.net> Hi. On Tue, 04 Apr 2006 12:09:57 +0100, Leon wrote: > That's a great idea. I second this. > The ugly interface of gtk1 has nowhere to fit into modern gnome > desktop. Although gtk1 programs tend to use quite less screen space than their gtk2 counterparts. From dwmw2 at infradead.org Tue Apr 4 11:33:17 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 12:33:17 +0100 Subject: rawhide report: 20060404 changes In-Reply-To: <4432233B.5060304@hhs.nl> References: <200604040727.k347RCCe029877@porkchop.devel.redhat.com> <4432233B.5060304@hhs.nl> Message-ID: <1144150397.11377.96.camel@pmac.infradead.org> On Tue, 2006-04-04 at 09:41 +0200, Hans de Goede wrote: > Erm and thats a problem how? Aren't most SIS chips integrated on x86 > motherboards? I know SIS has made a few videocards, but I wouldn't > expect on in a PPC machine, can't you make this disabling arch > dependent? I have an SiS card lying around somewhere. It's pure fluke that it was the Matrox I picked up to stick in my Pegasos the other day rather than the SiS. Non-portable code is broken code. I'd much rather see it just getting disabled -- we can be more pragmatic in the run-up to a release, if it isn't actually fixed by then. Per-arch exclusions are _always_ bad, because they tend to get forgotten about. -- dwmw2 From pbrobinson at gmail.com Tue Apr 4 11:42:23 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 4 Apr 2006 12:42:23 +0100 Subject: rawhide report: 20060404 changes In-Reply-To: <1144150397.11377.96.camel@pmac.infradead.org> References: <200604040727.k347RCCe029877@porkchop.devel.redhat.com> <4432233B.5060304@hhs.nl> <1144150397.11377.96.camel@pmac.infradead.org> Message-ID: <5256d0b0604040442k21a0983av36edb6bdd4a3d6f3@mail.gmail.com> > > Erm and thats a problem how? Aren't most SIS chips integrated on x86 > > motherboards? I know SIS has made a few videocards, but I wouldn't > > expect on in a PPC machine, can't you make this disabling arch > > dependent? > > I have an SiS card lying around somewhere. It's pure fluke that it was > the Matrox I picked up to stick in my Pegasos the other day rather than > the SiS. > > Non-portable code is broken code. I'd much rather see it just getting > disabled -- we can be more pragmatic in the run-up to a release, if it > isn't actually fixed by then. > > Per-arch exclusions are _always_ bad, because they tend to get forgotten > about. Is/Should there be a bug report so that its not forgotten about to be reinabled for select arches in the lead up to a release? Pete From nicolas.mailhot at laposte.net Tue Apr 4 11:59:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 4 Apr 2006 13:59:58 +0200 (CEST) Subject: gnome/gtk v1 in rawhide In-Reply-To: <20060404133238.72875b12@soran.addix.net> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> Message-ID: <61581.192.54.193.25.1144151998.squirrel@rousalka.dyndns.org> Le Mar 4 avril 2006 13:32, Ralf Ertzinger a ?crit : > Hi. > > On Tue, 04 Apr 2006 12:09:57 +0100, Leon wrote: > >> That's a great idea. I second this. >> The ugly interface of gtk1 has nowhere to fit into modern gnome >> desktop. > > Although gtk1 programs tend to use quite less screen space than their > gtk2 counterparts. They can use as little screen space as they want - they don't do i18n properly so they can be dumped as far as I'm concerned. This way they'll use even less screen estate (evil grin) -- Nicolas Mailhot From jdesbonnet at gmail.com Tue Apr 4 12:13:01 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Tue, 4 Apr 2006 13:13:01 +0100 Subject: Suspend problems on a thinkpad? In-Reply-To: References: <4430A3E6.3070109@redhat.com> Message-ID: <1cef3e950604040513u6dd55883tf97724203fd46dce@mail.gmail.com> >From a discussion here last week I think those disk errors are relating to the HPA (Host Protected Areas). I am 100% sure what it's all about, but as far as I can tell, its related to the hidden space the Thinkpad maintains on disk for diagnostic tools and Windows recovery. I believe it's possible to disable it but I suspect that might interfere with the Windows side of things. I think I'll wait for a fix (which I belive someone is working on, but I can't find any Bugzilla entries!). BTW: I notice that Ubuntu 5.10 live cd can suspend/unsuspend my Thinkpad T41p, but FC5 to-date cannot (that however might have something to do with it being a Live CD). Joe. On 4/3/06, Shane Stixrud wrote: > On Mon, 3 Apr 2006, Brad Smith wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Has anyone found a trick for (or even had a problem) getting suspend to work properly under FC5 on a > > Thinkpad T30? Under FC4 everything worked fine on mine, I just had to include "apm=on acpi=off" > > in the kernel args. After a fresh install of FC5, with or without the kernel args, it is a no go. > > When I close the laptop it goes into suspend, but when I open it again I experience varying levels > > of freezing up. I say varying because sometimes it's locked completely, sometimes the mouse moves > > but the cursor does not change, clicks are unresponsive and the keyboard does nothing. One time > > things seemed to work but when I moved my mouse over the gnome panel it disappeared. I switched to a > > VC and back, which somehow fixed the problem. > > Well suspend works fine on my T41 thinkpad, it is resume that kills my > system ;). In my case it resumes fine everything works for a few > seconds to a minute and then I get major disk errors in dmesg, disk mounts > read-only then system crashes, but not before I get disk corruption :(. > Sounds like your problem might be a bit different? > > I opened a bugzilla on my issue here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187633 > > Cheers, > Shane > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicu_fedora at nicubunu.ro Tue Apr 4 12:13:29 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 04 Apr 2006 15:13:29 +0300 Subject: gnome/gtk v1 in rawhide In-Reply-To: <20060404133238.72875b12@soran.addix.net> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> Message-ID: <443262E9.4040305@nicubunu.ro> Ralf Ertzinger wrote: > > Although gtk1 programs tend to use quite less screen space than their > gtk2 counterparts. I think this is because they usually are not following the Gnome HIG, not because of the widget set used (and this is for good reason - those programs are ancient, written before the HIG existed). -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From paul at city-fan.org Tue Apr 4 12:18:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Apr 2006 13:18:04 +0100 Subject: FC5 boot problems In-Reply-To: <4fb2cbe00604032306n626834e5w3253a5e8fb93a2d6@mail.gmail.com> References: <442E2805.2020401@knox.net.nz> <4fb2cbe00604020445j5fc28517se3989fe933ad5bd0@mail.gmail.com> <44313508.5080906@city-fan.org> <4fb2cbe00604032306n626834e5w3253a5e8fb93a2d6@mail.gmail.com> Message-ID: <443263FC.5060609@city-fan.org> Kevac Marko wrote: > On 4/3/06, Paul Howarth wrote: >> How can that help when the hang is *much* earlier in the boot process >> than kudzu startup? > > Well, i am talking about my situation. > For me turning off the kudzu was solution. > > I tried to turn it on again - FC freezes. FWIW, I did a clean install on a different hard disk and that did not exhibit the problem - kudzu enabled. Paul. From fedora at camperquake.de Tue Apr 4 12:21:55 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Apr 2006 14:21:55 +0200 Subject: gnome/gtk v1 in rawhide In-Reply-To: <443262E9.4040305@nicubunu.ro> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> <443262E9.4040305@nicubunu.ro> Message-ID: <20060404142155.546a5b6a@soran.addix.net> Hi. On Tue, 04 Apr 2006 15:13:29 +0300, Nicu Buculei wrote: > I think this is because they usually are not following the Gnome HIG, > not because of the widget set used (and this is for good reason - > those programs are ancient, written before the HIG existed). I think this is due to the smaller fonts they use. The same reason as to why Windows desktops look different from the usual GNOME/KDE screenshots - The windows standard fonts are smaller (I am not sure if they are antialiased or not) From dwmw2 at infradead.org Tue Apr 4 12:44:37 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 13:44:37 +0100 Subject: Move Evolution to Extras? Message-ID: <1144154677.11377.105.camel@pmac.infradead.org> Evolution is fairly much broken in FC5, and there's little movement even on the 'this mail crashes Evolution' bugs, let alone the "Evolution is totally unusable with IMAP" bugs. What are we going to do about it? One option might be to move it to Extras in the hope that someone will actually start to look after it there. Or perhaps just drop it entirely? Any better ideas? Volunteers? -- dwmw2 From dimi at lattica.com Tue Apr 4 12:53:19 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 04 Apr 2006 08:53:19 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <1144155199.2808.94.camel@dimi> On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > Evolution is fairly much broken in FC5 I'm curious why you are saying that. It's true, printing doesn't work for me [1] (which is a rather important function I might add), but other than that it's been OK here, both POP and IMAP. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186653 -- Dimi Paun Lattica, Inc. From mailinglists at erwinrol.com Tue Apr 4 12:58:46 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 04 Apr 2006 14:58:46 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <1144155526.6347.117.camel@xpc.home.erwinrol.com> On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? What will be a replacement for evolution ? Meaning something with a good address book, calendar and task management. Firebird, Sunbird aren't GNOME applications which gives them a different look and feel. Sylpheed only does mail, and isn't in core but in extra's. so what are the alternatives ? Evolution might be technically broken, but it still is one of the more useful GNOME applications. And yes even though i like evolution, it is a slow memory hog that hangs a lot (i haven't seen any "this mail crashes evolution" though). - Erwin From jspaleta at gmail.com Tue Apr 4 13:03:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Apr 2006 09:03:18 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> On 4/4/06, David Woodhouse wrote: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? Difficult to do considering the depchains. If you want beagle in Core then evolution has to be in Core with the current packaging. beagle needs evolution-sharp which needs evolution. -jef"though my candidate for wackiest depchain in Core right now is rhythmbox's dependancy on totem through the libtotem-plparser.so.1 library"spaleta From webmaster at margo.bijoux.nom.br Tue Apr 4 13:15:20 2006 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 4 Apr 2006 10:15:20 -0300 Subject: Move Evolution to Extras? In-Reply-To: <1144155199.2808.94.camel@dimi> References: <1144155199.2808.94.camel@dimi> Message-ID: <20060404131520.19567.qmail@hm196.locaweb.com.br> On Tue, 04 Apr 2006 08:53:19 -0400, Dimi Paun escreveu: > On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > > Evolution is fairly much broken in FC5 > > I'm curious why you are saying that. It's true, printing doesn't > work for me [1] (which is a rather important function I might add), > but other than that it's been OK here, both POP and IMAP. > Quoting David's blog: >Bug #336076 (RH #183219): Evolution no longer uses STATUS to check for new mail -- instead it SELECTs every single folder in the system, downloads all headers and flags for every mail. Add then bug #336074 (RH #167805) to the previous one and you get a pretty bad situation where you check all your old folders even when you dont want them and you do it using the slowest method possible (the above bug). Those two can be a bit problematic if you have an IMAP server that is outside of your network and your link is a bit overloaded or you have a lot of e-mail stored on the server. However, moving evolution to extras may not be a good idea IMHO, since evolution is the only tool (that I know of) that supports Exchange servers. That is certainly an important feature for many people in corporate environments (or people who use FC at home and need evolution to use the work e-mail). I'm not a big fan of evolution (specially because of the way it eats away the memory), but in my case, I have to use it because of that evil exchange server... -- Pedro Macedo From nphilipp at redhat.com Tue Apr 4 13:26:23 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 04 Apr 2006 15:26:23 +0200 Subject: Making /etc/localtime a symlink? In-Reply-To: <442E7C39.7000503@stefan-neufeind.de> References: <442E7C39.7000503@stefan-neufeind.de> Message-ID: <1144157184.2937.19.camel@gibraltar.stuttgart.redhat.com> On Sat, 2006-04-01 at 15:12 +0200, Stefan Neufeind wrote: > I was wondering if, instead of currently making /etc/localtime a copy of > the timezone to use, it would be a good idea to actually make it a > symlink. In the (unlikely) event that information for a timezone would > chance, updates would take effect automatically. > > initial /etc/localtime: part of glibc > e.g. /usr/share/zoneinfo/Europe/Berlin: part of tzdata > > So imho this would involve bundling /etc/localtime as a symlink in > glibc, a dep to tzdata (there is a dep from glibc-common to tzdata) and > adjusting installer etc. to not make copies but create symlinks. > > What do others think? I think it would be better if tzdata would copy the updated localtime file from /usr/share/zoneinfo/... (via %post) when upgrading depending on ZONE in /etc/sysconfig/clock. To allow custom timezones (real customized tz files or timezones the config tools don't know about) I propose to use ZONE=custom upon which neither tzdata nor system-config-date would touch /etc/localtime. Petr, what do you think? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jorton at redhat.com Tue Apr 4 13:32:27 2006 From: jorton at redhat.com (Joe Orton) Date: Tue, 4 Apr 2006 14:32:27 +0100 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> Message-ID: <20060404133227.GA24256@redhat.com> On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote: > I wish that people working on the server bits (e.g. Apache, Postfix) > would take a similar stance and only make their software read > settings from LDAP (or whatever) for the site-wide case. This always seems like a nice simple idea in theory. The reality is that you'd have to put so much complexity in to deal with stuff like working out what to do during a restart if the LDAP server suddenly stops responding (at the point where you have already thrown away the old config). You also have to come up with (and hard-code!) some LDAP schema; and have it extensible to third-party modules (i.e. generic enough that it's just untyped key-value pairs again). And how do you configure the LDAP connection: TLS, auth, etc? Just relying on the system-wide defaults doesn't cut it for 99% of apps so why would it here? And why only support an LDAP backend? Why not also an SQL database, or a WebDAV repository? So the reality is that rather than add all that complexity to 50 different daemons, it's better to go and write one single tool which can create flat file configurations from LDAP databases, or SQL databases, or whatever, and can know how to restart the daemons as necessary, and can apply a consistent LDAP schema across the board, etc. joe From jakub at redhat.com Tue Apr 4 13:33:45 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 4 Apr 2006 09:33:45 -0400 Subject: Making /etc/localtime a symlink? In-Reply-To: <1144157184.2937.19.camel@gibraltar.stuttgart.redhat.com> References: <442E7C39.7000503@stefan-neufeind.de> <1144157184.2937.19.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20060404133345.GE16307@devserv.devel.redhat.com> On Tue, Apr 04, 2006 at 03:26:23PM +0200, Nils Philippsen wrote: > > So imho this would involve bundling /etc/localtime as a symlink in > > glibc, a dep to tzdata (there is a dep from glibc-common to tzdata) and > > adjusting installer etc. to not make copies but create symlinks. > > > > What do others think? > > I think it would be better if tzdata would copy the updated localtime > file from /usr/share/zoneinfo/... (via %post) when upgrading depending > on ZONE in /etc/sysconfig/clock. To allow custom timezones (real > customized tz files or timezones the config tools don't know about) I > propose to use ZONE=custom upon which neither tzdata nor > system-config-date would touch /etc/localtime. Petr, what do you think? tzdata can't do that, since: a) it is a *.noarch.rpm package b) it can't rely on bash and coreutils being installed for its %post, that would be a fatal dependency loop But, glibc-common since ~ September 2005 does that in its %triggerin common -p /usr/sbin/tzdata-update -- tzdata Jakub From kms at passback.co.uk Tue Apr 4 13:34:14 2006 From: kms at passback.co.uk (Keith Sharp) Date: Tue, 04 Apr 2006 14:34:14 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <1144157654.19296.5.camel@animal.passback.co.uk> On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? I don't think you can move Evolution to FE at the moment because, as others have pointed out, there is (are) no readily available replacements that have similar functionality (email/calendar/tasks/memos/contacts). This throws up a more interesting question: if Red Hat are not going to assign an engineer to maintain Evolution, then how do non-Red Hat people get involved in maintaining packages in FC? Keith. PS. Evolution on FC5 works pretty well for me with an Exchange server at work. The only problem I repeatedly see is passing blank emails through filters causes a crash. From nicu_fedora at nicubunu.ro Tue Apr 4 13:35:19 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 04 Apr 2006 16:35:19 +0300 Subject: gnome/gtk v1 in rawhide In-Reply-To: <20060404142155.546a5b6a@soran.addix.net> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> <443262E9.4040305@nicubunu.ro> <20060404142155.546a5b6a@soran.addix.net> Message-ID: <44327617.6020907@nicubunu.ro> Ralf Ertzinger wrote: > Hi. > > On Tue, 04 Apr 2006 15:13:29 +0300, Nicu Buculei wrote: > >> I think this is because they usually are not following the Gnome HIG, >> not because of the widget set used (and this is for good reason - >> those programs are ancient, written before the HIG existed). > > I think this is due to the smaller fonts they use. The same reason as to > why Windows desktops look different from the usual GNOME/KDE screenshots - > The windows standard fonts are smaller (I am not sure if they are antialiased > or not) GTK 2 applications use Fontconfig, you can adjust the font size with gnome-font-properties and make it as small as you want. The size of GTK 2 windows is mainly due to spacing between elements. -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From overholt at redhat.com Tue Apr 4 13:40:40 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 4 Apr 2006 09:40:40 -0400 Subject: Where's eclipse-cdt? In-Reply-To: <20060403210137.GL18954@redhat.com> References: <1143980055.442fc017d841b@www.jouy.inra.fr> <1143984189.17730.1.camel@localhost.localdomain> <1143987237.442fdc2517606@www.jouy.inra.fr> <1143994910.18098.5.camel@ender> <1144020676.31660.20.camel@localhost.localdomain> <20060403210137.GL18954@redhat.com> Message-ID: <20060404134040.GC3715@redhat.com> * Andrew Overholt [2006-04-03 17:01]: > We do for this particular one (well, the SDK which was the blocker on > this). I'll build the CDT on ia64 now. This build finished and is is today's rawhide. Andrew From rdieter at math.unl.edu Tue Apr 4 13:53:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Apr 2006 08:53:02 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144157654.19296.5.camel@animal.passback.co.uk> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144157654.19296.5.camel@animal.passback.co.uk> Message-ID: <44327A3E.4040201@math.unl.edu> Keith Sharp wrote: > This throws up a more interesting question: if Red Hat are not going to > assign an engineer to maintain Evolution, then how do non-Red Hat people > get involved in maintaining packages in FC? Other than talking about things here and filing bug/enhancements to bugzilla.redhat.com? AFAIK, that's about it, at the moment. -- Rex From nicolas.mailhot at laposte.net Tue Apr 4 13:56:38 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 4 Apr 2006 15:56:38 +0200 (CEST) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404133227.GA24256@redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> Message-ID: <41831.192.54.193.25.1144158998.squirrel@rousalka.dyndns.org> Le Mar 4 avril 2006 15:32, Joe Orton a ?crit : > On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote: >> I wish that people working on the server bits (e.g. Apache, Postfix) >> would take a similar stance and only make their software read >> settings from LDAP (or whatever) for the site-wide case. > > This always seems like a nice simple idea in theory. The reality is > that you'd have to put so much complexity in to deal with... Also historically FOSS LDAP = openldap and openldap admin is interesting (to say the less). I don't know how good the netscape stuff is but if manageability is closer to what a normaly constituted human can bear we may see more LDAP use in the next years (which would rock sooooo much for every network constituted from more than 1 node) -- Nicolas Mailhot From tmraz at redhat.com Tue Apr 4 13:57:39 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 04 Apr 2006 15:57:39 +0200 Subject: Move Evolution to Extras? In-Reply-To: <44327A3E.4040201@math.unl.edu> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144157654.19296.5.camel@animal.passback.co.uk> <44327A3E.4040201@math.unl.edu> Message-ID: <1144159059.3455.6.camel@perun.kabelta.loc> On Tue, 2006-04-04 at 08:53 -0500, Rex Dieter wrote: > Keith Sharp wrote: > > > This throws up a more interesting question: if Red Hat are not going to > > assign an engineer to maintain Evolution, then how do non-Red Hat people > > get involved in maintaining packages in FC? > > Other than talking about things here and filing bug/enhancements to > bugzilla.redhat.com? AFAIK, that's about it, at the moment. Well patches are surely welcome and I don't think they will be rejected or forgotten if they fix real crashers or similar critical bugs. -- Tomas Mraz From dwmw2 at infradead.org Tue Apr 4 13:59:43 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 14:59:43 +0100 Subject: Move Evolution to Extras? In-Reply-To: <20060404131520.19567.qmail@hm196.locaweb.com.br> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> Message-ID: <1144159183.11377.148.camel@pmac.infradead.org> On Tue, 2006-04-04 at 10:15 -0300, Pedro Fernandes Macedo wrote: > Add then bug #336074 (RH #167805) to the previous one and you get a > pretty bad situation where you check all your old folders even when > you dont want them and you do it using the slowest method possible > (the above bug). > > Those two can be a bit problematic if you have an IMAP server that is > outside of your network and your link is a bit overloaded or you have > a lot of e-mail stored on the server. To put real numbers to 'a bit problematic'... Even after I fixed #336074 (RH #167805 -- filed September 2005, still in NEW state), it took two hours to start up for the first time when it was working over my DSL line, and it even took 23 minutes to start up when it was here in my house and connected via GigE to the IMAP server. It fetches every header for every mail in every active folder -- and without my patch for #336074 that would have been every folder in the system, not just the active folders. Whenever it reconnects, it updates its cache by downloading all new headers from the server. The cache in my ~/.evolution directory is about half a gigabyte, most of which is unnecessary. Each time it checks for new mail, it fetches the flags for every mail in every (active) folder -- instead of just issuing a single STATUS command for each (active) folder. For an idea of its runtime performance, see the graph from by my ISP: http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png You can see when it was started up (remotely) at about 7:30 on Saturday night, and stopped just after 10:15 on Sunday morning. The periodic mail check is set to something like 12 minute intervals -- 5 checks an hour. You can see my _original_ remote startup at about 7pm on the first day of http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-elided.png along with the result on the latency for the next few days till it was killed (with a brief respite on the second day because I'd killed it to play with a potential fix). Again, that's with #336074 fixed so it's doing about 12 times less work than the 'stock' evolution packages would be doing. The ISP didn't have the shiny new graphs in place back then, so it didn't show upload and download bandwidth -- but it's still fairly clear. Then there's the one which makes it unusable for people who use wu-imapd and check 'show only subscribed folders' -- that's BZ #181805. These are probably the minimal fixes we need to turn it from an unusable pile of crap into just a suboptimal pile of crap: http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png Gr. No, that's https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145314 in action. Let's try that again without trying to just select-and-middle-click like we can in any non-broken X application... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183219 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161397 -- dwmw2 From mailinglists at erwinrol.com Tue Apr 4 14:02:50 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 04 Apr 2006 16:02:50 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144157654.19296.5.camel@animal.passback.co.uk> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144157654.19296.5.camel@animal.passback.co.uk> Message-ID: <1144159371.6347.123.camel@xpc.home.erwinrol.com> On Tue, 2006-04-04 at 14:34 +0100, Keith Sharp wrote: > On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > I don't think you can move Evolution to FE at the moment because, as > others have pointed out, there is (are) no readily available > replacements that have similar functionality > (email/calendar/tasks/memos/contacts). > > This throws up a more interesting question: if Red Hat are not going to > assign an engineer to maintain Evolution, then how do non-Red Hat people > get involved in maintaining packages in FC? A more interesting question is; what are commercial users of RHEL and Suse supposed to use as email client? AFAIK both have evolution as default email client (hmmm suse maybe kmail when since they seem kde focused). So if it is really as broken as it is (extreme memory usage, random hangs, slow, poor imap support, etc.) shouldn't Redhat and Novell be fixing those things as quick as they can ? I mean the excuse to not use Linux was always "no office", i hope not that it will turn into a "no email client". - Erwin From dennis at ausil.us Tue Apr 4 14:09:15 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 4 Apr 2006 08:09:15 -0600 Subject: Move Evolution to Extras? In-Reply-To: <20060404131520.19567.qmail@hm196.locaweb.com.br> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> Message-ID: <200604040909.18487.dennis@ausil.us> On Tuesday 04 April 2006 08:15, Pedro Fernandes Macedo wrote: > However, moving evolution to extras may not be a good idea IMHO, since > evolution is the only tool (that I know of) that supports Exchange servers. > That is certainly an important feature for many people in corporate > environments (or people who use FC at home and need evolution to use the > work e-mail). I'm not a big fan of evolution (specially because of the way > it eats away the memory), but in my case, I have to use it because of that > evil exchange server... kmail supports exchange. Ive never tested it but there is uspport there for it. if you use kontact you get the exact same functionality of evolution. -- Regards Dennis Gilmore, RHCE Proud Australian From rdieter at math.unl.edu Tue Apr 4 14:19:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 04 Apr 2006 09:19:01 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144159059.3455.6.camel@perun.kabelta.loc> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144157654.19296.5.camel@animal.passback.co.uk> <44327A3E.4040201@math.unl.edu> <1144159059.3455.6.camel@perun.kabelta.loc> Message-ID: <44328055.6020309@math.unl.edu> Tomas Mraz wrote: > On Tue, 2006-04-04 at 08:53 -0500, Rex Dieter wrote: >>Keith Sharp wrote: >>>This throws up a more interesting question: if Red Hat are not going to >>>assign an engineer to maintain Evolution, then how do non-Red Hat people >>>get involved in maintaining packages in FC? >>Other than talking about things here and filing bug/enhancements to >>bugzilla.redhat.com? AFAIK, that's about it, at the moment. > Well patches are surely welcome and I don't think they will be rejected > or forgotten if they fix real crashers or similar critical bugs. Of course, that's where bugzilla.redhat.com comes in... (-: -- Rex From tmraz at redhat.com Tue Apr 4 14:36:03 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 04 Apr 2006 16:36:03 +0200 Subject: Move Evolution to Extras? In-Reply-To: <44328055.6020309@math.unl.edu> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144157654.19296.5.camel@animal.passback.co.uk> <44327A3E.4040201@math.unl.edu> <1144159059.3455.6.camel@perun.kabelta.loc> <44328055.6020309@math.unl.edu> Message-ID: <1144161364.3455.9.camel@perun.kabelta.loc> On Tue, 2006-04-04 at 09:19 -0500, Rex Dieter wrote: > Tomas Mraz wrote: > > On Tue, 2006-04-04 at 08:53 -0500, Rex Dieter wrote: > >>Keith Sharp wrote: > > >>>This throws up a more interesting question: if Red Hat are not going to > >>>assign an engineer to maintain Evolution, then how do non-Red Hat people > >>>get involved in maintaining packages in FC? > >>Other than talking about things here and filing bug/enhancements to > >>bugzilla.redhat.com? AFAIK, that's about it, at the moment. > > > Well patches are surely welcome and I don't think they will be rejected > > or forgotten if they fix real crashers or similar critical bugs. > > Of course, that's where bugzilla.redhat.com comes in... (-: Yes, I've just wanted to add to your previous mail that simple bug report helps but even better if it's accompanied with a proper patch. :) -- Tomas Mraz From j.w.r.degoede at hhs.nl Tue Apr 4 14:56:55 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 04 Apr 2006 16:56:55 +0200 Subject: Broken dep chains (Was Evolution) In-Reply-To: <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> Message-ID: <44328937.1030207@hhs.nl> Hi all, Jeff Spaleta wrote: > > -jef"though my candidate for wackiest depchain in Core right now is > rhythmbox's dependancy on totem through the libtotem-plparser.so.1 > library"spaleta > Yes it seems there are many interesting dep chains like this some solvable some not the above one would be solvabel by putting the .so in a seperate -libs package. Maybe we should have a wiki page where wacked dep chains can be posted when encountered and then if some one feels like doing something about this he has a place to look them up, or should we just bugzilla them all? Jeff did you bugzilla your example? If not shouldn't you? Regards, Hans From notting at redhat.com Tue Apr 4 15:17:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Apr 2006 11:17:22 -0400 Subject: gnome/gtk v1 in rawhide In-Reply-To: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> Message-ID: <20060404151722.GA10633@devserv.devel.redhat.com> Peter Robinson (pbrobinson at gmail.com) said: > I seem to remember I've asked this before... and the answer was > because gnucash needs it. So now that the gnucash version in rawhide > is 1.9.x and hence finally (yay) heading for gtk/gnome2 support can > all the gtk1/gnome1 stuff finally be shunted off to extras for some > core-size-reduction-love? Yeah, yeah, working on it. Bill From pbrobinson at gmail.com Tue Apr 4 15:18:53 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 4 Apr 2006 16:18:53 +0100 Subject: gnome/gtk v1 in rawhide In-Reply-To: <20060404151722.GA10633@devserv.devel.redhat.com> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404151722.GA10633@devserv.devel.redhat.com> Message-ID: <5256d0b0604040818hd4b4567xebbb54a956f98fd6@mail.gmail.com> On 4/4/06, Bill Nottingham wrote: > Peter Robinson (pbrobinson at gmail.com) said: > > I seem to remember I've asked this before... and the answer was > > because gnucash needs it. So now that the gnucash version in rawhide > > is 1.9.x and hence finally (yay) heading for gtk/gnome2 support can > > all the gtk1/gnome1 stuff finally be shunted off to extras for some > > core-size-reduction-love? > > Yeah, yeah, working on it. Cheers :-) From david at fubar.dk Tue Apr 4 15:20:52 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 11:20:52 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404133227.GA24256@redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> Message-ID: <1144164052.31422.21.camel@daxter.boston.redhat.com> Hi Joe, On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote: > On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote: > > I wish that people working on the server bits (e.g. Apache, Postfix) > > would take a similar stance and only make their software read > > settings from LDAP (or whatever) for the site-wide case. > > This always seems like a nice simple idea in theory. The reality is > that you'd have to put so much complexity in to deal with stuff like > working out what to do during a restart if the LDAP server suddenly > stops responding (at the point where you have already thrown away the > old config). You also have to come up with (and hard-code!) some LDAP > schema; and have it extensible to third-party modules (i.e. generic > enough that it's just untyped key-value pairs again). You could be more ambitious and just have a local LDAP proxy that caches values. Yes, this introduces additional complexity. > And how do you > configure the LDAP connection: TLS, auth, etc? Use mDNS and Avahi. Or UPnP. Or whaterver. But don't aim to support everything under the sun... it's just not worth it.. Pick one and go for that. > Just relying on the > system-wide defaults doesn't cut it for 99% of apps so why would it > here? And why only support an LDAP backend? Why not also an SQL > database, or a WebDAV repository? Because it's crazy to support everything; if you have that goal you end up with a lot of mediocre software. We have the Fedora Directory Server now, just use that. And I still want to echo: it's not enough to do this with patches to our own packages. You want to engage upstream of each project and make them buy in to the idea. You potentially want to change how upstream software works in order to support the concept of clusters. You need to make a case for each and every piece of upstream software why this is a good idea. > So the reality is that rather than add all that complexity to 50 > different daemons, 50!? Again, the golden rule here is simplicity. Don't task yourself with supporting everything under the sun; pick a few projects that are viable and go with that; for example - Apache - Postfix - Bind - Some SQL server and do a good job on them. Do you disagree? > it's better to go and write one single tool which can > create flat file configurations from LDAP databases, No, you really really want to change the way upstream software works. You need to look at the user stories to begin with; if I'm an administrator with at a big site what do I want to do? - Provisioning of machines; Want to be able to plug in a physical box and automatically make it join my cluster - 99% of users only need Apache, Postfix, Bind, some SQL server or whatever - (add more user stories here) Start with the user stories, create the architecture, make a plan, implement it. It's _a lot_ of work. Or maybe you think this either is the wrong approach or Utopia? FWIW, I think what we've been doing / are doing on the desktop with D-BUS/HAL/NetworkManager/g-v-m/g-p-m etc is very similar to this; this too was / is a lot of work. But if you see how people receive then most people like it. Sure, we have some work left (running NM, g-p-m, g-v-m when no one is logged in). Sure, some oldskool hackers like Pete Zaitchev [1] complain about it in a sorta condescending way, but if you read the reviews of FC3, FC4, FC5 you will see that we're going in the right direction. Yes, so maybe right now the desktop bits are not always suitable for l33t kernel hackers like Pete with very, suffice to say, unusual requirements but down the road we will fill those gaps too. It's just about prioritizing. I expect the same to be true if someone tries to revamp all the server bits. There is no such thing as a free lunch. But you got to aim high and be ambitious. David [1] : http://zaitcev.livejournal.com/55435.html From Lam at Lam.pl Tue Apr 4 15:33:35 2006 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 04 Apr 2006 17:33:35 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144155199.2808.94.camel@dimi> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144155199.2808.94.camel@dimi> Message-ID: <1144164816.2777.6.camel@pensja.lam.pl> Dnia 04-04-2006, wto o godzinie 08:53 -0400, Dimi Paun napisa?(a): > > Evolution is fairly much broken in FC5 > I'm curious why you are saying that. Noone mentioned it, so look here: http://bugzilla.gnome.org/reports/weekly-bug-summary.html and tell me "which GNOME application is the most buggy?" Evo has most open bugs, is the fastest new-bug-gainer, and has the most duplicates for things everyone knows about, but noone fixes. After trying to propose a patch in GNOME's bugzilla (not for Evo, and coincidentally, in bug you reported :)), I now can see why :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From avi at unix.sh Tue Apr 4 15:48:07 2006 From: avi at unix.sh (Avi Alkalay) Date: Tue, 4 Apr 2006 12:48:07 -0300 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404133227.GA24256@redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> Message-ID: On 4/4/06, Joe Orton wrote: > > On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote: > > I wish that people working on the server bits (e.g. Apache, Postfix) > > would take a similar stance and only make their software read > > settings from LDAP (or whatever) for the site-wide case. > > This always seems like a nice simple idea in theory. The reality is > that you'd have to put so much complexity in to deal with stuff like > working out what to do during a restart if the LDAP server suddenly > stops responding (at the point where you have already thrown away the > old config). You also have to come up with (and hard-code!) some LDAP > schema; and have it extensible to third-party modules (i.e. generic > enough that it's just untyped key-value pairs again). And how do you > configure the LDAP connection: TLS, auth, etc? Just relying on the > system-wide defaults doesn't cut it for 99% of apps so why would it > here? And why only support an LDAP backend? Why not also an SQL > database, or a WebDAV repository? > I also think LDAP adds a considerable ammount of complexity with its need for a schema, was not designed for this purpose, adds risk of network unavailability, makes no sense in single computer environments, and is wrongly inspired in AD, because AD is not LDAP: it is more than LDAP, and some parts of it can be represented as an LDAP server. On the other hand, if these softwares are elektrified, you can point their configurations to be read from the network, just switching the key database backend. This is transparent to the application. Regards, Avi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorton at redhat.com Tue Apr 4 15:58:45 2006 From: jorton at redhat.com (Joe Orton) Date: Tue, 4 Apr 2006 16:58:45 +0100 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144164052.31422.21.camel@daxter.boston.redhat.com> References: <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> Message-ID: <20060404155845.GD32306@redhat.com> On Tue, Apr 04, 2006 at 11:20:52AM -0400, David Zeuthen wrote: > On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote: > > it's better to go and write one single tool which can > > create flat file configurations from LDAP databases, > > No, you really really want to change the way upstream software works. Why? You're not making a case for that at all. Why can't you do this as an external tool? That is what upstream say, and I certainly agree. The end goal ("configure everything via LDAP") is no doubt a worthy goal, I don't disagree with that at all. But if it can be achieved by writing one simple tool rather than adding complexity to every daemon (for whatever subset of "every daemon" you find interesting), then why not do that? I don't think it's particularly useful to draw comparisons with the desktop, FWIW. Things like an HTTP server and an SMTP server are very different to X or any UI tool: they do not tend towards a Utopia of having "zero configuration" based on proper integration with hardware. Regards, joe From david at fubar.dk Tue Apr 4 15:58:01 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 11:58:01 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> Message-ID: <1144166281.31422.33.camel@daxter.boston.redhat.com> On Tue, 2006-04-04 at 12:48 -0300, Avi Alkalay wrote: > On the other hand, if these softwares are elektrified, you can point > their configurations to be read from the network, just switching the > key database backend. This is transparent to the application. But Elektra is just not good enough for this. You really really want to change the upstream software to *know* about the fact that it's reading configuration from a central repository. Said central repository will contain information that the a node can process in order to configure itself as part of the cluster. Hence, part of the configuration needs to contain the site-wide bits. This is important. Do you disagree? So.. you can never do this with a hack like Elektra. Networking is *hard*, saying "This is transparent to the application" is just a cop out since it doesn't handle many important cases such as "what's the default configuration for new nodes". In fact, I'd argue adopting Elektra is counter productive to getting upstream software to start thinking like this and it's why it's so dangerous to just start adopting Elektra. You can call this an Utopian dream all day long, but I guess where we differ is that you say Elektra is one step in the right direction towards the Utopia dream that I think we share. I argue it's actually a step in the wrong direction. Good enough is the enemy of perfect. And in Fedora we should not sell out and settle for "good enough". David From nicolas.mailhot at laposte.net Tue Apr 4 16:11:14 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 4 Apr 2006 18:11:14 +0200 (CEST) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144164052.31422.21.camel@daxter.boston.redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> Message-ID: <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> Le Mar 4 avril 2006 17:20, David Zeuthen a ?crit : > But if you see how people receive then most > people like it. Sure, we have some work left (running NM, g-p-m, g-v-m > when no one is logged in). Sure, some oldskool hackers like Pete > Zaitchev [1] complain about it in a sorta condescending way, but if you > read the reviews of FC3, FC4, FC5 you will see that we're going in the > right direction. > > Yes, so maybe right now the desktop bits are not always suitable for > l33t kernel hackers like Pete with very, suffice to say, unusual > requirements They're not unusal requirements. What you've done is what's called a regression, like most regressions it's caused by adding new features users are already thanking you for, and people whose setups you broke have not all noticed it yet and are just starting to curse. > but down the road we will fill those gaps too. It's just > about prioritizing. I expect the same to be true if someone tries to > revamp all the server bits. Would it have been so hard to include a server component from the start when people gave you early warnings instead of bolting it in as an afterthought ? -- Nicolas Mailhot From fedora at camperquake.de Tue Apr 4 16:14:05 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Apr 2006 18:14:05 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144164052.31422.21.camel@daxter.boston.redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> Message-ID: <20060404181405.2a163d93@soran.addix.net> Hi. On Tue, 04 Apr 2006 11:20:52 -0400, David Zeuthen wrote: > Yes, so maybe right now the desktop bits are not always suitable for > l33t kernel hackers like Pete with very, suffice to say, unusual > requirements I do not consider having a working network connection even if noone is currently logged in an "unusual requirement". From david at fubar.dk Tue Apr 4 16:16:14 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 12:16:14 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404155845.GD32306@redhat.com> References: <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <20060404155845.GD32306@redhat.com> Message-ID: <1144167375.31422.46.camel@daxter.boston.redhat.com> On Tue, 2006-04-04 at 16:58 +0100, Joe Orton wrote: > On Tue, Apr 04, 2006 at 11:20:52AM -0400, David Zeuthen wrote: > > On Tue, 2006-04-04 at 14:32 +0100, Joe Orton wrote: > > > it's better to go and write one single tool which can > > > create flat file configurations from LDAP databases, > > > > No, you really really want to change the way upstream software works. > > Why? You're not making a case for that at all. Why can't you do this > as an external tool? That is what upstream say, and I certainly agree. I suspect that neither you nor "upstream" is looking at user stories. > The end goal ("configure everything via LDAP") is no doubt a worthy > goal, I don't disagree with that at all. But if it can be achieved by > writing one simple tool Because it's not that simple for the user experience that at least I think is right. Here's a user story: "The administrator David got a message from his boss Brian that the employees are complaining that it takes too long to send email. David looks at the load graphs and says they need more hardware to handle the growth of MiniCorp Inc. David purchases a dual Xeon XYZ box and plugs it into the network. It automatically joins the IMAP and SMTP server clusters and starts serving mail to users. David uses the system admin console to finetune the load balancing of the servers on his cluster and checks that average response time for the IMAP service is now 0.2 seconds, down from 0.6 seconds. David sips some coffee and is happy." Does it really have to be more difficult? I think not. > rather than adding complexity to every daemon > (for whatever subset of "every daemon" you find interesting), then why > not do that? Because it's *hard* and if you look at what user stories are desirable it's just not that simple. > I don't think it's particularly useful to draw comparisons with the > desktop, FWIW. Things like an HTTP server and an SMTP server are very > different to X or any UI tool: they do not tend towards a Utopia of > having "zero configuration" based on proper integration with hardware. Sorry but I think this is totally unambitious. Near zero-configuration of server daemons, clustered or not, is indeed possible and there's even a whole vertical market for it. What I'm saying is that instead of doing half-baked solutions like reading one server config at a time via LDAP we should be approaching upstream projects and make their server software cluster aware. What's wrong with that? David From shane at geeklords.org Tue Apr 4 16:23:05 2006 From: shane at geeklords.org (Shane Stixrud) Date: Tue, 4 Apr 2006 09:23:05 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144166281.31422.33.camel@daxter.boston.redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144166281.31422.33.camel@daxter.boston.redhat.com> Message-ID: On Tue, 4 Apr 2006, David Zeuthen wrote: > On Tue, 2006-04-04 at 12:48 -0300, Avi Alkalay wrote: >> On the other hand, if these softwares are elektrified, you can point >> their configurations to be read from the network, just switching the >> key database backend. This is transparent to the application. > > But Elektra is just not good enough for this. You really really want to > change the upstream software to *know* about the fact that it's reading > configuration from a central repository. Said central repository will > contain information that the a node can process in order to configure > itself as part of the cluster. Hence, part of the configuration needs to > contain the site-wide bits. This is important. Do you disagree? Can you give an example of when one would want to make an application aware that it is "reading configuration from a central repository?". In most of the cases I can think the applications care not where it gets the data as long as it gets it. In the cases where it does need to know it is a central store, if you are going to have to make the application aware of that anyways why not just tag those keys that should/need be centralized as such, you could even have a sub-hierarchy under elektra for all of these keys i.e. /system/sw/someapp/netcfg/keys /system/sw/someapp/otherpaths/otherskeys Cheers, Shane From david at fubar.dk Tue Apr 4 16:25:12 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 12:25:12 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> Message-ID: <1144167913.31422.55.camel@daxter.boston.redhat.com> On Tue, 2006-04-04 at 18:11 +0200, Nicolas Mailhot wrote: > They're not unusal requirements. > What you've done is what's called a regression, like most regressions it's > caused by adding new features users are already thanking you for, and > people whose setups you broke have not all noticed it yet and are just > starting to curse. Changing things are painful, I and others realize that, sure. Again, it's about trade offs and prioritization. You can't please 100% of the user base 100% of the time. > Would it have been so hard to include a server component from the start > when people gave you early warnings instead of bolting it in as an > afterthought ? Uhm, no one is forcing you to use NetworkManager just yet so there is not really any regression. Btw, the price we pay to support two networking configuration stacks is higher than you think. David From zaitcev at redhat.com Tue Apr 4 16:26:29 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 4 Apr 2006 09:26:29 -0700 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <20060404092629.75903af7.zaitcev@redhat.com> On Tue, 04 Apr 2006 13:44:37 +0100, David Woodhouse wrote: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? Remember why we went with Evolution in the first place. It was Havoc's idea about the Open Source Architecture, and selecting one application instead of a gazillion of different ones. Implicit in this choice was the promise to fix it. Maybe explicit even, I do not remember. Now the upstream stewardhip, maintainership, or whatever seems to be collapsing and those frustrated with Evo try to jump ship, but to where? It sure as hell ain't Sylpheed. Maybe primates just need a good fork in the liver and Evo gets viable again. I hope at least. Anyway, talk to Havoc first, ask him if he planned for this eventuality. Funnily, in the same time period, we very nearly selected some obscure web browser instead of Firefox. It may be instructive to compare the cases with the Evo. -- Pete From mclasen at redhat.com Tue Apr 4 16:40:22 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 04 Apr 2006 12:40:22 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060404092629.75903af7.zaitcev@redhat.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> Message-ID: <1144168822.10620.0.camel@golem.boston.redhat.com> On Tue, 2006-04-04 at 09:26 -0700, Pete Zaitcev wrote: > Funnily, in the same time period, we very nearly selected some obscure > web browser instead of Firefox. It may be instructive to compare the > cases with the Evo. Are you trying to insinuate that firefox is any less broken than evo ? From dwmw2 at infradead.org Tue Apr 4 17:05:02 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 18:05:02 +0100 Subject: Move Evolution to Extras? In-Reply-To: <20060404092629.75903af7.zaitcev@redhat.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> Message-ID: <1144170302.11377.185.camel@pmac.infradead.org> On Tue, 2006-04-04 at 09:26 -0700, Pete Zaitcev wrote: > Now the upstream stewardhip, maintainership, or whatever seems to be > collapsing and those frustrated with Evo try to jump ship, but to where? > It sure as hell ain't Sylpheed. Maybe Thunderbird... but it doesn't do non-email stuff, and even the email part of it has its own problems -- http://mbligh.org/linuxdocs/Email/Clients/Thunderbird Maybe kontact -- although as discussed elsewhere I had to give up on switching to kmail because of http://bugs.kde.org/show_bug.cgi?id=26986 I suppose we could fix that though. > Maybe primates just need a good fork in the liver and Evo gets > viable again. I hope at least. The worst-offending primates _do_ seem to have got a fork in the liver already -- so maybe Novell's maintainership of Evolution is picking up. Certainly the folks in India seems a lot saner and I wouldn't expect the kind of responses I got to simple bug-fixes like this one any more... http://mail.gnome.org/archives/evolution-patches/2005-March/msg00435.html The responses: http://mail.gnome.org/archives/evolution-patches/2005-March/msg00458.html http://mail.gnome.org/archives/evolution-patches/2005-March/msg00461.html > Anyway, talk to Havoc first, ask him if he planned for this eventuality. > Funnily, in the same time period, we very nearly selected some obscure > web browser instead of Firefox. It may be instructive to compare the > cases with the Evo. We did the right thing when we shipped firefox, and we have mozilla developers in-house. We _may_ have done the right thing when we shipped Evolution, but we dropped the ball because we've never really had an in-house maintainer whose primary function is to keep Evolution on track. It's always just been packaged in someone's spare time, I believe. Allegedly we're supposed to be trying to hire an Evolution maintainer, although that req has been open for a while now: http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=961 That might be the way out of the fix we're in now -- but it can't happen fast enough. We already have people who've updated systems to FC5 and are regretting it because their users are extremely unhappy. What are we going to do about that? There were 'FC5Blocker' bugs filed against Evolution long before FC5 was released... and they're still not fixed. On the whole, I've been very unimpressed with FC5. Perhaps that's just because I haven't really been using it in anger on my real machines, because the Evolution bugs prevented me from doing so -- so I didn't get a chance to find and fix all the other things which break for _me_ before the final release, as I would normally have done before a release. -- dwmw2 From nicolas.mailhot at laposte.net Tue Apr 4 17:20:56 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Apr 2006 19:20:56 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144167913.31422.55.camel@daxter.boston.redhat.com> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> Message-ID: <1144171259.6489.3.camel@rousalka.dyndns.org> Le mardi 04 avril 2006 ? 12:25 -0400, David Zeuthen a ?crit : > On Tue, 2006-04-04 at 18:11 +0200, Nicolas Mailhot wrote: > > Would it have been so hard to include a server component from the start > > when people gave you early warnings instead of bolting it in as an > > afterthought ? > > Uhm, no one is forcing you to use NetworkManager just yet so there is > not really any regression. Which is why people complaining so far are few. > Btw, the price we pay to support two > networking configuration stacks is higher than you think. Probably. But no one advocated two config stacks - just one that took care of the whole problem-space (which includes the no-gui-nor-user-logged-in, many-users-logged-in, gui-user, tui-over-ssh-user) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sundaram at fedoraproject.org Tue Apr 4 17:24:28 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 04 Apr 2006 22:54:28 +0530 Subject: Move Evolution to Extras? In-Reply-To: <1144170302.11377.185.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> <1144170302.11377.185.camel@pmac.infradead.org> Message-ID: <1144171468.24151.55.camel@sundaram.pnq.redhat.com> On Tue, 2006-04-04 at 18:05 +0100, David Woodhouse wrote: > > The worst-offending primates _do_ seem to have got a fork in the liver > already -- so maybe Novell's maintainership of Evolution is picking up. > Certainly the folks in India seems a lot saner and I wouldn't expect the > kind of responses I got to simple bug-fixes like this one any more... Yes. It is beginning to get better. > > Allegedly we're supposed to be trying to hire an Evolution maintainer, > although that req has been open for a while now: > http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=961 There is progress on this now. Rahul From brugolsky at telemetry-investments.com Tue Apr 4 17:31:57 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 4 Apr 2006 13:31:57 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144167913.31422.55.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> Message-ID: <20060404173157.GF14317@ti64.telemetry-investments.com> On Tue, Apr 04, 2006 at 12:25:12PM -0400, David Zeuthen wrote: > Uhm, no one is forcing you to use NetworkManager just yet so there is > not really any regression. Btw, the price we pay to support two > networking configuration stacks is higher than you think. By two networking configuration stacks you mean the traditional method and the NetworkManager way? Wouldn't it have been better to have an actual design ... rather than thinking up a GUI interface to some use case, then starting coding? Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix." It seems that an "unusual requirement" is one that is difficult and inconvenient for that other operating system, i.e., a requirement that foregoes the monkey pressing buttons in front of a bitmapped display. Unix/Linux carries years of baggage, mis-designed features, and half-baked implementations. But today's GNOME hackers seem to have completely missed the value of (1) text, (2) tools, and (3) domain-specific little languages and protocols. One area where Unix went somewhat astray is that script and config syntax differences created unnecessary impedance [the original point of this thread] -- the Lisp machine folks had that much right. Two decades later, it's easy to see that domain-specific languages are best built without inventing lots of arcane syntax; these days S-exprs have been replaced by XML, XSLT (*vomit*), and worse. Unfortunately, simply stuffing name/value config pairs in a file is not the same as domain-specific design. I'm not holding my breath waiting for support for 20-year-old "unusual requirements" to be bolted on later. Bill Rugolsky From david at fubar.dk Tue Apr 4 18:00:14 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 14:00:14 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404173157.GF14317@ti64.telemetry-investments.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> Message-ID: <1144173615.31422.80.camel@daxter.boston.redhat.com> On Tue, 2006-04-04 at 13:31 -0400, Bill Rugolsky Jr. wrote: > On Tue, Apr 04, 2006 at 12:25:12PM -0400, David Zeuthen wrote: > > Uhm, no one is forcing you to use NetworkManager just yet so there is > > not really any regression. Btw, the price we pay to support two > > networking configuration stacks is higher than you think. > > By two networking configuration stacks you mean the traditional method > and the NetworkManager way? Correct. > Wouldn't it have been better to have > an actual design ... rather than thinking up a GUI interface to some > use case, then starting coding? There is always a fine line and one benefit of getting NM in the distribution early is that it helped moved the kernel networking stack forward insofar that many bugs got fixed. You know (or maybe you don't), the bad rep NetworkManager had for a while is partly due to really really broken drivers. That and the fact that NetworkManager is pretty useful to a lot of people who happens to have hardware supported by NM. > Pete's condescension is right on target: core Linux components are > being replaced by people who, by their own admission, "hate Unix." Hating UNIX and actually working on providing software that solves real problems without the user having to be computer literate are two completely different things. Yes, I admit to both, but obviously one doesn't imply the other. The condescension from Pete is not OK in my book because NetworkManager is still not default. For reasons partly related to kernel drivers, partly related to the fact we need a bit more infrastructure to do this right. > It seems that an "unusual requirement" is one that is difficult and > inconvenient for that other operating system, i.e., a requirement > that foregoes the monkey pressing buttons in front of a > bitmapped display. That's not really a nice thing to say. And NetworkManager is still not default. > Unix/Linux carries years of baggage, mis-designed features, and half-baked > implementations. But today's GNOME hackers seem to have completely > missed the value of (1) text, (2) tools, and (3) domain-specific little > languages and protocols. One area where Unix went somewhat astray is > that script and config syntax differences created unnecessary impedance [the > original point of this thread] -- the Lisp machine folks had that much > right. Two decades later, it's easy to see that domain-specific languages > are best built without inventing lots of arcane syntax; these days S-exprs > have been replaced by XML, XSLT (*vomit*), and worse. Unfortunately, > simply stuffing name/value config pairs in a file is not the same as > domain-specific design. > > I'm not holding my breath waiting for support for 20-year-old > "unusual requirements" to be bolted on later. NetworkManager is still not the default. I don't think it will be default before it does a lot more what the current default networking stack does including working when no user is logged in. My view is that Pete is blowing this out of proportion and I think you're just being his puppet in this particular case. David From nicolas.mailhot at laposte.net Tue Apr 4 18:19:10 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Apr 2006 20:19:10 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144173615.31422.80.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> Message-ID: <1144174760.6489.14.camel@rousalka.dyndns.org> Le mardi 04 avril 2006 ? 14:00 -0400, David Zeuthen a ?crit : > NetworkManager is still not the default. I don't think it will be > default before it does a lot more what the current default networking > stack does including working when no user is logged in. > > My view is that Pete is blowing this out of proportion and I think > you're just being his puppet in this particular case. Well, you know after all the times Gnome people removed functionality because they knew better and future would prove them right, then refused to put them back in even after people did not get used to the new world order ("residual" complaints as Putin says in Chechnia), your declarations of undying love for not-in-gui-session-management can be a tad frightening. But you can damn Pete for writing what a lot of people were thinking if you like. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dominik at greysector.net Tue Apr 4 18:21:22 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 4 Apr 2006 20:21:22 +0200 Subject: Move Evolution to Extras? In-Reply-To: <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> Message-ID: <20060404182122.GA8284@rathann.pekin.waw.pl> On Tuesday, 04 April 2006 at 15:03, Jeff Spaleta wrote: > On 4/4/06, David Woodhouse wrote: > > Evolution is fairly much broken in FC5, and there's little movement even > > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > > totally unusable with IMAP" bugs. > > > > What are we going to do about it? One option might be to move it to > > Extras in the hope that someone will actually start to look after it > > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? > > Difficult to do considering the depchains. If you want beagle in Core > then evolution has to be in Core with the current packaging. beagle > needs evolution-sharp which needs evolution. > > -jef"though my candidate for wackiest depchain in Core right now is > rhythmbox's dependancy on totem through the libtotem-plparser.so.1 > library"spaleta Here's another wacky one: mail-notification depends on evolution, gnome-pilot, NetworkManager and named. Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan From kaboom at oobleck.net Tue Apr 4 18:22:57 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 4 Apr 2006 14:22:57 -0400 (EDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144173615.31422.80.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> Message-ID: On Tue, 4 Apr 2006, David Zeuthen wrote: > Hating UNIX and actually working on providing software that solves real > problems without the user having to be computer literate are two > completely different things. Yes, I admit to both, but obviously one > doesn't imply the other. > > The condescension from Pete is not OK in my book because NetworkManager > is still not default. For reasons partly related to kernel drivers, > partly related to the fact we need a bit more infrastructure to do this > right. I think the worry is this: the lack of concern shown for backwards compatibility, needs of command-line users, etc. to date suggests that when it does become the default it will be the same sort of half-baked cock-up as was introduced in FC5 by gnome-mount.... later, chris From brugolsky at telemetry-investments.com Tue Apr 4 18:30:35 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 4 Apr 2006 14:30:35 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144173615.31422.80.camel@daxter.boston.redhat.com> References: <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> Message-ID: <20060404183035.GG14317@ti64.telemetry-investments.com> On Tue, Apr 04, 2006 at 02:00:14PM -0400, David Zeuthen wrote: > My view is that Pete is blowing this out of proportion and I think > you're just being his puppet in this particular case. Heh, I'm quite capable of thinking for myself, thank you. My thoughts on this and related topics are in the relevant archives ... As for blowing things out of proportion, take it for what it is: a lament that a mis-design will come into sufficiently wide-spread use that it will draw interest and resources away from a much better solution. And once it is "good enough" for your "typical" use cases, interest in covering the rest of the cases will wane. But there's no requirement that any of us accept gifts that we don't want, and NetworkManager, like any other free software, is a gift. So honestly, I have no sense of entitlement, just bemusement. Bill Rugolsky From ianburrell at gmail.com Tue Apr 4 18:32:06 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 4 Apr 2006 11:32:06 -0700 Subject: Move Evolution to Extras? In-Reply-To: <20060404182122.GA8284@rathann.pekin.waw.pl> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> Message-ID: On 4/4/06, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 04 April 2006 at 15:03, Jeff Spaleta wrote: > > > > Difficult to do considering the depchains. If you want beagle in Core > > then evolution has to be in Core with the current packaging. beagle > > needs evolution-sharp which needs evolution. > > > > -jef"though my candidate for wackiest depchain in Core right now is > > rhythmbox's dependancy on totem through the libtotem-plparser.so.1 > > library"spaleta > > Here's another wacky one: > > mail-notification depends on evolution, gnome-pilot, NetworkManager and named. > The evolution dependency on gnome-pilot (and pilot-link) isn't necessary. The evolution pilot conduits are easily separated into a subpackage. I put in a bug (178155) a while ago with a patch split the conduits into an evolution-pilot subpackage. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178155, - Ian From zaitcev at redhat.com Tue Apr 4 18:34:27 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 4 Apr 2006 11:34:27 -0700 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404173157.GF14317@ti64.telemetry-investments.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> Message-ID: <20060404113427.f4c1ab0b.zaitcev@redhat.com> On Tue, 4 Apr 2006 13:31:57 -0400, "Bill Rugolsky Jr." wrote: > Pete's condescension is right on target: core Linux components are > being replaced by people who, by their own admission, "hate Unix." There was no condescension, please take this back. And I never touched the subject of hate of Unix. What is up with putting words in my mouth here? Since we're on the topic, I do not mind if someone hates Unix, as long as he knows Unix, so he is not doomed to reinvent it, poorly. -- Pete From david at fubar.dk Tue Apr 4 18:36:20 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Apr 2006 14:36:20 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144174760.6489.14.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> Message-ID: <1144175781.31422.102.camel@daxter.boston.redhat.com> On Tue, 2006-04-04 at 20:19 +0200, Nicolas Mailhot wrote: > Well, you know after all the times Gnome people removed functionality > because they knew better and future would prove them right, then refused > to put them back in even after people did not get used to the new world > order ("residual" complaints as Putin says in Chechnia), your > declarations of undying love for not-in-gui-session-management can be a > tad frightening. Replacing all the old cruft with new stuff is bound to introduce a few more bugs along the way. I think it's called... progress? > But you can damn Pete for writing what a lot of people were thinking if > you like. That's nice. At least I learned something today: Never ever propose anything that might be a bit visionary on fedora-devel-list; you will just get shot down by the vocal minority and you will get flamed you for the improvements for the silent majority you helped create. David From skvidal at linux.duke.edu Tue Apr 4 18:43:40 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 14:43:40 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144175781.31422.102.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> Message-ID: <1144176220.11415.14.camel@cutter> On Tue, 2006-04-04 at 14:36 -0400, David Zeuthen wrote: > At least I learned something today: Never ever propose anything that > might be a bit visionary on fedora-devel-list; you will just get shot > down by the vocal minority and you will get flamed you for the > improvements for the silent majority you helped create. > Well, yah, As is their right. Half of working on open source software is being able to judge b/t what makes sense to you and what makes sense to any random person. Often times what makes sense to you is correct. Sometimes it is not. I'm not arguing on either side of this whole elektra thing. I'm sure it will shake itself out one way or the t'other. People will flame, it happens. I think we've all probably be irritated with some design decision at some point and a lot of us have had someone irritated with us b/c of a design decision we made. It shouldn't stop you from trying or from posting - it should just prepare you for the obvious. -sv From dimi at lattica.com Tue Apr 4 18:42:26 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 4 Apr 2006 14:42:26 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) References: <20060328180838.GE24725@devserv.devel.redhat.com><1143584970.30123.19.camel@localhost><604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com><604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com><9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk><20060404133227.GA24256@redhat.com><1144164052.31422.21.camel@daxter.boston.redhat.com><10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> Message-ID: <03ac01c65817$86ed0450$b6491b31@td612671> From: "David Zeuthen" > Uhm, no one is forcing you to use NetworkManager just yet so there is > not really any regression. I fear the day when we'll have to use NetworkManager, based on responses that I got to my complain: https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00413.html Again, the classical "you are not our use case". Not "sorry, we screwed up", not "we hope to fix it in the future". I mean, NetworkManager was going an idiotic thing: overwriting my manually created file without doing at least a backup. Not to mention use the stuff I've put in there, or try to restore it when it's done. And the answer from people that should know better is: "we don't care, you are not our user". Surely you don't think this gives folks the warm and fuzzies. -- Dimi Paun Lattica, Inc. From fedora at camperquake.de Tue Apr 4 18:43:54 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Apr 2006 20:43:54 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144175781.31422.102.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> Message-ID: <20060404204354.6d87ca25@nausicaa.camperquake.de> Hi. David Zeuthen wrote: > Replacing all the old cruft with new stuff is bound to introduce a few > more bugs along the way. I think it's called... progress? Replacing old cruft with new stuff is called "replacing old cruft with new stuff", technically. It becomes "progress" when things improve somewhere along the way. That's not to say that NM isn't progress, mark. From brugolsky at telemetry-investments.com Tue Apr 4 18:46:01 2006 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 4 Apr 2006 14:46:01 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404113427.f4c1ab0b.zaitcev@redhat.com> References: <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <20060404113427.f4c1ab0b.zaitcev@redhat.com> Message-ID: <20060404184601.GH14317@ti64.telemetry-investments.com> On Tue, Apr 04, 2006 at 11:34:27AM -0700, Pete Zaitcev wrote: > > Pete's condescension is right on target: core Linux components are > > being replaced by people who, by their own admission, "hate Unix." > > There was no condescension, please take this back. And I never > touched the subject of hate of Unix. What is up with putting words > in my mouth here? Didn't mean to put words in your mouth. David referred to it as condescension, my repetition of that word was merely in reference to his comment. I should have put it in scare quotes. The "hate Unix" reference is from David's own comments regarding your blog. Apologies. > Since we're on the topic, I do not mind if someone hates Unix, as long > as he knows Unix, so he is not doomed to reinvent it, poorly. I wonder what Henry Spencer would say about reinventing Windows 98 poorly as a warmup exercise. -Bill From jkeating at redhat.com Tue Apr 4 18:47:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 04 Apr 2006 14:47:42 -0400 Subject: Move Evolution to Extras? In-Reply-To: References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> Message-ID: <1144176462.18098.37.camel@ender> On Tue, 2006-04-04 at 11:32 -0700, Ian Burrell wrote: > I put in a bug (178155) a while ago with a patch split the conduits > into an evolution-pilot subpackage. While thats nice, it doesn't help in this regard. It is a subpackage of the main evolution source rpm. That means that the source rpm cannot go outside the Fedora build system. Not until we made modifications to how packages are brought in and how we look at the distribution. As it stands, it is not feasible to move Evolution outside of Core. This may change in the (near?) future, but that is left to be seen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Tue Apr 4 18:49:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 05 Apr 2006 00:19:18 +0530 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <03ac01c65817$86ed0450$b6491b31@td612671> References: <20060328180838.GE24725@devserv.devel.redhat.com> <1143584970.30123.19.camel@localhost> <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <03ac01c65817$86ed0450$b6491b31@td612671> Message-ID: <1144176558.24151.63.camel@sundaram.pnq.redhat.com> On Tue, 2006-04-04 at 14:42 -0400, Dimi Paun wrote: > From: "David Zeuthen" > > Uhm, no one is forcing you to use NetworkManager just yet so there is > > not really any regression. > > I fear the day when we'll have to use NetworkManager, based on > responses that I got to my complain: > https://www.redhat.com/archives/fedora-devel-list/2005-July/msg00413.html > > Again, the classical "you are not our use case". Not "sorry, we screwed up", > not "we hope to fix it in the future". I didnt read it that way. Thats why I depend on specific bug reports rather than rants on mailing lists to solve problems. Rahul From dwmw2 at infradead.org Tue Apr 4 18:55:08 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 19:55:08 +0100 Subject: Move Evolution to Extras? In-Reply-To: <20060404182122.GA8284@rathann.pekin.waw.pl> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> Message-ID: <1144176908.11377.193.camel@pmac.infradead.org> On Tue, 2006-04-04 at 20:21 +0200, Dominik 'Rathann' Mierzejewski wrote: > mail-notification depends on evolution, gnome-pilot, NetworkManager > and named. Evolution's dependency on SpamAssassin is bogus too -- doing that kind of filtering in the MUA as an _option_ is all very well, but it's very suboptimal to do it that way and there's no excuse for dragging SA into the workstation install where it doesn't belong. -- dwmw2 From nicolas.mailhot at laposte.net Tue Apr 4 19:09:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Apr 2006 21:09:24 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144175781.31422.102.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> Message-ID: <1144177771.6489.38.camel@rousalka.dyndns.org> Le mardi 04 avril 2006 ? 14:36 -0400, David Zeuthen a ?crit : > Replacing all the old cruft with new stuff is bound to introduce a few > more bugs along the way. I think it's called... progress? > > > But you can damn Pete for writing what a lot of people were thinking if > > you like. > > That's nice. > > At least I learned something today: Never ever propose anything that > might be a bit visionary on fedora-devel-list; you will just get shot > down by the vocal minority and you will get flamed you for the > improvements for the silent majority you helped create. David, Please take it with a grain of salt. People don't have to agree with all your write. I somehow agree on the ldap part coming handy (I wrote it some messages before). I also agreed on some of your other points. On this particular one I disagreed with you. Pete disagreed with you. Bill disagreed with you. Maybe that means this particular part of your vision is wrong ? Or miscommunicated ? Nothing you wrote so far was intended to assuage people's fear. The (shall I write it) contempt you've shown for historic RHL/Fedora users and their needs also did not help. Where do you think Fedora would be if they betrayed you like you seem intent on and let you drool over Bill lobotomised users without any grassroot support ? (why do you think Red Hat revived Fedora after letting it wither a few years) Your communication was very poor and I have some great examples of it at home. One of them put 3 million people on the streets last week. Then because someone was listening very hard to the silent majority and not to what people where actually saying it put 3 million people in the streets again today. The fact is even if the vocal minority is a minority, it's actually telling you things. OTOH you could completely misunderstand the silent majority and be none the wiser. The silent majority is difficult to understand. It doesn't speak loudly at all. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at linux.duke.edu Tue Apr 4 19:19:57 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 15:19:57 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144177771.6489.38.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> Message-ID: <1144178397.11415.17.camel@cutter> On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote: > > Nothing you wrote so far was intended to assuage people's fear. > The (shall I write it) contempt you've shown for historic RHL/Fedora > users and their needs also did not help. Where do you think Fedora would > be if they betrayed you like you seem intent on and let you drool over > Bill lobotomised users without any grassroot support ? (why do you think > Red Hat revived Fedora after letting it wither a few years) umm. what? When did red hat let fedora wither? > Your communication was very poor and I have some great examples of it at > home. One of them put 3 million people on the streets last week. Then > because someone was listening very hard to the silent majority and not > to what people where actually saying it put 3 million people in the > streets again today. umm What? when did something ANYONE say in fedora put 3 million people in the streets? I hope you're engaging in hyperbole. -sv From j.w.r.degoede at hhs.nl Tue Apr 4 19:16:28 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 04 Apr 2006 21:16:28 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144176462.18098.37.camel@ender> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> Message-ID: <4432C60C.2040504@hhs.nl> Jesse Keating wrote: > On Tue, 2006-04-04 at 11:32 -0700, Ian Burrell wrote: >> I put in a bug (178155) a while ago with a patch split the conduits >> into an evolution-pilot subpackage. > > While thats nice, it doesn't help in this regard. It is a subpackage of > the main evolution source rpm. That means that the source rpm cannot go > outside the Fedora build system. Not until we made modifications to how > packages are brought in and how we look at the distribution. > > As it stands, it is not feasible to move Evolution outside of Core. > This may change in the (near?) future, but that is left to be seen. > Agreed but that is still no excuse for the sometimes somewhat bizarre dep chains. If a package functions fine (although feature limited) without something and putting this something in launches a (long) extra depchain and the part which requires this can be seperated into a subpackage it should be a in subpackage. Regards, Hans From nicolas.mailhot at laposte.net Tue Apr 4 19:31:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Apr 2006 21:31:41 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144178397.11415.17.camel@cutter> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> <1144178397.11415.17.camel@cutter> Message-ID: <1144179104.6489.45.camel@rousalka.dyndns.org> Le mardi 04 avril 2006 ? 15:19 -0400, seth vidal a ?crit : > On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote: > > (why do you think > > Red Hat revived Fedora after letting it wither a few years) > > umm. what? When did red hat let fedora wither? deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I think) Then the press releases started rolling again and Fedora was not the ugly duckling anymore. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at linux.duke.edu Tue Apr 4 19:37:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 15:37:30 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144179104.6489.45.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> <1144178397.11415.17.camel@cutter> <1144179104.6489.45.camel@rousalka.dyndns.org> Message-ID: <1144179450.11415.19.camel@cutter> On Tue, 2006-04-04 at 21:31 +0200, Nicolas Mailhot wrote: > Le mardi 04 avril 2006 ? 15:19 -0400, seth vidal a ?crit : > > On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote: > > > (why do you think > > > Red Hat revived Fedora after letting it wither a few years) > > > > umm. what? When did red hat let fedora wither? > > deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I > think) Then the press releases started rolling again and Fedora was not > the ugly duckling anymore. the release announcements went out for every release. -sv From kloczek at zie.pg.gda.pl Tue Apr 4 19:41:03 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Tue, 04 Apr 2006 21:41:03 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144176462.18098.37.camel@ender> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> Message-ID: <1144179663.5040.27.camel@kloczek01.pracownicy.zie> Dnia 04-04-2006, wto o godzinie 14:47 -0400, Jesse Keating napisa?(a): > On Tue, 2006-04-04 at 11:32 -0700, Ian Burrell wrote: > > I put in a bug (178155) a while ago with a patch split the conduits > > into an evolution-pilot subpackage. > > While thats nice, it doesn't help in this regard. It is a subpackage of > the main evolution source rpm. That means that the source rpm cannot go > outside the Fedora build system. Not until we made modifications to how > packages are brought in and how we look at the distribution. Patch for current evolution.spec for doing this in attachment. Attached patch also fixes few other (sometimes very stupid) things in this spec: - remove "Require: libinotify" rule (remember: not versioned libraries dependencies are *allways* autogenerated by rpm on build stage), - replace run sequence autotools by single "autoreconf -f" in %build, - use --disable-schemas-install in configure parameters instead "excercises" in %install, - remove INSTALL from %doc (God .. now we have in system resources few hundrets minus one the same automake INSTALL document), - replace all --with-=no and --enable-=no by better redable --without- and --disable-, - use --dissable-static instead waste time in %build for generate static libraries only for prune them in %install, - use single command (rm) for remove all .la files (all without using additionaly command like xargs and find), - cleanups: s,$RPM_BUILD_ROOT/%{_,$RPM_BUILD_ROOT%{_, kloczek -------------- next part -------------- A non-text attachment was scrubbed... Name: evolution.spec.patch Type: text/x-patch Size: 6220 bytes Desc: not available URL: From jkeating at j2solutions.net Tue Apr 4 19:38:36 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 04 Apr 2006 15:38:36 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144179104.6489.45.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> <1144178397.11415.17.camel@cutter> <1144179104.6489.45.camel@rousalka.dyndns.org> Message-ID: <1144179516.18098.50.camel@ender> On Tue, 2006-04-04 at 21:31 +0200, Nicolas Mailhot wrote: > > deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I > think) Then the press releases started rolling again and Fedora was not > the ugly duckling anymore. > If anything, it was the media who no longer saw it as the ugly duckling. Red Hat is doing not much more, not much less marketing and such around Fedora, those in the media space are finally paying attention. A lot of that has to do with the Fedora community beating media folks over the head with our correct information and such. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Tue Apr 4 19:44:05 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 04 Apr 2006 12:44:05 -0700 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144175781.31422.102.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> Message-ID: <1144179845.28389.54.camel@localhost> On Tue, 2006-04-04 at 14:36 -0400, David Zeuthen wrote: > On Tue, 2006-04-04 at 20:19 +0200, Nicolas Mailhot wrote: > > Well, you know after all the times Gnome people removed functionality > > because they knew better and future would prove them right, then refused > > to put them back in even after people did not get used to the new world > > order ("residual" complaints as Putin says in Chechnia), your > > declarations of undying love for not-in-gui-session-management can be a > > tad frightening. > > Replacing all the old cruft with new stuff is bound to introduce a few > more bugs along the way. I think it's called... progress? > Getting rid of old cruft is fine. It's just that some of the changes made in the past have broken features that are central to expectations of how Unix systems should operate. People are worried that these great new changes are going to leave us with a trail of broken behavior among the features that made us start using Linux and Unix in the first place. Saying the new interface is more intuitive and better does not allay these worries, rather it adds to people's fears that the developers are not concerned about breaking the way Linux and Unix have always worked because the developers "know better". To make those worries go away, the "new stuff" has to learn to do the right thing for those old ways of doing things. > At least I learned something today: Never ever propose anything that > might be a bit visionary on fedora-devel-list; you will just get shot > down by the vocal minority and you will get flamed you for the > improvements for the silent majority you helped create. Visionary is fine. But as a developer of the new technology you have to keep in mind the features of the present system that users actually like and figure out how to keep your changes from compromising them. From my understanding of the technologies, I don't see anything wrong with their design. But the implementations have been geared towards doing things through a sparkly new graphical UI and user-managed services with little (perceived?) work enabling the equivalent commandline functions or how to divide permissions when the administrator wants the resource to be managed system-wide. In other words, great start! but you can't consider it a job well done until you've paid the same attention to usability on the command line as on the desktop and figured out how system-wide settings interact with per-user. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Apr 4 19:41:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Apr 2006 21:41:58 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144179104.6489.45.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> <1144178397.11415.17.camel@cutter> <1144179104.6489.45.camel@rousalka.dyndns.org> Message-ID: <1144179721.6489.49.camel@rousalka.dyndns.org> Le mardi 04 avril 2006 ? 21:31 +0200, Nicolas Mailhot a ?crit : > Le mardi 04 avril 2006 ? 15:19 -0400, seth vidal a ?crit : > > On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote: > > > (why do you think > > > Red Hat revived Fedora after letting it wither a few years) > > > > umm. what? When did red hat let fedora wither? > > deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I > think) Then the press releases started rolling again and Fedora was not > the ugly duckling anymore. Which makes me think (slow thinker that I am) now that this period is over could we add a Fedora History page in the wiki with the "eat your brainz" satire ? Or is it still too early ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From seg at haxxed.com Tue Apr 4 19:48:16 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 04 Apr 2006 14:48:16 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144155199.2808.94.camel@dimi> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144155199.2808.94.camel@dimi> Message-ID: <1144180097.10632.162.camel@localhost> On Tue, 2006-04-04 at 08:53 -0400, Dimi Paun wrote: > On Tue, 2006-04-04 at 13:44 +0100, David Woodhouse wrote: > > Evolution is fairly much broken in FC5 > > I'm curious why you are saying that. It's true, printing doesn't > work for me [1] (which is a rather important function I might add), > but other than that it's been OK here, both POP and IMAP. > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186653 I'm going to jump on the WORKSFORME bandwagon. I've been using Evolution for a while. I use it with my own imap server. (courier) Other than the occasional hang, I've never had a problem, and I've never understood what everyone is complaining about. I also use the contacts and calendar, and I like the way it integrates with the GNOME panel clock. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From kloczek at zie.pg.gda.pl Tue Apr 4 19:51:53 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Tue, 04 Apr 2006 21:51:53 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144179663.5040.27.camel@kloczek01.pracownicy.zie> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <1144179663.5040.27.camel@kloczek01.pracownicy.zie> Message-ID: <1144180313.5040.29.camel@kloczek01.pracownicy.zie> Dnia 04-04-2006, wto o godzinie 21:41 +0200, Tomasz K?oczko napisa?(a): [..] > Patch for current evolution.spec for doing this in attachment. Sorry but previouse patch was with incorect Group in pilot subpackage and small bug in %build. kloczek -------------- next part -------------- A non-text attachment was scrubbed... Name: evolution.spec.patch Type: text/x-patch Size: 6503 bytes Desc: not available URL: From smooge at gmail.com Tue Apr 4 19:44:49 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 4 Apr 2006 13:44:49 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144154677.11377.105.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> On 4/4/06, David Woodhouse wrote: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? I ditched Evolution during the 2.0 series of cruft.. and have been doing nothing but converting people to Thunderbird who are with FC5. As far as I can tell Evolution-2.6 is a pain in the butt with more pain than gain. If beagle is dependant on it, then maybe it would be better if someone figured out a replacement on beagle than keeping evolution. beagle is also on our list of removal due to its "I eat batteries" on laptops (the major users of Fedora it seems here in our environment). > > -- > dwmw2 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From lamont at gurulabs.com Tue Apr 4 20:02:29 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 4 Apr 2006 14:02:29 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144170302.11377.185.camel@pmac.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> <1144170302.11377.185.camel@pmac.infradead.org> Message-ID: <200604041402.33869.lamont@gurulabs.com> On Tuesday 04 April 2006 11:05am, David Woodhouse wrote: > On Tue, 2006-04-04 at 09:26 -0700, Pete Zaitcev wrote: > > Now the upstream stewardhip, maintainership, or whatever seems to be > > collapsing and those frustrated with Evo try to jump ship, but to where? > > It sure as hell ain't Sylpheed. > > Maybe Thunderbird... but it doesn't do non-email stuff, and even the > email part of it has its own problems -- > http://mbligh.org/linuxdocs/Email/Clients/Thunderbird > > Maybe kontact -- although as discussed elsewhere I had to give up on > switching to kmail because of http://bugs.kde.org/show_bug.cgi?id=26986 > I suppose we could fix that though. That's a pretty trivial "bug". It's just an RFE, but I agree; it would be fairly simple to implement. However, I think it's fairly harsh of you to give up on KMail for this. I've used KMail (and now Kontact which embeds KMail) for years and this has never been an issue for me. If I delete a message, it goes in the trashcan. If I purge the trashcan, it's gone; if not, I can get it back. Then again, I almost never delete email (which reminds me that it's time to archive 2004's email :) ). I used KMail for years, then I switched to Evolution with 1.4 and went to Kontact about 1.5 years ago (after Evolution 2.0). During the past year and a half, many of my co-workers and friends have used either Evolution or Kontact. I would have to say, based on the comments and experiences of those people, that those using Kontact have had far fewer problems than those using Evolution. That said, I think Evolution is an excellent program, for the most part. It's just lost the love of developers and maintainers. I don't know what's happening over at Novel with Miguel & friends working on Evolution, but regardless of whatever is going on there, Red Hat, IMHO, needs to have an Evo developer/maintainer on staff. It is far too important a component to have let it get this way. Regardless, I'll be sticking with Kontact for a while. But, I'll try out Evo again from time to time. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lamont at gurulabs.com Tue Apr 4 20:07:45 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 4 Apr 2006 14:07:45 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144180313.5040.29.camel@kloczek01.pracownicy.zie> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144179663.5040.27.camel@kloczek01.pracownicy.zie> <1144180313.5040.29.camel@kloczek01.pracownicy.zie> Message-ID: <200604041407.45850.lamont@gurulabs.com> On Tuesday 04 April 2006 01:51pm, Tomasz K?oczko wrote: > Dnia 04-04-2006, wto o godzinie 21:41 +0200, Tomasz K?oczko napisa?(a): > [..] > > > Patch for current evolution.spec for doing this in attachment. > > Sorry but previouse patch was with incorect Group in pilot subpackage > and small bug in %build. You should attach this patch to a bugzilla entry. It'll just get lost in here. I don't know if there is already a "bug" to which it would make to attach such a patch. If not, please, create one. Either way, let the list know the bug number you've attached it to. At that point, it's the responsibility of the package maintainer. But as I understand it, there isn't one. Question for those in charge around here, who should pick up this ball then? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Apr 4 20:13:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 05 Apr 2006 01:43:07 +0530 Subject: Move Evolution to Extras? In-Reply-To: <200604041407.45850.lamont@gurulabs.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144179663.5040.27.camel@kloczek01.pracownicy.zie> <1144180313.5040.29.camel@kloczek01.pracownicy.zie> <200604041407.45850.lamont@gurulabs.com> Message-ID: <1144181588.24151.68.camel@sundaram.pnq.redhat.com> On Tue, 2006-04-04 at 14:07 -0600, Lamont R. Peterson wrote: > > At that point, it's the responsibility of the package maintainer. But as I > understand it, there isn't one. Question for those in charge around here, > who should pick up this ball then? Someone who is getting hired. http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=961 Rahul From skvidal at linux.duke.edu Tue Apr 4 20:34:13 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 16:34:13 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144179721.6489.49.camel@rousalka.dyndns.org> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <1144177771.6489.38.camel@rousalka.dyndns.org> <1144178397.11415.17.camel@cutter> <1144179104.6489.45.camel@rousalka.dyndns.org> <1144179721.6489.49.camel@rousalka.dyndns.org> Message-ID: <1144182854.11415.23.camel@cutter> On Tue, 2006-04-04 at 21:41 +0200, Nicolas Mailhot wrote: > Le mardi 04 avril 2006 ? 21:31 +0200, Nicolas Mailhot a ?crit : > > Le mardi 04 avril 2006 ? 15:19 -0400, seth vidal a ?crit : > > > On Tue, 2006-04-04 at 21:09 +0200, Nicolas Mailhot wrote: > > > > (why do you think > > > > Red Hat revived Fedora after letting it wither a few years) > > > > > > umm. what? When did red hat let fedora wither? > > > > deemphasised if you want to be politically correct (RHL 8 to FC-2 or 3 I > > think) Then the press releases started rolling again and Fedora was not > > the ugly duckling anymore. > > Which makes me think (slow thinker that I am) now that this period is > over could we add a Fedora History page in the wiki with the "eat your > brainz" satire ? > > Or is it still too early ? > I'm pretty sure we have the brane satire somewhere. If not google has it. :) -sv From kloczek at zie.pg.gda.pl Tue Apr 4 20:37:18 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Tue, 04 Apr 2006 22:37:18 +0200 Subject: Move Evolution to Extras? In-Reply-To: <200604041407.45850.lamont@gurulabs.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <1144179663.5040.27.camel@kloczek01.pracownicy.zie> <1144180313.5040.29.camel@kloczek01.pracownicy.zie> <200604041407.45850.lamont@gurulabs.com> Message-ID: <1144183038.5040.51.camel@kloczek01.pracownicy.zie> Dnia 04-04-2006, wto o godzinie 14:07 -0600, Lamont R. Peterson napisa?(a): > On Tuesday 04 April 2006 01:51pm, Tomasz K?oczko wrote: > > Dnia 04-04-2006, wto o godzinie 21:41 +0200, Tomasz K?oczko napisa?(a): > > [..] > > > > > Patch for current evolution.spec for doing this in attachment. > > > > Sorry but previouse patch was with incorect Group in pilot subpackage > > and small bug in %build. > > You should attach this patch to a bugzilla entry. It'll just get lost in > here. Done. I'm include this patch here because it solves some (again: very stupid) things which also sits in *many* other Fedora packages .. for review by other Fedora developers. Each bugzilla entry is rewieved by only limited numbers developer eye balls. kloczek From dwmw2 at infradead.org Tue Apr 4 20:37:56 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 21:37:56 +0100 Subject: Move Evolution to Extras? In-Reply-To: <200604041402.33869.lamont@gurulabs.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> <1144170302.11377.185.camel@pmac.infradead.org> <200604041402.33869.lamont@gurulabs.com> Message-ID: <1144183076.11377.201.camel@pmac.infradead.org> On Tue, 2006-04-04 at 14:02 -0600, Lamont R. Peterson wrote: > That's a pretty trivial "bug". It's just an RFE, but I agree; it would be > fairly simple to implement. However, I think it's fairly harsh of you to > give up on KMail for this. I've used KMail (and now Kontact which embeds > KMail) for years and this has never been an issue for me. If I delete a > message, it goes in the trashcan. If I purge the trashcan, it's gone; if > not, I can get it back. > > Then again, I almost never delete email I delete a lot of it :) I appreciate that it's subjective -- but I really can't deal with the mailbox index jumping around like that as I delete messages. It just completely screws up the way my eye tracks down the index. Obviously, changing mailer is hard, and there are some things which you just take a while to get used to... but that isn't one of them. -- dwmw2 From fedora at adslpipe.co.uk Tue Apr 4 21:35:39 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Tue, 04 Apr 2006 22:35:39 +0100 Subject: gnome/gtk v1 in rawhide In-Reply-To: <20060404133238.72875b12@soran.addix.net> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> Message-ID: <4432E6AB.1030703@adslpipe.co.uk> Ralf Ertzinger wrote: > Although gtk1 programs tend to use quite less screen space than their > gtk2 counterparts. I think that is a valid point, GTK2 apps do have a "Lego Duplo" quality in comparison to other windowing toolkits, even after reducing font sizes from the defaults and fiddling with the theme details shipped with Fedora a 1280x1024 monitor running Gnome feels comparable to an 800x600 monitor running Win2K :-( I can just about get used to panels top *and* bottom of the screen eating into my area (I realise I could change the arrangement) and I need to keep reminding myself to actually make use of multiple workspaces. I'd prefer windows to have thinner borders and splitters, a touch less white space bordering everything, and denser packing of controls, or are there any "skinnier" themes that I ought to look at instead? From peter at thecodergeek.com Tue Apr 4 22:02:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 4 Apr 2006 15:02:27 -0700 (PDT) Subject: Move Evolution to Extras? In-Reply-To: <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> Message-ID: <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> Stephen J. Smoogen said: > I ditched Evolution during the 2.0 series of cruft.. and have been > doing nothing but converting people to Thunderbird who are with FC5. > As far as I can tell Evolution-2.6 is a pain in the butt with more > pain than gain. Agreed. Pretty much the only reason I use Evolution currently is that it is the only mail client I've tried which actually obeys my font settings. Hopefully the recent Pango-ification of Thunderbird will fix this in FC5... -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From sdl.web at gmail.com Tue Apr 4 22:12:06 2006 From: sdl.web at gmail.com (Leon) Date: Tue, 04 Apr 2006 23:12:06 +0100 Subject: Move Evolution to Extras? References: <1144154677.11377.105.camel@pmac.infradead.org> Message-ID: David Woodhouse writes: > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. > > What are we going to do about it? One option might be to move it to > Extras in the hope that someone will actually start to look after it > there. Or perhaps just drop it entirely? Any better ideas? Volunteers? > > -- > dwmw2 I don't use evolution mainly because of its long startup time. I hate waiting for apps to start up. I think it would generally be a good idea keep it installed. I expect more and more users are coming to Linux. And evolution is important for them since most of them are trained by outlook. Regards, -- Leon From lamont at gurulabs.com Tue Apr 4 22:14:01 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 4 Apr 2006 16:14:01 -0600 Subject: Move Evolution to Extras? In-Reply-To: <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> Message-ID: <200604041614.06080.lamont@gurulabs.com> On Tuesday 04 April 2006 04:02pm, Peter Gordon wrote: > Stephen J. Smoogen said: > > I ditched Evolution during the 2.0 series of cruft.. and have been > > doing nothing but converting people to Thunderbird who are with FC5. > > As far as I can tell Evolution-2.6 is a pain in the butt with more > > pain than gain. > > Agreed. Pretty much the only reason I use Evolution currently is that it > is the only mail client I've tried which actually obeys my font settings. > Hopefully the recent Pango-ification of Thunderbird will fix this in FC5... Really? Well, I use Kontact and it always respect my font choices. I guess you have not tried it. :) -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From peter at thecodergeek.com Tue Apr 4 22:22:32 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 4 Apr 2006 15:22:32 -0700 (PDT) Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <200604041614.06080.lamont@gurulabs.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> Message-ID: <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> Lamont R. Peterson said: >> Agreed. Pretty much the only reason I use Evolution currently is that it >> is the only mail client I've tried which actually obeys my font settings. >> Hopefully the recent Pango-ification of Thunderbird will fix this in FC5... > > Really? Well, I use Kontact and it always respect my font choices. I guess > you have not tried it. :) Yeah but Kontact is a Qt/KDE application... ;) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From dwmw2 at infradead.org Tue Apr 4 22:40:56 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Apr 2006 23:40:56 +0100 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> Message-ID: <1144190457.11116.5.camel@shinybook.infradead.org> On Tue, 2006-04-04 at 15:22 -0700, Peter Gordon wrote: > > Really? Well, I use Kontact and it always respect my font choices. I guess > > you have not tried it. :) > > Yeah but Kontact is a Qt/KDE application... ;) That just means it's not _surprising_ when it gives you options which allow you to make it behave how you want it to, rather than forcing the user to conform to _its_ model. -- dwmw2 From benjy.grogan at gmail.com Tue Apr 4 22:48:11 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Tue, 4 Apr 2006 18:48:11 -0400 Subject: Fedora Looks Fresh and Functions Well In-Reply-To: References: <1143717142.3802.673.camel@sundaram.pnq.redhat.com> Message-ID: On 3/30/06, Rudolf Kastl wrote: > 2006/3/30, Rahul Sundaram : > > On Thu, 2006-03-30 at 04:28 -0500, Benjy Grogan wrote: > > > Hello, > > > > > > I'm really enjoying using FC5. Tomboy is a great tool for jotting > > > down ideas. I actually put together this email using a few tomboy > > > notes. I have a few suggestions -- that you can take or leave -- that > > > I wanted to share to help out with 'Fedora's way forward'. :) Here > > > they are: > > > > > > > > > 1) A welcome to Fedora (or RHEL) tutorial for new accounts and even > > > maybe a tips section everytime you log in. DAC would be a really good > > > topic for new users. > > > > Do you want to help with that? . Docs project has a number of people who > > introduce themselves but then dont contribute. So the actual > > contributors are extremely low now. > > > > http://fedoraproject.org/wiki/DocsProject > > > > > > > > > > 2) Have a place in Preferences set up for the two or three available > > > Javas (Sun's and the OSS ones). Then when you have installed Sun's > > > Java you have a place to switch back to the old one, and vice versa. > > > (Question: Is a compiled Azureus the same if it's based on Sun or > > > GCJ?) > > > > > > > Fedora wouldnt ship Sun Java. Azureus is GCJ compiled. > > > > http://fedora.redhat.com/docs/release-notes/fc5/#sn-Java > > > > The alternatives mechanism already allows you to switch between any > > implementation of Java as long as it is appropriately packaged. Check > > out the third question in > > > > http://www.redhat.com/magazine/001nov04/departments/tips_tricks/ > > > > > > > > > 3) I have a question on codecs. Is it possible to get all OSS codecs > > > these days based on the GStreamer plugin system? I think the whole > > > audio/video codec problem would go away if there was a GStreamer Codec > > > management system where OSS codecs would be there by default and then > > > the user would go out and get all the proprietary GStreamer codecs > > > he/she is missing. It should be simple to look at a Fedora system, > > > and say "alright, got those ones, but missing these ones (like > > > mp3/avi). And I can figure out where to get them." And this > > > presupposes a future where there are only Gstreamer codecs. > > > > Thats exactly how it is supposed to be working. We are almost there at > > this point. > > > > > > > > 4) Since Firefox is one of the most important pieces of the Linux OS > > > these days, it would be great to have all of the alphas, betas and RCs > > > available in update-testing. That would allow some users to test > > > Firefox for bugs over an extended period of time before 2.0 or 3.0 > > > comes out. Obviously, under some guidance from Fedora with all the > > > patches they put into it. > > > > fedora updates-testing repository is just for testing updates that would > > almost always be later pushed out as actual updates. Having a > > experimental repository might be a good idea but the current usage of > > updates-testing repository is low enough to not deviate into that. > > That wouldnt fit though into the definition of the experimental > repository proposal i am still working on unless the experimental ff > is packaged in a way to coexist with current stable releases (wouldnt > even be bad for regression testing then.). i will add it to the > argumentation chain. I'm currently trying to get a CVS build of Firefox 2.0 to run on FC5. The build compiled fine in my home directory. And when I go to the executable and run it to determine the version I get: $ ./firefox --version Mozilla Firefox 1.6a1, Copyright (c) 1998 - 2006 mozilla.org But if I then run it as $ ./firefox all that happens is the default firefox 1.5.0.1 loads up. The exact same thing occurs if I d/l the tarball from the Bon Echo release homepage and follow the instructions: Extract the tarball and run ./firefox: tar -xzvf bonecho-alpha1.tar.gz cd firefox ./firefox ... so I'm guessing there is some configuration I have to do. If anyone can enlighten me I would appreciate it. I found Bug 157133 useful in showing me how to fix some selinux problems I had with the libraries libxpcom_core.so, libxpcom.so, libmozjs.so, and libxul.so. Before I could run firefox, I had to deal with this message on each of those libraries: $ ./firefox ./firefox-bin: error while loading shared libraries: ./libxpcom.so: cannot restore segment prot after reloc: Permission denied The solution was to follow some advice from Dan Walsh in Bug 157133 and do as so: # chcon -t texrel_shlib_t ./libxpcom_core.so # chcon -t texrel_shlib_t ./libxpcom.so # chcon -t texrel_shlib_t ./libmozjs.so # chcon -t texrel_shlib_t ./libxul.so Yet, now I'm dealing with the problem of Firefox automatically redirecting to the version of Firefox that comes with FC5. Any help would be appreciated, Thanks, Benjy From mailinglists at erwinrol.com Tue Apr 4 23:22:00 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Apr 2006 01:22:00 +0200 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1144190457.11116.5.camel@shinybook.infradead.org> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> Message-ID: <1144192920.6347.130.camel@xpc.home.erwinrol.com> On Tue, 2006-04-04 at 23:40 +0100, David Woodhouse wrote: > On Tue, 2006-04-04 at 15:22 -0700, Peter Gordon wrote: > > > Really? Well, I use Kontact and it always respect my font choices. I guess > > > you have not tried it. :) > > > > Yeah but Kontact is a Qt/KDE application... ;) > > That just means it's not _surprising_ when it gives you options which > allow you to make it behave how you want it to, rather than forcing the > user to conform to _its_ model. KDE apps, including Kontact, force me to use the KDE look and feel, and pretty much ignore the GNOME settings I am used to. So KDE is just as well forcing _its_ model on you, just a different model. Of course a KDE vs. GNOME flamewar is not going to fix the problem that evolution is a good application but just needs some fixing by someone with a lot of time :-) - Erwin From seg at haxxed.com Wed Apr 5 01:48:22 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 04 Apr 2006 20:48:22 -0500 Subject: gnome/gtk v1 in rawhide In-Reply-To: <4432E6AB.1030703@adslpipe.co.uk> References: <5256d0b0604040330g751c1eb1vc7daf4d5f9283e51@mail.gmail.com> <20060404133238.72875b12@soran.addix.net> <4432E6AB.1030703@adslpipe.co.uk> Message-ID: <1144201704.10632.172.camel@localhost> On Tue, 2006-04-04 at 22:35 +0100, Andy Burns wrote: > I think that is a valid point, GTK2 apps do have a "Lego Duplo" quality > in comparison to other windowing toolkits, even after reducing font > sizes from the defaults and fiddling with the theme details shipped with > Fedora a 1280x1024 monitor running Gnome feels comparable to an 800x600 > monitor running Win2K :-( The fact that spacing is hardwired into applications and specified by *pixel* (look at the Gnome HIG) is really really broken. As we're heading into an era of 300dpi LCD screens, this is going to have to be fixed sooner or later... (I guess the cairo-ization is a step towards this) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From prarit at sgi.com Wed Apr 5 01:53:41 2006 From: prarit at sgi.com (Prarit Bhargava) Date: Tue, 04 Apr 2006 21:53:41 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 Message-ID: <44332325.8050207@sgi.com> Hello, A set of CD ISOs and a DVD ISO based on the March 20, 2006 image of the ia64 Fedora development branch (also known as rawhide) are available from http://oss.sgi.com/projects/fedora The CD set consists of FC5-ia64-disc1.iso FC5-ia64-disc2.iso FC5-ia64-disc3.iso FC5-ia64-disc4.iso FC5-ia64-disc5.iso, and the DVD iso is FC5-ia64-DVD.iso These ISOs are not officially supported by the Fedora Project, however, a tracking bugzilla has been opened for the fedora-ia64 project here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=fedora-ia64 In order to track issues found with the ia64 Fedora development branch or issues with the ISOS, please enter "fedora-ia64" or 163350 in the "blocks" field of new bugzillas. You can contribute by signing up on the fedora-ia64 mailing list here: http://www.redhat.com/mailman/listinfo/fedora-ia64-list Enjoy, Prarit. From selinux at gmail.com Wed Apr 5 02:14:20 2006 From: selinux at gmail.com (Tom London) Date: Tue, 4 Apr 2006 19:14:20 -0700 Subject: '-Wunused-param' in kernel compiles? Message-ID: <4c4ba1530604041914y1f93c3f5hd0daa173a6633bbd@mail.gmail.com> The last few kernels appear to be compiled with '-Wunused-param'. That right? Is this a 'going forward' feature? Appears to break vmware. Just want to know if I need work on this, or if it will revert at some future point... tom -- Tom London From bojan at rexursive.com Wed Apr 5 02:21:23 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 05 Apr 2006 12:21:23 +1000 Subject: Move Evolution to Extras? Message-ID: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> > Evolution is fairly much broken in FC5, and there's little movement even > on the 'this mail crashes Evolution' bugs, let alone the "Evolution is > totally unusable with IMAP" bugs. I can't say I'm some kind of expert e-mail user, but Evo 2.6 seems to be working mostly OK here. I use it against dovecot-1.0/IMAP at home (two client machines) and with Exchange/Exchange at work. Since I also run LDAP addressbook at home, I find it rather useful to be able to edit entries directly from Evo. Having native access to GAL at work is also very useful. I would most definitely be in favour of fixing bugs and spliting out packages that provide functionality for other software and getting rid of bogus dependencies. However, I'm not sure if removing this package from core is a good idea. Is there a decent replacement under Fedora default desktop (Gnome) that covers all ground that Evo covers now? -- Bojan From pnasrat at redhat.com Wed Apr 5 02:25:43 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 04 Apr 2006 22:25:43 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <44332325.8050207@sgi.com> References: <44332325.8050207@sgi.com> Message-ID: <1144203943.12268.17.camel@enki.eridu> On Tue, 2006-04-04 at 21:53 -0400, Prarit Bhargava wrote: > Hello, > > A set of CD ISOs and a DVD ISO based on the March 20, 2006 image of the > ia64 Fedora development branch (also known as rawhide) are available from > > http://oss.sgi.com/projects/fedora http://oss.sgi.com/projects/fedora-ia64/download - 404 http://oss.sgi.com/projects/fedora/download/ - 403 http://oss.sgi.com/projects/fedora/download/FC5-ia64-disc1.iso seems correct. > The CD set consists of > > FC5-ia64-disc1.iso > FC5-ia64-disc2.iso > FC5-ia64-disc3.iso > FC5-ia64-disc4.iso > FC5-ia64-disc5.iso, I assume for the weekly snapshots of rawhide that you'll be putting unique (eg date based) names on the isos so they can be readily identified, else you're going to run into trouble tracking issues across media sets. Do these isos correspond with FC5 or a random snapshot? Paul From davej at redhat.com Wed Apr 5 02:38:47 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 4 Apr 2006 21:38:47 -0500 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <4c4ba1530604041914y1f93c3f5hd0daa173a6633bbd@mail.gmail.com> References: <4c4ba1530604041914y1f93c3f5hd0daa173a6633bbd@mail.gmail.com> Message-ID: <20060405023847.GH5804@redhat.com> On Tue, Apr 04, 2006 at 07:14:20PM -0700, Tom London wrote: > The last few kernels appear to be compiled with '-Wunused-param'. That right? > > Is this a 'going forward' feature? > > Appears to break vmware. it should only break if its being compiled with -Werror, which is insane, as it's guaranteed to break on newer gcc's. > Just want to know if I need work on this, or if it will revert at some > future point... I turned on a few 'give me a few zillion extra warnings' switches a few days ago, I'm fixing a bunch of stuff up from time to time, it'll be turned off eventually. Dave -- http://www.codemonkey.org.uk From jspaleta at gmail.com Wed Apr 5 04:07:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 00:07:53 -0400 Subject: Move Evolution to Extras? In-Reply-To: <4432C60C.2040504@hhs.nl> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <4432C60C.2040504@hhs.nl> Message-ID: <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> On 4/4/06, Hans de Goede wrote: > Agreed but that is still no excuse for the sometimes somewhat bizarre > dep chains. If a package functions fine (although feature limited) > without something and putting this something in launches a (long) extra > depchain and the part which requires this can be seperated into a > subpackage it should be a in subpackage. Your logic also hits on another packaging policy limitation in Core which doesn't strongly delineate between hard requirements and optional functionality which depends on an additional package to be installed to be functional. The evolution "requirement" on spamassasin is an example of how the line between hard requirements and optional functionality is blurred delibrately by the package maintainer to ensure that evolution installs with the spamassasin support enabled without additional effort by unsuspecting users. Making the effort to subpackage functionality further only makes sense if the application package maintainers are going to stop treating the runtime optional functionality as hard requirements in the packaging spec. -jef From jeff at ocjtech.us Wed Apr 5 04:19:43 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 04 Apr 2006 23:19:43 -0500 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <4c4ba1530604041914y1f93c3f5hd0daa173a6633bbd@mail.gmail.com> References: <4c4ba1530604041914y1f93c3f5hd0daa173a6633bbd@mail.gmail.com> Message-ID: <1144210783.2572.5.camel@lt16585.campus.dmacc.edu> On Tue, 2006-04-04 at 19:14 -0700, Tom London wrote: > The last few kernels appear to be compiled with '-Wunused-param'. That right? > > Is this a 'going forward' feature? > > Appears to break vmware. I'm not sure that -Wunused-param is what broke VMware. I just tried to configure VMware server beta 2 (build 22874) with kernel 2.6.16-1.2118_FC6 and found this error buried in the output: In file included from /tmp/vmware-config0/vmmon-only/linux/driver.h:20, from /tmp/vmware-config0/vmmon-only/linux/driver.c:49: /tmp/vmware-config0/vmmon-only/./include/compat_wait.h: At top level: /tmp/vmware-config0/vmmon-only/./include/compat_wait.h:60: error: conflicting types for ?poll_initwait? include/linux/poll.h:62: error: previous declaration of ?poll_initwait? was here It wouldn't surprise me if the Linux kernel developers changed an API that broke VMware. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Wed Apr 5 05:00:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 04 Apr 2006 22:00:27 -0700 Subject: Move Evolution to Extras? In-Reply-To: <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> Message-ID: <44334EEB.2010803@thecodergeek.com> Peter Gordon wrote: > Agreed. Pretty much the only reason I use Evolution currently is that it > is the only mail client I've tried which actually obeys my font settings. > Hopefully the recent Pango-ification of Thunderbird will fix this in FC5... Huzzah. I've got the official build from Mozilla.com, and some configuring; and Thunderbird *still* doesn't fully obey the settings. However, the fonts are actually nice though. /me goes off to transfer mail from Evolution... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From bojan at rexursive.com Wed Apr 5 06:01:42 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 05 Apr 2006 16:01:42 +1000 Subject: '-Wunused-param' in kernel compiles? Message-ID: <20060405160142.z2vxtwn7s4ow8gco@www.rexursive.com> Have you tried any of these: http://ftp.cvut.cz/vmware/ For instance: http://ftp.cvut.cz/vmware/vmware-any-any-update101.tar.gz PS. I haven't tried VMware on current Rawhide yet, so the kernel API may have been changed again to the point where the above patches don't help. -- Bojan From bogdan.mustiata at gmail.com Wed Apr 5 07:48:11 2006 From: bogdan.mustiata at gmail.com (Bogdan Mustiata) Date: Wed, 05 Apr 2006 10:48:11 +0300 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1144192920.6347.130.camel@xpc.home.erwinrol.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> Message-ID: <4433763B.9000701@gmail.com> Erwin Rol wrote: > On Tue, 2006-04-04 at 23:40 +0100, David Woodhouse wrote: > >> On Tue, 2006-04-04 at 15:22 -0700, Peter Gordon wrote: >> >>>> Really? Well, I use Kontact and it always respect my font choices. I guess >>>> you have not tried it. :) >>>> >>> Yeah but Kontact is a Qt/KDE application... ;) >>> >> That just means it's not _surprising_ when it gives you options which >> allow you to make it behave how you want it to, rather than forcing the >> user to conform to _its_ model. >> > > KDE apps, including Kontact, force me to use the KDE look and feel, and > pretty much ignore the GNOME settings I am used to. So KDE is just as > well forcing _its_ model on you, just a different model. > > Of course a KDE vs. GNOME flamewar is not going to fix the problem that > evolution is a good application but just needs some fixing by someone > with a lot of time :-) > > - Erwin > I didn't knew that GNOME and KDE _should_ integrate ;-) so I don't get your point about KDE being forcing. Anyway I belive that David tried to point out that KDE lets *you* configure it fully as you want, while GNOME limits you because of all usability stuff (HIG and so on). Anyway after I have tried Evolution, Kontact and Thunderbird and remained with Thunderbird. Bogdan From db-fedora at 3di.it Wed Apr 5 07:59:14 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Wed, 05 Apr 2006 09:59:14 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <20060404173157.GF14317@ti64.telemetry-investments.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> Message-ID: <443378D2.8020805@3di.it> Bill Rugolsky Jr. wrote: > By two networking configuration stacks you mean the traditional method > and the NetworkManager way? Wouldn't it have been better to have > an actual design ... rather than thinking up a GUI interface to some > use case, then starting coding? > > Pete's condescension is right on target: core Linux components are > being replaced by people who, by their own admission, "hate Unix." Well, the former goes hand in hand with the latter, apparently. There is a saying: "Those that don't understand Unix are comdemned to reimplement it ... poorly". > It seems that an "unusual requirement" is one that is difficult and > inconvenient for that other operating system, i.e., a requirement > that foregoes the monkey pressing buttons in front of a > bitmapped display. The irony is that legacy operating systems are moving in the opposite direction, introducing text, tools and domain-specific little languages. > Unix/Linux carries years of baggage, mis-designed features, and half-baked > implementations. But today's GNOME hackers seem to have completely > missed the value of (1) text, (2) tools, and (3) domain-specific little > languages and protocols. One area where Unix went somewhat astray is > that script and config syntax differences created unnecessary impedance [the > original point of this thread] -- the Lisp machine folks had that much > right. Two decades later, it's easy to see that domain-specific languages > are best built without inventing lots of arcane syntax; these days S-exprs > have been replaced by XML, XSLT (*vomit*), and worse. In my experience, XML does not really work for domain specific languages because it is too heavy on syntax baggage for humans - it is best thought of as textual XDR: good for program-to-program data interchange. I believe your reaction to XSLT confirms this. > Unfortunately, > simply stuffing name/value config pairs in a file is not the same as > domain-specific design. > > I'm not holding my breath waiting for support for 20-year-old > "unusual requirements" to be bolted on later. Davide Bolcioni -- There is no place like /home. From mailinglists at erwinrol.com Wed Apr 5 07:59:56 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Apr 2006 09:59:56 +0200 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <4433763B.9000701@gmail.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> Message-ID: <1144223996.6347.140.camel@xpc.home.erwinrol.com> On Wed, 2006-04-05 at 10:48 +0300, Bogdan Mustiata wrote: > I didn't knew that GNOME and KDE _should_ integrate ;-) They shouldn't, hence i don't want kmail but a GNOME mailer. > so I don't get > your point about KDE being forcing. > Anyway I belive that David tried to point out that KDE lets *you* > configure it fully as you want, while GNOME limits you because of all > usability stuff (HIG and so on). What if I don't want to configure every little thing, or am not smart enough to do so ? And one configuration option that i could not find in KDE was the "follow GNOME HIG and theme" one ;-) > Anyway after I have tried Evolution, Kontact and Thunderbird and > remained with Thunderbird. Thunderbird isn't bad, it just doesn't do calendar and task management. - Erwin From db-fedora at 3di.it Wed Apr 5 08:18:35 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Wed, 05 Apr 2006 10:18:35 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144175781.31422.102.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> Message-ID: <44337D5B.5090603@3di.it> David Zeuthen wrote: > Replacing all the old cruft with new stuff is bound to introduce a few > more bugs along the way. I think it's called... progress? On legacy operating systems, it turned out to be actually a dead end. >>But you can damn Pete for writing what a lot of people were thinking if >>you like. > > > That's nice. > > At least I learned something today: Never ever propose anything that > might be a bit visionary on fedora-devel-list; you will just get shot > down by the vocal minority and you will get flamed you for the > improvements for the silent majority you helped create. As a sysadmin I might be a part of the vocal minority, and I actually agree that many of the problems you want to address are there and need to be addressed - it's just that, and I believe many of the others are actually trying to say just this, the proposed vision carries along a price we're not willing to pay. Just my $0.02, Davide Bolcioni -- There is no place like /home. From jorton at redhat.com Wed Apr 5 08:35:42 2006 From: jorton at redhat.com (Joe Orton) Date: Wed, 5 Apr 2006 09:35:42 +0100 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <1144167375.31422.46.camel@daxter.boston.redhat.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <604aa7910603281512h35cb7c11n5dc295326aef7ed5@mail.gmail.com> <9BB9650A-3E73-47BF-96CA-6BAA323F6F9A@fubar.dk> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <20060404155845.GD32306@redhat.com> <1144167375.31422.46.camel@daxter.boston.redhat.com> Message-ID: <20060405083542.GA26312@redhat.com> On Tue, Apr 04, 2006 at 12:16:14PM -0400, David Zeuthen wrote: > On Tue, 2006-04-04 at 16:58 +0100, Joe Orton wrote: > > The end goal ("configure everything via LDAP") is no doubt a worthy > > goal, I don't disagree with that at all. But if it can be achieved by > > writing one simple tool > > Because it's not that simple for the user experience that at least I > think is right. s/simple tool/tool with single specific purpose/. This is standard Unix philosophy. You're not making the case that httpd itself needs to be more "cluster aware" or whatever. Your "user story" is great and warm and fuzzy, and can be achieved, AFAICS, by writing a tool which generates httpd configurations, and IMAP server configuration, and whatever, based on some LDAP database. That tool can do all the tricky stuff like having a daemon which polls the LDAP database for changes, knowing when to restart httpd into a new configuration, and knowing how to map a particular LDAP schema into an specific httpd configuration; it can easily scale to supporting lots of different daemons since it's basically the same logic for each. That can all be done without destabilizing the codebases of all the daemons you want to support. Regards, joe From jfrieben at freesurf.fr Wed Apr 5 08:06:17 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 5 Apr 2006 10:06:17 +0200 (CEST) Subject: GCC ADA compiler driver failure for recent Fedora Core kernels Message-ID: <15583.194.94.224.254.1144224377.squirrel@jose.freesurf.fr> I have a problem with both (current, i.e. fully updated updated) FC5 *and* FC6/rawhide: I install the system from scratch. All volumes get formatted, no additional or customized dot files, one stock test user account. My default shell is "csh" but "bash" makes no difference. My local ".rpmmacros" file reads: %_usrsrc /home/test/build %_tmppath /home/test/build/var/tmp and the corresponding directory tree has been created in test's home directory in order to avoid building the package as "root". Result after installing FC5 w/o any updates: "checking for gnatbind... gnatbind checking whether compiler driver understands Ada... yes" After fully updating the system as of 04/04/06 or [updating to/installing] FC6/rawhide from scratch and booting the system again, the Ada driver stops working (!): "checking for gnatbind... gnatbind checking whether compiler driver understands Ada... no" In the first case, the system boots "kernel-2.6.15-1.2054_FC5", in the second case "kernel-2.6.16-1.2080_FC5" or FC6 rawhide kernel respectively. After rebooting the [updated/rawhide] system again and booting "kernel-2.6.15-1.2054_FC5", case #1 occurs, thus no error message. Rebooting the system several times confirms that for the original FC5 kernel, the configure script passes successfully when checking Ada support, whereas for update kernel and current FC6/rawhide kernels, the script fails. I had posted a bug report at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187687 It had been closed as "WORKSFORME" but I had reopened it after finding out that the issue actually depends on the kernel version (!) as described above. Any similar observations? Any clues? From dwmw2 at infradead.org Wed Apr 5 09:43:13 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 10:43:13 +0100 Subject: Move Evolution to Extras? In-Reply-To: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> Message-ID: <1144230193.6227.8.camel@pmac.infradead.org> On Wed, 2006-04-05 at 12:21 +1000, Bojan Smojver wrote: > I can't say I'm some kind of expert e-mail user, but Evo 2.6 seems to > be working mostly OK here. It seems broken to me -- your reply lacked a 'References:' or 'In-Reply-To:' header, and thus was detached from the thread because it didn't indicate which message it was a response to. Please try to fix that -- it's very rude to post without threading information to public fora; especially busy mailing lists like this one. -- dwmw2 From dwmw2 at infradead.org Wed Apr 5 09:44:45 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 10:44:45 +0100 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <1144203943.12268.17.camel@enki.eridu> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> Message-ID: <1144230285.6227.10.camel@pmac.infradead.org> On Tue, 2006-04-04 at 22:25 -0400, Paul Nasrat wrote: > I assume for the weekly snapshots of rawhide that you'll be putting > unique (eg date based) names on the isos so they can be readily > identified, else you're going to run into trouble tracking issues > across media sets. To be honest, I'm not convinced that weekly ISO builds are particularly useful -- we don't do that for rawhide on other architectures either. It's probably better just to encourage people to use rsync to keep up with rawhide, rather than downloading it all over again each week. > Do these isos correspond with FC5 or a random snapshot? Rawhide for about a week leading up to March 20th was identical to FC5 in all but the 'fedora-release' package. If making an IA64 'FC5' I'd be inclined to replace the fedora-release package too. In fact, you almost certainly want to do that anyway, since you'll be publishing the errata, and fedora-release contains the yum configuration. Aside from the updates, the next task is building Extras and Livna for IA64, of course... -- dwmw2 From bogdan.mustiata at gmail.com Wed Apr 5 09:47:09 2006 From: bogdan.mustiata at gmail.com (Bogdan Mustiata) Date: Wed, 05 Apr 2006 12:47:09 +0300 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1144223996.6347.140.camel@xpc.home.erwinrol.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> <1144223996.6347.140.camel@xpc.home.erwinrol.com> Message-ID: <4433921D.6060305@gmail.com> Erwin Rol wrote: > And one configuration option that i could not find in > KDE was the "follow GNOME HIG and theme" one ;-) > That would certainly be a bug if it would appear. I would probably go to TWM if so :-D Bogdan From Lam at Lam.pl Wed Apr 5 10:01:40 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 05 Apr 2006 12:01:40 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144230193.6227.8.camel@pmac.infradead.org> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> Message-ID: <1144231300.2760.7.camel@pensja.lam.pl> Dnia 05-04-2006, ?ro o godzinie 10:43 +0100, David Woodhouse napisa?(a): > > I can't say I'm some kind of expert e-mail user, but Evo 2.6 seems to > > be working mostly OK here. > It seems broken to me -- your reply lacked a 'References:' or > 'In-Reply-To:' header, and thus was detached from the thread because it > didn't indicate which message it was a response to. User-Agent: Internet Messaging Program (IMP) H3 (4.1) Evolution 2.6 doesn't have a problem there. It doesn't have that many problems at all - it's just it's not enough actively maintained and bugs (probably simple, sometimes with patches available in many bugzillas at once) aren't fixed. Evolution is a good mailer, only the changes are in wrong direction [adding new untested features instead of fixing recently added (and proved to be buggy) untested features :)]. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From emeric.maschino at jouy.inra.fr Wed Apr 5 10:23:35 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 05 Apr 2006 12:23:35 +0200 Subject: open DRM failed (Operation not permitted) Message-ID: <1144232615.5104.80.camel@localhost.localdomain> Hi, With yesterday's updates, all the needed bits to enable DRI acceleration with ATI graphics adapters sporting a R300 chipset were back in Rawhide. Unfortunately, on my Itanium workstation with an ATI FireGL X1 graphics adapter, I'm getting "open DRM failed (Operation not permitted)" when I'm invoking glxinfo or glxgears (for example). I already experienced this problem before the R300 bits were removed from Rawhide (https://www.redhat.com/archives/fedora-devel-list/2006- February/msg01324.html). From Xorg.0.log, DRM seems to be initialized properly. I've checked the permissions on the /dev/dri/card0 file, they seem to be OK: crw------- emeric root system_u:object_r:dri_device_t card0 (as user emeric) Mike Harris didn't see this problem before and suggested me that it may be due to udev, so I've filed a bug on bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184045). Altering the rules as suggested there didn't help. Disabling SELinux as advised in this post (http://www.redhat.com/archives/fedora-test-list/2006- February/msg01681.html) didn't help. I have a Section DRI in my xorg.conf file (mode 0666). stracing glxinfo as in this post (http://www.redhat.com/archives/fedora-test-list/2006- February/msg01638.html) shows a similar error. Any idea what's going wrong? Many thanks, ?meric From dwmw2 at infradead.org Wed Apr 5 10:36:14 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 11:36:14 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1144231300.2760.7.camel@pensja.lam.pl> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> <1144231300.2760.7.camel@pensja.lam.pl> Message-ID: <1144233374.6227.15.camel@pmac.infradead.org> On Wed, 2006-04-05 at 12:01 +0200, Leszek Matok wrote: > User-Agent: Internet Messaging Program (IMP) H3 (4.1) Ah, right. Please don't use broken mailers to post to public fora. -- dwmw2 From bojan at rexursive.com Wed Apr 5 10:40:06 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 05 Apr 2006 20:40:06 +1000 Subject: Move Evolution to Extras? Message-ID: <1144233606.9585.7.camel@coyote.rexursive.com> > It seems broken to me -- your reply lacked a 'References:' or > 'In-Reply-To:' header, and thus was detached from the thread because it > didn't indicate which message it was a response to. He, he, the message wasn't even sent from Evo. It was sent from IMP. And detachment is due to the fact that I chose not the receive messages from the list. So, I just "fake" the replies (like this one I'm sending now from Evo :-) > Please try to fix that -- it's very rude to post without threading > information to public fora; especially busy mailing lists like this one. Whoa! Attack of the mailing list police ;-) -- Bojan From dwmw2 at infradead.org Wed Apr 5 10:42:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 11:42:25 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1144233606.9585.7.camel@coyote.rexursive.com> References: <1144233606.9585.7.camel@coyote.rexursive.com> Message-ID: <1144233745.6227.16.camel@pmac.infradead.org> On Wed, 2006-04-05 at 20:40 +1000, Bojan Smojver wrote: > And detachment is due to the fact that I chose not the receive > messages from the list. So, I just "fake" the replies (like this one > I'm sending now from Evo :-) By clicking on the links in the mailing list archive? Those ought to include &In-Reply-To= in the mailto: links -- if they don't, we should get them fixed. -- dwmw2 From prarit at sgi.com Wed Apr 5 10:52:33 2006 From: prarit at sgi.com (Prarit Bhargava) Date: Wed, 05 Apr 2006 06:52:33 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <1144203943.12268.17.camel@enki.eridu> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> Message-ID: <4433A171.4050200@sgi.com> Paul Nasrat wrote: > On Tue, 2006-04-04 at 21:53 -0400, Prarit Bhargava wrote: > >>Hello, >> >>A set of CD ISOs and a DVD ISO based on the March 20, 2006 image of the >>ia64 Fedora development branch (also known as rawhide) are available from >> >> http://oss.sgi.com/projects/fedora > > > http://oss.sgi.com/projects/fedora-ia64/download - 404 Yep, that doesn't exist. 'fedora', not 'fedora-ia64' > > http://oss.sgi.com/projects/fedora/download/ - 403 > Odd .. that seems to work for me (off of my home connection). I'll check into it ... > > > > I assume for the weekly snapshots of rawhide that you'll be putting > unique (eg date based) names on the isos so they can be readily > identified, else you're going to run into trouble tracking issues across > media sets. Do these isos correspond with FC5 or a random snapshot? > My plan was to take a weekly snapshot of rawhide and give it a date-based name to avoid the problem(s) you bring up. P. From prarit at sgi.com Wed Apr 5 10:54:26 2006 From: prarit at sgi.com (Prarit Bhargava) Date: Wed, 05 Apr 2006 06:54:26 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <1144230285.6227.10.camel@pmac.infradead.org> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> Message-ID: <4433A1E2.5060308@sgi.com> David Woodhouse wrote: > On Tue, 2006-04-04 at 22:25 -0400, Paul Nasrat wrote: > >>I assume for the weekly snapshots of rawhide that you'll be putting >>unique (eg date based) names on the isos so they can be readily >>identified, else you're going to run into trouble tracking issues >>across media sets. > > > To be honest, I'm not convinced that weekly ISO builds are particularly > useful -- we don't do that for rawhide on other architectures either. > It's probably better just to encourage people to use rsync to keep up > with rawhide, rather than downloading it all over again each week. > Unfortunately, it seems I have users who are unwilling to use yum, etc., in the short term. They would prefer weekly snapshots. > >> Do these isos correspond with FC5 or a random snapshot? > > > Rawhide for about a week leading up to March 20th was identical to FC5 > in all but the 'fedora-release' package. > Yep -- I replaced fedora-release with the FC5 version in the images. I didn't mention it because I didn't think it was that important :). > Aside from the updates, the next task is building Extras and Livna for > IA64, of course... > Whaddya think I'm working on? :) P. From gilboad at gmail.com Wed Apr 5 10:46:23 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 13:46:23 +0300 Subject: Vim-7 Preview In-Reply-To: <4419531C.3070803@redhat.de> References: <4419531C.3070803@redhat.de> Message-ID: <1144233983.2789.13.camel@gilboa-work-dev> On Thu, 2006-03-16 at 12:59 +0100, Karsten Hopp wrote: > Hello, > > I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/ > > Most prominent new features are gvim with windows in multiple tab pages (:help tabpage), > spell checking (:help spell) and omni-completion (:help new-omni-completion). > > A description of the new features of vim-7 is available with :help version7 > > Please report any problems in bugzilla and make sure to mention the package version > > Have fun... > Karsten > > > -- > Learn. Network. Experience open source. > Red Hat Summit Nashville | May 30 - June 2, 2006 > Learn more: http://www.redhat.com/promo/summit/ > rpmbuild barfs on FC5/x86_64 vimtutor build. It looks like a bad rpmmacros on my side. (Though I can't really find the source of the problem.) [gilboa at gilboa-work-dev SPECS]$ rpmbuild -ba vim7.spec > build.log 2>&1 [gilboa at gilboa-work-dev SPECS]$ cat build.log | egrep -e 'tutor|Bad' cp vimtutor /var/tmp/vim7-7.0aa.000-root/bin/vimtutor chmod 755 /var/tmp/vim7-7.0aa.000-root/bin/vimtutor /bin/sh ./mkinstalldirs /var/tmp/vim7-7.0aa.000-root/var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor mkdir /var/tmp/vim7-7.0aa.000-root/var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor chmod 755 /var/tmp/vim7-7.0aa.000-root/var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/man1/vimtutor.1 cp ../runtime/tutor/README* ../runtime/tutor/tutor* /var/tmp/vim7-7.0aa.000-root/var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor chmod 644 /var/tmp/vim7-7.0aa.000-root/var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor/* installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/fr/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/fr.ISO8859-1/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/fr.UTF-8/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/it/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/it.ISO8859-1/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/it.UTF-8/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/ru.KOI8-R/man1/vimtutor.1 installing /var/tmp/vim7-7.0aa.000-root/usr/share/man/ru.UTF-8/man1/vimtutor.1 + mv ./bin/vimtutor ./usr/bin/vimtutor7 + perl -pi -e s,/var/tmp/vim7-7.0aa.000-root,, ./usr/share/man/man1/vim.1 ./usr/share/man/man1/vimtutor.1 + pushd /var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor /var/tmp/rpm-tmp.36168: line 97: pushd: /var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.36168 (%install) Bad exit status from /var/tmp/rpm-tmp.36168 (%install) Any idea what's wrong? Gilboa P.S. Any chance of getting x86_64 build in your repo? From prarit at sgi.com Wed Apr 5 11:12:54 2006 From: prarit at sgi.com (Prarit Bhargava) Date: Wed, 05 Apr 2006 07:12:54 -0400 Subject: [Fedora-ia64-list] Re: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <4433A171.4050200@sgi.com> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <4433A171.4050200@sgi.com> Message-ID: <4433A636.6080103@sgi.com> >> http://oss.sgi.com/projects/fedora/download/ - 403 >> ftp://oss.sgi.com/projects/fedora/download P. From dwmw2 at infradead.org Wed Apr 5 11:24:15 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 12:24:15 +0100 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <4433A1E2.5060308@sgi.com> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> <4433A1E2.5060308@sgi.com> Message-ID: <1144236255.6227.30.camel@pmac.infradead.org> On Wed, 2006-04-05 at 06:54 -0400, Prarit Bhargava wrote: > > To be honest, I'm not convinced that weekly ISO builds are particularly > > useful -- we don't do that for rawhide on other architectures either. > > It's probably better just to encourage people to use rsync to keep up > > with rawhide, rather than downloading it all over again each week. > > Unfortunately, it seems I have users who are unwilling to use yum, etc., > in the short term. They would prefer weekly snapshots. They actually want to _reinstall_ weekly? Or do a full 'upgrade' weekly? Even so, they could quite happily do that from a normal rawhide mirror like everyone else does, rather than using ISO images. That just seems like a gratuitous waste of bandwidth to me -- for rawhide even more so than for the actual releases. > Yep -- I replaced fedora-release with the FC5 version in the images. I > didn't mention it because I didn't think it was that important :). The _real_ FC5 version -- doesn't that mean the updates repo is configured to point at a non-existent directory? > > Aside from the updates, the next task is building Extras and Livna for > > IA64, of course... > > Whaddya think I'm working on? :) :) -- dwmw2 From karsten at redhat.de Wed Apr 5 10:24:06 2006 From: karsten at redhat.de (Karsten Hopp) Date: Wed, 5 Apr 2006 12:24:06 +0200 Subject: Vim-7 Preview In-Reply-To: <1144233983.2789.13.camel@gilboa-work-dev> References: <4419531C.3070803@redhat.de> <1144233983.2789.13.camel@gilboa-work-dev> Message-ID: <20060405102406.GC16469@redhat.de> On Wed, Apr 05, 2006 at 01:46:23PM +0300, Gilboa Davara wrote: > pushd: /var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor: No such > file or directory > error: Bad exit status from /var/tmp/rpm-tmp.36168 (%install) > Bad exit status from /var/tmp/rpm-tmp.36168 (%install) > > Any idea what's wrong? > Gilboa > P.S. Any chance of getting x86_64 build in your repo? > vim-7.0c BETA should be in today's Rawhide for all archs. Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From ich at frank-schmitt.net Wed Apr 5 06:33:05 2006 From: ich at frank-schmitt.net (Frank Schmitt) Date: Wed, 05 Apr 2006 08:33:05 +0200 Subject: Move Evolution to Extras? References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> <1144170302.11377.185.camel@pmac.infradead.org> <200604041402.33869.lamont@gurulabs.com> <1144183076.11377.201.camel@pmac.infradead.org> Message-ID: David Woodhouse writes: > On Tue, 2006-04-04 at 14:02 -0600, Lamont R. Peterson wrote: >> That's a pretty trivial "bug". It's just an RFE, but I agree; it would be >> fairly simple to implement. However, I think it's fairly harsh of you to >> give up on KMail for this. I've used KMail (and now Kontact which embeds >> KMail) for years and this has never been an issue for me. If I delete a >> message, it goes in the trashcan. If I purge the trashcan, it's gone; if >> not, I can get it back. >> >> Then again, I almost never delete email > > I delete a lot of it :) > > I appreciate that it's subjective -- but I really can't deal with the > mailbox index jumping around like that as I delete messages. It just > completely screws up the way my eye tracks down the index. Obviously, > changing mailer is hard, and there are some things which you just take a > while to get used to... but that isn't one of them. Marking all messages you want to delete with Control+Click first and deleting them all with Delete isn't an option? -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From mailinglists at erwinrol.com Wed Apr 5 12:02:44 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Apr 2006 14:02:44 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144233374.6227.15.camel@pmac.infradead.org> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> <1144231300.2760.7.camel@pensja.lam.pl> <1144233374.6227.15.camel@pmac.infradead.org> Message-ID: <1144238564.2781.2.camel@xpc.home.erwinrol.com> On Wed, 2006-04-05 at 11:36 +0100, David Woodhouse wrote: > On Wed, 2006-04-05 at 12:01 +0200, Leszek Matok wrote: > > User-Agent: Internet Messaging Program (IMP) H3 (4.1) > > Ah, right. Please don't use broken mailers to post to public fora. BTW are the bugs you mentioned only in evolution 2.2.3 (which you seem to be using) or are those things you mentioned also in 2.6.0 (the last version) ? - Erwin From gilboad at gmail.com Wed Apr 5 12:03:03 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 15:03:03 +0300 Subject: Vim-7 Preview In-Reply-To: <20060405102406.GC16469@redhat.de> References: <4419531C.3070803@redhat.de> <1144233983.2789.13.camel@gilboa-work-dev> <20060405102406.GC16469@redhat.de> Message-ID: <1144238583.2789.15.camel@gilboa-work-dev> On Wed, 2006-04-05 at 12:24 +0200, Karsten Hopp wrote: > On Wed, Apr 05, 2006 at 01:46:23PM +0300, Gilboa Davara wrote: > > pushd: /var/tmp/vim7-7.0aa.000-root/usr/share/vim/vim70aa/tutor: No such > > file or directory > > error: Bad exit status from /var/tmp/rpm-tmp.36168 (%install) > > Bad exit status from /var/tmp/rpm-tmp.36168 (%install) > > > > Any idea what's wrong? > > Gilboa > > P.S. Any chance of getting x86_64 build in your repo? > > > > vim-7.0c BETA should be in today's Rawhide for all archs. > > Karsten > > -- > Karsten Hopp GPG 1024D/70ABD02C > Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C > Red Hat Deutschland, Hauptstaetter Str.58 > 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 OK. Thanks. I'll try building it on my FC5/64 once it's out. Gilboa From pnasrat at redhat.com Wed Apr 5 12:08:48 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 05 Apr 2006 08:08:48 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <4433A171.4050200@sgi.com> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <4433A171.4050200@sgi.com> Message-ID: <1144238928.12268.31.camel@enki.eridu> On Wed, 2006-04-05 at 06:52 -0400, Prarit Bhargava wrote: > Paul Nasrat wrote: > > On Tue, 2006-04-04 at 21:53 -0400, Prarit Bhargava wrote: > > > >>Hello, > >> > >>A set of CD ISOs and a DVD ISO based on the March 20, 2006 image of the > >>ia64 Fedora development branch (also known as rawhide) are available from > >> > >> http://oss.sgi.com/projects/fedora > > > > > > http://oss.sgi.com/projects/fedora-ia64/download - 404 > > Yep, that doesn't exist. 'fedora', not 'fedora-ia64' That's the Download link on the page here: http://oss.sgi.com/projects/fedora/

The ISOs and a mirror of Fedora Core IA64 development branch can be accessed via ftp by clicking on the Download link on the left hand side of this page. Can you get that updated with the ftp uri. Paul From Lam at Lam.pl Wed Apr 5 12:15:22 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 05 Apr 2006 14:15:22 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144238564.2781.2.camel@xpc.home.erwinrol.com> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> <1144231300.2760.7.camel@pensja.lam.pl> <1144233374.6227.15.camel@pmac.infradead.org> <1144238564.2781.2.camel@xpc.home.erwinrol.com> Message-ID: <1144239322.2760.15.camel@pensja.lam.pl> Dnia 05-04-2006, ?ro o godzinie 14:02 +0200, Erwin Rol napisa?(a): > BTW are the bugs you mentioned only in evolution 2.2.3 (which you seem > to be using) or are those things you mentioned also in 2.6.0 (the last > version) ? In Evolution, since I guess 1.4, every next version brings more annoying bugs for old users than new features to gain new users. I guess he downgraded ;) I worked around one most annoying thing and can live with Evo 2.6, actually it would be perfect if not my (not very typical, probably, but then again, I'm not the only person complaining) account setup. So let's face the truth - only little percentage of "real life" users are hitting the bugs we - techies - are hitting with our sophisticated needs :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From pnasrat at redhat.com Wed Apr 5 12:16:48 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 05 Apr 2006 08:16:48 -0400 Subject: [ANNOUNCE]: IA64 ISOs based on Fedora Core 5 In-Reply-To: <4433A1E2.5060308@sgi.com> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> <4433A1E2.5060308@sgi.com> Message-ID: <1144239409.12268.34.camel@enki.eridu> On Wed, 2006-04-05 at 06:54 -0400, Prarit Bhargava wrote: > David Woodhouse wrote: > > On Tue, 2006-04-04 at 22:25 -0400, Paul Nasrat wrote: > > > >>I assume for the weekly snapshots of rawhide that you'll be putting > >>unique (eg date based) names on the isos so they can be readily > >>identified, else you're going to run into trouble tracking issues > >>across media sets. > > > > > > To be honest, I'm not convinced that weekly ISO builds are particularly > > useful -- we don't do that for rawhide on other architectures either. > > It's probably better just to encourage people to use rsync to keep up > > with rawhide, rather than downloading it all over again each week. > > > > Unfortunately, it seems I have users who are unwilling to use yum, etc., > in the short term. They would prefer weekly snapshots. Really having done this for ppc, and also working on anaconda - I'd heartily recommend using NFS and tracking rawhide. With NFS it's trivial to drop in an RHupdates to fix up issues, with isos it becomes much harder. Paul From gilboad at gmail.com Wed Apr 5 12:20:11 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 15:20:11 +0300 Subject: Move Evolution to Extras? In-Reply-To: <1144239322.2760.15.camel@pensja.lam.pl> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> <1144231300.2760.7.camel@pensja.lam.pl> <1144233374.6227.15.camel@pmac.infradead.org> <1144238564.2781.2.camel@xpc.home.erwinrol.com> <1144239322.2760.15.camel@pensja.lam.pl> Message-ID: <1144239611.2789.24.camel@gilboa-work-dev> On Wed, 2006-04-05 at 14:15 +0200, Leszek Matok wrote: > Dnia 05-04-2006, ?ro o godzinie 14:02 +0200, Erwin Rol napisa?(a): > > BTW are the bugs you mentioned only in evolution 2.2.3 (which you seem > > to be using) or are those things you mentioned also in 2.6.0 (the last > > version) ? > In Evolution, since I guess 1.4, every next version brings more annoying > bugs for old users than new features to gain new users. I guess he > downgraded ;) I worked around one most annoying thing and can live with > Evo 2.6, actually it would be perfect if not my (not very typical, > probably, but then again, I'm not the only person complaining) account > setup. So let's face the truth - only little percentage of "real life" > users are hitting the bugs we - techies - are hitting with our > sophisticated needs :) > > Lam > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Ummm..... While not directly an Evolution bug, I doubt that having a broken Evolution - gnome-pilot - pilot-link since mid-life FC3 hits only tech users... Gilboa From rdieter at math.unl.edu Wed Apr 5 12:41:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 07:41:58 -0500 Subject: Move Evolution to Extras? In-Reply-To: <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <4432C60C.2040504@hhs.nl> <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> Message-ID: <4433BB16.6090706@math.unl.edu> Jeff Spaleta wrote: > Your logic also hits on another packaging policy limitation in Core > which doesn't strongly delineate between hard requirements and > optional functionality which depends on an additional package to be > installed to be functional. AFAIK, the latest (or soon to be included in rawhide?) version of rpm will support new tags: Requires(hint): and/or Requires(missingok): to allow for such soft requirements. -- Rex From dwmw2 at infradead.org Wed Apr 5 12:43:29 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 13:43:29 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1144238564.2781.2.camel@xpc.home.erwinrol.com> References: <20060405122123.kuqo5ea5k4s400w8@www.rexursive.com> <1144230193.6227.8.camel@pmac.infradead.org> <1144231300.2760.7.camel@pensja.lam.pl> <1144233374.6227.15.camel@pmac.infradead.org> <1144238564.2781.2.camel@xpc.home.erwinrol.com> Message-ID: <1144241009.6227.37.camel@pmac.infradead.org> On Wed, 2006-04-05 at 14:02 +0200, Erwin Rol wrote: > BTW are the bugs you mentioned only in evolution 2.2.3 (which you seem > to be using) or are those things you mentioned also in 2.6.0 (the last > version) ? I believe they're all in 2.6 -- I have _tried_ 2.6, but it's fairly much impossible for me to actually use it from day to day. Some of the bugs were reported many years ago against older versions, but I'm not aware of anything having been _fixed_ in Evolution 2.6, on the mailer side -- the only changes I've noticed have been regressions. I'm actually tempted to see if I can build Evolution 2.2 for FC5, for that reason. -- dwmw2 From rdieter at math.unl.edu Wed Apr 5 12:45:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 07:45:28 -0500 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1144223996.6347.140.camel@xpc.home.erwinrol.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> <1144223996.6347.140.camel@xpc.home.erwinrol.com> Message-ID: <4433BBE8.30305@math.unl.edu> Erwin Rol wrote: > What if I don't want to configure every little thing, or am not smart > enough to do so ? And one configuration option that i could not find in > KDE was the "follow GNOME HIG and theme" one ;-) There is gtk-qt-engine in Fedora Extras, but, unfortunately, it's a bit buggy wrt recent gtk2 releases. -- Rex From jspaleta at gmail.com Wed Apr 5 12:47:29 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 08:47:29 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <44337D5B.5090603@3di.it> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <44337D5B.5090603@3di.it> Message-ID: <604aa7910604050547id296213r5b3c7e8c4aee134b@mail.gmail.com> On 4/5/06, Davide Bolcioni wrote: > As a sysadmin I might be a part of the vocal minority, and I actually agree > that many of the problems you want to address are there and need to be > addressed - it's just that, and I believe many of the others are > actually trying to say just this, the proposed vision carries along a > price we're not willing to pay. A useful cmdline tool to interact with dbus would go a long long way. Something for dbus which is at least as functional a tool as gconftool is for gconf. A cmdline tool that exposed introspection as to what methods were available over the bus so admins can ask questions with regard to what clients and methods are currently active on the bus and introspection per method so we can ask what arguments a particular method takes without having to dig up an API document PER DBUS CLIENT to figure out what methods take what arguments PER CLIENT. To make use of dbus and anything which is expected to communicate over dbus I need a tool designed to navigate the dbus space on the cmdline. Something I can use to explore the space, discover which services are available and how to communicate which each service, so I can then script actions or fire off individual actions over remote concole connections if required. dbus-send right now allows me to script actions across dbus, but without the introspection tool to explore the space dbus will continue to be under utilized for sysadmin actions... and thats going to be a big big problem moving forward. Because as more services expect to be controlled over dbus, admins will be using other approaches they are more comfortable with because the minimal set of cmdline tools to interact with dbus are not available. dbus definitely has potential as a very powerful sysadmin oriented technology. It's certaintly not a bad technology but it needs a cmdline oriented interface with introspection to be approachable enough for sysadmins to start working with it to solve their specific local policy/action needs. I encourage everyone to take a look at the oddjob package in Extras to see one direction in which dbus can be taken to morph it into something useful for a sysadmin. -jef From jfrieben at freesurf.fr Wed Apr 5 12:48:32 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 5 Apr 2006 14:48:32 +0200 (CEST) Subject: GCC ADA compiler driver failure for recent Fedora Core kernels In-Reply-To: <15583.194.94.224.254.1144224377.squirrel@jose.freesurf.fr> References: <15583.194.94.224.254.1144224377.squirrel@jose.freesurf.fr> Message-ID: <55859.194.94.224.254.1144241312.squirrel@jose.freesurf.fr> I forgot of course to mention explicitly that the configure failure occurs while trying to rebuild a current GCC package, i.e.: rpmbuild --rebuild gcc-4.1.0-3.src.rpm From nomis80 at nomis80.org Wed Apr 5 12:56:37 2006 From: nomis80 at nomis80.org (Simon Perreault) Date: Wed, 5 Apr 2006 08:56:37 -0400 Subject: Qt 4 RPM poke Message-ID: <200604050856.37985.nomis80@nomis80.org> Hi, You posted on March 13 a spec for Qt 4 that needed just a little bit of work before being submitted to Fedora Extras. What is the status on that RPM? I'm very interested in that package. I would be willing to submit it and maintain it myself if you wish. From mailinglists at erwinrol.com Wed Apr 5 13:02:22 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Apr 2006 15:02:22 +0200 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <4433BBE8.30305@math.unl.edu> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> <1144223996.6347.140.camel@xpc.home.erwinrol.com> <4433BBE8.30305@math.unl.edu> Message-ID: <1144242142.2781.10.camel@xpc.home.erwinrol.com> On Wed, 2006-04-05 at 07:45 -0500, Rex Dieter wrote: > Erwin Rol wrote: > > > What if I don't want to configure every little thing, or am not smart > > enough to do so ? And one configuration option that i could not find in > > KDE was the "follow GNOME HIG and theme" one ;-) > > There is gtk-qt-engine in Fedora Extras, but, unfortunately, it's a bit > buggy wrt recent gtk2 releases. Doesn't the gtk-qt engine create a GTK theme that uses a Qt theme ? With other words GNOME applications look like Qt applications. For a gnome desktop it would be better if there was a Qt theme engine that uses GTK to draw Qt/KDE applications. Also since Qt is GPL, doesn't the gtk-qt-engine introduce some licensing problems, cause all GTK applications will than be "linked" with Qt, and so they all should be GPL (which isn't needed with GTK) And things like cut and paste, URL default aps, etc. still will be different. The only two KDE apps i use are kdevelop and k3d and I hate the small differences, I would not suggest mixing KDE and GNOME, they are just to different. - Erwin From bogdan.mustiata at gmail.com Wed Apr 5 13:03:06 2006 From: bogdan.mustiata at gmail.com (Bogdan Mustiata) Date: Wed, 05 Apr 2006 16:03:06 +0300 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <4433BBE8.30305@math.unl.edu> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> <1144223996.6347.140.camel@xpc.home.erwinrol.com> <4433BBE8.30305@math.unl.edu> Message-ID: <4433C00A.9030906@gmail.com> Rex Dieter wrote: > Erwin Rol wrote: > >> What if I don't want to configure every little thing, or am not smart >> enough to do so ? And one configuration option that i could not find in >> KDE was the "follow GNOME HIG and theme" one ;-) > > There is gtk-qt-engine in Fedora Extras, but, unfortunately, it's a > bit buggy wrt recent gtk2 releases. > > -- Rex > It doesn't follow HIG anyway... so... Bogdan From selinux at gmail.com Wed Apr 5 13:45:43 2006 From: selinux at gmail.com (Tom London) Date: Wed, 5 Apr 2006 06:45:43 -0700 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <20060405160142.z2vxtwn7s4ow8gco@www.rexursive.com> References: <20060405160142.z2vxtwn7s4ow8gco@www.rexursive.com> Message-ID: <4c4ba1530604050645q18e6f7der1f1aac7988b72b99@mail.gmail.com> On 4/4/06, Bojan Smojver wrote: > Have you tried any of these: > > http://ftp.cvut.cz/vmware/ > > For instance: > > http://ftp.cvut.cz/vmware/vmware-any-any-update101.tar.gz > > PS. I haven't tried VMware on current Rawhide yet, so the kernel API > may have been changed again to the point where the above patches don't > help. > > -- > Bojan > Yup, tried the above, and still fails. Messaging with Petr (@vmware) is suggesting the '-Wunused-param' path. I'm still digging.... tom -- Tom London From rdieter at math.unl.edu Wed Apr 5 13:52:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 08:52:47 -0500 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1144242142.2781.10.camel@xpc.home.erwinrol.com> References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> <4433763B.9000701@gmail.com> <1144223996.6347.140.camel@xpc.home.erwinrol.com> <4433BBE8.30305@math.unl.edu> <1144242142.2781.10.camel@xpc.home.erwinrol.com> Message-ID: <4433CBAF.10304@math.unl.edu> Erwin Rol wrote: > Doesn't the gtk-qt engine create a GTK theme that uses a Qt theme ? With > other words GNOME applications look like Qt applications. For a gnome > desktop it would be better if there was a Qt theme engine that uses GTK > to draw Qt/KDE applications. True, but who cares as long as the look-n-feel is consistent? > Also since Qt is GPL, doesn't the gtk-qt-engine introduce some licensing > problems, cause all GTK applications will than be "linked" with Qt, and > so they all should be GPL (which isn't needed with GTK) I don't think a theme-engine counts as "linking" in the GPL-sense, but that's just my non-lawyer opinion. -- Rex From jfrieben at freesurf.fr Wed Apr 5 13:56:49 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 5 Apr 2006 15:56:49 +0200 (CEST) Subject: GCC ADA compiler driver failure for recent Fedora Core kernels In-Reply-To: <15583.194.94.224.254.1144224377.squirrel@jose.freesurf.fr> References: <15583.194.94.224.254.1144224377.squirrel@jose.freesurf.fr> Message-ID: <2088.194.94.224.254.1144245409.squirrel@arlette.freesurf.fr> Ok, issue has been identified as a kernel bug introduced on post-FC5 final kernels: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187853 From buildsys at redhat.com Wed Apr 5 14:09:24 2006 From: buildsys at redhat.com (Build System) Date: Wed, 5 Apr 2006 10:09:24 -0400 Subject: rawhide report: 20060405 changes Message-ID: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> Removed package Guppi Removed package oaf Removed package gal Removed package gnome-print Removed package gnome-libs Updated Packages: a2ps-4.13b-50 ------------- * Tue Apr 04 2006 Tim Waugh 4.13b-50 - Use sort correctly in make_font_map.sh (bug #187884). anaconda-11.1.0.3-1 ------------------- * Tue Apr 04 2006 Chris Lumens 11.1.0.3-1 - Fix up for rhpxl Modes changes. - Fix handling of video driver if there's no list of drivers available. - Add modes files and libuser to images. - Allow updates to contain entire directories that may be missing. - Clean up deprecation warnings. at-spi-1.7.7-5 -------------- * Tue Apr 04 2006 Matthias Clasen - 1.7.7-5 - Fix a missing declaration - Fix segfaults on x86_64 * Tue Apr 04 2006 Matthias Clasen - 1.7.7-1 - Update to 1.7.7 atk-1.11.4-2 ------------ * Tue Apr 04 2006 Matthias Clasen - 1.11.4-2 - Update to 1.11.4 bash-3.1-11 ----------- * Tue Apr 04 2006 Tim Waugh 3.1-11 - Patchlevel 16. bind-30:9.3.2-20.FC6 -------------------- * Tue Apr 04 2006 Jason Vas Dias - 30:9.3.2-20 - fix resolver.c ncache_adderesult segfault reported in addenda to bug 173961 (upstream bugs #15642, #15528 ?) - allow named ability to generate core dumps after setuid (upstream bug #15753) cups-1:1.2-0.2.rc1.6 -------------------- * Tue Apr 04 2006 Tim Waugh 1:1.2-0.2.rc1.6 - Tweak to allow 'usb:/dev/usb/lp0'-style URIs again. dasher-4.0.2-2 -------------- * Tue Apr 04 2006 Matthias Clasen - 4.0.2-2 - Update to 4.0.2 eclipse-changelog-1:2.0.1_fc-26 ------------------------------- * Tue Apr 04 2006 Andrew Overholt 2.0.1_fc-26 - Add ia64. eclipse-pydev-1:0.9.3_fc-15 --------------------------- * Tue Apr 04 2006 Andrew Overholt 0.9.3_fc-15 - Add ia64. elfutils-0.120-2 ---------------- * Tue Apr 04 2006 Roland McGrath - 0.120-2 - Update to 0.120 - License changed to GPL, with some exceptions for using the libelf, libebl, libdw, and libdwfl library interfaces. Red Hat elfutils is an included package of the Open Invention Network. - dwarf.h updated for DWARF 3.0 final specification. - libelf: Fix corruption in ELF_C_RDWR uses (#187618). - libdwfl: New function dwfl_version; fixes for offline. firstboot-1.4.8-1 ----------------- * Tue Apr 04 2006 Chris Lumens 1.4.8-1 - Allow firstboot to run in kadischi (#186870). - Updated for rhpxl changes. gnucash-1.9.3-2 --------------- * Tue Apr 04 2006 Bill Nottingham - 1.9.3-2 - fix conflict with qof (#187267) gphoto2-2.1.99-10 ----------------- * Tue Apr 04 2006 Radek Vok??l 2.1.99-10 - fix crash in ptp2 module * Tue Mar 14 2006 Than Ngo 2.1.99-9 - fix gphoto2-config hplip-0.9.10-4 -------------- * Tue Apr 04 2006 Tim Waugh 0.9.10-4 - Use case-insensitive matching. 0.9.8 gave all-uppercase in some situations. - Last known working hpijs comes from 0.9.8, so use that. kdeaccessibility-1:3.5.2-1 -------------------------- * Tue Apr 04 2006 Than Ngo 1:3.5.2-1 - update to 3.5.2 kdegames-6:3.5.2-1 ------------------ * Tue Apr 04 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 kdemultimedia-6:3.5.2-1 ----------------------- * Tue Apr 04 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 kernel-2.6.16-1.2121_FC6 ------------------------ * Tue Apr 04 2006 Dave Jones - Reenable non-standard serial ports. (#187466) - Reenable snd-es18xx for x86-32 (#187733) - Map x86 kernel to 4MB physical address. librsvg2-2.14.3-2 ----------------- * Tue Apr 04 2006 Matthias Clasen 2.14.3-2 - Update to 2.14.3 * Sun Mar 12 2006 Ray Strode 2.14.2-1 - Update to 2.14.2 * Sat Mar 11 2006 Bill Nottingham 2.14.1-2 - fix bad libart dep mkbootdisk-1.5.3-1 ------------------ * Wed Apr 05 2006 Peter Vrabec 1.5.3-1 - fix tail command usage (#187876) * Tue Mar 07 2006 Peter Vrabec 1.5.2-6 - build as noarch net-snmp-5.3-7 -------------- * Wed Apr 05 2006 Radek Vok??l 5.3-7 - fix parsing of /proc/diskstats - fix disman monitor crash - fix perl vendor name - fix OID lookup fail netdump-0.7.14-5 ---------------- * Tue Apr 04 2006 Bill Nottingham - 0.7.14-5 - build against glib2 netpbm-10.33-1 -------------- * Wed Apr 05 2006 Jindrich Novy 10.33-3 - update to 10.33 - drop upstreamed .ppmdepth patch - fix segfault in ppmtompeg when encoding jpeg images (#185970) openssl-0.9.8a-6 ---------------- * Tue Apr 04 2006 Tomas Mraz - 0.9.8a-6 - fix stale open handles in libica (#177155) - fix build if 'rand' or 'passwd' in buildroot path (#178782) - initialize VIA Padlock engine (#186857) rhpxl-0.19-1 ------------ * Tue Apr 04 2006 Chris Lumens 0.19-1 - Remove obsolete functions in mouse.py. - Create a new Modes class. sane-backends-1.0.17-8 ---------------------- * Wed Apr 05 2006 Nils Philippsen 1.0.17-8 - don't use automake * Tue Apr 04 2006 Nils Philippsen - require gphoto2-devel in sane-backends-devel * Fri Mar 24 2006 Nils Philippsen 1.0.17-7 - don't include *.la files scim-qtimm-0.9.4-3 ------------------ * Wed Apr 05 2006 Jens Petersen - 0.9.4-3 - add epoch to obsoletes selinux-policy-2.2.29-3 ----------------------- * Thu Mar 30 2006 Dan Walsh 2.2.29-3 - Get auditctl working in MLS policy shadow-utils-2:4.0.15-2 ----------------------- * Tue Apr 04 2006 Peter Vrabec 2:4.0.15-2 - properly notify nscd to flush its cache(#186803) squirrelmail-1.4.6-5.fc6 ------------------------ * Tue Apr 04 2006 Warren Togami 1.4.6-5 - Fix Chinese and Korean too subversion-1.3.1-3 ------------------ * Tue Apr 04 2006 Joe Orton 1.3.1-3 - update to 1.3.1 - update to psvn.el r19138 (Stefan Reichoer) - build -java on s390 again * Thu Feb 16 2006 Florian La Roche - 1.3.0-5 - do not package libs within subversion-ruby, these are already available via the main package systemtap-0.5.5-2 ----------------- * Tue Apr 04 2006 Roland McGrath - 0.5.5-2 - Rebuilt for devel * Tue Apr 04 2006 Roland McGrath - 0.5.5-1 - Many changes, affected PRs include: 2068, 2293, 1989, 2334, 1304, 2390, 2425, 953. * Wed Feb 01 2006 Frank Ch. Eigler - 0.5.4-1 - PRs 1916, 2205, 2142, 2060, 1379 tetex-3.0-20 ------------ * Fri Mar 31 2006 Jindrich Novy 3.0-20 - define NeedWidePrototypes for xdvi to display Japanese correctly (#178411) vim-1:7.0c.000-1 ---------------- * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 - vim-7.0c BETA * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 - Rawhide build as vim, opposed to vim7 (prerelease) - conflict with older man-pages-{it,fr} packages - cleanup lang stuff * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 - make it coexist with vim-6 (temporarily) - new CVS snapshot xferstats-2.16-14 ----------------- * Fri Apr 14 2006 Bill Nottingham - 2.16-14 - build against glib2 xfig-3.2.4-18 ------------- * Tue Apr 04 2006 Than Ngo 3.2.4-18 - no parameter negotiation for xfig, fix #187902 xorg-x11-drv-ati-6.5.7.3-4.cvs20060404 -------------------------------------- * Tue Apr 04 2006 Kristian H??gsberg 6.5.7.3-4.cvs20060404 - Update to CVS snapshot from 20060404. xorg-x11-drv-i810-1.4.1.3-4.cvs20060322.1 ----------------------------------------- * Tue Apr 04 2006 Kristian H??gsberg 1.4.1.3-4.cvs20060322.1 - Add patch to add missing #include's, specifically assert.h. xorg-x11-server-1.0.99.2-1 -------------------------- * Tue Apr 04 2006 Kristian H??gsberg 1.0.99.2-1 - Update to 1.0.99.2 snapshot and go back to using mesa-source package. - Drop xorg-server-1.0.99-composite-visibility.patch. - Drop xorg-server-1.0.1-backtrace.patch. - Drop xorg-server-0.99.3-rgb.txt-dix-config-fix.patch. - Add xorg-server-1.0.99.2-spiffiffity.patch. * Thu Mar 23 2006 Kristian H??gsberg - Pass --with-dri-driver-path so we're sure to point it to the right path. * Wed Mar 22 2006 Soren Sandmann 1.0.99.1-2 - Add xorg-server-1.0.99-composite-visibility.patch to get rid of flashing titlebars in compositing metacity. xsane-0.99-4 ------------ * Wed Apr 05 2006 Nils Philippsen - 0.99-4 - use XSANE.lang instead of xsane.lang to avoid %doc multilib regression * Tue Apr 04 2006 Nils Philippsen - 0.99-3 - fix medium-definitions patch to not barf on obsolete options in config file (#185269, by Aldy Hernandez) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) mkbootdisk - 1.5.3-1.noarch requires syslinux rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 mkbootdisk - 1.5.3-1.noarch requires syslinux Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 From mike at mommabears.com Wed Apr 5 14:11:48 2006 From: mike at mommabears.com (MJang) Date: Wed, 05 Apr 2006 07:11:48 -0700 Subject: Tripwire in Extras Message-ID: <1144246308.3904.7.camel@localhost> Folks, I see Tripwire has been removed from FC5 extras, but per http://fedoraproject.org/wiki/Extras/FC5Status , it's probably going to get a new maintainer soon. Will it be available in FC5 Extras after it gets the new maintainer, or will it go someplace else like Extras-Development? I've tried posting this to the Extras list, with no response. That list seems dedicated to bug discussions, so I'm not surprised that my question there was ignored. Thanks, Mike From dwmw2 at infradead.org Wed Apr 5 14:14:33 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 15:14:33 +0100 Subject: Move Evolution to Extras? In-Reply-To: References: <1144154677.11377.105.camel@pmac.infradead.org> <20060404092629.75903af7.zaitcev@redhat.com> <1144170302.11377.185.camel@pmac.infradead.org> <200604041402.33869.lamont@gurulabs.com> <1144183076.11377.201.camel@pmac.infradead.org> Message-ID: <1144246473.6227.67.camel@pmac.infradead.org> On Wed, 2006-04-05 at 08:33 +0200, Frank Schmitt wrote: > Marking all messages you want to delete with Control+Click first and > deleting them all with Delete isn't an option? This is IMAP. Clicking 'delete' marks a mail for deletion, and expunging the folder actually does delete those mails which have been so marked. Anything else is just the MUA playing silly buggers. I don't think the workaround you suggest would be very compatible with my workflow. I work through a folder with whatever the keystroke is for 'next new message' (I mapped it to ']' since it's a KDE app and I can change things like that, and I'm used to that key in Evolution). I delete messages or read them, and keeping a set of random mails selected in order that I can delete them would be complicated. I want to just mark them for deletion, like I can in any normal MUA. -- dwmw2 From dimi at lattica.com Wed Apr 5 14:14:33 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 5 Apr 2006 10:14:33 -0400 Subject: rawhide report: 20060405 changes References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> Message-ID: <05f701c658bb$465e9490$b6491b31@td612671> From: "Build System" > > Removed package Guppi > > Removed package oaf > > Removed package gal > > Removed package gnome-print > > Removed package gnome-libs Cool, what's the story here? -- Dimi Paun Lattica, Inc. From gilboad at gmail.com Wed Apr 5 14:19:26 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 17:19:26 +0300 Subject: pilot-link.org: Anonymous CVS Removed indefinitely Message-ID: <1144246766.2789.31.camel@gilboa-work-dev> I'm just posting this, so -please- don't shoot the messenger: ---------------------------------------------------------------------------- Submitted by desrod on Mon, 03/27/2006 - 01:50. Since the Fedora Linux distribution (always problems with Fedora, sigh) has decided to ignore the FAT GLARING WARNING about NOT packaging up pilot-link 0.12.x in their releases, I?ve taken anonymous CVS down indefinitely, and hourly snapshots will also be removed. Those who wish to use the code, will have to wait until official releases are made. Sorry, but this has happened way too often with Fedora (and previously with the Red Hat packagers) to ignore time and time again. Their ignorance has increased our maintenance headaches, and I?m frankly tired of dealing with the support issues. ---------------------------------------------------------------------------- Problem is: pilot-link AND gnome-pilot are semi-broken on FC4 and completely broken on FC5. Now that CVS is shut, until pilot-link 0.12 is released (and there's not tables for that) there's little chance that FC5 will be fixed. My question is: Will it be possible to roll-back all patches and go back to 0.11? Please? Pretty please? Gilboa From pbrobinson at gmail.com Wed Apr 5 14:22:59 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 5 Apr 2006 15:22:59 +0100 Subject: rawhide report: 20060405 changes In-Reply-To: <05f701c658bb$465e9490$b6491b31@td612671> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> <05f701c658bb$465e9490$b6491b31@td612671> Message-ID: <5256d0b0604050722o3c990613jab7b1eb2175120ce@mail.gmail.com> On 4/5/06, Dimi Paun wrote: > From: "Build System" > > > > Removed package Guppi > > > > Removed package oaf > > > > Removed package gal > > > > Removed package gnome-print > > > > Removed package gnome-libs > > Cool, what's the story here? Removing the old gnome1 dependancies now that the last core app (gnucash) no longer requires gnome1. I think they're headed to extras. Peter From jos at xos.nl Wed Apr 5 14:26:51 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 5 Apr 2006 16:26:51 +0200 Subject: Tripwire in Extras In-Reply-To: <1144246308.3904.7.camel@localhost>; from mike@mommabears.com on Wed, Apr 05, 2006 at 07:11:48AM -0700 References: <1144246308.3904.7.camel@localhost> Message-ID: <20060405162651.A25673@xos037.xos.nl> On Wed, Apr 05, 2006 at 07:11:48AM -0700, MJang wrote: > I see Tripwire has been removed from FC5 extras, but per > http://fedoraproject.org/wiki/Extras/FC5Status , it's probably going to > get a new maintainer soon. Will it be available in FC5 Extras after it > gets the new maintainer, or will it go someplace else like > Extras-Development? Shouldn't Tripwire be replaced by another package, that is the successor of Tripwire? I don't remember its name, but (long ago) I got the impression that Tripwire was not actively maintained anymore and/or had some licensing issues and that there existed a fork/successor of it. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From gilboad at gmail.com Wed Apr 5 14:27:31 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 17:27:31 +0300 Subject: rawhide report: 20060405 changes In-Reply-To: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> Message-ID: <1144247251.2789.34.camel@gilboa-work-dev> On Wed, 2006-04-05 at 10:09 -0400, Build System wrote: > > vim-1:7.0c.000-1 > ---------------- > * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 > - vim-7.0c BETA > > * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 > - Rawhide build as vim, opposed to vim7 (prerelease) > - conflict with older man-pages-{it,fr} packages > - cleanup lang stuff > > * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 > - make it coexist with vim-6 (temporarily) > - new CVS snapshot Thanks! vim-6.4 package dropped? Gilboa From rdieter at math.unl.edu Wed Apr 5 14:30:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 09:30:10 -0500 Subject: roll-back to 0.11? In-Reply-To: <1144246766.2789.31.camel@gilboa-work-dev> References: <1144246766.2789.31.camel@gilboa-work-dev> Message-ID: <4433D472.9090000@math.unl.edu> Gilboa Davara wrote: > My question is: > Will it be possible to roll-back all patches and go back to 0.11? > Please? > Pretty please? Last I heard, that was the plan. -- Rex From gilboad at gmail.com Wed Apr 5 14:35:13 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 17:35:13 +0300 Subject: roll-back to 0.11? In-Reply-To: <4433D472.9090000@math.unl.edu> References: <1144246766.2789.31.camel@gilboa-work-dev> <4433D472.9090000@math.unl.edu> Message-ID: <1144247713.2789.39.camel@gilboa-work-dev> On Wed, 2006-04-05 at 09:30 -0500, Rex Dieter wrote: > Gilboa Davara wrote: > > > My question is: > > Will it be possible to roll-back all patches and go back to 0.11? > > Please? > > Pretty please? > > Last I heard, that was the plan. > > -- Rex > Hello Rex, Thanks for the info. Hopefully it'll be sooner then later :( The number of open palm-related bugs in bugzilla.redhat and bugzilla.gnome is beginning to pick up... Gilboa BTW, unlike FC4, FC5's kpilot (kde-palm sync) is also broken... sigh... Seems like the same pilot-link/udev/etc problem. From vandrove at vc.cvut.cz Wed Apr 5 14:51:56 2006 From: vandrove at vc.cvut.cz (Petr Vandrovec) Date: Wed, 05 Apr 2006 16:51:56 +0200 Subject: '-Wunused-param' in kernel compiles? Message-ID: <4433D98C.4050203@vc.cvut.cz> [Sorry for breaking threading, but I just copy&pasted this from web archive as I'm not subscribed to fedora-devel-list] > On Tue, 2006-04-04 at 19:14 -0700, Tom London wrote: >> The last few kernels appear to be compiled with '-Wunused-param'. That right? >> >> Is this a 'going forward' feature? >> >> Appears to break vmware. > > I'm not sure that -Wunused-param is what broke VMware. I just tried to > configure VMware server beta 2 (build 22874) with kernel > 2.6.16-1.2118_FC6 and found this error buried in the output: > > In file included from /tmp/vmware-config0/vmmon-only/linux/driver.h:20, > from /tmp/vmware-config0/vmmon-only/linux/driver.c:49: > /tmp/vmware-config0/vmmon-only/./include/compat_wait.h: At top level: > /tmp/vmware-config0/vmmon-only/./include/compat_wait.h:60: error: conflicting types for ?poll_initwait? > include/linux/poll.h:62: error: previous declaration of ?poll_initwait? was here > > It wouldn't surprise me if the Linux kernel developers changed an API > that broke VMware. Yes, it is broken due to -Wunused-param. We attempt to compile (vmmon-only/autoconf/epoll.c) (Hm, I see a problem that we are using return in function returning void, but as gcc allows this...) #include void poll_test(void) { struct poll_wqueues test; return poll_initwait(&test); } and if this builds without warning it means that poll_initwait() takes 'struct poll_wqueues*' as its argument. If it emits warning (that poll_wqueues pointer had to be converted to poll_table pointer) then code decides that this is pre-epoll kernel. And with current 2.6.16-1.2118 this test fails as even in correct case linux/poll.h emits warnings... We can probably rewrite this test in the way compat_wait.h uses to reverify it (redeclare prototype in a form we expect, we added this later as if pre-epoll code is built with epoll kernel it emits just warning during build, but crashes at runtime), but there are other tests (one testing type of last argument of nopage vma handler) which I do not know how to rewrite without using -Werror: #include static struct page *LinuxDriverNoPage(struct vm_area_struct *vma, unsigned long address, int *type) { (void)vma; (void)address; *type = VM_FAULT_MINOR; return NULL; } struct vm_operations_Struct vmuser_mops = { .nopage = LinuxDriverNoPage }; If you can tell me how to rewrite this detection without relying on -Werror, then we can probably stop doing that. Petr From selinux at gmail.com Wed Apr 5 14:55:55 2006 From: selinux at gmail.com (Tom London) Date: Wed, 5 Apr 2006 07:55:55 -0700 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <4c4ba1530604050645q18e6f7der1f1aac7988b72b99@mail.gmail.com> References: <20060405160142.z2vxtwn7s4ow8gco@www.rexursive.com> <4c4ba1530604050645q18e6f7der1f1aac7988b72b99@mail.gmail.com> Message-ID: <4c4ba1530604050755n52258481ubabc764db4740907@mail.gmail.com> On 4/5/06, Tom London wrote: > On 4/4/06, Bojan Smojver wrote: > > Have you tried any of these: > > > > http://ftp.cvut.cz/vmware/ > > > > For instance: > > > > http://ftp.cvut.cz/vmware/vmware-any-any-update101.tar.gz > > > > PS. I haven't tried VMware on current Rawhide yet, so the kernel API > > may have been changed again to the point where the above patches don't > > help. > > > > -- > > Bojan > > > Yup, tried the above, and still fails. > > Messaging with Petr (@vmware) is suggesting the '-Wunused-param' path. > > I'm still digging.... > OK. Here's what I've figured out.... The vmware 'configure' system (vmware-config.pl) attempts to auto-configure by compiling small 'test' programs and detecting success. It uses '-Werror'. Since the recent kernel builds include '-Wunused-param', this makes this break. (Seems a bit fragile to me; there should be a better way....) Anyhow, the resulting failed compiles cause some significant compile-time parameters (e.g., VMW_HAVE_EPOLL) not to be set correctly. Removing the '-Werror' from the makefiles (thanks to Dave Jones for the hint!) allows vmware-config.pl to complete (spewing lots of warning messages, but completes). I can now startup vmware (didn't connect to sound hardware, but rest seems OK). I'm guessing that when -Wunused-param is removed from the kernel builds, this will settle. I'll try to get VMware folks to ponder this, but I suspect we're on our own until -Wunused-param reverts. tom -- Tom London From Nigel.Metheringham at dev.intechnology.co.uk Wed Apr 5 14:57:52 2006 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Wed, 05 Apr 2006 15:57:52 +0100 Subject: pilot-link.org: Anonymous CVS Removed indefinitely In-Reply-To: <1144246766.2789.31.camel@gilboa-work-dev> References: <1144246766.2789.31.camel@gilboa-work-dev> Message-ID: <1144249073.17742.36.camel@angua.localnet> On Wed, 2006-04-05 at 17:19 +0300, Gilboa Davara wrote: > Will it be possible to roll-back all patches and go back to 0.11? This should have been done for FC5. Now all the arguments about handling the roll back still apply - although since no one in RH apparently gives a fuck for any of the pilot support tools there will probably be nothing done at all. If a roll back is done it will require building a pilot-link set, with an Epoch version set so it overrides the FC4/FC5 ones. Then all the directly dependant packages also need to be rebuilt, which includes:- * gnome-pilot* * jpilot * kpilot potentially some of the other packages with less direct dependencies need rebuilding as well:- * evolution (fairly sure this had to be rebuilt for palm breakage in FC4) * kdepim * beagle (possibly - due to evo) which is a huge pile of updates and disk space/download bandwidth! Adding the patch from BZ 186779 does fix the basic pilot-xfer crash problem, and does not require other packages to be rebuilt. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186779 There are other workroundable bugs in gnome-pilot, and udev issues, however the situation is actually rather better than with FC4 where someone worked out every subsystem that palm devices touched and carefully broke every one of them (from kernel to evolution) Having someone who occasionally moved bugs out of new state would be nice. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From selinux at gmail.com Wed Apr 5 14:58:39 2006 From: selinux at gmail.com (Tom London) Date: Wed, 5 Apr 2006 07:58:39 -0700 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <4c4ba1530604050755n52258481ubabc764db4740907@mail.gmail.com> References: <20060405160142.z2vxtwn7s4ow8gco@www.rexursive.com> <4c4ba1530604050645q18e6f7der1f1aac7988b72b99@mail.gmail.com> <4c4ba1530604050755n52258481ubabc764db4740907@mail.gmail.com> Message-ID: <4c4ba1530604050758o605909f9l9d9d8fb83e2a81bf@mail.gmail.com> My message stepped on Petr's more complete response. -- Tom London From fedora at wir-sind-cool.org Wed Apr 5 15:04:13 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 5 Apr 2006 17:04:13 +0200 Subject: Tripwire in Extras In-Reply-To: <20060405162651.A25673@xos037.xos.nl> References: <1144246308.3904.7.camel@localhost> <20060405162651.A25673@xos037.xos.nl> Message-ID: <20060405170413.6623a46b.fedora@wir-sind-cool.org> On Wed, 5 Apr 2006 16:26:51 +0200, Jos Vos wrote: > On Wed, Apr 05, 2006 at 07:11:48AM -0700, MJang wrote: > > > I see Tripwire has been removed from FC5 extras, but per > > http://fedoraproject.org/wiki/Extras/FC5Status , it's probably going to > > get a new maintainer soon. Will it be available in FC5 Extras after it > > gets the new maintainer, or will it go someplace else like > > Extras-Development? > > Shouldn't Tripwire be replaced by another package, that is the > successor of Tripwire? I don't remember its name, but (long ago) > I got the impression that Tripwire was not actively maintained > anymore and/or had some licensing issues and that there existed > a fork/successor of it. The successor/replacement is called "rpm -Va" plus SELinux. ;) No, seriously, other projects like AIDE (also in Fedora Extras as "aide") have not seen a lot of progress as to beat Tripwire by lengths. There's also the problem of prelinking, which confuses these integrity checkers and their users. From dax at gurulabs.com Wed Apr 5 15:12:20 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 05 Apr 2006 9:12:20 -0600 Subject: pilot-link.org: Anonymous CVS Removed indefinitely In-Reply-To: <1144246766.2789.31.camel@gilboa-work-dev> References: <1144246766.2789.31.camel@gilboa-work-dev> Message-ID: <7492-SnapperMsg827D11E1C0598EE1@[68.27.62.191]> ..... Original Message ....... On Wed, 05 Apr 2006 17:19:26 +0300 "Gilboa Davara" wrote: >I'm just posting this, so -please- don't shoot the messenger: >---------------------------------------------------------------------------- >Submitted by desrod on Mon, 03/27/2006 - 01:50. >Since the Fedora Linux distribution (always problems with Fedora, sigh) >has decided to ignore the FAT GLARING WARNING about NOT packaging up >pilot-link 0.12.x in their releases, I?ve taken anonymous CVS down >indefinitely, and hourly snapshots will also be removed. > >Those who wish to use the code, will have to wait until official >releases are made. > >Sorry, but this has happened way too often with Fedora (and previously >with the Red Hat packagers) to ignore time and time again. Their >ignorance has increased our maintenance headaches, and I?m frankly tired >of dealing with the support issues. >---------------------------------------------------------------------------- > >Problem is: pilot-link AND gnome-pilot are semi-broken on FC4 and >completely broken on FC5. FC5 pilot-link 0.128cvs works great for me and my Treo650. ___ Dax Kelson Sent with my Treo From gilboad at gmail.com Wed Apr 5 15:22:22 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 05 Apr 2006 18:22:22 +0300 Subject: pilot-link.org: Anonymous CVS Removed indefinitely In-Reply-To: <7492-SnapperMsg827D11E1C0598EE1@[68.27.62.191]> References: <1144246766.2789.31.camel@gilboa-work-dev> <7492-SnapperMsg827D11E1C0598EE1@[68.27.62.191]> Message-ID: <1144250542.2789.44.camel@gilboa-work-dev> On Wed, 2006-04-05 at 09:12 -0600, Dax Kelson wrote: > ..... Original Message ....... > On Wed, 05 Apr 2006 17:19:26 +0300 "Gilboa Davara" wrote: > >I'm just posting this, so -please- don't shoot the messenger: > >---------------------------------------------------------------------------- > >Submitted by desrod on Mon, 03/27/2006 - 01:50. > >Since the Fedora Linux distribution (always problems with Fedora, sigh) > >has decided to ignore the FAT GLARING WARNING about NOT packaging up > >pilot-link 0.12.x in their releases, I?ve taken anonymous CVS down > >indefinitely, and hourly snapshots will also be removed. > > > >Those who wish to use the code, will have to wait until official > >releases are made. > > > >Sorry, but this has happened way too often with Fedora (and previously > >with the Red Hat packagers) to ignore time and time again. Their > >ignorance has increased our maintenance headaches, and I?m frankly tired > >of dealing with the support issues. > >---------------------------------------------------------------------------- > > > >Problem is: pilot-link AND gnome-pilot are semi-broken on FC4 and > >completely broken on FC5. > > FC5 pilot-link 0.128cvs works great for me and my Treo650. > > ___ > Dax Kelson > Sent with my Treo Baah! Having pilot-link semi-working is far from being enough... I'd assume that most people need/require contact/calender integration with kmail/kpilot and/or evolution/gnome-pilot. Gilboa From pmatilai at laiskiainen.org Wed Apr 5 15:28:24 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 05 Apr 2006 18:28:24 +0300 Subject: Move Evolution to Extras? In-Reply-To: <4433BB16.6090706@math.unl.edu> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <4432C60C.2040504@hhs.nl> <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> <4433BB16.6090706@math.unl.edu> Message-ID: <4433E218.6030408@laiskiainen.org> Rex Dieter wrote: > Jeff Spaleta wrote: > >> Your logic also hits on another packaging policy limitation in Core >> which doesn't strongly delineate between hard requirements and >> optional functionality which depends on an additional package to be >> installed to be functional. > > AFAIK, the latest (or soon to be included in rawhide?) version of rpm > will support new tags: > Requires(hint): > and/or > Requires(missingok): > to allow for such soft requirements. Yup. Votes for getting a newer rpm version into rawhide sooner than later to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 ;) - Panu - From skvidal at linux.duke.edu Wed Apr 5 15:36:30 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Apr 2006 11:36:30 -0400 Subject: Move Evolution to Extras? In-Reply-To: <4433E218.6030408@laiskiainen.org> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <4432C60C.2040504@hhs.nl> <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> <4433BB16.6090706@math.unl.edu> <4433E218.6030408@laiskiainen.org> Message-ID: <1144251390.15925.63.camel@cutter> On Wed, 2006-04-05 at 18:28 +0300, Panu Matilainen wrote: > Rex Dieter wrote: > > Jeff Spaleta wrote: > > > >> Your logic also hits on another packaging policy limitation in Core > >> which doesn't strongly delineate between hard requirements and > >> optional functionality which depends on an additional package to be > >> installed to be functional. > > > > AFAIK, the latest (or soon to be included in rawhide?) version of rpm > > will support new tags: > > Requires(hint): > > and/or > > Requires(missingok): > > to allow for such soft requirements. > > Yup. Votes for getting a newer rpm version into rawhide sooner than > later to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 ;) If there is a decision to support this stuff it might be a good idea to make sure we're converging on the same mechanism that the opensuse folks are. -sv From pmatilai at laiskiainen.org Wed Apr 5 15:47:05 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 05 Apr 2006 18:47:05 +0300 Subject: Move Evolution to Extras? In-Reply-To: <1144251390.15925.63.camel@cutter> References: <1144154677.11377.105.camel@pmac.infradead.org> <604aa7910604040603j2292b9fbnf320280c8c2d641b@mail.gmail.com> <20060404182122.GA8284@rathann.pekin.waw.pl> <1144176462.18098.37.camel@ender> <4432C60C.2040504@hhs.nl> <604aa7910604042107g7a38b961o2395fe4d9d5ef648@mail.gmail.com> <4433BB16.6090706@math.unl.edu> <4433E218.6030408@laiskiainen.org> <1144251390.15925.63.camel@cutter> Message-ID: <4433E679.1000501@laiskiainen.org> seth vidal wrote: > On Wed, 2006-04-05 at 18:28 +0300, Panu Matilainen wrote: >> Rex Dieter wrote: >>> Jeff Spaleta wrote: >>> >>>> Your logic also hits on another packaging policy limitation in Core >>>> which doesn't strongly delineate between hard requirements and >>>> optional functionality which depends on an additional package to be >>>> installed to be functional. >>> AFAIK, the latest (or soon to be included in rawhide?) version of rpm >>> will support new tags: >>> Requires(hint): >>> and/or >>> Requires(missingok): >>> to allow for such soft requirements. >> Yup. Votes for getting a newer rpm version into rawhide sooner than >> later to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174307 ;) > > If there is a decision to support this stuff it might be a good idea to > make sure we're converging on the same mechanism that the opensuse folks > are. What is Opensuse using/doing then? Requires(hint) and Provides(hint) are just an rpm mechanism for allowing soft dependencies, anything beyond that is basically a policy question what to do about those in the depsolver. - Panu - From k.healy at student.ucc.ie Wed Apr 5 15:53:51 2006 From: k.healy at student.ucc.ie (k.healy at student.ucc.ie) Date: Wed, 05 Apr 2006 15:53:51 GMT Subject: Lock up after resume from S3 suspend when ide dma is enabled (FC5) Message-ID: <4433e80f.3c.5132.1315430907@student.ucc.ie> Hello, This follows on from a post on the fedora-list... https://www.redhat.com/archives/fedora-list/2006-April/msg00581.html Quick summary -- S3 suspend works, system resumes ok, then after about 20-60 secs it locks up completely. I've tracked this down to ide dma - booting the kernel with ide=nodma removes the problem. I appreciate this is is more than likely an upstream kernel issue, but hopefully people here could help me confirm this, and identify the problem in more detail, before taking things there. I assume this is somewhat hardware specific, since it doesn't seem to have been reported already. I've got a Samsung SP1614N (160GB) PATA disk, running off an nForce 2 chipset with integrated graphics (GF4MX). (Its a Soltek SL7-BA-F mainboard with an Athlon XP Barton CPU). Test case to reproduce on stock FC5 (both 2.6.15-1.2054 and 2.6.16-1.2080 kernels) 1. Reboot, and hit 'a' at the grub prompt to edit the kernel parameters 2. Add 'apm=off ide=nodma init=/bin/bash', and then boot (I'm not sure if the apm=off is really necessary) 3. Enter 'echo "mem" > /sys/power/state' ...system should suspend... 4. Wake system (At this point I have no video (see note below), so I have to type blind, and toggle the caps lock key to check the system is still responding) 5. Type some commands, toggle caps lock, wait a few mins. Confirm the system is still alive. 6. Repeat as above, but remove 'ide=nodma' from the kernel parameters, and confirm that the system locks up after a minute or two. (For me, with dma enabled, once I hit the power button to resume, the system disk activity LED also comes on and stays on indefinitely) Note on video --- Without the nvidia driver loaded, the video doesn't come back for me after a resume. I'm bypassing the loading of this, and pretty much everything else using the init=/bin/bash kernel parameter to give a minimal system to help isolate this issue. But just to confirm - using the Nvidia driver rpms from atrpms as described in the fedora-list post, the system suspends and resumes from X successfully. I'd appreciate it if anyone who has a Samsung PATA disk and/or an nForce 2 chipset could try out this test case.And any suggestions for getting more information on the lock-up would be helpful. There are some kernel messages showing up before it hangs, but they don't get written to the log because of the ide issues. I'm going to see if I can dump them to a usb flash drive. I've tried sysrq without success, but this is probably because the video is locked up. Maybe sysrq over a serial console - is this possible with the stock Fedora kernels? Even with DMA disabled, some ide error messages show up in the log...I don't know if they are significant or not ---------------------- hda: status error: status=0x51 { DriveReady SeekComplete Error } hda: status error: error=0x04 { DriveStatusError } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT hda: status error: status=0x51 { DriveReady SeekComplete Error } hda: status error: error=0x04 { DriveStatusError } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT done hda: status error: status=0x51 { DriveReady SeekComplete Error } hda: status error: error=0x04 { DriveStatusError } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT hda: status error: status=0x51 { DriveReady SeekComplete Error } hda: status error: error=0x04 { DriveStatusError } ide: failed opcode was: unknown hda: no DRQ after issuing MULTWRITE_EXT ide0: reset: success ---------------------- Regards, Ken From kevin.kofler at chello.at Wed Apr 5 16:05:39 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 5 Apr 2006 16:05:39 +0000 (UTC) Subject: [OT] Re: Move Evolution to Extras? References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> Message-ID: > KDE apps, including Kontact, force me to use the KDE look and feel, and > pretty much ignore the GNOME settings I am used to. So KDE is just as > well forcing _its_ model on you, just a different model. Well, if you use the good old Bluecurve theme (not Clearlooks which has no KDE equivalent) in both Qt/KDE and GTK+/GNOME, you'll have to look very closely to even notice the difference. It's good enough for me. (I run KDE, but GTK+ apps integrate very well with my desktop.) Kevin Kofler From kevin.kofler at chello.at Wed Apr 5 16:13:34 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 5 Apr 2006 16:13:34 +0000 (UTC) Subject: Move Evolution to Extras? References: <1144233606.9585.7.camel@coyote.rexursive.com> Message-ID: > And detachment is due to the fact that I chose not the receive messages from the list. So, I just "fake" the > replies (like this one I'm sending now from Evo You can use GMANE's web interface to post properly-threaded replies to Fedora mailing lists without being subscribed. It also avoids getting your non-subscriber mails trashed as spam. You only have to send one e-mail per list as a reply to a GMANE e-mail address verification, everything else goes through the web. Kevin Kofler From bernd.bartmann at gmail.com Wed Apr 5 16:16:16 2006 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Wed, 5 Apr 2006 18:16:16 +0200 Subject: Missing update announcements Message-ID: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> Now that FC5 final is out a problem seems to reappear that I thought was gone since FC4 came out: FC core updates appear on the download mirrors but some of them never get announced on fedora-announce-list. Since the release of FC5 the following announcments are missing: For FC4: anacron-2.3-36.FC4 dia-0.94-13.fc4 dovecot-0.99.14-8.fc4 For FC5: cairo-1.0.4-1 GConf2-2.14.0-1 xscreensaver-4.24-2 gnome-screensaver-2.14.0-1.fc5 liboil-0.3.8-1.fc5 newt-0.52.2-6 xterm-211-4.FC5 I've opened bugs for every missing announcements and tracker bugs to get an overview. For FC4 the tracker bug is #161106, for FC5 it is #188051. Can someone @fedora or @redhat please look into this issue. I thought the process was somehow automated since FC4 came out. It would be helpful to get an explanation about the internal process how updates are released. Thanks in advance, Bernd. From rdieter at math.unl.edu Wed Apr 5 16:19:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 11:19:44 -0500 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: References: <1144154677.11377.105.camel@pmac.infradead.org> <80d7e4090604041244n4a94e61br440651859c137bb0@mail.gmail.com> <53130.127.0.0.1.1144188147.squirrel@www.thecodergeek.com> <200604041614.06080.lamont@gurulabs.com> <53387.127.0.0.1.1144189352.squirrel@www.thecodergeek.com> <1144190457.11116.5.camel@shinybook.infradead.org> <1144192920.6347.130.camel@xpc.home.erwinrol.com> Message-ID: <4433EE20.9040807@math.unl.edu> Kevin Kofler wrote: > Well, if you use the good old Bluecurve theme (not Clearlooks which has no KDE > equivalent) IMO, Clearlooks is pretty close to KDE's Plastik. -- Rex From esr at thyrsus.com Tue Apr 4 15:16:40 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 4 Apr 2006 11:16:40 -0400 Subject: Fedora Art Team Now Open In-Reply-To: <4430AE40.3080108@redhat.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> Message-ID: <20060404151640.GD9219@thyrsus.com> Warren Togami : > Join the [fedora-art] team, figure out what the goals are and who is > interested to work on them, and we can have a community meeting on > IRC sometime soon to form some kind of organization. Your answer is good in principle. I have to be honest and admit that the crappy art is not a sufficiently high priority for me to put time into fixing this. The codecs issue is much, *much* more important. -- Eric S. Raymond From esr at thyrsus.com Tue Apr 4 15:05:59 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Tue, 4 Apr 2006 11:05:59 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <4430ACBA.9040204@redhat.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> Message-ID: <20060404150558.GA9219@thyrsus.com> Warren Togami : > Eric, you are completely divorced from reality if you truly think this > is safe and prudent. You are essentially asking Red Hat to become a > martyr and destroy itself. Would that really be good for the community? Negotiating an MP3 license with Fraunhofer (to give just one possible example) would not constitute self-destruction. > What you advocate will not win this war in the long-run. These are not > technical or community growth problems, but tough political and legal > issues that we cannot simply ignore because it would be convenient. Funny you should say that. "Ignore this issue" is exactly the response I seem to be seeing from most of the Fedora list. > The actions and resources Red Hat uses to fight software patents and > protect the future of FOSS is "corporate cowardice"? No, but refusing to carry MP3 decoders when there is no patent block on them is. Whether there is such a patent block or not has been disputed. I originally believed not, persons on this list have claimed there is, the person who made the "corporate cowardice" accusation says they're full of crap and suggests that I challenge them to produce a patent number. I think he's making an unrealistic demand -- but it is a fact that SUSe carries encoders. If SUSe can do it, why not Red Hat or Fedora? > Red Hat engages in substantive actions to fight software patents. > > Do you? Yes, as a matter of fact. I invented the basic logic of the reciprocal patent-termination clauses now used in several open-source licenses. And it's partly because of my jawboning that IBM opened up a patent pool. -- Eric S. Raymond From Axel.Thimm at ATrpms.net Wed Apr 5 16:35:21 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Apr 2006 18:35:21 +0200 Subject: : IA64 ISOs based on Fedora Core 5 In-Reply-To: <1144230285.6227.10.camel@pmac.infradead.org> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> Message-ID: <20060405163521.GS30438@neu.nirvana> On Wed, Apr 05, 2006 at 10:44:45AM +0100, David Woodhouse wrote: > On Tue, 2006-04-04 at 22:25 -0400, Paul Nasrat wrote: > > I assume for the weekly snapshots of rawhide that you'll be putting > > unique (eg date based) names on the isos so they can be readily > > identified, else you're going to run into trouble tracking issues > > across media sets. > > To be honest, I'm not convinced that weekly ISO builds are particularly > useful -- we don't do that for rawhide on other architectures either. > It's probably better just to encourage people to use rsync to keep up > with rawhide, rather than downloading it all over again each week. > > > Do these isos correspond with FC5 or a random snapshot? > > Rawhide for about a week leading up to March 20th was identical to FC5 > in all but the 'fedora-release' package. > > If making an IA64 'FC5' I'd be inclined to replace the fedora-release > package too. In fact, you almost certainly want to do that anyway, since > you'll be publishing the errata, and fedora-release contains the yum > configuration. That might be helpful: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187250 > Aside from the updates, the next task is building Extras and Livna for > IA64, of course... and who's going to do ATrpms? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jspaleta at gmail.com Wed Apr 5 16:38:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 12:38:19 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060404150558.GA9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> Message-ID: <604aa7910604050938u3c9edc54pd470d9dd090a6a23@mail.gmail.com> On 4/4/06, Eric S. Raymond wrote: > No, but refusing to carry MP3 decoders when there is no patent block > on them is. Why do you continue reiterating the assumption that there is no patent block on mp3 decoders? You have been repeatedly told that decoder royalties do in fact exist and you have publicly acknowledged that your original assertion they patent royalties on the decoders did not exist was a false assumption based on errenous information on your part. Please stop dragging the discussion backwards by bringing up the point about decoder patents that you know now to be false. I personally feel by resurrecting the issue of decoder patents..again... you are acting in bad faith in this discussion and are delibrately misleading people who still give your comments on these matters enough weight to not fact check what you are saying. Stop. -jef From vonbrand at inf.utfsm.cl Wed Apr 5 17:05:36 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 05 Apr 2006 13:05:36 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: Your message of "Tue, 04 Apr 2006 11:05:59 -0400." <20060404150558.GA9219@thyrsus.com> Message-ID: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> Eric S. Raymond wrote: > Warren Togami : > > Eric, you are completely divorced from reality if you truly think this > > is safe and prudent. You are essentially asking Red Hat to become a > > martyr and destroy itself. Would that really be good for the community? > Negotiating an MP3 license with Fraunhofer (to give just one possible > example) would not constitute self-destruction. How do you know it hasn't been tried? In any case, what info is out there on the matter clearly indicates the people in control of the license will /never/ agree on an open-source version, so the point is more than moot. > > What you advocate will not win this war in the long-run. These are not > > technical or community growth problems, but tough political and legal > > issues that we cannot simply ignore because it would be convenient. > Funny you should say that. "Ignore this issue" is exactly the response > I seem to be seeing from most of the Fedora list. The Fedora enthusiasts don't think that your current proposal has merit. So you'd better look elsewhere for people sharing your view and helping you implementing it. > > The actions and resources Red Hat uses to fight software patents and > > protect the future of FOSS is "corporate cowardice"? > No, but refusing to carry MP3 decoders when there is no patent block > on them is. Funny... seraching Google for 'mp3 patent' takes you directly to , and in the patents listed at least "Process for the detecting of errors in the transmission of frequency-coded digital signals" would seem to apply... > Whether there is such a patent block or not has been disputed. I > originally believed not, persons on this list have claimed there is, > the person who made the "corporate cowardice" accusation says they're > full of crap and suggests that I challenge them to produce a patent > number. I think he's making an unrealistic demand -- but it is a fact > that SUSe carries encoders. If SUSe can do it, why not Red Hat or > Fedora? Which SUSE? The paid one? No problem, they can pay for the codecs. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From paul at cypherpunks.ca Wed Apr 5 17:32:01 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 5 Apr 2006 19:32:01 +0200 (CEST) Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060404150558.GA9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> Message-ID: On Tue, 4 Apr 2006, Eric S. Raymond wrote: > number. I think he's making an unrealistic demand -- but it is a fact > that SUSe carries encoders. If SUSe can do it, why not Red Hat or > Fedora? Because SuSe is a German company, and Germany does not recognise software patents? And RedHat is an US based company, and the US is fucked up? What this discussion has done for me in the past two weeks is wondering if I should either just unsubscribe, or not read this list anymore. It is certainly not leading to anywhere. I just Eric discusses this with RedHat lawyers privately. And perhaps he can post a summary to the list in two weeks? Paul From jspaleta at gmail.com Wed Apr 5 17:33:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 13:33:08 -0400 Subject: Missing update announcements In-Reply-To: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> Message-ID: <604aa7910604051033s61f3d1d0q1b19bd45ea05f0ff@mail.gmail.com> On 4/5/06, Bernd Bartmann wrote: > For FC5: > cairo-1.0.4-1 > GConf2-2.14.0-1 > xscreensaver-4.24-2 > gnome-screensaver-2.14.0-1.fc5 > liboil-0.3.8-1.fc5 > newt-0.52.2-6 > xterm-211-4.FC5 fyi some of these have annoucements in test-list when they where introduced in updates-testing. This might indicate some brokenness associated with the process by which things are moved from -testing in to updates-released whereby the notification text isn't be reposted on the annouce-list like it should. Others are missing the testing annoucement as well which would indicate another sort of problem. -jef From ed at eh3.com Wed Apr 5 17:36:16 2006 From: ed at eh3.com (Ed Hill) Date: Wed, 05 Apr 2006 13:36:16 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060404150558.GA9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> Message-ID: <1144258576.8633.303.camel@ernie> On Tue, 2006-04-04 at 11:05 -0400, Eric S. Raymond wrote: > Warren Togami : > > The actions and resources Red Hat uses to fight software patents and > > protect the future of FOSS is "corporate cowardice"? > > No, but refusing to carry MP3 decoders when there is no patent block > on them is. > > Whether there is such a patent block or not has been disputed. I > originally believed not, persons on this list have claimed there is, > the person who made the "corporate cowardice" accusation says they're > full of crap and suggests that I challenge them to produce a patent > number. I think he's making an unrealistic demand -- but it is a fact > that SUSe carries encoders. If SUSe can do it, why not Red Hat or > Fedora? Hi Eric, Either there are valid (or likely to prove valid if challenged) patent claims or there aren't. If you don't know, then please get off your terminal and do some actual research (eg. schedule time with a credible patent attorney, ask the patent holders what license terms they would be willing to discuss, etc.) before making any claims. Without any substantial insight into the legal status and/or the licensing terms (and for you this seems to be the case), your musings on this topic are all noise and no signal. Ed ps - Yes, we're all certain that the lawyers at SuSE/Novell, Red Hat, and other Linux-distributing companies have reviewed the issue. You must also be aware that these companies do not owe you (or any other third parties) detailed explanations of their legal opinions and/or strategies. So, you really need to do (at least a little) research before challenging folks. -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From kevin.kofler at chello.at Wed Apr 5 17:36:03 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 5 Apr 2006 17:36:03 +0000 (UTC) Subject: pilot-link.org: Anonymous CVS Removed indefinitely References: <1144246766.2789.31.camel@gilboa-work-dev> Message-ID: So they expect you to package the obsolete September 2003 release? 0.12.x is now in "prerelease" state since January 2005 (!), when are they going to allow you to package it? Time for a fork? The maintainer himself says: "After almost 16 months of waiting, the first new version of pilot-link is now available for testing. The last version of pilot-link, 0.11.8, was released back in September of 2003. Its been a long time coming!", "The commandline tools are much more stable, the main library now supports many more devices and platforms, and code has been refactored and cleaned up in a LOT of places, and MANY other things have been added or removed." and "Many of us are already using 0.12.0-pre1 daily for our production use. It is very stable, and works well for most current devices that we?ve had the time and resources to test", which IMHO is reason enough to use the new code despite his "big fat warning". As for GUI tools not being compatible with the new code yet, how does he expect them to become compatible if they can't access the new code? Kevin Kofler From wtogami at redhat.com Wed Apr 5 17:39:00 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 05 Apr 2006 13:39:00 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060404150558.GA9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> Message-ID: <443400B4.2030706@redhat.com> Eric S. Raymond wrote: > Warren Togami : >> Eric, you are completely divorced from reality if you truly think this >> is safe and prudent. You are essentially asking Red Hat to become a >> martyr and destroy itself. Would that really be good for the community? > > Negotiating an MP3 license with Fraunhofer (to give just one possible > example) would not constitute self-destruction. > "Fedora distributes only 100% Free and Open Source Software. FOSS requires software to be freely modifiable and freely redistributable. Paying a royalty for Fedora to distribute something like MPEG for DVD capability would make it not Free, because that removes the ability for others to redistribute the software." You conveniently neglected to respond to this part. I wonder, why ESR the founder of the Open Source Initiative is advocating for willful violation and conflict with the GPL within America. > >> The actions and resources Red Hat uses to fight software patents and >> protect the future of FOSS is "corporate cowardice"? > > No, but refusing to carry MP3 decoders when there is no patent block > on them is. > Come back with a legally binding, written, perpetual, and irrevocable promise that Fraunhofer grants a royalty free license for FOSS to use MP3. Until then, insisting that Red Hat is a "coward" by not shipping MP3 is essentially asking Red Hat to be a martyr and risk destroying itself. You have a right to say or think anything you want, but nobody will listen if you are repeatedly irresponsible and unreasonable. Warren Togami wtogami at redhat.com From aph at redhat.com Wed Apr 5 17:39:08 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 5 Apr 2006 18:39:08 +0100 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> Message-ID: <17460.188.983178.409740@zapata.pink> Paul Wouters writes: > > What this discussion has done for me in the past two weeks is wondering > if I should either just unsubscribe, or not read this list anymore. It > is certainly not leading to anywhere. I agree. This is a serious issue: these discussions are severely reducing the usefulness of this mailing list for developers. There's nothing wrong with discussing this stuff, but we need another group for it. (Please, no "how to use a killfile" explanations. This legal / political stuff is off-topic.) Andrew. From Lam at Lam.pl Wed Apr 5 17:38:31 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 05 Apr 2006 19:38:31 +0200 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> References: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> Message-ID: <1144258711.2760.33.camel@pensja.lam.pl> Dnia 05-04-2006, ?ro o godzinie 13:05 -0400, Horst von Brand napisa?(a): > How do you know it hasn't been tried? In any case, what info is out there > on the matter clearly indicates the people in control of the license will > /never/ agree on an open-source version, so the point is more than moot. It doesn't have to be open-source, it simply has to be legal. Fluendo with gstreamer and Totem are perfectly legal (they paid Thomson the money), the only problem are GPL apps linked to gstreamer (linking at run-time with proprietary things, even via a stack of LGPL modules, violates the GPL). It IS the matter of distribution then. You can make a separate yum repository for perfectly legal MP3 gstreamer plugin (Fluendo will give you a licence for free and it's their responsibility for it to be legal - you're not making Fedora more prosecution-prone), only it has to conflict with Rhythmbox for example. It's still possible to make a program ESR was writing about (popup asks if you want to enable this plugin repository in your yum.repos.d/file, then tells you "in order to play this file you have to install XXX, but this will remove YYY from your system" - yum can tell it to you). The only problem I could see here would be some dependency specific to Fedora that would force the presence of some GPL-licensed and gst-enabled program in my system. This could probably be fixed somehow. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From alan at clueserver.org Wed Apr 5 17:57:53 2006 From: alan at clueserver.org (alan) Date: Wed, 5 Apr 2006 10:57:53 -0700 (PDT) Subject: Fedora Art Team Now Open In-Reply-To: <20060404151640.GD9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> <20060404151640.GD9219@thyrsus.com> Message-ID: On Tue, 4 Apr 2006, Eric S. Raymond wrote: > Warren Togami : >> Join the [fedora-art] team, figure out what the goals are and who is >> interested to work on them, and we can have a community meeting on >> IRC sometime soon to form some kind of organization. > > Your answer is good in principle. I have to be honest and admit that > the crappy art is not a sufficiently high priority for me to put time > into fixing this. > > The codecs issue is much, *much* more important. Both issues need to be resolved. Since the solutions are being solved by different groups of people, I don't see why there is an issue here. (Artists will not solve codec issues, just as programmers will not resolve crappy art issues.) -- "Remember there is a big difference between kneeling down and bending over." - Frank Zappa From casimiro.barreto at gmail.com Wed Apr 5 18:21:25 2006 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Wed, 05 Apr 2006 15:21:25 -0300 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <1144258711.2760.33.camel@pensja.lam.pl> References: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <1144258711.2760.33.camel@pensja.lam.pl> Message-ID: <44340AA5.9020001@gmail.com> Man... That conversation is just getting insane... What is legal in one country may be illegal in other countries and so on and so forth and we just come back to the 1960's (yeah, most of you had not been born). For those of you (including lawyers) who thinks that the Vietnam War was that war won by Rambo (aka Silvester Stallone) killing dozens (thousands) of "bad communist oriental people", I had some bad news: this discussion about "open software" dates from that time. In 46 years of discussion, we see again and again the same arguments. But the fact that remains is that nobody in the bloody hell of planet earth can make a patent out of an unrealized idea... I patent devices. I patent a device that decodes some code. I can't patent the code itself. I can't patent an idea... The code may, as far as I know, be "copyrighted" to the author who wrote it and he can sell it tho others. Like a book. If writers behave the same way, nothing would have been written since ... well ... perhaps the greeks some 400 years BC. It is obvious that every new code will have something "borrowed" from previous code. That is called evolution. I heard the same kind of discussion when network was at its beginings... Most of you were in the kindergarden. Oh... yeah... OSI will triumph against Ethernet because it is a set of completely free and openly defined protocols. Ethernet is closed, proprietary and evil defined. Hey... just take a look on SNMP and its evil peculiarities... while CMIS and CMIP is free... OSI handles much better industrial environments with lots of non-stochastic networks (field-bus/token-rings), the FTAM for interconection in industrial environments... Little of that survives today... What we see is Ethernet V4, SNMP V4/V6 and so on ans so forth... I heard the same kind of discussion when PCs started to be manufactured around the world... About patents held by IBM. Any of you believe that RPOC payed any royalty to IBM? I do much doubt... not to mention lots of latin american countries... I heard people saying (perhaps you were at high school) that *NUX would never go ahead because it was owned by Digital, that became Compaq, that became HP. And yes, there are people still issuing M$ and other vendors (Sun, Apple, etc) because the "original idea of Windows" belonged to Xerox Vista. To be issued, you just must be alive and someone else think you looked at him in strange way... Anyways, if this discussion about legal/illegal does not move to a forum focused in laws and litigation, I do think that it will be a dead end for all of us... Regards, Casimiro PS: sorry to be writting again, but it just ... off when you have to delete dozens of crazy messages. Leszek Matok escreveu: > Dnia 05-04-2006, ?ro o godzinie 13:05 -0400, Horst von Brand napisa?(a): > >> How do you know it hasn't been tried? In any case, what info is out there >> on the matter clearly indicates the people in control of the license will >> /never/ agree on an open-source version, so the point is more than moot. >> > It doesn't have to be open-source, it simply has to be legal. Fluendo > with gstreamer and Totem are perfectly legal (they paid Thomson the > money), the only problem are GPL apps linked to gstreamer (linking at > run-time with proprietary things, even via a stack of LGPL modules, > violates the GPL). It IS the matter of distribution then. You can make a > separate yum repository for perfectly legal MP3 gstreamer plugin > (Fluendo will give you a licence for free and it's their responsibility > for it to be legal - you're not making Fedora more prosecution-prone), > only it has to conflict with Rhythmbox for example. It's still possible > to make a program ESR was writing about (popup asks if you want to > enable this plugin repository in your yum.repos.d/file, then tells you > "in order to play this file you have to install XXX, but this will > remove YYY from your system" - yum can tell it to you). > > The only problem I could see here would be some dependency specific to > Fedora that would force the presence of some GPL-licensed and > gst-enabled program in my system. This could probably be fixed somehow. > > Lam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten at redhat.de Wed Apr 5 17:27:19 2006 From: karsten at redhat.de (Karsten Hopp) Date: Wed, 5 Apr 2006 19:27:19 +0200 Subject: rawhide report: 20060405 changes In-Reply-To: <1144247251.2789.34.camel@gilboa-work-dev> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> <1144247251.2789.34.camel@gilboa-work-dev> Message-ID: <20060405172719.GA23394@redhat.de> On Wed, Apr 05, 2006 at 05:27:31PM +0300, Gilboa Davara wrote: > On Wed, 2006-04-05 at 10:09 -0400, Build System wrote: > > > > vim-1:7.0c.000-1 > > ---------------- > > * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 > > - vim-7.0c BETA > > > > * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 > > - Rawhide build as vim, opposed to vim7 (prerelease) > > - conflict with older man-pages-{it,fr} packages > > - cleanup lang stuff > > > > * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 > > - make it coexist with vim-6 (temporarily) > > - new CVS snapshot > > Thanks! > vim-6.4 package dropped? > Yes. This is Rawhide, isn't it ? Vim-7 will be out in time for FC6, so this gives us time to fix some bugs. Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From cmadams at hiwaay.net Wed Apr 5 18:47:03 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Apr 2006 13:47:03 -0500 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <1144258711.2760.33.camel@pensja.lam.pl> References: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <1144258711.2760.33.camel@pensja.lam.pl> Message-ID: <20060405184702.GA545423@hiwaay.net> Once upon a time, Leszek Matok said: > It doesn't have to be open-source, it simply has to be legal. Wrong. A primary goal of Fedora is a fully Open Source distrobution. If you don't want an Open Source distrobution, then go somewhere else. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Wed Apr 5 18:50:30 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Apr 2006 13:50:30 -0500 Subject: Fedora Art Team Now Open In-Reply-To: <20060404151640.GD9219@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430AE40.3080108@redhat.com> <20060404151640.GD9219@thyrsus.com> Message-ID: <20060405185030.GB545423@hiwaay.net> Once upon a time, Eric S. Raymond said: > Your answer is good in principle. I have to be honest and admit that > the crappy art is not a sufficiently high priority for me to put time > into fixing this. > > The codecs issue is much, *much* more important. And what are you doing on the codecs that is taking up time? The issue there is resolved, unless you are getting a lawyer and talking to Fraunhofer (which of course only covers MP3, not WMA, Quicktime, etc.). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gilboad at gmail.com Wed Apr 5 18:57:37 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 5 Apr 2006 21:57:37 +0300 Subject: pilot-link.org: Anonymous CVS Removed indefinitely In-Reply-To: References: <1144246766.2789.31.camel@gilboa-work-dev> Message-ID: <9050516b0604051157l71f58a64l4dcbb02bfdbff84f@mail.gmail.com> On 4/5/06, Kevin Kofler wrote: > So they expect you to package the obsolete September 2003 release? 0.12.x is > now in "prerelease" state since January 2005 (!), when are they going to allow > you to package it? Time for a fork? > > The maintainer himself says: "After almost 16 months of waiting, the first new > version of pilot-link is now available for testing. The last version of > pilot-link, 0.11.8, was released back in September of 2003. Its been a long > time coming!", "The commandline tools are much more stable, the main library > now supports many more devices and platforms, and code has been refactored and > cleaned up in a LOT of places, and MANY other things have been added or > removed." and "Many of us are already using 0.12.0-pre1 daily for our > production use. It is very stable, and works well for most current devices that > we've had the time and resources to test", which IMHO is reason enough to use > the new code despite his "big fat warning". As for GUI tools not being > compatible with the new code yet, how does he expect them to become compatible > if they can't access the new code? > > Kevin Kofler > In general, yes. I can only speak in my behalf, but I expect Fedora to use the obsolete 0.11.8 simply because... it works. Having 0.12-test doesn't really help much, if both evolution and kmail palm integration is dead. By the sheer number of open bugs, It seems that I'm not alone. I'm not pointing fingers... I'm just asking Fedora maintainers to reconsider the decision to use 0.12 considering the CVS lock. Gilboa From smooge at gmail.com Wed Apr 5 19:00:59 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 5 Apr 2006 13:00:59 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144233606.9585.7.camel@coyote.rexursive.com> References: <1144233606.9585.7.camel@coyote.rexursive.com> Message-ID: <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> On 4/5/06, Bojan Smojver wrote: > > information to public fora; especially busy mailing lists like this one. > > Whoa! Attack of the mailing list police ;-) > You have no idea. I think dwmw2 knows the RFC's, proposed RFC's, and accepted practices according to xyz authority better than the authors. And he can quote every place they went wrong too. -- Stephen J Smoogen. CSIRT/Linux System Administrator From shane at geeklords.org Wed Apr 5 19:12:48 2006 From: shane at geeklords.org (Shane Stixrud) Date: Wed, 5 Apr 2006 12:12:48 -0700 (PDT) Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: <604aa7910604050547id296213r5b3c7e8c4aee134b@mail.gmail.com> References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <44337D5B.5090603@3di.it> <604aa7910604050547id296213r5b3c7e8c4aee134b@mail.gmail.com> Message-ID: On Wed, 5 Apr 2006, Jeff Spaleta wrote: > > A useful cmdline tool to interact with dbus would go a long long way. > Something for dbus which is at least as functional a tool as gconftool > is for gconf. I am curious what type of interactions do you for-see admins performing with dbus? I am not that familiar with dbus but it sounds interesting, it is unclear to me how an admin would use it though. Cheers, Shane From dwmw2 at infradead.org Wed Apr 5 19:30:13 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 20:30:13 +0100 Subject: : IA64 ISOs based on Fedora Core 5 In-Reply-To: <20060405163521.GS30438@neu.nirvana> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> <20060405163521.GS30438@neu.nirvana> Message-ID: <1144265413.6227.93.camel@pmac.infradead.org> On Wed, 2006-04-05 at 18:35 +0200, Axel Thimm wrote: > > Aside from the updates, the next task is building Extras and Livna > > for IA64, of course... > > and who's going to do ATrpms? ;) ATrpms hasn't even caught up with the platform support we had in the final release of FC4 yet -- I don't think there's any need to worry about building for IA64 for now. -- dwmw2 From avi at unix.sh Wed Apr 5 19:36:06 2006 From: avi at unix.sh (Avi Alkalay) Date: Wed, 5 Apr 2006 16:36:06 -0300 Subject: Improving fonts on Fedora Message-ID: This HOWTO shows how to improve font rendering quality on the screen: http://www.tldp.org/HOWTO/Font-HOWTO/ Throughout the document, you'll see it pointing to some RPMs, that are located here: http://avi.alkalay.net/software/freetype.bci/FC5/ http://avi.alkalay.net/software/webcore-fonts Regards, Avi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Wed Apr 5 19:42:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 15:42:58 -0400 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <44337D5B.5090603@3di.it> <604aa7910604050547id296213r5b3c7e8c4aee134b@mail.gmail.com> Message-ID: <604aa7910604051242h12fd144ag49df145b875a5456@mail.gmail.com> On 4/5/06, Shane Stixrud wrote: > On Wed, 5 Apr 2006, Jeff Spaleta wrote: > > > > > A useful cmdline tool to interact with dbus would go a long long way. > > Something for dbus which is at least as functional a tool as gconftool > > is for gconf. > > I am curious what type of interactions do you for-see admins performing > with dbus? I am not that familiar with dbus but it sounds interesting, it > is unclear to me how an admin would use it though. How exactly do i answer that if you aren't familiar with dbus? I suggest you look at oddjob in Extras, which lets you define simple dbus clients that wrap common admin actions so that you can communicate over dbus to fire off those actions. I think if you are able to understand how to use oddjob then you will understand why I think having a cmdline tools which allows for instrospection over the bus would be invaluable to help admins learn how to use dbus communication effectively. oddjob is the first software implementation that I've seen that attempts to harness the power of dbus communications as a tool for sysadmin tasks instead of streamlining the desktop user oriented experience at the application level. Introspection isn't so important when dbus as a sort of back-channel for application-to-application communication... but its definitely much more important when dbus is exposed directly as a tool to help sysadmin's better organize the janitorial crap they have to do locally on their systems. -jef From dwmw2 at infradead.org Wed Apr 5 19:57:33 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 20:57:33 +0100 Subject: Move Evolution to Extras? In-Reply-To: <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> Message-ID: <1144267053.6227.107.camel@pmac.infradead.org> On Wed, 2006-04-05 at 13:00 -0600, Stephen J. Smoogen wrote: > You have no idea. I think dwmw2 knows the RFC's, proposed RFC's, and > accepted practices according to xyz authority better than the authors. > And he can quote every place they went wrong too. Hehe. I explained the problem -- which he may not have noticed, although I'm not entirely sure how that could be the case since his mail isn't part of the thread to which he was replying. I asked, nicely, if he could possibly try to fix it. Quite why he thought that was an 'attack of the mailing list police' I don't know. If this _was_ one of the mailing lists that I police, then the offending mail wouldn't have got through in the first place -- I filter and reject for that. Smooge, you no longer work in an environment where it's mandatory to react harshly and negatively to simple technical requests -- I _know_ you're only doing it for fun and for old times' sake now :) -- dwmw2 From nicolas.mailhot at laposte.net Wed Apr 5 19:59:17 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Apr 2006 21:59:17 +0200 Subject: Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management) In-Reply-To: References: <604aa7910603281442g219074d1m1f82acd0a86d3463@mail.gmail.com> <20060404133227.GA24256@redhat.com> <1144164052.31422.21.camel@daxter.boston.redhat.com> <10241.192.54.193.25.1144167074.squirrel@rousalka.dyndns.org> <1144167913.31422.55.camel@daxter.boston.redhat.com> <20060404173157.GF14317@ti64.telemetry-investments.com> <1144173615.31422.80.camel@daxter.boston.redhat.com> <1144174760.6489.14.camel@rousalka.dyndns.org> <1144175781.31422.102.camel@daxter.boston.redhat.com> <44337D5B.5090603@3di.it> <604aa7910604050547id296213r5b3c7e8c4aee134b@mail.gmail.com> Message-ID: <1144267165.17861.12.camel@rousalka.dyndns.org> Le mercredi 05 avril 2006 ? 12:12 -0700, Shane Stixrud a ?crit : > On Wed, 5 Apr 2006, Jeff Spaleta wrote: > > A useful cmdline tool to interact with dbus would go a long long way. > > Something for dbus which is at least as functional a tool as gconftool > > is for gconf. > > I am curious what type of interactions do you for-see admins performing > with dbus? I am not that familiar with dbus but it sounds interesting, it > is unclear to me how an admin would use it though. Components expose actions via dbus -> obvious sysadmin scripting target Components expose events via dbus -> you could write triggers (instead of polling cron jobs), logging/supervision scripts. Plugging nagios on d-bus might be interesting Of course if the perfect GUI admin app existed there would be no need for manual sysadmin action, but if systems didn't have to be cobbled together all the time there would be little need of administering in the first place. -- Nicolas Mailhot Positive attitude -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Wed Apr 5 19:59:38 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Apr 2006 21:59:38 +0200 Subject: : IA64 ISOs based on Fedora Core 5 In-Reply-To: <1144265413.6227.93.camel@pmac.infradead.org> References: <44332325.8050207@sgi.com> <1144203943.12268.17.camel@enki.eridu> <1144230285.6227.10.camel@pmac.infradead.org> <20060405163521.GS30438@neu.nirvana> <1144265413.6227.93.camel@pmac.infradead.org> Message-ID: <20060405195938.GA21733@neu.nirvana> On Wed, Apr 05, 2006 at 08:30:13PM +0100, David Woodhouse wrote: > On Wed, 2006-04-05 at 18:35 +0200, Axel Thimm wrote: > > > Aside from the updates, the next task is building Extras and Livna > > > for IA64, of course... > > > > and who's going to do ATrpms? ;) > > ATrpms hasn't even caught up with the platform support we had in the > final release of FC4 yet -- I don't think there's any need to worry > about building for IA64 for now. While the above was more of a joke, I do have access to an Altix, but unfortunately no ppc. Some scientific apps at ATrpms might soon see ia64 rpm archs. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From mchristi at redhat.com Thu Apr 6 08:29:56 2006 From: mchristi at redhat.com (Mike Christie) Date: Thu, 06 Apr 2006 03:29:56 -0500 Subject: how do I integrate patches and get updated rpms to users Message-ID: <4434D184.1070807@redhat.com> Hi, sorry of this is the wrong list. Maybe it should go to the maintiner list but I am not yet on that. I packaged the iscsi-initiator-utils rpm and have some fixes I need to integrate. I think I know how to update cvs and the spec file and that stuff from this doc http://fedora.redhat.com/docs/developers-guide/ But how does the update get propagated to the user so when they do a yum command they get the newest version? Do I have to send mail to someone or another list or does someone watch the cvs commits or is there some magic in the build system? And one other question about updating packages. Should I assume someone will be running the current kernel? If a new kernel is released and it lets say a sysfs file is removed or has some new behavior or the netlink interface has changed, should I build in the userspace application (in this case iscsid and iscsiadm) the ability to support all Fedora kernels or just the current one? Thanks From esr at thyrsus.com Wed Apr 5 21:06:45 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 17:06:45 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <604aa7910604050938u3c9edc54pd470d9dd090a6a23@mail.gmail.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> <604aa7910604050938u3c9edc54pd470d9dd090a6a23@mail.gmail.com> Message-ID: <20060405210645.GA16936@thyrsus.com> Jeff Spaleta : > On 4/4/06, Eric S. Raymond wrote: > > No, but refusing to carry MP3 decoders when there is no patent block > > on them is. > > Why do you continue reiterating the assumption that there is no patent > block on mp3 decoders? I have not in fact made that assertion. I don't regard the question as being factually settled one way or the other. What I know atthis point is that Fraunhofer has a royalty schedule for decoders. I don't know if there's an actual patent behind that. My informant has expressed skepticism; I anm simply in fact-finding mode. -- Eric S. Raymond From wtogami at redhat.com Wed Apr 5 21:10:39 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 05 Apr 2006 17:10:39 -0400 Subject: how do I integrate patches and get updated rpms to users In-Reply-To: <4434D184.1070807@redhat.com> References: <4434D184.1070807@redhat.com> Message-ID: <4434324F.7020407@redhat.com> Mike Christie wrote: > Hi, sorry of this is the wrong list. Maybe it should go to the maintiner > list but I am not yet on that. > > I packaged the iscsi-initiator-utils rpm and have some fixes I need to > integrate. I think I know how to update cvs and the spec file and that > stuff from this doc > http://fedora.redhat.com/docs/developers-guide/ This guide is very old and does not reflect how the Fedora Project works. It sounds like you are confused by this document. > > But how does the update get propagated to the user so when they do a yum > command they get the newest version? Do I have to send mail to someone > or another list or does someone watch the cvs commits or is there some > magic in the build system? iscsi-initiator-utils is neither in Core nor Extras currently. You probably want to get it into Fedora Extras first for FC5 support. http://fedoraproject.org/wiki/Extras Here is all information related to the Fedora Extras project. You need to submit your package to the package review process then request an account for cvsextras access. > > And one other question about updating packages. Should I assume someone > will be running the current kernel? If a new kernel is released and it > lets say a sysfs file is removed or has some new behavior or the netlink > interface has changed, should I build in the userspace application (in > this case iscsid and iscsiadm) the ability to support all Fedora kernels > or just the current one? > You should try your best to maintain compatibility within a Fedora release, but that is not always possible because Fedora releases typically follow the latest upstream kernel version. When things break in that fashion, then you should follow the latest upstream kernel interfaces. Only *attempt* to provide backwards compatibility if it wont make the software too ugly and full of cruft that will remain there forever, poorly tested and unused. Warren Togami wtogami at redhat.com From esr at thyrsus.com Wed Apr 5 21:22:15 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 17:22:15 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <443400B4.2030706@redhat.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> <443400B4.2030706@redhat.com> Message-ID: <20060405212215.GC16936@thyrsus.com> Warren Togami : > Come back with a legally binding, written, perpetual, and irrevocable > promise that Fraunhofer grants a royalty free license for FOSS to use > MP3. Until then, insisting that Red Hat is a "coward" by not shipping > MP3 is essentially asking Red Hat to be a martyr and risk destroying itself. This is out of hand. First, I never made that accusation. I reported someone else making it and said I wished I had a better defense against it. Second, it isn't my job to negotiate agreements with Fraunhofer. That job belongs to an organization like Red Hat that has lawyers and money and can make a business judgement about cost versus expected gain in market share. Third, negotiating an agreement with Fraunhofer would not consutute martyrdom. What is it with the zeolots on this list, anyway? No contact with reality at *all*... -- Eric S. Raymond From warren at togami.com Wed Apr 5 21:21:41 2006 From: warren at togami.com (Warren Togami) Date: Wed, 05 Apr 2006 17:21:41 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405212215.GC16936@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> <443400B4.2030706@redhat.com> <20060405212215.GC16936@thyrsus.com> Message-ID: <443434E5.3@togami.com> Eric S. Raymond wrote: > > Second, it isn't my job to negotiate agreements with Fraunhofer. That > job belongs to an organization like Red Hat that has lawyers and money > and can make a business judgement about cost versus expected gain in > market share. > > Third, negotiating an agreement with Fraunhofer would not consutute martyrdom. "Fedora distributes only 100% Free and Open Source Software. FOSS requires software to be freely modifiable and freely redistributable. Paying a royalty for Fedora to distribute something like MPEG for DVD capability would make it not Free, because that removes the ability for others to redistribute the software." You again conveniently neglected to respond to this part. Making a deal or paying royalties is simply not an option for the Fedora Project because it violates the central tenets of FOSS, and conflicts with the GPL. Warren Togami wtogami at redhat.com From esr at thyrsus.com Wed Apr 5 21:16:22 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 17:16:22 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> Message-ID: <20060405211622.GB16936@thyrsus.com> Horst von Brand : > Which SUSE? The paid one? No problem, they can pay for the codecs. Which, I'm suggesting, Red Hat could do also. I don't undesstand why this is a difficult concept. -- Eric S. Raymond From bdpepple at ameritech.net Wed Apr 5 21:41:43 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 05 Apr 2006 17:41:43 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405211622.GB16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> Message-ID: <1144273303.3647.3.camel@shuttle.piedmont.com> On Wed, 2006-04-05 at 17:16 -0400, Eric S. Raymond wrote: > Horst von Brand : > > Which SUSE? The paid one? No problem, they can pay for the codecs. > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > is a difficult concept. As Warren has stated numerous times, this won't happen since Fedora will only distribute 100% Free and Open Source Software. /B -- Brian Pepple 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: 191 bytes Desc: This is a digitally signed message part URL: From pmatilai at laiskiainen.org Wed Apr 5 21:42:44 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 06 Apr 2006 00:42:44 +0300 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405211622.GB16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> Message-ID: <1144273370.15501.32.camel@dhcppc0> On Wed, 2006-04-05 at 17:16 -0400, Eric S. Raymond wrote: > Horst von Brand : > > Which SUSE? The paid one? No problem, they can pay for the codecs. > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > is a difficult concept. I don't understand why it's so difficult to understand that such deals are against Fedora's main objectives as has been stated in this thread over and over and over and over again. - Panu - From fedora at adslpipe.co.uk Wed Apr 5 21:42:49 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 05 Apr 2006 22:42:49 +0100 Subject: Today's rawhide xorg/radeon Message-ID: <443439D9.70706@adslpipe.co.uk> Since the release of FC5 I've only been keeping up with updates + updates-testing, until I noticed that rawhide today had xorg/ati updates So duly installed and restarted X xorg-x11-drv-ati-6.5.7.3-4.cvs20060404 xorg-x11-server-1.0.99.2-1 With rawhide during the FC5T1/T2/T3 period (before the removal of r300 acceleration from FC5) I never had *any* 3D joy with the opensource drivers on my X550, they didn't even give me fallback mesa software GL Am I right in assuming that these drivers contain the recent r300 patches that Dave refers to? http://airlied.livejournal.com/24874.html I do get some progress, for the first time on this box opensource drivers don't produce errors with glxinfo/glxgears I get display: :0.0 screen: 0 OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.5) The GL xscreensavers run, but the (lack of) speed and high CPU usage lead me to think that I'm not getting h/w 3D, but at least I am now getting s/w fallback :-) I am loading DRI/DRM modules in xorg.conf in /var/log/Xorg.0.log I see drm errors for cards 0 to 254 (which I think I've always seen) drmOpenDevice: node name is /dev/dri/card254 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed followed by (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM which I think is new to this update I also see (EE) AIGLX: Screen 0 is not DRI capable (II) Loading local sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/lib64/xorg/modules/extensions/libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.2 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 It seems harsh to log this progress as a bugzilla entry, so just asking here first, should I "expect" any more than this at this stage of development? From esr at thyrsus.com Wed Apr 5 21:51:36 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 17:51:36 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <1144273303.3647.3.camel@shuttle.piedmont.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> Message-ID: <20060405215136.GG16936@thyrsus.com> Brian Pepple : > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > > is a difficult concept. > > As Warren has stated numerous times, this won't happen since Fedora will > only distribute 100% Free and Open Source Software. Are we having trouble distinguishing between "Red Hat" and "Fedora", then? -- Eric S. Raymond From dwmw2 at infradead.org Wed Apr 5 21:50:09 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Apr 2006 22:50:09 +0100 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405215136.GG16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> <20060405215136.GG16936@thyrsus.com> Message-ID: <1144273809.11116.14.camel@shinybook.infradead.org> On Wed, 2006-04-05 at 17:51 -0400, Eric S. Raymond wrote: > Are we having trouble distinguishing between "Red Hat" and "Fedora", > then? This is a Fedora list. -- dwmw2 From jspaleta at gmail.com Wed Apr 5 21:50:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 5 Apr 2006 17:50:16 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405215136.GG16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> <20060405215136.GG16936@thyrsus.com> Message-ID: <604aa7910604051450k5b397161v188112f3389fd31b@mail.gmail.com> On 4/5/06, Eric S. Raymond wrote: > Are we having trouble distinguishing between "Red Hat" and "Fedora", then? You seem to be. -jef From bdpepple at ameritech.net Wed Apr 5 22:02:55 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 05 Apr 2006 18:02:55 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405215136.GG16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> <20060405215136.GG16936@thyrsus.com> Message-ID: <1144274575.5626.2.camel@shuttle.piedmont.com> On Wed, 2006-04-05 at 17:51 -0400, Eric S. Raymond wrote: > Brian Pepple : > > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > > > is a difficult concept. > > > > As Warren has stated numerous times, this won't happen since Fedora will > > only distribute 100% Free and Open Source Software. > > Are we having trouble distinguishing between "Red Hat" and "Fedora", then? Not at all. Just look at the list this is on. ;) /B -- Brian Pepple 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: 191 bytes Desc: This is a digitally signed message part URL: From esr at thyrsus.com Wed Apr 5 22:15:29 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 18:15:29 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <1144274575.5626.2.camel@shuttle.piedmont.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> <20060405215136.GG16936@thyrsus.com> <1144274575.5626.2.camel@shuttle.piedmont.com> Message-ID: <20060405221529.GK16936@thyrsus.com> Brian Pepple : > > Are we having trouble distinguishing between "Red Hat" and "Fedora", then? > > Not at all. Just look at the list this is on. ;) Michael Tiemann encouraged me to "engage the Fedora community directly". I think this may have been a mistake. -- Eric S. Raymond From fedora at adslpipe.co.uk Wed Apr 5 22:12:10 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 05 Apr 2006 23:12:10 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <443439D9.70706@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk> Message-ID: <443440BA.50103@adslpipe.co.uk> Andy Burns wrote: > should I "expect" any more than this at this stage of > development? Just had a thought, do these xorg updates need a newer kernel than 2080_FC5? From seanlkml at sympatico.ca Wed Apr 5 22:08:59 2006 From: seanlkml at sympatico.ca (sean) Date: Wed, 5 Apr 2006 18:08:59 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405212215.GC16936@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> <443400B4.2030706@redhat.com> <20060405212215.GC16936@thyrsus.com> Message-ID: On Wed, 5 Apr 2006 17:22:15 -0400 "Eric S. Raymond" wrote: > What is it with the zeolots on this list, anyway? No contact with reality > at *all*... Quotation from the official ESR dictionary: zeal?ot n. Anyone who disagrees or has priorities that conflict with dictionary author. S. From orion at cora.nwra.com Wed Apr 5 22:17:30 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 05 Apr 2006 16:17:30 -0600 Subject: Vim-7 Preview - /usr/share/vim/vim70c question In-Reply-To: <20060405102406.GC16469@redhat.de> References: <4419531C.3070803@redhat.de> <1144233983.2789.13.camel@gilboa-work-dev> <20060405102406.GC16469@redhat.de> Message-ID: Karsten Hopp wrote: > > vim-7.0c BETA should be in today's Rawhide for all archs. > > Karsten Is there any way to install system-wide vim version independent syntax and indent .vim files? My cmake package in extras currently drops them in /usr/share/vim/vim64/syntax and indent and will need to be updated to vim70c (and others in the future). Is there some way to avoid this? - Orion From vikasx.aggarwal at intel.com Wed Apr 5 22:26:43 2006 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Wed, 5 Apr 2006 15:26:43 -0700 Subject: updating stage2.img Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A082299F4@orsmsx408> Hi, I am trying to insert a utility into stage2.img for FC5-test3, this utility will be run by slightly modified anaconda installer (version 10.12.14). So far I could not get my utility inside stage2.img. 1) I tried it doing manually but "buildinstall' will replace it. 2) If I try to update stage2.img manually after running buildinstalll, then NFS boot from boot.iso complains that install-tree does'nt match. Timestamp changed ? 3) Adding my utility in upd-instroot script should make it available in stage2.img, I tried but add to my frustration its not there when I boot from install disk1. Please provide me with the procedure for building the custom distro for fc5, I need to insert a tool into stage2.img and installer will run that utility. Appreciate your help in this Thanks -vikas aggarwal -------------- next part -------------- An HTML attachment was scrubbed... URL: From camilo at mesias.co.uk Wed Apr 5 22:48:03 2006 From: camilo at mesias.co.uk (Cam) Date: Wed, 05 Apr 2006 23:48:03 +0100 Subject: "expected gains in market share" Message-ID: <44344923.7070805@mesias.co.uk> Eric, Do you really think that a substantial population of adopters are ready and waiting but held back because mp3 isn't in Fedora? I think that's nonsense. If you rank potential users by ability, the vast majority will not use Fedora because they can't buy a machine with it pre-installed; others will not use Fedora because they aren't confident about partitioning disks or shrinking NTFS partitions. I'm not aware of any vendor that ships Fedora (and IMHO it's not likely as a vendor would chose something which would be supported for longer than a given Fedora release). Given that other users will have to follow technical instructions to burn CDs or perform a network install, they will have a level of ability where they are more than capable of getting mp3 support through the established methods. I think there are better goals that would increase adoption: 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials and demos with video showing features 2. technical improvements: provide email notification through thunderbird; provide desktop integration for firefox; any other workflow related improvements 3. better documentation from a user's perspective - how to do task X instead of how to use 'Banshee' (or any other obscurely named app) 4. bling, because people will make the effort to see it, even if it's not a productivity enhancement; it also gets you noticed in print. As a bleeding edge distro Fedora is well placed to make the most of this. I think any of the above would do more to increase adoption than merely including mp3 support. -Cam -- <-- camilo at mesias.co.uk From jkeating at j2solutions.net Wed Apr 5 22:47:16 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 5 Apr 2006 18:47:16 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405221529.GK16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <1144274575.5626.2.camel@shuttle.piedmont.com> <20060405221529.GK16936@thyrsus.com> Message-ID: <200604051847.16256.jkeating@j2solutions.net> On Wednesday 05 April 2006 18:15, Eric S. Raymond wrote: > Michael Tiemann encouraged me to "engage the Fedora community directly". > I think this may have been a mistake. Why? Because the community at large doesn't agree with your views? Boohoo, that's life. Fedora doesn't want to do what you think it should. Too bad. If that is the limit of what you have to offer, well then there are other projects down the road which may do what you want. More power to them (and you). You asked if we could do something, we said no. We listed why, you just didn't read it or agree to it. I'm sorry. The project being right does not require you to agree with it. I'm sorry your feelers are hurt, but instead of whining about it, either find a venue for your thoughts and desires, or come up with something that is aligned with the goals of the Fedora Project. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From alan at clueserver.org Wed Apr 5 22:57:24 2006 From: alan at clueserver.org (alan) Date: Wed, 5 Apr 2006 15:57:24 -0700 (PDT) Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405211622.GB16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> Message-ID: On Wed, 5 Apr 2006, Eric S. Raymond wrote: > Horst von Brand : >> Which SUSE? The paid one? No problem, they can pay for the codecs. > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > is a difficult concept. "Once you pay Danegeld, you never get rid of the Dane." -- "Remember there is a big difference between kneeling down and bending over." - Frank Zappa From michael at knox.net.nz Wed Apr 5 23:00:31 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Apr 2006 11:00:31 +1200 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405211622.GB16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> Message-ID: <44344C0F.2030507@knox.net.nz> Eric S. Raymond wrote: > Horst von Brand : >> Which SUSE? The paid one? No problem, they can pay for the codecs. > > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > is a difficult concept. So a RedHat Pro desktop solution? I would buy it. Save the hassle of setting up the stuff that I need. Michael (note: read RedHat, not Fedora) From jkeating at redhat.com Wed Apr 5 23:05:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Apr 2006 19:05:28 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <44344C0F.2030507@knox.net.nz> References: <20060404150558.GA9219@thyrsus.com> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> Message-ID: <200604051905.28725.jkeating@redhat.com> On Wednesday 05 April 2006 19:00, Michael J. Knox wrote: > So a RedHat Pro desktop solution? > > I would buy it. Save the hassle of setting up the stuff that I need. > > Michael > > (note: read RedHat, not Fedora) Why not 'Joe's Pro Linux'? Strip all the "redhat" "Red Hat" "Fedora" whatevers from the sources, add your wizbang stuff, release it. Nothing stops you from doing this. This is how things like CentOS exist. It just won't be called Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jdesbonnet at gmail.com Wed Apr 5 23:12:58 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 6 Apr 2006 00:12:58 +0100 Subject: "expected gains in market share" In-Reply-To: <44344923.7070805@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> Message-ID: <1cef3e950604051612l48a4e7a2l4cf6e9e1137eb22c@mail.gmail.com> I find screen recordings a very helpful teaching aid when dealing with novice users. And they are very easy to make (given the right software). What's the state of the art in screen recording in Linux nowadays? I can only find tools like vnc2swf which do not handle audio directly. Nothing like Macromedia Captivate seems to exist. Joe. On 4/5/06, Cam wrote: > 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials > and demos with video showing features From michael at knox.net.nz Wed Apr 5 23:17:33 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Apr 2006 11:17:33 +1200 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <200604051905.28725.jkeating@redhat.com> References: <20060404150558.GA9219@thyrsus.com> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> <200604051905.28725.jkeating@redhat.com> Message-ID: <4434500D.90307@knox.net.nz> Jesse Keating wrote: > On Wednesday 05 April 2006 19:00, Michael J. Knox wrote: >> So a RedHat Pro desktop solution? >> >> I would buy it. Save the hassle of setting up the stuff that I need. >> >> Michael >> >> (note: read RedHat, not Fedora) > > Why not 'Joe's Pro Linux'? Strip all the "redhat" "Red Hat" "Fedora" > whatevers from the sources, add your wizbang stuff, release it. Nothing > stops you from doing this. This is how things like CentOS exist. It just > won't be called Fedora. > Of course. I agree with you there too. Just trying to say, that both sides have merit. A RedHat Pro? Sure, works for me, Fedora Core 100% free? Works for me too. However, I do feel this thread is out living its usefulness and breeding discontent. Michael From esr at thyrsus.com Wed Apr 5 23:27:03 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 19:27:03 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <44344C0F.2030507@knox.net.nz> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> Message-ID: <20060405232702.GD17814@thyrsus.com> Michael J. Knox : > Eric S. Raymond wrote: > >Horst von Brand : > >>Which SUSE? The paid one? No problem, they can pay for the codecs. > > > >Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > >is a difficult concept. > > So a RedHat Pro desktop solution? > > I would buy it. Save the hassle of setting up the stuff that I need. It was one of my early suggestions in this discussion. Later I tried to develop the idea of third-party yum repositories to carry "impure" stuff. -- Eric S. Raymond From a.kurtz at hardsun.net Wed Apr 5 23:17:53 2006 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Wed, 05 Apr 2006 16:17:53 -0700 Subject: "expected gains in market share" In-Reply-To: <1cef3e950604051612l48a4e7a2l4cf6e9e1137eb22c@mail.gmail.com> References: <44344923.7070805@mesias.co.uk> <1cef3e950604051612l48a4e7a2l4cf6e9e1137eb22c@mail.gmail.com> Message-ID: <44345021.9030609@hardsun.net> Joe Desbonnet wrote: > I find screen recordings a very helpful teaching aid when dealing with > novice users. And they are very easy to make (given the right > software). > > What's the state of the art in screen recording in Linux nowadays? I > can only find tools like vnc2swf which do not handle audio directly. > Nothing like Macromedia Captivate seems to exist. > > Joe. > > On 4/5/06, Cam wrote: > >> 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials >> and demos with video showing features >> Try byzanz for animated GIFs or istanbul for Theora videos, both in FC5. http://fedoraproject.org/wiki/ScreenCasting has more information, such as how to add audio and a link to VMware video conversion instructions. -- Aaron Kurtz GPG Key ID: ED588CF2 From esr at thyrsus.com Wed Apr 5 23:32:40 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 19:32:40 -0400 Subject: "expected gains in market share" In-Reply-To: <44344923.7070805@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> Message-ID: <20060405233240.GE17814@thyrsus.com> Cam : > Do you really think that a substantial population of adopters are ready > and waiting but held back because mp3 isn't in Fedora? I think there is a very large population of potential users who would consider lack of MP3 and other multimedia playback a showstopper -- that it's one of the checklist features nontechnical users look for in 2006. > I think there are better goals that would increase adoption: I have no argument with any of those goals. Whether they're "better" in terms of being more effective at raising market share, I dunno. Wider availability of preinstalls sounds nice, but I don't notice emachines or WalMart penguin boxes taking over the world. -- Eric S. Raymond From dwmw2 at infradead.org Wed Apr 5 23:28:49 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 00:28:49 +0100 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405232702.GD17814@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> <20060405232702.GD17814@thyrsus.com> Message-ID: <1144279729.6227.112.camel@pmac.infradead.org> On Wed, 2006-04-05 at 19:27 -0400, Eric S. Raymond wrote: > > So a RedHat Pro desktop solution? > It was one of my early suggestions in this discussion. Not a topic for discussion on a Fedora list. Probably not a very realistic idea either -- but if you want to pitch it to Red Hat management, go wild. > Later I tried to develop the idea of third-party yum repositories to > carry "impure" stuff. We already have a 'Fedora Extras for the Free World'. It's not really a topic for discussion on this list either. -- dwmw2 From michael at knox.net.nz Wed Apr 5 23:30:44 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Apr 2006 11:30:44 +1200 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405232702.GD17814@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> <20060405232702.GD17814@thyrsus.com> Message-ID: <44345324.9050802@knox.net.nz> Eric S. Raymond wrote: > Michael J. Knox : >> Eric S. Raymond wrote: >>> Horst von Brand : >>>> Which SUSE? The paid one? No problem, they can pay for the codecs. >>> Which, I'm suggesting, Red Hat could do also. I don't undesstand why this >>> is a difficult concept. >> So a RedHat Pro desktop solution? >> >> I would buy it. Save the hassle of setting up the stuff that I need. > > It was one of my early suggestions in this discussion. Later I tried to > develop the idea of third-party yum repositories to carry "impure" > stuff. Which would also work... However, the horse as been truly flogged now, I am sure you can see that. Perhaps, as I stated earlier, that yourself and any other like minded person, should get together and start working on it. Its more than clear that Fedora is not going to change (I don't think there was a request to make it change, but I could have missed that email), so its time to put step up and produce some results. Michael From camilo at mesias.co.uk Wed Apr 5 23:41:55 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 06 Apr 2006 00:41:55 +0100 Subject: "expected gains in market share" In-Reply-To: <20060405233240.GE17814@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> Message-ID: <443455C3.50802@mesias.co.uk> Eric > I have no argument with any of those goals. Whether they're "better" > in terms of being more effective at raising market share, I dunno. I think that burning ISOs, shrinking NTFS and repartitioning are more of an impediment to uptake. Do you think there are users that are happy to do all that tech stuff, yet will abandon their new install because configuring and using a third party repo is too hard? Mp3 support is relatively easily obtained through third party repos, and if that's too much of a hurdle for some users, it's a moot point. Your "nontechnical users" will fall at an earlier hurdle. -Cam -- <-- camilo at mesias.co.uk From bojan at rexursive.com Wed Apr 5 23:40:12 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 5 Apr 2006 23:40:12 +0000 (UTC) Subject: Move Evolution to Extras? References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> <1144267053.6227.107.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > I explained the problem -- which he may not have noticed, although I'm > not entirely sure how that could be the case since his mail isn't part > of the thread to which he was replying. I asked, nicely, if he could > possibly try to fix it. He noticed, all right, but was too lazy to do much about it, I'm afraid. My bad and all that - neither IMP nor Evo have anything to do with any of it. > Quite why he thought that was an 'attack of the mailing list police' I > don't know. If this _was_ one of the mailing lists that I police, then > the offending mail wouldn't have got through in the first place -- I > filter and reject for that. That part of my post was followed by a ;-), which would sort of imply a joke. I was just trying to make fun of your "very rude" qualification. I would qualify what I did as "inconvenient" or maybe even "not very nice", but I think you were being just a tad too serious with "very rude", so I tried to joke about it. Ah, don't worry, it's all good. I'll try harder to follow the threads next time. PS. This is being posted from gmane. Normally, I just read mailman archives, which doesn't have this fancy interface, hence the "fake" e-mails. -- Bojan From cmadams at hiwaay.net Wed Apr 5 23:48:16 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 5 Apr 2006 18:48:16 -0500 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405215136.GG16936@thyrsus.com> References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> <1144273303.3647.3.camel@shuttle.piedmont.com> <20060405215136.GG16936@thyrsus.com> Message-ID: <20060405234816.GA957644@hiwaay.net> Once upon a time, Eric S. Raymond said: > Are we having trouble distinguishing between "Red Hat" and "Fedora", then? If you mean "the royal We" (e.g. yourself), then yes. Read the To: header. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwmw2 at infradead.org Wed Apr 5 23:55:12 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 00:55:12 +0100 Subject: Move Evolution to Extras? In-Reply-To: References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> <1144267053.6227.107.camel@pmac.infradead.org> Message-ID: <1144281312.6227.118.camel@pmac.infradead.org> On Wed, 2006-04-05 at 23:40 +0000, Bojan Smojver wrote: > That part of my post was followed by a ;-), which would sort of imply a joke. I > was just trying to make fun of your "very rude" qualification. I would qualify > what I did as "inconvenient" or maybe even "not very nice", but I think you were > being just a tad too serious with "very rude", so I tried to joke about it. Ah, > don't worry, it's all good. Don't worry -- I'm only taunting Smooge, and he loves me so it's OK :) > I'll try harder to follow the threads next time. Thanks. > PS. This is being posted from gmane. Normally, I just read mailman > archives, which doesn't have this fancy interface, hence the "fake" > e-mails. Mailman (well, pipermail) archives ought to have mailto: links with which you can reply, and they should have correct &In-Reply-To=... settings in the URL. See, for example, the first link on http://lists.infradead.org/pipermail/linux-mtd/2006-April/015277.html -- dwmw2 From esr at thyrsus.com Wed Apr 5 23:59:41 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 19:59:41 -0400 Subject: "expected gains in market share" In-Reply-To: <443455C3.50802@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> Message-ID: <20060405235941.GA18419@thyrsus.com> Cam : > I think that burning ISOs, shrinking NTFS and repartitioning are more of > an impediment to uptake. I guess I'm working from the assumption that most end-users will have pre-cooked ISOs someone gave them. And you're right, re-partitioning is a significant barrier. But we don't even get that far if the user contemplating installation asks J. Random Linux Geek "Can I use it to store my iTunes stuff?" and his answer is a lecture about Ogg Vorbis. -- Eric S. Raymond From camilo at mesias.co.uk Thu Apr 6 00:23:41 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 06 Apr 2006 01:23:41 +0100 Subject: "expected gains in market share" In-Reply-To: <20060405235941.GA18419@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> Message-ID: <44345F8D.10001@mesias.co.uk> Eric > re-partitioning is a significant barrier. But we don't even get that > far if the user contemplating installation asks J. Random Linux Geek > "Can I use it to store my iTunes stuff?" and his answer is a lecture > about Ogg Vorbis. I don't think that's a valid point. If support for iTunes is a real requirement, then *all* linux distros will be unable to provide something that even comes close. Pester Apple for a linux iTunes... If basic mp3 support is the requirement, then *all* linux distros (with some minor tweaks, sure) will do the job. I'm sure J Random would back me up on that. -Cam -- <-- camilo at mesias.co.uk From bojan at rexursive.com Thu Apr 6 00:28:36 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 6 Apr 2006 00:28:36 +0000 (UTC) Subject: Move Evolution to Extras? References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> <1144267053.6227.107.camel@pmac.infradead.org> <1144281312.6227.118.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > Mailman (well, pipermail) archives ought to have mailto: links with > which you can reply, and they should have correct &In-Reply-To=... > settings in the URL. See, for example, the first link on > http://lists.infradead.org/pipermail/linux-mtd/2006-April/015277.html >From what I can see, the above is different to Fedora Devel archives. For instance, your message is archived here: http://www.redhat.com/archives/fedora-devel-list/2006-April/msg00408.html None of that info is present on the page - not even when the source is viewed in the browser. Maybe there is another lot of archived messages on RH servers that I'm not used to using or something - I don't know. -- Bojan From esr at thyrsus.com Thu Apr 6 00:41:30 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 5 Apr 2006 20:41:30 -0400 Subject: "expected gains in market share" In-Reply-To: <44345F8D.10001@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> <44345F8D.10001@mesias.co.uk> Message-ID: <20060406004129.GA18701@thyrsus.com> Cam : > If support for iTunes is a real requirement, then *all* linux distros > will be unable to provide something that even comes close. Pester Apple > for a linux iTunes... > > If basic mp3 support is the requirement, then *all* linux distros (with > some minor tweaks, sure) will do the job. I'm sure J Random would back > me up on that. Hm. I was under the impression that the iTunes format was essentially a DRM wrapper around MP3 and that stripping it off ore re-applying it isn't hard. I guess I must have that wrong? -- Eric S. Raymond From camilo at mesias.co.uk Thu Apr 6 00:46:57 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 06 Apr 2006 01:46:57 +0100 Subject: "expected gains in market share" In-Reply-To: <20060406004129.GA18701@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> <44345F8D.10001@mesias.co.uk> <20060406004129.GA18701@thyrsus.com> Message-ID: <44346501.1070209@mesias.co.uk> Eric > Hm. I was under the impression that the iTunes format was essentially > a DRM wrapper around MP3 and that stripping it off ore re-applying it > isn't hard. I guess I must have that wrong? I'm not a lawyer or an mp3 expert but I imagine stripping DRM wrappers is an order of magnitude less legal than actually playing 'clean' mp3s. Really! -Cam -- <-- camilo at mesias.co.uk From dominik at greysector.net Thu Apr 6 00:48:59 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 6 Apr 2006 02:48:59 +0200 Subject: "expected gains in market share" In-Reply-To: <20060406004129.GA18701@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> <44345F8D.10001@mesias.co.uk> <20060406004129.GA18701@thyrsus.com> Message-ID: <20060406004859.GB7947@rathann.pekin.waw.pl> On Thursday, 06 April 2006 at 02:41, Eric S. Raymond wrote: > Cam : > > If support for iTunes is a real requirement, then *all* linux distros > > will be unable to provide something that even comes close. Pester Apple > > for a linux iTunes... > > > > If basic mp3 support is the requirement, then *all* linux distros (with > > some minor tweaks, sure) will do the job. I'm sure J Random would back > > me up on that. > > Hm. I was under the impression that the iTunes format was essentially > a DRM wrapper around MP3 and that stripping it off ore re-applying it > isn't hard. I guess I must have that wrong? AAC, not MP3. It has been reverse-engineered, too: http://www.theregister.co.uk/2004/01/05/itunes_drm_cracked_wide_open/ http://nanocrew.net/software/sharpmusique/ Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan From dominik at greysector.net Thu Apr 6 00:50:28 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 6 Apr 2006 02:50:28 +0200 Subject: "expected gains in market share" In-Reply-To: <44346501.1070209@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> <44345F8D.10001@mesias.co.uk> <20060406004129.GA18701@thyrsus.com> <44346501.1070209@mesias.co.uk> Message-ID: <20060406005028.GC7947@rathann.pekin.waw.pl> On Thursday, 06 April 2006 at 02:46, Cam wrote: > Eric > > >Hm. I was under the impression that the iTunes format was essentially > >a DRM wrapper around MP3 and that stripping it off ore re-applying it > >isn't hard. I guess I must have that wrong? > > I'm not a lawyer or an mp3 expert but I imagine stripping DRM wrappers > is an order of magnitude less legal than actually playing 'clean' mp3s. In the US, it is. Think: DMCA. Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan From dwmw2 at infradead.org Thu Apr 6 01:06:24 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 02:06:24 +0100 Subject: Move Evolution to Extras? In-Reply-To: References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> <1144267053.6227.107.camel@pmac.infradead.org> <1144281312.6227.118.camel@pmac.infradead.org> Message-ID: <1144285584.6227.121.camel@pmac.infradead.org> On Thu, 2006-04-06 at 00:28 +0000, Bojan Smojver wrote: > From what I can see, the above is different to Fedora Devel archives. For > instance, your message is archived here: > > http://www.redhat.com/archives/fedora-devel-list/2006-April/msg00408.html > > None of that info is present on the page - not even when the source is viewed in > the browser. Maybe there is another lot of archived messages on RH servers that > I'm not used to using or something - I don't know. In that case, the fedora-devel archives should probably be fixed. -- dwmw2 From rdieter at math.unl.edu Thu Apr 6 01:39:23 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Apr 2006 20:39:23 -0500 Subject: Qt 4 RPM poke In-Reply-To: <200604050856.37985.nomis80@nomis80.org> References: <200604050856.37985.nomis80@nomis80.org> Message-ID: <4434714B.6080902@math.unl.edu> Simon Perreault wrote: > You posted on March 13 a spec for Qt 4 that needed just a little bit of work > before being submitted to Fedora Extras. What is the status on that RPM? I've got one ready. I'll submit it to Extras tomorrow morning. Sneak-peak: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.unstable/qt4-4.1.2-1.src.rpm -- Rex From benjy.grogan at gmail.com Thu Apr 6 00:25:55 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Wed, 5 Apr 2006 20:25:55 -0400 Subject: Firefox Test Releases on Fedora Message-ID: Dear Fedora Developers, I've noticed some funny problems with Firefox on Fedora. Nothing catastrophic but not as user friendly as Firefox on Windows XP. I list the problems below. But I think it would be a good idea to have Firefox 2.0 test releases available in an experimental repository for FC5 so that they could get testing before Firefox 2.0 is released in September. This idea is similar to the AIGLX repository available for AIGLX's testing, and also similar to the inclusion of Gnome development branches in rawhide. I've been trying unsuccesfully to get a CVS build of Firefox to work on FC5, but for whatever reason after all is done it redirects to Firefox 1.5.0.1. But here are the minor nuisances I've experienced with Firefox 1.5.0.1 on FC5: 1) The middle button on the mouse doesn't allow the scroll button to appear, so that I can navigate up and down long web pages. 2) The middle button on the mouse doesn't allow other tabs to be closed simply by middle-button-clicking the tabs. 3) Certain keywords, such as 'wp linux' to look up Linux in Wikipedia don't work. 4) If I drag selected text into the search box at the top of Firefox it will automatically begin to search for that text in the current tab. In fact, I actually want to go to another new tab before beginning the search, and from that new tab I will activate the search box. This isn't a problem on Windows XP. 5) Occasionally web sites unintentionally become draggable. Then the only thing to do is drag the draggable to the tab where it is already shown. I think it happens because you click on a new tab, and then accidentally drag the new tab outside of it's place. For whatever reason, this never happens to me on Windows XP. So Firefox doesn't have the same polish as Windows XP, but overall it's highly functional. I think it's more important to have test releases of Firefox 2.0 available to testers so that all those nasty bugs that can only be rooted out by long term use of a test release are in fact rooted out. Benjy From bignose+hates-spam at benfinney.id.au Thu Apr 6 03:40:02 2006 From: bignose+hates-spam at benfinney.id.au (Ben Finney) Date: Thu, 06 Apr 2006 13:40:02 +1000 Subject: Red Hat's "Cowardice" against Software Patents References: <20060404150558.GA9219@thyrsus.com> <200604051705.k35H5akX006396@laptop11.inf.utfsm.cl> <20060405211622.GB16936@thyrsus.com> Message-ID: <874q17v0bx.fsf@benfinney.id.au> "Eric S. Raymond" writes: > Horst von Brand : > > Which SUSE? The paid one? No problem, they can pay for the codecs. > > Which, I'm suggesting, Red Hat could do also. Which would be useless to Fedora, and would also be useless to anyone downstream (i.e. wanting to re-distribute Fedora). Just because Red Hat obtain a license to exercise the technology covered by the patent doesn't grant anyone downstream of them a license. If you *can* get Fraunhofer to grant a patent license that applies to everyone downstream of the party to whom the license is granted, for a price that party is able to pay, then you've effectively negated the monopoly of that particular patent. I would welcome such a scenario, but I think it has "a snowball's chance in a supernova" of occurring, to quote some recently-seen hyperbole. -- \ "The World is not dangerous because of those who do harm but | `\ because of those who look at it without doing anything." -- | _o__) Albert Einstein | Ben Finney From lmacken at redhat.com Thu Apr 6 05:08:44 2006 From: lmacken at redhat.com (Luke Macken) Date: Thu, 6 Apr 2006 01:08:44 -0400 Subject: Missing update announcements In-Reply-To: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> Message-ID: <20060406050843.GA14736@tomservo.boston.redhat.com> On Wed, Apr 05, 2006 at 06:16:16PM +0200, Bernd Bartmann wrote: > Now that FC5 final is out a problem seems to reappear that I thought > was gone since FC4 came out: FC core updates appear on the download > mirrors but some of them never get announced on fedora-announce-list. > > Since the release of FC5 the following announcments are missing: > > For FC4: > anacron-2.3-36.FC4 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01335.html > dia-0.94-13.fc4 Claims to be sent. > dovecot-0.99.14-8.fc4 Claims to be sent. > For FC5: > cairo-1.0.4-1 Developer chose not to have update mail sent. > GConf2-2.14.0-1 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01319.html > xscreensaver-4.24-2 Developer chose not to have update mail sent. > gnome-screensaver-2.14.0-1.fc5 Update system was supposed to send, but for some reason it didn't. > liboil-0.3.8-1.fc5 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01684.html > newt-0.52.2-6 Update system was supposed to send, but for some reason it didn't. > xterm-211-4.FC5 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01709.html > I've opened bugs for every missing announcements and tracker bugs to > get an overview. For FC4 the tracker bug is #161106, for FC5 it is > #188051. Please file bugs like this against Fedora Infrastructure under the 'update system' component from now on. > Can someone @fedora or @redhat please look into this issue. I thought > the process was somehow automated since FC4 came out. It would be > helpful to get an explanation about the internal process how updates > are released. This process is automated.. but where you have automation, you have a fan waiting to be hit by shit. The update system already goes out and grabs the url for the archived update mail, so I'll add periodic checks to make sure that all update mails that were supposed to go out actually do. Thanks, luke From j.w.r.degoede at hhs.nl Thu Apr 6 06:02:45 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 06 Apr 2006 08:02:45 +0200 Subject: Today's rawhide xorg/radeon In-Reply-To: <443440BA.50103@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> Message-ID: <4434AF05.5020103@hhs.nl> Andy Burns wrote: > Andy Burns wrote: > >> should I "expect" any more than this at this stage of development? > > Just had a thought, do these xorg updates need a newer kernel than > 2080_FC5? > Yes I think you're right on the money there, because of stability issues the radeon drm driver was disabled for > r200 cards in the currentl FC-5 kernel. I believe its reenabled in the latest rawhide kernel but I'm not sure, go check the changelog. Regards, Hans From buildsys at redhat.com Thu Apr 6 07:17:23 2006 From: buildsys at redhat.com (Build System) Date: Thu, 6 Apr 2006 03:17:23 -0400 Subject: rawhide report: 20060406 changes Message-ID: <200604060717.k367HNkU025551@porkchop.devel.redhat.com> Updated Packages: checkpolicy-1.30.4-1 -------------------- * Wed Apr 05 2006 Dan Walsh - 1.30.4-1 - Latest upgrade from NSA * Changed require_class to reject permissions that have not been declared if building a base module. gnucash-1.9.4-1 --------------- * Thu Apr 06 2006 Bill Nottingham - 1.9.4-1 - update to 1.9.4 iptraf-3.0.0-2 -------------- * Wed Apr 05 2006 Miroslav Lichvar 3.0.0-2 - fix crash when parsing long network interface name (#187937) kdeadmin-7:3.5.2-1 ------------------ * Wed Apr 05 2006 Than Ngo 7:3.5.2-1 - update to 3.5.2 kdeartwork-3.5.2-1 ------------------ * Wed Apr 05 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdebindings-3.5.2-1 ------------------- * Wed Apr 05 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdeedu-3.5.2-1 -------------- * Wed Apr 05 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdegraphics-7:3.5.2-1 --------------------- * Wed Apr 05 2006 Than Ngo 7:3.5.2-1 - update to 3.5.2 * Tue Mar 14 2006 Than Ngo 7:3.5.1-4 - fix build problem with gphoto2 kdesdk-3.5.2-1 -------------- * Wed Apr 05 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdeutils-6:3.5.2-1 ------------------ * Wed Apr 05 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdevelop-9:3.3.2-1 ------------------ * Wed Apr 05 2006 Than Ngo 9:3.3.2-1 - update to 3.3.2 kdewebdev-6:3.5.2-1 ------------------- * Wed Apr 05 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 libsepol-1.12.5-1 ----------------- * Wed Apr 05 2006 Dan Walsh 1.12.5-1 - Upgrade to latest from NSA * Merged fix for leak of optional package sections from Ivan Gyurdiev. policycoreutils-1.30.4-2 ------------------------ * Wed Mar 29 2006 Dan Walsh 1.30.4-2 - Fix audit2allow to not require ausearch. - Fix man page - Add libflashplayer to restorecond.conf sound-juicer-2.14.1-2 --------------------- * Wed Apr 05 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 system-config-users-1.2.44-1 ---------------------------- * Wed Apr 05 2006 Nils Philippsen - 1.2.44 - rephrase some error messages to ease translation (#154204) * Mon Mar 27 2006 Nils Philippsen - 1.2.43 - pick up translation updates Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) mkbootdisk - 1.5.3-1.noarch requires syslinux rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 mkbootdisk - 1.5.3-1.noarch requires syslinux Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 From bogdan.mustiata at gmail.com Thu Apr 6 07:58:33 2006 From: bogdan.mustiata at gmail.com (Bogdan Mustiata) Date: Thu, 06 Apr 2006 10:58:33 +0300 Subject: "expected gains in market share" In-Reply-To: <44344923.7070805@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> Message-ID: <4434CA29.40308@gmail.com> Cam wrote: > Eric, > > Do you really think that a substantial population of adopters are > ready and waiting but held back because mp3 isn't in Fedora? > ... > -Cam Yes. And not only MP3 itself is the problem, there are also movies and games that don't fit *any* distribution into a *real* competitor for M$. Yes, OpenOffice it's cool, and yes I love all of the KDE, GNOME, k3b, amarok, banshee, gimp, kdevelop, inkscape ... and all the other best written application in the OpenSource world and even all this bleeding edge technology incorporated in Fedora like SELinux or Xen, but the most users don't care about all that. They want to see a movie, play a game or install software (for that, they even pay money for) _easy_. This _easy_ component is a crucial one, because as it was stated in another post you *can not* tell a user to edit some /etc/ file to get his drivers working, you *can not* tell a user he has dependencies problems simply because in his mind they don't exist, you *can not* put a user who has spent thousands of dollars on a multimedia system to configure it from console or worse his system doesn't work because it was build from the ground only with M$ products in mind, etc. etc. I could go on and on about that. My point is this one: There _is a substantial population of adopters ready and waiting but held back because multimedia isn't in Fedora_, and I am really sorry for that... but I simply LOVE RedHat because they didn't include that support, because the are fighting to the root of the problem, and that's software patents. Sooner or later some M$ users will wake up and see they are in fact in slavery and decide to take action. I know at least several ways how can people be encouraged to switch to Linux. - Better desktop experience. Cool themes and gDesklets or superKaramba don't stay unnoticed. 3D stuff is also Ok :) - Better OpenSource cross-platform applications. If someone uses all the day only gimp & OpenOffice it won't be a drama for him to use his applications on Linux and not on Windows. Presentation of other "hot" *NIX only application at LUGs (e.g. kdevelop, amarok, quanta, bluefish, etc. etc.) - _Easy_ (graphically wold do) to install missing multimedia from Internet. - Graphical configuration of most of the things. I think at least those are some reasons of the huge GNOME/Ubuntu success and I respect that. Anyway I use Fedora/KDE for my Desktop and also Fedora for my servers and I want to tell you: RedHat and Fedora community did a great job. Thank you. Bogdan From uraeus at gnome.org Thu Apr 6 08:42:34 2006 From: uraeus at gnome.org (Christian Fredrik Kalager Schaller) Date: Thu, 06 Apr 2006 10:42:34 +0200 Subject: "expected gains in market share" In-Reply-To: <20060406004129.GA18701@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <443455C3.50802@mesias.co.uk> <20060405235941.GA18419@thyrsus.com> <44345F8D.10001@mesias.co.uk> <20060406004129.GA18701@thyrsus.com> Message-ID: <1144312954.2259.14.camel@localhost.localdomain> On Wed, 2006-04-05 at 20:41 -0400, Eric S. Raymond wrote: > Cam : > > If support for iTunes is a real requirement, then *all* linux distros > > will be unable to provide something that even comes close. Pester Apple > > for a linux iTunes... > > > > If basic mp3 support is the requirement, then *all* linux distros (with > > some minor tweaks, sure) will do the job. I'm sure J Random would back > > me up on that. > > Hm. I was under the impression that the iTunes format was essentially > a DRM wrapper around MP3 and that stripping it off ore re-applying it > isn't hard. I guess I must have that wrong? Yes, you have that very wrong. First of all with laws like DMCA 'stripping it off' would be illegal. We do not agree with the law, but it is the law at least in the US, but also many EU countries are these days rolling out DMCA like laws. No idea about the rest of the world. It is also not easy at all I think to strip it off even if you are in a place without DMCA, sharpmusique and friends don't actually strip it off, instead they grab the music from the iTunes store before the DRM is applied. As others has mentioned the format in question is not mp3, but AAC. The license fees and terms for this can be found here: http://www.vialicensing.org/products/mpeg4aac/license.terms.html Even if Red Hat coughed up the money to support AAC they would still be unable to legally support Fairplay as Apple has disallowed anyone else from licensing/using it. And as I have mentioned before. As soon as you start bundling a licensed technology like this then you can't have any of your GPL applications use it. My suggestion is that instead of continuing this, by this time repetitive and boring discussion, you instead buy yourself a copy of RHEL Workstation which do come with support for some properietary formats including mp3 afaik. If you are missing some formats then you can complain as paying customer to Red Hat customer support. Christian From dwmw2 at infradead.org Thu Apr 6 09:20:28 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 10:20:28 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <4434AF05.5020103@hhs.nl> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> <4434AF05.5020103@hhs.nl> Message-ID: <1144315228.6227.126.camel@pmac.infradead.org> On Thu, 2006-04-06 at 08:02 +0200, Hans de Goede wrote: > Yes I think you're right on the money there, because of stability issues > the radeon drm driver was disabled for > r200 cards in the currentl FC-5 > kernel. I believe its reenabled in the latest rawhide kernel but I'm not > sure, go check the changelog. Yes, it's enabled in rawhide, with some checks on the X server to make sure it's new enough. It'll also be enabled in the 2085 and later kernels if you use the 'allow_r300' module parameter when loading radeon.ko. I don't think we built that yet though -- it's only in CVS. It's trivial enough to rebuild just radeon.ko though, if you want to. -- dwmw2 From gilboad at gmail.com Thu Apr 6 10:03:05 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 06 Apr 2006 13:03:05 +0300 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <4434500D.90307@knox.net.nz> References: <20060404150558.GA9219@thyrsus.com> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> <200604051905.28725.jkeating@redhat.com> <4434500D.90307@knox.net.nz> Message-ID: <1144317785.26758.1.camel@gilboa-work-dev> On Thu, 2006-04-06 at 11:17 +1200, Michael J. Knox wrote: > Jesse Keating wrote: > > On Wednesday 05 April 2006 19:00, Michael J. Knox wrote: > >> So a RedHat Pro desktop solution? > >> > >> I would buy it. Save the hassle of setting up the stuff that I need. > >> > >> Michael > >> > >> (note: read RedHat, not Fedora) > > > > Why not 'Joe's Pro Linux'? Strip all the "redhat" "Red Hat" "Fedora" > > whatevers from the sources, add your wizbang stuff, release it. Nothing > > stops you from doing this. This is how things like CentOS exist. It just > > won't be called Fedora. > > > > Of course. I agree with you there too. > > Just trying to say, that both sides have merit. A RedHat Pro? Sure, > works for me, Fedora Core 100% free? Works for me too. > > However, I do feel this thread is out living its usefulness and breeding > discontent. > > Michael > Umm.... assuming this thread was productive and/or informational. Nothing to see here people... move along... Gilboa From fedora at adslpipe.co.uk Thu Apr 6 10:05:17 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 11:05:17 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <1144315228.6227.126.camel@pmac.infradead.org> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl> <1144315228.6227.126.camel@pmac.infradead.org> Message-ID: <4434E7DD.4080707@adslpipe.co.uk> David Woodhouse wrote: > Yes, it's enabled in rawhide, with some checks on the X server to make > sure it's new enough. OK, using kernel 2121_FC6 looks better, all the DRI errors previously reported are gone, here are snippets from Xorg.0.log (II) RADEON(0): PCIE card detected drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) (WW) RADEON(0): Enabling DRM support (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0" (**) RADEON(0): DRI Finishing init ! (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): Direct rendering enabled (**) RADEON(0): Setting up final surfaces (**) RADEON(0): Initializing Acceleration (II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer. (II) RADEON(0): Render acceleration disabled and although GL apps run they are still using CPU horsepower rather than GPU, is there any setting which will "convince" the driver to try to use h/w acceleration? > It'll also be enabled in the 2085 and later kernels if you use the > 'allow_r300' module parameter when loading radeon.ko. is 2085 a candidate for FC5 updates? (via updates-testing) From nicolas.mailhot at laposte.net Thu Apr 6 10:06:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 6 Apr 2006 12:06:28 +0200 (CEST) Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405212215.GC16936@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <4430ACBA.9040204@redhat.com> <20060404150558.GA9219@thyrsus.com> <443400B4.2030706@redhat.com> <20060405212215.GC16936@thyrsus.com> Message-ID: <37768.192.54.193.53.1144317988.squirrel@rousalka.dyndns.org> Le Mer 5 avril 2006 23:22, Eric S. Raymond a ?crit : > What is it with the zeolots on this list, anyway? No contact with reality > at *all*... Eric, to make it clear (though I despair you'll understand what I'll write) 1. discussions on RH paid offerings (aka RHEL) -> on RHEL ML 2. discussions of RH 100% FOSS and redistributable offerings -> on fedora list 3. discussions of RH-blessed 100% FOSS and redistributable offerings -> on fedora-extras list 4. discussions of anything else -> on other lists (livna, centos, freshrpms, whatever) It's not real clear if you want to talk about 1. or 4. but what's blindingly clear to everyone but you is it does not belong in 2. Except if you want to be told : 1. you're off topic 2. what you want is not within Fedora goals (what 2 is about) Which has already happened numerous times and fallen in deaf ears. -- Nicolas Mailhot From andy at warmcat.com Thu Apr 6 10:25:19 2006 From: andy at warmcat.com (Andy Green) Date: Thu, 06 Apr 2006 11:25:19 +0100 Subject: Thread is in fact 'community input' In-Reply-To: <1144317785.26758.1.camel@gilboa-work-dev> References: <20060404150558.GA9219@thyrsus.com> <20060405211622.GB16936@thyrsus.com> <44344C0F.2030507@knox.net.nz> <200604051905.28725.jkeating@redhat.com> <4434500D.90307@knox.net.nz> <1144317785.26758.1.camel@gilboa-work-dev> Message-ID: <4434EC8F.1020002@warmcat.com> Gilboa Davara wrote: >> However, I do feel this thread is out living its usefulness and breeding >> discontent. > Umm.... assuming this thread was productive and/or informational. > > Nothing to see here people... move along... If this community input thing RHAT are on the second attempt with is going to mean anything, you can expect an increase in threads like this chewing stuff over from The Outside in. Wrongheaded as Eric has been in this thread IMO, it's legitimate to bring all this up. Either make a new fedora-politics list for it -- so long as it isn't an unpopulated ghetto, or the discussion will move back to where the players are -- or use the threading features of your mailreader to stop it bothering you. You aren't in a position to assess the value of this thread for all its readers. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From dwmw2 at infradead.org Thu Apr 6 11:01:39 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 12:01:39 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <4434E7DD.4080707@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> <4434AF05.5020103@hhs.nl> <1144315228.6227.126.camel@pmac.infradead.org> <4434E7DD.4080707@adslpipe.co.uk> Message-ID: <1144321299.6227.129.camel@pmac.infradead.org> On Thu, 2006-04-06 at 11:05 +0100, Andy Burns wrote: > and although GL apps run they are still using CPU horsepower rather than > GPU, is there any setting which will "convince" the driver to try to use > h/w acceleration? You have Mesa's r300_dri.so too? > > It'll also be enabled in the 2085 and later kernels if you use the > > 'allow_r300' module parameter when loading radeon.ko. > > is 2085 a candidate for FC5 updates? (via updates-testing) When it (well, a later kernel) eventually gets built, yes. I just committed the change and didn't trigger a build at the time. -- dwmw2 From dennis at ausil.us Thu Apr 6 11:44:59 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 6 Apr 2006 06:44:59 -0500 Subject: Qt 4 RPM poke In-Reply-To: <4434714B.6080902@math.unl.edu> References: <200604050856.37985.nomis80@nomis80.org> <4434714B.6080902@math.unl.edu> Message-ID: <200604060645.00607.dennis@ausil.us> On Wednesday 05 April 2006 8:39 pm, Rex Dieter wrote: > Simon Perreault wrote: > > You posted on March 13 a spec for Qt 4 that needed just a little bit of > > work before being submitted to Fedora Extras. What is the status on that > > RPM? > > I've got one ready. I'll submit it to Extras tomorrow morning. > > Sneak-peak: > http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.unstable/qt4-4.1.2-1.src >.rpm > > -- Rex One problem i see with your package Rex is that qt4-devel conflicts with qt-devel so with out removing packages is impossible to develop with qt3 qnd qt4 at the same time. and this also means that qt-designer can only have one version installed also. Dennis From pbrobinson at gmail.com Thu Apr 6 11:25:17 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 6 Apr 2006 12:25:17 +0100 Subject: Fedora with laptops/networking/docking stations etc Message-ID: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> Hi All, Been running FC5/rawhide for ages and absolutely love it but I have a couple of queries wrt to various laptop support. Firstly with NetworkManager do we still need to run the network scripts. The reason I ask with my laptop at work I have wired, and home wireless and as a result it takes ages to time out on alternate interfaces and increases boot time greatly. Or can I run the network script with the 2 interfaces disabled for boot time (so just localhost) and let NM deal with what ever interface is up. Similarly what's the status of docking stations support? With my Dell Latitude when ever I undock then redock the wired network interface (tg3) doesn't work and it takes a reboot to fix. I think its to do with routing of the physical output to either the local port or dock port. Same with suspending it within the dock. Otherwise this is a rocking release. Well done! Pete From mark at borkware.net Thu Apr 6 11:52:51 2006 From: mark at borkware.net (Mark Rosenstand) Date: Thu, 6 Apr 2006 13:52:51 +0200 Subject: Qt 4 RPM poke In-Reply-To: <200604060645.00607.dennis@ausil.us> References: <200604050856.37985.nomis80@nomis80.org> <4434714B.6080902@math.unl.edu> <200604060645.00607.dennis@ausil.us> Message-ID: <200604061352.52060.mark@borkware.net> On Thursday 06 April 2006 13:44, Dennis Gilmore wrote: > One problem i see with your package Rex is that qt4-devel conflicts > with qt-devel so with out removing packages is impossible to develop > with qt3 qnd qt4 at the same time. and this also means that > qt-designer can only have one version installed also. I believe Qt4 provides a backwards compatability layer for Qt3. From rdieter at math.unl.edu Thu Apr 6 12:20:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 06 Apr 2006 07:20:31 -0500 Subject: Qt 4 RPM poke In-Reply-To: <200604060645.00607.dennis@ausil.us> References: <200604050856.37985.nomis80@nomis80.org> <4434714B.6080902@math.unl.edu> <200604060645.00607.dennis@ausil.us> Message-ID: <4435078F.7080507@math.unl.edu> Dennis Gilmore wrote: > One problem i see with your package Rex is that qt4-devel conflicts with > qt-devel so with out removing packages is impossible to develop with qt3 > qnd qt4 at the same time. and this also means that qt-designer can only have > one version installed also. Yep. Both -devel pkgs (try to) define QTDIR pointing to themselves, so I added the Conflicts. What would you suggest? -- Rex From jspaleta at gmail.com Thu Apr 6 12:14:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Apr 2006 08:14:18 -0400 Subject: Firefox Test Releases on Fedora In-Reply-To: References: Message-ID: <604aa7910604060514y2300079ve3b5254337cd4c20@mail.gmail.com> On 4/5/06, Benjy Grogan wrote: > 1) The middle button on the mouse doesn't allow the scroll button to > appear, so that I can navigate up and down long web pages. Go into the firefox preferences in the Edit menu Advancd tab select Use autoscrolling > > 3) Certain keywords, such as 'wp linux' to look up Linux in Wikipedia > don't work. Where are the keywords defined in the windows xp version? Are they defined in the default bookmarks that are included in the windows XP version? Quite honestly I don't see this a a problem at all. You can add additional keywords in each bookmark entry, keywords as a piece of technology are meant to be customizable per user. From fedora at adslpipe.co.uk Thu Apr 6 12:16:40 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 13:16:40 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <1144321299.6227.129.camel@pmac.infradead.org> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org><4434E7DD.4080707@adslpipe.co.uk> <1144321299.6227.129.camel@pmac.infradead.org> Message-ID: <443506A8.5070201@adslpipe.co.uk> David Woodhouse wrote: > You have Mesa's r300_dri.so too? Err, no, just r200_dri.so and radeon_dri.so I've updated mesa-lib* from rawhide and restarted X (II) AIGLX: Loaded and initialized /usr/lib64/dri/r300_dri.so (II) GLX: Initialized DRI GL provider for screen 0 fglrxinfo gives display: :0.0 screen: 0 OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R300 20040924 TCL OpenGL version string: 1.3 Mesa 6.5 Looks like everything is happily loading :-) If I run any GL program it isn't so happy, e.g. /usr/libexec/xscreensaver/juggler3d drmRadeonCmdBuffer: -22 (exiting) dmesg shows [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed I guess now it *is* time to hit bugzilla? Are there any "gentler" openGL tests I can try (I don't seem to have glxgears apart from fgl_glxgears which fails due to using private extensions) From che666 at gmail.com Thu Apr 6 12:17:51 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 6 Apr 2006 14:17:51 +0200 Subject: "expected gains in market share" In-Reply-To: References: <44344923.7070805@mesias.co.uk> Message-ID: 2006/4/6, Rudolf Kastl : > 2006/4/6, Cam : > > Eric, > > > > Do you really think that a substantial population of adopters are ready > > and waiting but held back because mp3 isn't in Fedora? > > i agree... installing the livna release package and yum installing an > mp3 addon package isnt a really big deal. and also this way we push > superior formats that are free... mp3 is just a suboptimal legacy > format in my eyes anyways. > > > > > I think that's nonsense. If you rank potential users by ability, the > > vast majority will not use Fedora because they can't buy a machine with > > it pre-installed; > > Lots of users have windows preinstalled and they dont know anything > else or cant imagine that something else that doesnt cost anything can > even be better for their use cases. > > > > others will not use Fedora because they aren't > > confident about partitioning disks or shrinking NTFS partitions. > > You cant do that with windows xp... you need addon tools whereas the > most known and easiest to find tools are proprietary. The win os just > doesent even provide those basic features and i doubt vista will fix > it because they have a tough time to catch up with their desktop to > not look like from 1995. Vector based desktop in vista... i use svg > themes since ages on linux ... also well i dont expect them to develop > lots of additions to the basic os because fixing up the few basic apps > they supply (like gnomemeeting and the directx crash i reported around > 8 years ago that is still present in the xp version). > > > > > I'm not aware of any vendor that ships Fedora (and IMHO it's not likely > > as a vendor would chose something which would be supported for longer > > than a given Fedora release). Given that other users will have to follow > > technical instructions to burn CDs or perform a network install, they > > will have a level of ability where they are more than capable of getting > > mp3 support through the established methods. > > There are how tos. If a person isnt able to follow a simple 3 step > procedure that is well documented with how tos i am asking myself if > the person: > > a) should use a computer at all > b) maybe should start learning to read > c) is a member of the intended audience for _any_ software product typo: i meant "is not a member" instead "is a member" > > > > > > I think there are better goals that would increase adoption: > > > > 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials > > and demos with video showing features > > A live cd would definitely help and also show the user if the system > actually does support his hardware and meet his requirements and use > cases. A vmware image would probably just introduce additional bugs > and make linux appear lots slower than it actually is. Sure live cds > are slower than a hd install aswell but theres no host os eating up > ram and cpu power. > > > > 2. technical improvements: provide email notification through > > thunderbird; provide desktop integration for firefox; any other workflow > > related improvements > > Well i prefer evolution personally. And as for firefox... a new > frontend to the renderer like galeon that does integrate properly with > gnome would be nicer and faster as well as better integrating. I just > dont see that happen with firefox. > > > 3. better documentation from a user's perspective - how to do task X > > instead of how to use 'Banshee' (or any other obscurely named app) > > Thats two completly different kinds of documentation. Theres > application specific ones and task specific ones. Task specific ones > should probably describe how to achieve a result in multible and as > far as possible task independent ways. > > > 4. bling, because people will make the effort to see it, even if it's > > not a productivity enhancement; it also gets you noticed in print. As a > > bleeding edge distro Fedora is well placed to make the most of this. > > Bling on by default also requires it to be less buggy and > problematic.Installing bling is nothing but adding one repo yumming > the server, using gdmsetup and choosing aiglx and enabling composite. > Then triggering a gconf switch and done. I think if you cant handle > that at the moment you are also not able to attach gdb and report bugs > upstream properly which is what is required at the moment besides > fixing more drivers up for it and getting bugs squashed. > > But yes i agree... the majority of win users can be easily attracted > with nice eye candy that doesent need a dual core cpu (compare vista). > > > > > I think any of the above would do more to increase adoption than merely > > including mp3 support. > > Looking at mp3 support for me means looking back to nonfree legacy > stuff. i never look back. > > > regards, > Rudolf Kastl > > p.s. as always just my personal opinion > > > > > -Cam > > > > -- > > > > <-- > > camilo at mesias.co.uk > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From che666 at gmail.com Thu Apr 6 12:20:37 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 6 Apr 2006 14:20:37 +0200 Subject: "expected gains in market share" In-Reply-To: References: <44344923.7070805@mesias.co.uk> Message-ID: 2006/4/6, Rudolf Kastl : > 2006/4/6, Cam : > > Eric, > > > > Do you really think that a substantial population of adopters are ready > > and waiting but held back because mp3 isn't in Fedora? > > i agree... installing the livna release package and yum installing an > mp3 addon package isnt a really big deal. and also this way we push > superior formats that are free... mp3 is just a suboptimal legacy > format in my eyes anyways. > > > > > I think that's nonsense. If you rank potential users by ability, the > > vast majority will not use Fedora because they can't buy a machine with > > it pre-installed; > > Lots of users have windows preinstalled and they dont know anything > else or cant imagine that something else that doesnt cost anything can > even be better for their use cases. > > > > others will not use Fedora because they aren't > > confident about partitioning disks or shrinking NTFS partitions. > > You cant do that with windows xp... you need addon tools whereas the > most known and easiest to find tools are proprietary. The win os just > doesent even provide those basic features and i doubt vista will fix > it because they have a tough time to catch up with their desktop to > not look like from 1995. Vector based desktop in vista... i use svg > themes since ages on linux ... also well i dont expect them to develop > lots of additions to the basic os because fixing up the few basic apps > they supply (like gnomemeeting and the directx crash i reported around > 8 years ago that is still present in the xp version). another typo: instead "gnomemeeting" i meant "netmeeting" of course. It crashes when even a small directx application is open... just one of the many bugs in the simple and small tools they provide for ages. > > > > > I'm not aware of any vendor that ships Fedora (and IMHO it's not likely > > as a vendor would chose something which would be supported for longer > > than a given Fedora release). Given that other users will have to follow > > technical instructions to burn CDs or perform a network install, they > > will have a level of ability where they are more than capable of getting > > mp3 support through the established methods. > > There are how tos. If a person isnt able to follow a simple 3 step > procedure that is well documented with how tos i am asking myself if > the person: > > a) should use a computer at all > b) maybe should start learning to read > c) is a member of the intended audience for _any_ software product > > > > > > I think there are better goals that would increase adoption: > > > > 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials > > and demos with video showing features > > A live cd would definitely help and also show the user if the system > actually does support his hardware and meet his requirements and use > cases. A vmware image would probably just introduce additional bugs > and make linux appear lots slower than it actually is. Sure live cds > are slower than a hd install aswell but theres no host os eating up > ram and cpu power. > > > > 2. technical improvements: provide email notification through > > thunderbird; provide desktop integration for firefox; any other workflow > > related improvements > > Well i prefer evolution personally. And as for firefox... a new > frontend to the renderer like galeon that does integrate properly with > gnome would be nicer and faster as well as better integrating. I just > dont see that happen with firefox. > > > 3. better documentation from a user's perspective - how to do task X > > instead of how to use 'Banshee' (or any other obscurely named app) > > Thats two completly different kinds of documentation. Theres > application specific ones and task specific ones. Task specific ones > should probably describe how to achieve a result in multible and as > far as possible task independent ways. > > > 4. bling, because people will make the effort to see it, even if it's > > not a productivity enhancement; it also gets you noticed in print. As a > > bleeding edge distro Fedora is well placed to make the most of this. > > Bling on by default also requires it to be less buggy and > problematic.Installing bling is nothing but adding one repo yumming > the server, using gdmsetup and choosing aiglx and enabling composite. > Then triggering a gconf switch and done. I think if you cant handle > that at the moment you are also not able to attach gdb and report bugs > upstream properly which is what is required at the moment besides > fixing more drivers up for it and getting bugs squashed. > > But yes i agree... the majority of win users can be easily attracted > with nice eye candy that doesent need a dual core cpu (compare vista). > > > > > I think any of the above would do more to increase adoption than merely > > including mp3 support. > > Looking at mp3 support for me means looking back to nonfree legacy > stuff. i never look back. > > > regards, > Rudolf Kastl > > p.s. as always just my personal opinion > > > > > -Cam > > > > -- > > > > <-- > > camilo at mesias.co.uk > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > p.s. sorry for all the typos... didnt have much time to respond but couldnt resist. From ndbecker2 at gmail.com Thu Apr 6 12:21:13 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 06 Apr 2006 08:21:13 -0400 Subject: r200? was: Today's rawhide xorg/radeon References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> <4434AF05.5020103@hhs.nl> <1144315228.6227.126.camel@pmac.infradead.org> Message-ID: David Woodhouse wrote: > On Thu, 2006-04-06 at 08:02 +0200, Hans de Goede wrote: >> Yes I think you're right on the money there, because of stability issues >> the radeon drm driver was disabled for > r200 cards in the currentl FC-5 >> kernel. I believe its reenabled in the latest rawhide kernel but I'm not >> sure, go check the changelog. > > Yes, it's enabled in rawhide, with some checks on the X server to make > sure it's new enough. > > It'll also be enabled in the 2085 and later kernels if you use the > 'allow_r300' module parameter when loading radeon.ko. I don't think we > built that yet though -- it's only in CVS. It's trivial enough to > rebuild just radeon.ko though, if you want to. > I have (--) Chipset ATI Radeon XPRESS 200M 5955 (PCIE) found No dri/drm here, is it supposed to work? drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed I did install 2.6.16-1.2121_FC6 (otherwise, current FC5) From fedora at adslpipe.co.uk Thu Apr 6 12:22:12 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 13:22:12 +0100 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> Message-ID: <443507F4.3000108@adslpipe.co.uk> Peter Robinson wrote: > Similarly what's the status of docking stations support? With my Dell > Latitude when ever I undock then redock the wired network interface > (tg3) doesn't work and it takes a reboot to fix. I have a Latitude D800, which gets used in various configutations depending where I vsisit 1) undocked with just internal LCD 2) docked to d/port with just external DVI LCD 3) docked to ad/dock with internal LCD and external VGA LCD My X config is for 1280x800 which is the internal LCD, when I dock I get centered or stretched displays on the external monitor(s) it would be nice to switch to different display/head configurations, does hotplug "notice" docking events? From che666 at gmail.com Thu Apr 6 12:17:03 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 6 Apr 2006 14:17:03 +0200 Subject: "expected gains in market share" In-Reply-To: <44344923.7070805@mesias.co.uk> References: <44344923.7070805@mesias.co.uk> Message-ID: 2006/4/6, Cam : > Eric, > > Do you really think that a substantial population of adopters are ready > and waiting but held back because mp3 isn't in Fedora? i agree... installing the livna release package and yum installing an mp3 addon package isnt a really big deal. and also this way we push superior formats that are free... mp3 is just a suboptimal legacy format in my eyes anyways. > > I think that's nonsense. If you rank potential users by ability, the > vast majority will not use Fedora because they can't buy a machine with > it pre-installed; Lots of users have windows preinstalled and they dont know anything else or cant imagine that something else that doesnt cost anything can even be better for their use cases. > others will not use Fedora because they aren't > confident about partitioning disks or shrinking NTFS partitions. You cant do that with windows xp... you need addon tools whereas the most known and easiest to find tools are proprietary. The win os just doesent even provide those basic features and i doubt vista will fix it because they have a tough time to catch up with their desktop to not look like from 1995. Vector based desktop in vista... i use svg themes since ages on linux ... also well i dont expect them to develop lots of additions to the basic os because fixing up the few basic apps they supply (like gnomemeeting and the directx crash i reported around 8 years ago that is still present in the xp version). > > I'm not aware of any vendor that ships Fedora (and IMHO it's not likely > as a vendor would chose something which would be supported for longer > than a given Fedora release). Given that other users will have to follow > technical instructions to burn CDs or perform a network install, they > will have a level of ability where they are more than capable of getting > mp3 support through the established methods. There are how tos. If a person isnt able to follow a simple 3 step procedure that is well documented with how tos i am asking myself if the person: a) should use a computer at all b) maybe should start learning to read c) is a member of the intended audience for _any_ software product > > I think there are better goals that would increase adoption: > > 1. marketing: a 'sampler' live-CD or VMWare image; web based tutorials > and demos with video showing features A live cd would definitely help and also show the user if the system actually does support his hardware and meet his requirements and use cases. A vmware image would probably just introduce additional bugs and make linux appear lots slower than it actually is. Sure live cds are slower than a hd install aswell but theres no host os eating up ram and cpu power. > 2. technical improvements: provide email notification through > thunderbird; provide desktop integration for firefox; any other workflow > related improvements Well i prefer evolution personally. And as for firefox... a new frontend to the renderer like galeon that does integrate properly with gnome would be nicer and faster as well as better integrating. I just dont see that happen with firefox. > 3. better documentation from a user's perspective - how to do task X > instead of how to use 'Banshee' (or any other obscurely named app) Thats two completly different kinds of documentation. Theres application specific ones and task specific ones. Task specific ones should probably describe how to achieve a result in multible and as far as possible task independent ways. > 4. bling, because people will make the effort to see it, even if it's > not a productivity enhancement; it also gets you noticed in print. As a > bleeding edge distro Fedora is well placed to make the most of this. Bling on by default also requires it to be less buggy and problematic.Installing bling is nothing but adding one repo yumming the server, using gdmsetup and choosing aiglx and enabling composite. Then triggering a gconf switch and done. I think if you cant handle that at the moment you are also not able to attach gdb and report bugs upstream properly which is what is required at the moment besides fixing more drivers up for it and getting bugs squashed. But yes i agree... the majority of win users can be easily attracted with nice eye candy that doesent need a dual core cpu (compare vista). > > I think any of the above would do more to increase adoption than merely > including mp3 support. Looking at mp3 support for me means looking back to nonfree legacy stuff. i never look back. regards, Rudolf Kastl p.s. as always just my personal opinion > > -Cam > > -- > > <-- > camilo at mesias.co.uk > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at adslpipe.co.uk Thu Apr 6 12:27:21 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 13:27:21 +0100 Subject: r200? was: Today's rawhide xorg/radeon In-Reply-To: References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org> Message-ID: <44350929.8000302@adslpipe.co.uk> Neal Becker wrote: > No dri/drm here, is it supposed to work? I think it's best to say that the chances are improving ;-) You need to update the following "above" FC5 kernel.x86_64 2.6.16-1.2121_FC6 xorg-x11-drv-ati-6.5.7.3-4.cvs20060404 xorg-x11-server-1.0.99.2-1 mesa-libGL.x86_64 6.5-1 mesa-libGLU.x86_64 6.5-1 From camilo at mesias.co.uk Thu Apr 6 12:33:19 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 06 Apr 2006 13:33:19 +0100 Subject: [OT] ntfsresize and RIP In-Reply-To: References: <44344923.7070805@mesias.co.uk> Message-ID: <44350A8F.9050808@mesias.co.uk> Rudolf >> others will not use Fedora because they aren't >> confident about partitioning disks or shrinking NTFS partitions. > > You cant do that with windows xp... you need addon tools whereas the > most known and easiest to find tools are proprietary. The win os just > doesent even provide those basic features and i doubt vista will fix > it because they have a tough time to catch up with their desktop to > not look like from 1995. I did it using free tools though. If anyone's interested I recommend RIP and ntfsresize. It is unglamorous but effective: http://www.tux.org/pub/people/kent-robotti/looplinux/rip/ http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html -Cam -- camilo at mesias.co.uk <-- From gajownik at fedora.pl Thu Apr 6 12:34:52 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 06 Apr 2006 14:34:52 +0200 Subject: Firefox Test Releases on Fedora In-Reply-To: References: Message-ID: <44350AEC.7010004@fedora.pl> Dnia 04/06/2006 05:23 AM, U?ytkownik Benjy Grogan napisa?: > 2) The middle button on the mouse doesn't allow other tabs to be > closed simply by middle-button-clicking the tabs. Open ?about:config? page and change value of ?middlemouse.contentLoadURL? variable (should be set to "false"). -- ^_* From fedora at adslpipe.co.uk Thu Apr 6 12:52:22 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 13:52:22 +0100 Subject: r200? was: Today's rawhide xorg/radeon In-Reply-To: References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org> Message-ID: <44350F06.4000100@adslpipe.co.uk> Neal Becker wrote: > No dri/drm here, is it supposed to work? I thought r200 was supposed to be working in FC5? From ivazquez at ivazquez.net Thu Apr 6 13:06:59 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 06 Apr 2006 09:06:59 -0400 Subject: r200? was: Today's rawhide xorg/radeon In-Reply-To: <44350F06.4000100@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> <4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org> <44350F06.4000100@adslpipe.co.uk> Message-ID: <1144328819.14119.0.camel@ignacio.lan> On Thu, 2006-04-06 at 13:52 +0100, Andy Burns wrote: > Neal Becker wrote: > > > No dri/drm here, is it supposed to work? > > I thought r200 was supposed to be working in FC5? The 200M is RS400 according to my man page. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From nomis80 at nomis80.org Thu Apr 6 13:19:39 2006 From: nomis80 at nomis80.org (Simon Perreault) Date: Thu, 6 Apr 2006 09:19:39 -0400 (EDT) Subject: Qt 4 RPM poke In-Reply-To: <4435078F.7080507@math.unl.edu> References: <200604050856.37985.nomis80@nomis80.org> <4434714B.6080902@math.unl.edu><200604060645.00607.dennis@ausil.us> <4435078F.7080507@math.unl.edu> Message-ID: <53019.132.203.30.153.1144329579.squirrel@mail.nomis80.org> On Thu, April 6, 2006 8:20, Rex Dieter said: > Yep. Both -devel pkgs (try to) define QTDIR pointing to themselves, so > I added the Conflicts. What would you suggest? One thing is certain: there should be *no* conflict between qt-devel and qt4-devel. It is very frequent to want to develop using Qt 3 and Qt 4 at the same time. Since QTDIR is not essential using Qt 4, it should be disabled in that package. Everything will work as long as stuff is installed in the location the configure script was told. From ndbecker2 at gmail.com Thu Apr 6 13:31:42 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 06 Apr 2006 09:31:42 -0400 Subject: r200? was: Today's rawhide xorg/radeon References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org> <44350F06.4000100@adslpipe.co.uk> Message-ID: Andy Burns wrote: > Neal Becker wrote: > >> No dri/drm here, is it supposed to work? > > I thought r200 was supposed to be working in FC5? > It's working fine, but no dri/drm. From linux_4ever at yahoo.com Thu Apr 6 13:40:45 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 6 Apr 2006 06:40:45 -0700 (PDT) Subject: Tripwire in Extras In-Reply-To: <20060405170413.6623a46b.fedora@wir-sind-cool.org> Message-ID: <20060406134045.9427.qmail@web51511.mail.yahoo.com> >There's also the problem of prelinking, which confuses these integrity >checkers and their users. And they all need to be taught about extended attributes. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dennis at ausil.us Thu Apr 6 13:41:47 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 6 Apr 2006 08:41:47 -0500 Subject: Qt 4 RPM poke In-Reply-To: <4435078F.7080507@math.unl.edu> References: <200604050856.37985.nomis80@nomis80.org> <200604060645.00607.dennis@ausil.us> <4435078F.7080507@math.unl.edu> Message-ID: <200604060841.48133.dennis@ausil.us> On Thursday 06 April 2006 07:20, Rex Dieter wrote: > Dennis Gilmore wrote: > > One problem i see with your package Rex is that qt4-devel conflicts > > with qt-devel so with out removing packages is impossible to develop > > with qt3 qnd qt4 at the same time. and this also means that qt-designer > > can only have one version installed also. > > Yep. Both -devel pkgs (try to) define QTDIR pointing to themselves, so > I added the Conflicts. What would you suggest? > > -- Rex qt4 not to define it. If building qt4 stuff I can define QTDIR in the makefile to point to qt4 until KDE 4 is released -- Regards Dennis Gilmore, RHCE Proud Australian From nphilipp at redhat.com Thu Apr 6 14:41:18 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 06 Apr 2006 16:41:18 +0200 Subject: Today's rawhide xorg/radeon In-Reply-To: <443506A8.5070201@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk> <4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org> <4434E7DD.4080707@adslpipe.co.uk> <1144321299.6227.129.camel@pmac.infradead.org> <443506A8.5070201@adslpipe.co.uk> Message-ID: <1144334478.2859.33.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-04-06 at 13:16 +0100, Andy Burns wrote: > Are there any "gentler" openGL tests I can try (I don't seem to have > glxgears apart from fgl_glxgears which fails due to using private > extensions) nils at gibraltar:~> rpm -qf `which glxgears` glx-utils-6.4.2-6 Try that. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From Curtis at GreenKey.net Thu Apr 6 15:42:38 2006 From: Curtis at GreenKey.net (Curtis Doty) Date: Thu, 06 Apr 2006 08:42:38 -0700 Subject: CVS system migration done In-Reply-To: <442873EC.1050702@GreenKey.net> References: <442873EC.1050702@GreenKey.net> Message-ID: <443536EE.8050202@GreenKey.net> Curtis Doty wrote: > Elliot Lee wrote: >> cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to a >> new system. Please let me know if there are any problems that need >> fixing... >> > 404 http://cvs.fedora.redhat.com/webfiles/ > > That was awhile ago. Right this instant I'm getting timeouts, though. HUP. The 404 is gone but the extras tarball is missing and the core tarball is a week old. :-( Or am I looking at this wrong? ../C From david at fubar.dk Thu Apr 6 16:19:32 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Apr 2006 12:19:32 -0400 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> Message-ID: <1144340373.7336.15.camel@daxter.boston.redhat.com> On Thu, 2006-04-06 at 12:25 +0100, Peter Robinson wrote: > Hi All, > > Been running FC5/rawhide for ages and absolutely love it but I have a > couple of queries wrt to various laptop support. There is also http://www.redhat.com/mailman/listinfo/fedora-laptop-list > Firstly with NetworkManager do we still need to run the network > scripts. The reason I ask with my laptop at work I have wired, and > home wireless and as a result it takes ages to time out on alternate > interfaces and increases boot time greatly. Or can I run the network > script with the 2 interfaces disabled for boot time (so just > localhost) and let NM deal with what ever interface is up. Ideally NM will get into shape so we don't need two network configuration stacks [1]. Either does something the other doesn't (NM does VPN very nicely, legacy scripts does things like interface bonding etc.) [1] : especially the way the old scripts rename networking networking interfaces coupled with how the kernel announces this back to user space is at best very broken wrt HAL/NetworkManager > Similarly what's the status of docking stations support? With my Dell > Latitude when ever I undock then redock the wired network interface > (tg3) doesn't work and it takes a reboot to fix. I think its to do > with routing of the physical output to either the local port or dock > port. Same with suspending it within the dock. I'm not sure about docking stations, sorry. > Otherwise this is a rocking release. Well done! Thanks :-) David From hughsient at gmail.com Thu Apr 6 16:35:31 2006 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 06 Apr 2006 17:35:31 +0100 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144340373.7336.15.camel@daxter.boston.redhat.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> Message-ID: <1144341331.26501.2.camel@localhost.localdomain> On Thu, 2006-04-06 at 12:19 -0400, David Zeuthen wrote: > I'm not sure about docking stations, sorry. Why not expose the docking status in HAL so that g-p-m and n-m can find out what's going on and modify policy accordingly? I don't have a fancy laptop that can dock, but I'm sure someone that does could take the code for the vendor specific set-lcd and get-lcd code and scripts and make this "just work". I think this is very vendor specific on how to get the docked status. Richard. From david at fubar.dk Thu Apr 6 19:25:23 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Apr 2006 15:25:23 -0400 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144341331.26501.2.camel@localhost.localdomain> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> <1144341331.26501.2.camel@localhost.localdomain> Message-ID: <1144351524.7336.22.camel@daxter.boston.redhat.com> On Thu, 2006-04-06 at 17:35 +0100, Richard Hughes wrote: > On Thu, 2006-04-06 at 12:19 -0400, David Zeuthen wrote: > > I'm not sure about docking stations, sorry. > > Why not expose the docking status in HAL so that g-p-m and n-m can find > out what's going on and modify policy accordingly? Ideally we would. And we would export a D-BUS interface with an EjectDockingStation() method and make the System menu in GNOME use this through a pretty icon or something. Or maybe if the docking station is hot-pluggable we wouldn't need this. > I don't have a fancy laptop that can dock, but I'm sure someone that > does could take the code for the vendor specific set-lcd and get-lcd > code and scripts and make this "just work". > > I think this is very vendor specific on how to get the docked status. Most if it is ACPI nowadays I think. From time to other I do try out my docking station for my T41 and the result varies. It would probably be useful to start a thread about this on the new fedora-laptop-list - I'm just not sure all the people we want on this list (including pjones, davej, Alan Cox) is on it yet. I would start by collecting data about docking stations; ask people how it works under Windows etc etc. David From rdieter at math.unl.edu Thu Apr 6 19:30:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 06 Apr 2006 14:30:21 -0500 Subject: Qt 4 RPM poke References: <200604050856.37985.nomis80@nomis80.org> <4434714B.6080902@math.unl.edu> Message-ID: Rex Dieter wrote: > Simon Perreault wrote: > >> You posted on March 13 a spec for Qt 4 that needed just a little bit of >> work before being submitted to Fedora Extras. What is the status on that >> RPM? > > I've got one ready. I'll submit it to Extras tomorrow morning. Submitted: http://bugzilla.redhat.com/bugzilla/188180 -- Rex From davej at redhat.com Thu Apr 6 19:42:28 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 6 Apr 2006 14:42:28 -0500 Subject: '-Wunused-param' in kernel compiles? In-Reply-To: <4433D98C.4050203@vc.cvut.cz> References: <4433D98C.4050203@vc.cvut.cz> Message-ID: <20060406194228.GW5804@redhat.com> On Wed, Apr 05, 2006 at 04:51:56PM +0200, Petr Vandrovec wrote: > If you can tell me how to rewrite this detection without relying on > -Werror, then we can probably > stop doing that. Wow, that's truly horrible ;-) (and incredibly fragile should newer gcc's ever add extra warnings to -Wall) Tomorrows kernel build will have -Wextra removed from the CFLAGS, so it should stop warning. Dave -- http://www.codemonkey.org.uk From k.healy at student.ucc.ie Thu Apr 6 19:51:08 2006 From: k.healy at student.ucc.ie (k.healy) Date: Thu, 6 Apr 2006 19:51:08 +0000 (UTC) Subject: Lock up after resume from S3 suspend when ide dma is enabled (FC5) References: <4433e80f.3c.5132.1315430907@student.ucc.ie> Message-ID: > There are some kernel messages showing up before it hangs, > but they don't get written to the log because of the ide > issues. I'm going to see if I can dump them to a usb flash > drive. Ok, I managed to grab some of the messages (manually, since everything was so locked up). ----- ... ohci_hcd 0000:00:02.0: wakeup ohci_hcd 0000:00:02.1: wakeup Restarting tasks... done ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] hda: dma_timer_expiry: dma status == 0x21 ----- > I've tried sysrq without success, but this is probably > because the video is locked up. Maybe sysrq over a serial > console - is this possible with the stock Fedora kernels? > I got a serial console going by adding the kernel parameter 'console=ttyS0'. Unfortunately, this doesn't survive the suspend, no matter whether ide dma is enabled or not, which suggests ide dma may not be the root cause. On that topic, I have been reading through LKML about nforce2 issues. About 2 years ago (kernels around 2.6.0 to 2.6.7), there was a problem with system lockups with a lot of the same symptoms. This was eventually traced to a timing issue in the nforce2 chipset connected to the "C1 disconnect" power management features. (Search for: nforce2 apic c1halt). As far as I know, there was no ACPI suspend support around at that time, so I'm wondering if this problem is being unmasked again by the ACPI suspend/resume code. Ken From mike at miketc.com Thu Apr 6 20:03:41 2006 From: mike at miketc.com (Mike Chambers) Date: Thu, 06 Apr 2006 15:03:41 -0500 Subject: [Fwd: Fedora Foundation] Message-ID: <1144353821.13630.1.camel@scrappy.miketc.com> Just in case any of you aren't on the Announce or Fedora lists, you can read this for yourself. Sorry for cross posting or if most have already read this, but didn't see anyone from either list (or I missed it) really commenting much on it. Mike -------- Forwarded Message -------- > From: Max Spevack > Reply-To: fedora-list at redhat.com > To: fedora-announce-list at redhat.com > Subject: Fedora Foundation > Date: Tue, 4 Apr 2006 22:55:32 -0400 (EDT) > > To my fellow Fedora community members: > > As many of you are aware, FUDCon Boston is this Friday. One of the most > important topics that we will be discussing there is the future of the > Fedora Project, specifically with regard to the Fedora Foundation. > > I'd like to ask you all to read the document that follows this note. It > reviews Red Hat's intentions in initially announcing the Fedora > Foundation, and outlines the problems that have led us to the decision to > move in a different direction. It also discusses the plan that we are > implementing instead, and the steps that we are taking to ensure that the > Fedora Project continues to thrive and grow. > > It is as complete, honest, and transparent as we can make it. If you feel > that there are places in which it lacks those qualities, call us on it, > and we will respond. > > This document represents the work of many people both inside of Red Hat > and within the Fedora community. It is a long read, but a very worthwhile > one. > > So take a look, read, digest, and share your thoughts. I look forward to > discussing this in great detail on email, and also with as many of you as > possible in person at LinuxWorld and at FUDCon over the next few days. > Many of Red Hat's most active Fedora folks will be at those two shows, so > please come and talk with us. > > Sincerely, > Max Spevack > > ========================= > > Last June, Red Hat announced its intention to launch the Fedora > Foundation. We've had a lot of smart people working hard to make this > Foundation happen, but in the end, it just didn't help to accomplish our > goals for Fedora. Instead, we are restructuring Fedora Project, with > dramatically increased leadership from within the Fedora community. > > The next obvious question -- "Why no Foundation?" -- deserves a detailed > explanation. > > === > > WHY NO FOUNDATION? > > When we announced the Foundation, it was with a very specific purpose, and > in a very specific context. The announcement was made by Mark Webbink, > who has been the intellectual property guru at Red Hat for a long time > now. His stated goal for the Foundation: to act as a repository for > patents that would protect the interests of the open source community. > > Once we announced the intention to form a Foundation, people inside and > outside of Red Hat were interested in working beyond the stated purpose -- > an intellectual property repository -- and instead saw this new Foundation > as a potential tool to solve all sorts of Fedora-related issues. Every > Fedora issue became a nail for the Foundation hammer, and the scope of the > Foundation quickly became too large for efficient progress. > > A team moved forward to create the Foundation itself. We created the > legal entity, came up with some very basic and flexible bylaws, and > appointed a board to run it temporarily. This all happened pretty > quickly, because this was the easy part. We had articles of incorporation > in September 2005. > > Then came the hard part: articulating the precise responsibilities of the > Foundation. This conversation took months, but ultimately it came back > around, again and again, to a single question: "What could a Fedora > Foundation accomplish that the Fedora Project, with strong community > leadership, could not accomplish?" > > So here, in order, were the possible answers to that question -- and why > we found, in every single case, that the Fedora Foundation was not the > right answer. > > ONE: The Fedora Foundation could be an entity for the development of an > open source patent commons. > > This was the obvious starting place, and what we actually announced. One > of the lurking concerns of the open source community is the threat of > software patents. The Fedora Foundation could have been an ideal > repository for defensive patents. We envisioned soliciting patentable > ideas from businesses and/or individuals, paying for the prosecution of > these patents, and then guaranteeing open source developers the > unrestricted right to code against these patents using a similar mechanism > to the Red Hat patent promise. > (http://www.redhat.com/legal/patent_policy.html). > > What we weren't counting on was the rapid progress of the Open Invention > Network (http://www.openinventionnetwork.com/press.html), which serves a > similar purpose for businesses in a much more compelling way. Without > going into too much detail, it became clear to us that OIN is going to be > the 800-pound gorilla in the patent commons space, and we were eager to > join forces. > > OK, so much for soliciting patents from businesses. What about > individuals? If we were to focus the Fedora Foundation's efforts on > soliciting patentable ideas from individuals, how many could we get? Our > gut decision: not many. Most developers who actually work for a living > have agreements with their employers that prevent them from pursuing > patents independently. Many university students who pursue patents are > required to grant them to the university. > > After putting a lot of work into the idea of a Fedora Foundation patent > commons, in the end it just didn't seem compelling. So we shelved the > idea. > > TWO: The Fedora Foundation could act as a single point of standing for > legal issues. > > The Free Software Foundation serves this purpose for the GNU projects. > We thought that the Fedora Foundation might successfully serve the same > purpose for Fedora projects. Have you ever noticed that the GNU projects > all require contributors to assign copyright to the FSF? That's because > there's this legal idea called "standing" that matters deeply to lawyers > and judges. Here's a little skit that helps to explain why standing is > important: > > BAILIFF: Come to order for case Z-38-BB-92. Plaintiff is Small Software > Project. Defendant is Great Big Computer Corporation. > > JUDGE: OK, have a seat, folks. The docket is busy today, and I've got a > doctor's appointment in two hours. Plaintiff, what's this all about? > > PLAINTIFF'S COUNSEL: Well, your honor, there's this license called the GPL > that the defendant is *totally* violating. Basically, they stole the > plaintiff's code and put it into their software program. > > DEFENDANT'S COUNSEL: Hold it right there. Your Honor, plaintiff doesn't > have standing in this case. There's 100 different developers that wrote > this code, and the plaintiff only represents six of them. Plaintiff > clearly doesn't even have the legal right to sue us, Your Honor. > > JUDGE: Looks like this case could be Pretty Hard, and this whole > "standing" thing gives me a perfect excuse not to think about it. > Counsel, get back to me when you've got the other 94 plaintiffs. > > So, standing is a big concern. In the world of lawyers, it's one of the > big potential unknowns around defending open source projects, especially > projects that have lots of contributors. > > The obvious problem with establishing standing in this way, though, is > that a single entity *must* own *everything* in your project. That's why > the FSF *requires* copyright assignment. > > What Fedora projects currently exist where copyright assignment makes > sense? > > Well... none, as it turns out. Let's look at some of the current Fedora > projects as examples. > > At present, the two most successful Fedora projects are Core and Extras -- > which, together, basically constitute a big Linux distribution. And what > is a distribution? Ideally, it's a high-quality repackaging and > integration of content owned by others. That's the whole point. In such > cases, copyright assignment makes no sense at all. > > Then there's the Fedora Documentation project, which produces > documentation and makes it available under the Open Publication License > (http://opencontent.org/openpub/) without options. Given the liberal > nature of this license, it just doesn't seem all that useful to ask > contributors to assign copyright for defense of these works. > > Then there's the Fedora Directory Server, which Red Hat purchased and open > sourced. No question who holds standing there; it's Red Hat. The time > may come when the Fedora Directory Server project is ready to incorporate > lots of changes from the community, but until that time comes, the > question of copyright assignment is pretty much a theoretical question. > > Which is what a lot of this comes down to -- the question of legal > standing is either an open or theoretical question at best, and probably > better left to an organization such as the FSF that focuses a great deal > more attention on these types of questions. > > Put another way: we have a finite amount of resources to make Fedora > better. How much of that cash should be going to expensive lawyers -- > especially if Red Hat already has lawyers who have a strong incentive to > defend Fedora, should such a defense prove to be necessary? > > So the Fedora Foundation didn't seem compelling as a mechanism for > copyright assignment, either. > > THREE: The Fedora Foundation could act as an entity for funding > Fedora-related activities that Red Hat didn't have great interest in > funding. > > Funny thing, that. We asked some of our closest friends this question: > "Would you donate to an independent Fedora Foundation?" The answers were > very interesting, and ran the gamut. Some people were incredibly > enthusiastic: "We'd love to give money!" Some were neutral: "Thanks, but > we'd rather contribute code." And some were less enthusiastic: "Red Hat > is a successful, profitable company. Why are you asking *me* for money?" > > Here's another funny thing: if you choose to incorporate as a non-profit > entity in the United States, then you subject yourself to a number of > rigorous IRS tax tests. One of these tests is the "public support test." > If you say you're a public charity, well by golly, you have to prove it. > If, within four years, you aren't collecting fully one third of your money > from public sources, then you're not actually a public charity. > > People are always shocked when we tell them how many resources Red Hat > puts into Fedora. If we were to make the Fedora Foundation a truly > independent entity, then we'd have to track every dime of that expense as > "in-kind contributions". That means we'd have to track: > > * The cost of bandwidth for distributing Fedora to the world; > > * Every hour that Red Hat engineers spend working on Fedora, whether that > is the actual writing of code, release engineering, testing, etc.; > > * Legal expenses of running a Foundation; > > * Administrative expenses of running a Foundation. > > As an intellectual exercise, let's ignore all of those numbers for now > except for bandwidth. Back in the day, when Red Hat would release a > distro, we would regularly get angry calls from network admins at big > datacenters, complaining that we were eating all of their bandwidth. If > you ever meet any of our IT guys over a beer, be sure to ask them about > the time we melted a switch at UUNet. > > The demand for Fedora is every bit as high, and the March 20 release of > Fedora Core 5 was no exception. So let's take a conservative guess and > say that the bandwidth cost for distributing Fedora comes to $1.5 million > a year. Yes, even though we have BitTorrent trackers and Fedora mirror > sites worldwide. > > That means that a public Fedora Foundation would have to raise $750k in > public funds -- remember the one-third public support test -- every single > year, just to pay for *bandwidth*, assuming no growth and no other > expenses. > > So what would happen, under such a scenario, if Red Hat were to decide to > spend more money on Fedora? Because that's exactly what Red Hat wants to > do. > > There were alternatives to the public charity angle. We could have set up > a private operating foundation, and we explored this avenue -- but then it > wouldn't really be an independent entity. It would be a shell. The fact > that Red Hat would still likely bear the legal risk of Foundation > decisions, and the complication of raising public funds, made any 501(c) > less attractive. > > In short: the fund raising burden for a truly independent Fedora > Foundation would be terrifying. So the Fedora Foundation clearly wasn't > compelling as a fund raising entity -- if anything, it represented an > impediment to building a better Fedora Project. > > FOUR: The Fedora Foundation could provide mechanisms for more community > participation in key decision-making processes. > > >From the day the Fedora Project was started over two years ago, it's been > our goal to build these mechanisms, Foundation or no Foundation. How > successful have we been? > > Initially, we had some problems. In the last year, though, we've had some > pretty clear successes. The Fedora Extras project is a good example here. > When we officially launched it in February 2005 at FUDCon Boston, we put > together a steering committee that consisted of a pretty even mix of Red > Hat and community packagers. At FUDCon Germany last summer, we > strengthened the group with more European members. Earlier this year, we > successfully handed off leadership of the committee to a community member. > Red Hat continues to provide logistical and legal support, but Fedora > Extras policy is determined by the community. > > So what happens when the Fedora Extras Steering Committee (also known as > FESCO) runs into difficulty? Well, they escalate the issue to "the > Board." And who is "the Board?" It's been the people running the Fedora > Foundation -- but it's also been the people running the Fedora Project. > Whenever "the Board" had been asked to make a decision, there's been no > practical distinction between "Project" and "Foundation." > > What *is* vital, whether we're talking about "The Foundation" or "The > Project," is the actual presence of community members on the board -- but > more on that later. > > FIVE: The Fedora Foundation could serve as a truly independent entity, > providing the ability for Fedora to grow separately from Red Hat's > interests. > > This is the real heart of the matter. This is what some people want to > see: a more independent Fedora. This is The Question That Must Be > Answered. > > The simple and honest answer: Red Hat *must* maintain a certain amount of > control over Fedora decisions, because Red Hat's business model *depends* > upon Fedora. Red Hat contributes millions of dollars in staff and > resources to the success of Fedora, and Red Hat also accepts all of the > legal risk for Fedora. Therefore, Red Hat will sometimes need to make > tough decisions about Fedora. We won't do it often, and when we do, we > will discuss the rationale behind such decisions as openly as we can -- as > we did with the recent Mono decision. > > But just because Red Hat has veto power over decisions, it does not follow > that Red Hat wants to use that power. Nor does it follow that Red Hat > must make all of the important decisions about Fedora. In fact, effective > community decision making is one of the most direct measures of Fedora's > success. > > The most important promise about Fedora -- once free, always free -- still > stands. We aim to set the standard for open source innovation. A truly > open Fedora Project is what makes that possible. > > === > > THE NEW FEDORA PROJECT LEADERSHIP MODEL > > Since Fedora's inception two years ago, a diverse global community has > developed around Fedora -- and, as in any open source project, natural > leaders have emerged. The time has come to reward some of these leaders > with the opportunity to define the direction of the Fedora Project at the > highest level. > > Therefore, we've reconstituted the Fedora Project Board to include these > community leaders directly. > > Initially, there are nine board members: five Red Hat members and four > Fedora community members. This Board is responsible for making all of the > operational decisions of the greater Fedora project, including decisions > about budget and strategic direction. > > In addition to the nine board members, there is also be a chairman > appointed by Red Hat, who has veto power over any decision. It's our > expectation that this veto power will be used infrequently, since we're > all aware of the negative consequences that could arise from the use of > such power in a community project. > > The chairman of the Fedora Project is Max Spevack. Max has been with Red > Hat since 2004, previously as a QA engineer and QA team lead for Red Hat > Network. He is a member of the Fedora Ambassadors steering committee, and > has been a Linux user since 1999. > > The Fedora Project board members from Red Hat are Jeremy Katz, Bill > Nottingham, Elliot Lee, Chris Blizzard, and Rahul Sundaram. > > Jeremy Katz is a Red Hat engineer. He is the longtime maintainer for > Anaconda, and a founding member of the Fedora Extras steering committee. > > Bill Nottingham joined Red Hat in May of 1998, working on projects ranging > from the initial port of Red Hat Linux to ia64, booting and hardware > detection, multilib content definition and fixing, and is currently doing > work related to stateless Linux. He's also been involved in various > technical lead details, such as package CVS infrastructure and > distribution content definition. > > Elliot Lee has been a software engineer at Red Hat since 1996. His open > source contributions include release engineering for Fedora Core, > co-founding the GNOME project, and maintaining assorted open source > libraries and utilities. He is a founding member of the Fedora Extras > steering committee. Elliot current leads the Fedora infrastructure team, > making it easier and enjoyable for contributors to get more done. > > Chris Blizzard is an engineering manager for Red Hat. He has served on > the board of the Mozilla Foundation, and is currently leading the One > Laptop Per Child project for Red Hat. > > Rahul Sundaram is a Red Hat associate based in Pune, India. He is a > longstanding contributor to multiple Fedora projects, a Fedora Ambassador > for India, and a member of the Fedora Ambassadors steering committee. > > The Fedora Project board members from the community are Seth Vidal, Paul > W. Frields, Rex Dieter, and a fourth board member to be named as soon as > possible. > > Seth Vidal is the project lead for yum, which is one of the key building > blocks for software management in Fedora. He also maintains mock, the > basis for the Fedora Extras build system. He is a founding member of the > Fedora Extras steering committee, and he was one of the people chiefly > responsible for the first ever release of Fedora Extras packages in 2005. > Seth is also the lead administrator of the infrastructure at > fedoraproject.org, which includes the Fedora project wiki, RSS feed > aggregator, and bittorrent server. > > Paul W. Frields has been a Linux user and enthusiast since 1997, and > joined the Fedora Documentation Project in 2003, shortly after the launch > of Fedora. As contributing writer, editor, and a founding member of the > Documentation Project steering committee, Paul has worked on a variety of > tasks, including the Documentation Guide, the Installation Guide, the > document building infrastructure, and the soon-to-emerge RPM packaging > toolchain. Paul is also a Fedora Extras package maintainer. > > Rex Dieter works as Computer System Administrator in the Mathematics > Department at the University of Nebraska Lincoln. Rex is a KDE advocate > and founded the KDE Red Hat project. He is also an active contributor to > Fedora Extras. Rex lives in Omaha, Nebraka, with his wife, 2 children, > and 4 cats. > > It's true that a lot of the key governance details -- term length, board > composition, election or appointment process -- have yet to be resolved. > One of the first responsibilities of the new board will be to work with > the Fedora community to answer these questions. > > === > > Red Hat has been supporting a free Linux distribution for over ten years, > and Red Hat will *always* support a free Linux distribution. We want to > work together with the Fedora community to make Fedora better. We want a > Fedora that is a true partnership between Red Hat and the community. We > want to build effective models to make that partnership real. We want to > see the folks at MySQL managing MySQL in Fedora. We want to see the folks > from kde.org managing KDE in Fedora. We want to see the folks at Planet > CCRMA managing audio production applications in Fedora. We want Fedora to > be a launching pad not just for open source software, but for open content > of all kinds. We want the Fedora Project to be a way to fill the > community with high quality software and content, and we want to empower > the Fedora community to innovate in ways we'd never even considered. > > The new Fedora Project Board has a strong mandate to make these things > happen, and has the full support of Red Hat. We ask that you, the members > of the Fedora community, give them your full support as well, and we thank > you for all the support you've given us so far. We would not have made it > nearly this far without your patience, your friendship, and your tireless > help. From dwmw2 at infradead.org Thu Apr 6 21:04:00 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 22:04:00 +0100 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144340373.7336.15.camel@daxter.boston.redhat.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> Message-ID: <1144357440.11116.31.camel@shinybook.infradead.org> On Thu, 2006-04-06 at 12:19 -0400, David Zeuthen wrote: > Ideally NM will get into shape so we don't need two network > configuration stacks [1]. Either does something the other doesn't (NM > does VPN very nicely, legacy scripts does things like interface > bonding etc.) That and bridges, bluetooth, IPv6, DSL, correct handling of system WEP keys which the user isn't allowed to know, etc... -- dwmw2 From sundaram at fedoraproject.org Thu Apr 6 21:23:58 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Apr 2006 02:53:58 +0530 Subject: [Fwd: Fedora Foundation] In-Reply-To: <91f88ee20604061359x27bd87a0m9e3a58082e8cbce4@mail.gmail.com> References: <1144353821.13630.1.camel@scrappy.miketc.com> <91f88ee20604061359x27bd87a0m9e3a58082e8cbce4@mail.gmail.com> Message-ID: <1144358638.24151.169.camel@sundaram.pnq.redhat.com> Hi > However some development cycles need tighter release control -- like > the Kernel for example (not that I am picking on any one particular > portion of this past FC5 testing cycle.) Are people running FC > installations truly in earnest of implementing software so quickly? Everytime any version as been withheld as updates there have been requests for it. So I assume they are. Kernel is one of top five components getting the largest number of bug reports for a long time simply because it is critical and covers a large amount of core aspects of the system and all these updates fix a ton of them. > Seems like another software outfit liked to push testing of their core > OpSys out onto the end users shoulders. What is OpSys? Core development and testing is to be done within the external community too and that needs to be much more than what is present currently. Development pace within a project improves when the line between end users and developers blurs. > But, maybe I have become > blinded to the greater SDLC. What is SDLC? > > > > The most important promise about Fedora -- once free, always free -- still > > > stands. We aim to set the standard for open source innovation. A truly > > > open Fedora Project is what makes that possible. > > Free until the "best of breed" projects are pulled into RHEL and then > what? Not necessarily all the best of breed components but what fits into RHEL product space. RHEL is open source too. So its Free in that aspect > A code split? Branches off into RHEL and then Red Hat starts maintaining it as a product. > Maybe this is where my understanding of Fedora's > relationship to RHEL breaks down... If you got any specific questions, let me know especially if that understanding is relevant to Fedora. Rahul From david at fubar.dk Thu Apr 6 21:40:57 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 06 Apr 2006 17:40:57 -0400 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144357440.11116.31.camel@shinybook.infradead.org> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> <1144357440.11116.31.camel@shinybook.infradead.org> Message-ID: <1144359657.7336.34.camel@daxter.boston.redhat.com> On Thu, 2006-04-06 at 22:04 +0100, David Woodhouse wrote: > That and bridges, bluetooth, IPv6, DSL, correct handling of system WEP > keys which the user isn't allowed to know, etc... Yup. And it's only going to take longer as long as people like yourself only sends patches for Bluetooth stuff etc. to the legacy scripts instead of NetworkManager. David From fedora at adslpipe.co.uk Thu Apr 6 21:45:04 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Thu, 06 Apr 2006 22:45:04 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <1144334478.2859.33.camel@gibraltar.stuttgart.redhat.com> References: <443439D9.70706@adslpipe.co.uk> <443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org><4434E7DD.4080707@adslpipe.co.uk><1144321299.6227.129.camel@pmac.infradead.org><443506A8.5070201@adslpipe.co.uk> <1144334478.2859.33.camel@gibraltar.stuttgart.redhat.com> Message-ID: <44358BE0.20807@adslpipe.co.uk> Nils Philippsen wrote: > nils at gibraltar:~> rpm -qf `which glxgears` > glx-utils-6.4.2-6 thanks, my box was still running rawhide from just before FC5, I remember some discussion about glxinfo/glxgears being awol a while back, anyway, today the box has been flattened and is now running FC5+updates, I'll add selective parts of rawhide (x/mesa/kernel) to just to test r300 dri/drm again ... From dwmw2 at infradead.org Thu Apr 6 22:45:44 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Apr 2006 23:45:44 +0100 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144359657.7336.34.camel@daxter.boston.redhat.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> <1144357440.11116.31.camel@shinybook.infradead.org> <1144359657.7336.34.camel@daxter.boston.redhat.com> Message-ID: <1144363545.11116.51.camel@shinybook.infradead.org> On Thu, 2006-04-06 at 17:40 -0400, David Zeuthen wrote: > Yup. And it's only going to take longer as long as people like yourself > only sends patches for Bluetooth stuff etc. to the legacy scripts > instead of NetworkManager. I _was_ sending patches for NetworkManager at one point -- it didn't even work with IPv6 until I fixed it, which was fairly surprising. You might need a $30 budget to test Bluetooth, but IPv6 is free. Fixing NM to support Bluetooth PAN has been on my TODO list for a while, but of _course_ the standard initscripts were far more of a priority. -- dwmw2 From ivg2 at cornell.edu Fri Apr 7 01:03:54 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 06 Apr 2006 21:03:54 -0400 Subject: rawhide report: 20060405 changes In-Reply-To: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> Message-ID: <4435BA7A.5090204@cornell.edu> > > xorg-x11-server-1.0.99.2-1 > -------------------------- > * Tue Apr 04 2006 Kristian H??gsberg 1.0.99.2-1 > - Update to 1.0.99.2 snapshot and go back to using mesa-source package. > - Drop xorg-server-1.0.99-composite-visibility.patch. > - Drop xorg-server-1.0.1-backtrace.patch. > - Drop xorg-server-0.99.3-rgb.txt-dix-config-fix.patch. > - Add xorg-server-1.0.99.2-spiffiffity.patch. > > * Thu Mar 23 2006 Kristian H??gsberg > - Pass --with-dri-driver-path so we're sure to point it to the right path. > > * Wed Mar 22 2006 Soren Sandmann 1.0.99.1-2 > - Add xorg-server-1.0.99-composite-visibility.patch to get rid of flashing > titlebars in compositing metacity. > Crashes the closed Nvidia driver for me, and *that* is really bad, since it's the only driver I can use, there is no other functional graphics driver on my computer. I tried fbdev ("does not support EGA/VGA planes"), vesa (graphics corruption), vga (8-bit depth max, totally unusable), and of course nv, which has been broken since blocker bug #182396, which nobody has looked at yet. Backtrace: 0: /usr/bin/Xorg (xf86SigHandler + 0x82) 1: /lib64/libc.so.6 Hardware: x86_64, Nvidia GeForce 6800 GS 256 Software: Fedora Core/Extras/Livna Rawhide ========== It did force me to find a workable non-nvidia solution, however. It seems that doing: modprobe vga16fb, and then running the nv driver makes it work (until I restart X, at which point graphics get corrupted again). I also tried fbdev in between, maybe that matters. From wtogami at redhat.com Fri Apr 7 01:21:34 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 06 Apr 2006 21:21:34 -0400 Subject: FC 5 libraw1394 as static library In-Reply-To: <44351557.2070504@gmail.com> References: <44351557.2070504@gmail.com> Message-ID: <4435BE9E.5040000@redhat.com> S?bastien S?n?gas wrote: > Hi, > > I enjoy with the libraw1394 that you support. But i am using now a FC 5 > wich is distributed with the libraw1394 as shared library. So my > question is what should I do to get the library as static. Should I just > recompile it or there is a package existing directly built for this > distrib. I tried to get a package with yum but without any success. > Could you help me please > S?bastien > It is generally against Fedora policy to ship static libraries in the distribution so we have been actively removing them over time. In the vast majority of cases supported by the Fedora distribution, static libraries are actually not needed and programs that linked them in can be easily modified to link to the dynamic library. If you are using the static library for some less usual case like embedded systems or profiling, then you should build your own static library from source manually. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Apr 7 01:43:34 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 06 Apr 2006 21:43:34 -0400 Subject: Asian Squirrelmail trouble In-Reply-To: <39981.216.248.170.114.1144342562.squirrel@www.hyde-tech.com> References: <39981.216.248.170.114.1144342562.squirrel@www.hyde-tech.com> Message-ID: <4435C3C6.6030706@redhat.com> Hyde Yamakawa wrote: > Hello, sir, > > I am the one asked to fix the Japanese encoding problem of > squirrelmail-1.4.6-3.fc4 and thank you again for your fixing. > > I have two more concerns about this squirellmail. > One is the file name in Japanese is mis decoded when save the > attached file. > And another is mis decoding part of Japanese in body sometimes. > > Should I report these to bugzilla also? > > I am just wondering if these are known and inpossible to fix > because they have been existing quite long time. > > I am sorry but if you can speak Japanese so I wrote in English. > Which is better English or Japanese? > I am Japanese. > > Regards, > Hyde > Sorry, my Japanese language skill is very poor so I must communicate in English for now. We are not happy about squirrelmail because it is poorly maintained by the upstream project and "stuck in the past" with very little progress and very poor support for non-Western language encodings. I *want* to replace squirrelmail with something more modern, with strong commercial and community support behind the project, and well designed international encoding support. But I don't have time to seek, test, and package alternatives to squirrelmail currently. One of our European engineers dwmw2 tried to improve the Unicode situation in our squirrelmail with the current scripted conversion hack in an attempt to workaround upstream squirrelmail's horrible localization policy where their encodings are inconsistently mixed. This improved things a bit only for some European languages, but not the Asian languages. As you may be well aware, it is currently infeasible to expect the Asian countries to use only Unicode encoding due to the constantly moving standards and different glyphs in different languages using the same code-points, among other problems. In order to support the current reality of language specific encodings in Asian languages, it would require native developers to "fix" the problem and submit patches upstream. This however is going to be a difficult problem because there is no easy agreement among developers and users in those countries about what exactly is the "best" way of doing it. To make matters worse, if you look at the current squirrelmail code it is full of ugly hacks in support of Asian encodings that bafflingly make little sense. For example, why the heck is the web interface in EUCJP encoding while e-mail sent and received is ISO-2022-JP by default? Within Japan for example, currently users are using mainly ISO-2022-JP, which is the default encoding in Microsoft Windows XP and below. I heard that Windows Vista will be UTF-8 by default with support for the new government mandated JIS X 0213:2004 standard in the private area. Fedora has been UTF-8 for a long time now. I suspect this is a cause of "wrong" encodings when saving files from squirrelmail because some users want the Windows XP default of ISO-2022-JP encodings and other users want UTF-8 encodings? I don't know for certain and don't have time to research this myself. In any case, these encoding troubles for Asian software are difficult to solve due to the bewildering reality of conflicting requirements and necessity of supporting both legacy and new systems. Squirrelmail will probably never be fixed by the current upstream project. If you want it to be fixed, then native Japanese developers will need to work on it, then convince the upstream project to accept their patches. Sorry I cannot be more helpful. Warren Togami wtogami at redhat.com From ivg2 at cornell.edu Fri Apr 7 04:55:20 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 07 Apr 2006 00:55:20 -0400 Subject: rawhide report: 20060405 changes In-Reply-To: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> Message-ID: <4435F0B8.7040805@cornell.edu> > vim-1:7.0c.000-1 > ---------------- > * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 > - vim-7.0c BETA > > * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 > - Rawhide build as vim, opposed to vim7 (prerelease) > - conflict with older man-pages-{it,fr} packages > - cleanup lang stuff > > * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 > - make it coexist with vim-6 (temporarily) > - new CVS snapshot > Pressing arrows in insert mode prints A,C,B,D instead of moving the cursor... From vonbrand at inf.utfsm.cl Fri Apr 7 01:19:16 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Thu, 06 Apr 2006 21:19:16 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: Your message of "Wed, 05 Apr 2006 17:16:22 -0400." <20060405211622.GB16936@thyrsus.com> Message-ID: <200604070119.k371JG9s003532@pincoya.inf.utfsm.cl> Eric S. Raymond wrote: > Horst von Brand : > > Which SUSE? The paid one? No problem, they can pay for the codecs. > Which, I'm suggesting, Red Hat could do also. I don't undesstand why this > is a difficult concept. Because this is Fedora, not Red Hat. That seems to be the hard-to-grasp concept here... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From dakingun at gmail.com Fri Apr 7 05:18:48 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 7 Apr 2006 01:18:48 -0400 Subject: rawhide report: 20060405 changes In-Reply-To: <4435F0B8.7040805@cornell.edu> References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> <4435F0B8.7040805@cornell.edu> Message-ID: On 4/7/06, Ivan Gyurdiev wrote: > > > vim-1:7.0c.000-1 > > ---------------- > > * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 > > - vim-7.0c BETA > > > > * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 > > - Rawhide build as vim, opposed to vim7 (prerelease) > > - conflict with older man-pages-{it,fr} packages > > - cleanup lang stuff > > > > * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 > > - make it coexist with vim-6 (temporarily) > > - new CVS snapshot > > > Pressing arrows in insert mode prints A,C,B,D instead of moving the > cursor... > This build seems not to be reading /etc/vimrc, which might be causing this and a bunch of other issues too, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188112. I believe the maintainer is looking into it. Deji From n0dalus+redhat at gmail.com Fri Apr 7 07:21:02 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 7 Apr 2006 16:51:02 +0930 Subject: Firefox Test Releases on Fedora In-Reply-To: References: Message-ID: <6280325c0604070021t57f4ca15me0ae6ba882874c1@mail.gmail.com> On 4/6/06, Benjy Grogan wrote: > > But here are the minor nuisances I've experienced with Firefox 1.5.0.1 on FC5: I've seen most of these problems in all Firefox releases for Linux that I can remember. > 1) The middle button on the mouse doesn't allow the scroll button to > appear, so that I can navigate up and down long web pages. Enable autoscroll. > 2) The middle button on the mouse doesn't allow other tabs to be > closed simply by middle-button-clicking the tabs. Whenever I start a fresh Firefox install the first thing I do is about:config, type 'middle' in the search box, and disable middlemouse.contentLoadURL. This is set like this on UNIX platforms because they think we will want to use middle mouse pasting to load urls. Personally I think being able to close a tab is much more useful. > 3) Certain keywords, such as 'wp linux' to look up Linux in Wikipedia > don't work. Redhat replaces all of Firefox's default bookmarks instead of just adding to them :(. I filed a bug about this, but I don't think anyone noticed at the time: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178069 n0dalus. From buildsys at redhat.com Fri Apr 7 07:27:45 2006 From: buildsys at redhat.com (Build System) Date: Fri, 7 Apr 2006 03:27:45 -0400 Subject: rawhide report: 20060407 changes Message-ID: <200604070727.k377RjsG018060@porkchop.devel.redhat.com> Updated Packages: alsa-utils-1.0.11-5.rc2 ----------------------- * Thu Apr 06 2006 Martin Stransky 1.0.11-5.rc2 - fixed rules file (#186494) - fixed Audigi mixer switch (#187807) apr-1.2.6-2 ----------- * Thu Apr 06 2006 Joe Orton 1.2.6-2 - update to 1.2.6 apr-util-1.2.6-2 ---------------- * Thu Apr 06 2006 Joe Orton 1.2.6-2 - update to 1.2.6 - define LDAP_DEPRECATED in apr_ldap.h (r391985, #188073) audit-1.1.6-1 ------------- * Thu Apr 06 2006 Steve Grubb 1.1.6-1 - New message types - Support new rule format found in 2.6.17 and later kernels - Add support for audit by role, clearance, type, sensitivity cups-1:1.2-0.2.rc1.7 -------------------- * Thu Apr 06 2006 Tim Waugh 1:1.2-0.2.rc1.7 - Build requires openldap-devel. - Sync pstops.c with svn 5372. gcc-4.1.0-6 ----------- * Thu Apr 06 2006 Jakub Jelinek 4.1.0-6 - update from gcc-4_1-branch (-r) - PRs classpath/24752, classpath/27028, libgcj/26625, libgcj/27024, tree-optimization/26996 - reenable PR c++/19238, c++/21764 fixes, only PR c++/21581 is not applied - better fix for Java GC vs. pthread_create (Bryce McKinlay, #, PR libgcj/13212) - fix objc_push_parm (#185398) - fix ICE with -feliminate-dwarf2-dups and using namespace (#187787, PR debug/27057) * Wed Apr 05 2006 Jakub Jelinek 4.1.0-5 - update from gcc-4_1-branch (-r112431:112706) - PRs bootstrap/26936, bootstrap/27023, classpath/25924, fortran/19303, fortran/25358, fortran/26816, java/25414, java/26042, java/26858, libfortran/26735, libgcj/26990, libstdc++/26777, testsuite/25741, tree-optimization/18527, tree-optimization/26763, tree-optimization/26830 - merge gomp changes from trunk (-r112602:112603 and -r112618:112619) - temporarily revert PR c++/21764, c++/19238, c++/21581 fixes (#187399) ghostscript-8.15.1-8 -------------------- * Thu Apr 06 2006 Tim Waugh 8.15.1-8 - Fix pdfwrite (bug #187834). - CUPS filters go in /usr/lib/cups/filter even on lib64 platforms. gnome-power-manager-2.15.0-1 ---------------------------- * Fri Apr 07 2006 Ray Strode - 2.15.0-1 - update to 2.15.0 to get the cool new runtime analysis graphs. * Mon Mar 27 2006 Ray Strode - 2.14.0-2 - use blank screensaver when lid is closed instead of of turning off screensaver completly (bug 186849). httpd-2.2.0-6 ------------- * Thu Apr 06 2006 Joe Orton 2.2.0-6 - rebuild to pick up apr-util LDAP interface fix (#188073) kde-i18n-1:3.5.2-1 ------------------ * Mon Apr 03 2006 Than Ngo 1:3.5.2-1 - update to 3.5.2 kdeaddons-3.5.2-1 ----------------- * Thu Apr 06 2006 Than Ngo 3.5.2-1 - update to 3.5.2 kdenetwork-7:3.5.2-1 -------------------- * Thu Apr 06 2006 Than Ngo 7:3.5.2-0.1.fc5 - update to 3.5.2 kdepim-6:3.5.2-1 ---------------- * Wed Mar 29 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 6:3.5.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes kernel-2.6.16-1.2122_FC6 ------------------------ * Thu Apr 06 2006 Dave Jones - Rebuild without a zillion warnings. man-pages-pl-0.24-2 ------------------- * Thu Apr 06 2006 Karsten Hopp 0.24-2 - remove some vim man pages provided by current vim metacity-2.15.0-3 ----------------- * Thu Apr 06 2006 Soren Sandmann - 2.16.0-3 - Bump libcm to 0.0.18. mkbootdisk-1.5.3-2 ------------------ * Thu Apr 06 2006 Peter Vrabec 1.5.3-2 - change noarch back to ExclusiveArch net-tools-1.60-66 ----------------- * Thu Apr 06 2006 Radek Vok??l - 1.60-66 - add note about -T to netstat policycoreutils-1.30.4-4 ------------------------ * Thu Apr 06 2006 Karsten Hopp 1.30.4-4 - added some missing buildrequires - added Requires: initscripts for /sbin/service * Thu Apr 06 2006 Karsten Hopp 1.30.4-3 - use absolute path /sbin/service scim-1.4.4-13 ------------- * Fri Apr 07 2006 Jens Petersen - 1.4.4-13 - update to scim-bridge-0.1.4 selinux-policy-2.2.29-4 ----------------------- * Thu Mar 30 2006 Dan Walsh 2.2.29-4 - More textrel_shlib_t file path fixes - Add ada support subversion-1.3.1-4 ------------------ * Thu Apr 06 2006 Joe Orton 1.3.1-4 - move libsvn_swig_ruby* back to subversion-ruby system-config-printer-0.6.151.2-1 --------------------------------- * Wed Mar 29 2006 Tim Waugh 0.6.151.2-1 - 0.6.151.2: - Prevent traceback seen in bug #163125. * Wed Mar 29 2006 Tim Waugh 0.6.151.1-1 - 0.6.151.1: - Don't make the Action->Sharing... menu entry insensitive (bug #187239). tzdata-2006c-1 -------------- * Thu Apr 06 2006 Petr Machata - 2006c-1 - Upstream 2006c - Time-related changes: - dozens of historical and commentary changes - Iran stopped observing DST - Sri Lanka switches from UTC+6 to UTC+5:30 - America/Thule and America/Edmonton will adopt new US rules, starting 2007 - Tunisia is adopting regular DST - Code: - asctime.c: Chages in format strings to silent gcc warnings - removing K&R notation from function signatures - few fixes across the code * Thu Mar 16 2006 Petr Machata - 2006b-2 - Patch for Sri Lanka time zone change (#184514) wireless-tools-1:28-0.pre16.1.6 ------------------------------- * Thu Apr 06 2006 Dan Williams - 1:28-0.pre16.1 - Update to 28 pre16 - Rebuild for WE-20 xorg-x11-server-1.0.99.2-2 -------------------------- * Thu Apr 06 2006 Adam Jackson 1.0.99.2-2 - Remove LBX to match upstream policy. - Add Xephyr server. * Tue Apr 04 2006 Kristian H??gsberg 1.0.99.2-1 - Update to 1.0.99.2 snapshot and go back to using mesa-source package. - Drop xorg-server-1.0.99-composite-visibility.patch. - Drop xorg-server-1.0.1-backtrace.patch. - Drop xorg-server-0.99.3-rgb.txt-dix-config-fix.patch. - Add xorg-server-1.0.99.2-spiffiffity.patch. * Thu Mar 23 2006 Kristian H??gsberg - Pass --with-dri-driver-path so we're sure to point it to the right path. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) mkbootdisk - 1.5.3-1.noarch requires syslinux rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 mkbootdisk - 1.5.3-1.noarch requires syslinux Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 From imcc at spsoftindia.com Fri Apr 7 09:37:48 2006 From: imcc at spsoftindia.com (imcc) Date: Fri, 7 Apr 2006 15:07:48 +0530 Subject: how to check file is open Message-ID: Hi, I am currently working on backup application which portable On Linux, windows and MAC-Osx . While taking the backup I want to exclude those files Which are open. In Linux lsof uses /proc//fd directory to list Open files. Q. In windows how to check whether a file is already Open or not. Is there any API for this checking or file property to check? Sunil SPSOFT -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Fri Apr 7 10:09:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 07 Apr 2006 11:09:04 +0100 Subject: how to check file is open In-Reply-To: References: Message-ID: <44363A40.4010801@city-fan.org> imcc wrote: > Hi, > > I am currently working on backup application which portable > > On Linux, windows and MAC-Osx . > > > > While taking the backup I want to exclude those files > > Which are open. > > > > > > In Linux lsof uses /proc//fd directory to list > > Open files. > > > > Q. In windows how to check whether a file is already Open or not. > > > > Is there any API for this checking or file property to check? A better option would be use the Volume Shadow Copy Service on Windows, which enables backup of open files. That's what the bacula client for Windows does anyway. http://www.bacula.org/rel-manual/Windows_Version_Bacula.html#SECTION000397000000000000000 Paul. From fedora at adslpipe.co.uk Fri Apr 7 10:29:35 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Fri, 07 Apr 2006 11:29:35 +0100 Subject: Today's rawhide xorg/radeon In-Reply-To: <443506A8.5070201@adslpipe.co.uk> References: <443439D9.70706@adslpipe.co.uk><443440BA.50103@adslpipe.co.uk><4434AF05.5020103@hhs.nl><1144315228.6227.126.camel@pmac.infradead.org><4434E7DD.4080707@adslpipe.co.uk><1144321299.6227.129.camel@pmac.infradead.org> <443506A8.5070201@adslpipe.co.uk> Message-ID: <44363F0F.3000301@adslpipe.co.uk> Andy Burns wrote: > I guess now it *is* time to hit bugzilla? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188228 From dwmw2 at infradead.org Fri Apr 7 11:16:18 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 07 Apr 2006 12:16:18 +0100 Subject: Asian Squirrelmail trouble In-Reply-To: <4435C3C6.6030706@redhat.com> References: <39981.216.248.170.114.1144342562.squirrel@www.hyde-tech.com> <4435C3C6.6030706@redhat.com> Message-ID: <1144408578.4097.22.camel@pmac.infradead.org> On Thu, 2006-04-06 at 21:43 -0400, Warren Togami wrote: > One of our European engineers dwmw2 tried to improve the Unicode > situation in our squirrelmail with the current scripted conversion hack > in an attempt to workaround upstream squirrelmail's horrible > localization policy where their encodings are inconsistently mixed. > This improved things a bit only for some European languages, but not the > Asian languages. Squirrelmail was a mess. It would confuse character sets whenever the user quoted a mail with non-ASCII characters, if the character set of the mail being quoted was different from the character set of the user. By switching it to use UTF-8 throughout, we fixed that problem -- and in doing so we made it conform to the Fedora policy of using UTF-8 for everything -- a policy which we've had for a long time now. So I changed all the locales to use UTF-8, changed their help text, etc. It was slightly more complicated for the Asian locales, as Warren says. The Korean help text was _supposed_ to be in EUC-KR encoding, but 'iconv' refused to convert it to UTF-8, claiming that it wasn't valid EUC-KR to start with. The Japanese support in Squirrelmail has 'EUC-JP' hard-coded in one or two more places than the normal configuration files, and does the confusing thing with EUC-JP in the Web interface and ISO-2022-JP in the email. I _thought_ we'd switched both of those to UTF-8, but I'm afraid I lack the knowledge of Japanese which would be necessary to do meaningful tests. Yamakawa-san, if you are able to spare some of your time to help us test the behaviour of Squirrelmail packages in the Japanese locale, then that would be very much appreciated. > As you may be well aware, it is currently infeasible to expect the Asian > countries to use only Unicode encoding due to the constantly moving > standards and different glyphs in different languages using the same > code-points, among other problems. I've heard it said that UTF-8 is insufficient for Asian locales, but I've also heard it argued against -- I lack the knowledge to judge its truthfulness. I had supposed that the Fedora policy of using UTF-8 everywhere was sane and correct -- are you suggesting that it really isn't? I know there are Luddites even in Europe who object to UTF-8. I ignore those too. I'd prefer to fix the bugs and make sure Squirrelmail works correctly in UTF-8 for all languages, rather than reverting to obsolescent character sets for certain locales. -- dwmw2 From imcc at spsoftindia.com Fri Apr 7 12:12:07 2006 From: imcc at spsoftindia.com (imcc) Date: Fri, 7 Apr 2006 17:42:07 +0530 Subject: how to check file is open Message-ID: Hi, I am currently working on backup application which portable On Linux, windows and MAC-Osx . While taking the backup I want to exclude those files Which are open. In Linux lsof uses /proc//fd directory to list Open files. Q. In windows how to check whether a file is already Open or not. Is there any API for this checking or file property to check? Sunil SPSOFT -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten at redhat.de Fri Apr 7 11:52:08 2006 From: karsten at redhat.de (Karsten Hopp) Date: Fri, 7 Apr 2006 13:52:08 +0200 Subject: rawhide report: 20060405 changes In-Reply-To: References: <200604051409.k35E9O63019998@porkchop.devel.redhat.com> <4435F0B8.7040805@cornell.edu> Message-ID: <20060407115207.GC9989@redhat.de> > On 4/7/06, Ivan Gyurdiev wrote: > > > > > vim-1:7.0c.000-1 > > > ---------------- > > > * Tue Apr 04 2006 Karsten Hopp 7.0c.000-1 > > > - vim-7.0c BETA > > > > > > * Wed Mar 22 2006 Karsten Hopp 7.0aa.000-3 > > > - Rawhide build as vim, opposed to vim7 (prerelease) > > > - conflict with older man-pages-{it,fr} packages > > > - cleanup lang stuff > > > > > > * Thu Mar 16 2006 Karsten Hopp 7.0aa.000-2 > > > - make it coexist with vim-6 (temporarily) > > > - new CVS snapshot > > > > > Pressing arrows in insert mode prints A,C,B,D instead of moving the > > cursor... > > > This build seems not to be reading /etc/vimrc, which might be causing > this and a bunch of other issues too, see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188112. I believe > the maintainer is looking into it. > > Deji A stupid leftover from the vim7 test release where I've changed the vimrc filename to vim7rc to be able to coexist with vim-6. This should be fixed in vim-7.0c.000-3 Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From dominik at greysector.net Fri Apr 7 13:48:34 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 7 Apr 2006 15:48:34 +0200 Subject: wpa_supplicant support for ifup In-Reply-To: <44169D5E.9090705@redhat.com> References: <44169D5E.9090705@redhat.com> Message-ID: <20060407134834.GB3575@rathann.pekin.waw.pl> On Tuesday, 14 March 2006 at 11:39, Harald Hoyer wrote: > What do you think about the attached patch to ifup-wireless? Works for me :) How does it work? What do I put in ifcfg-ethX in case it's WPA-enabled? Besides, your patch contains a lot of whitespace changes which obscure the real changes. Regards, R. -- MPlayer developer and RPMs maintainer: http://rpm.greysector.net/mplayer/ There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan From vonbrand at inf.utfsm.cl Fri Apr 7 14:03:18 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 07 Apr 2006 10:03:18 -0400 Subject: Rawhide woes: CUPS and xpdf Message-ID: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> I'm near wit's ends with two very annoying problems with rawhide currently, one concerning printing and the other using xpdf for presentations. Both are bugzilla'd. Re: Printing: It doesn't work, period. From a x86_64 to a local paralell printer, or from a i386 notebook over the network (both are PostScript printers), the only things I can print are the testpage (via the CUPS control page) or text files (via lpr). If I try to print PostScript of PDF, CUPS claims the files get queued, are being printed, and then got printed normally, but nothing whatsoever does show up. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186954 Re: Presentations with xpdf. In Gnome, run "xpdf -fullscreen mumblefoo.pdf", and get a window /with/ borders and menu etc, plus the taskbars aren't hidden. In xfce the window at least fills the whole screen, but the decorations remain. Also, acroread (AdobeReader_enu-7.0.5-1) [sorry for the french] doesn't fill the screen in Gnome, but it does under xfce. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176023 Any clues? Does this work for anybody (I'd be pretty surprised if across the board breakage of printing didn't start a riot, so...)? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From j.w.r.degoede at hhs.nl Fri Apr 7 14:22:46 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 07 Apr 2006 16:22:46 +0200 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> Message-ID: <443675B6.4060405@hhs.nl> Horst von Brand wrote: > I'm near wit's ends with two very annoying problems with rawhide currently, > one concerning printing and the other using xpdf for presentations. Both > are bugzilla'd. > > Re: Printing: It doesn't work, period. From a x86_64 to a local paralell > printer, or from a i386 notebook over the network (both are PostScript > printers), the only things I can print are the testpage (via the CUPS > control page) or text files (via lpr). If I try to print PostScript of PDF, > CUPS claims the files get queued, are being printed, and then got printed > normally, but nothing whatsoever does show up. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186954 > > Any clues? Does this work for anybody (I'd be pretty surprised if across > the board breakage of printing didn't start a riot, so...)? I see the same (x86_64 too!), although with some twiddling I got printing to work from openoffice, hey ooo is i386, I smell a rat here :) > Re: Presentations with xpdf. In Gnome, run "xpdf -fullscreen mumblefoo.pdf", > and get a window /with/ borders and menu etc, plus the taskbars aren't > hidden. In xfce the window at least fills the whole screen, but the > decorations remain. Also, acroread (AdobeReader_enu-7.0.5-1) [sorry for the > french] doesn't fill the screen in Gnome, but it does under xfce. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176023 > This is because the new Metacity causes problem with fullscreen apps, file a bug against Metacity I guess, or fix all the apps SDL en allegro games still work. Regards, Hans p.s. I've added comments about this to both bugs! From fedora at camperquake.de Fri Apr 7 14:31:07 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 7 Apr 2006 16:31:07 +0200 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> Message-ID: <20060407163107.30cec776@soran.addix.net> Hi. On Fri, 07 Apr 2006 10:03:18 -0400, Horst von Brand wrote: > Re: Printing: It doesn't work, period. From a x86_64 to a local > paralell printer, or from a i386 notebook over the network (both are > PostScript printers), the only things I can print are the testpage > (via the CUPS control page) or text files (via lpr). If I try to > print PostScript of PDF, CUPS claims the files get queued, are being > printed, and then got printed normally, but nothing whatsoever does > show up. Same here (cups to a PS printer via SMB). Cups test page works, and claims that the imageable area is 260x367mm, which is plainly ridiculous (this is an A4 printer), although I do now know where those numbers come from. Printing the A4 test page results in the printer spinning up (so something is sent there), but no print is produced in the end. From j.w.r.degoede at hhs.nl Fri Apr 7 14:31:32 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 07 Apr 2006 16:31:32 +0200 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060407163107.30cec776@soran.addix.net> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> Message-ID: <443677C4.4050104@hhs.nl> Ralf Ertzinger wrote: > Hi. > > On Fri, 07 Apr 2006 10:03:18 -0400, Horst von Brand wrote: > >> Re: Printing: It doesn't work, period. From a x86_64 to a local >> paralell printer, or from a i386 notebook over the network (both are >> PostScript printers), the only things I can print are the testpage >> (via the CUPS control page) or text files (via lpr). If I try to >> print PostScript of PDF, CUPS claims the files get queued, are being >> printed, and then got printed normally, but nothing whatsoever does >> show up. > > Same here (cups to a PS printer via SMB). Cups test page works, and claims > that the imageable area is 260x367mm, which is plainly ridiculous (this is > an A4 printer), although I do now know where those numbers come from. > > Printing the A4 test page results in the printer spinning up (so something > is sent there), but no print is produced in the end. > In my case there is a print prodecuded containging the upperleft or was it lower right? corner of the 1 cm border of the A4 testpage, besides that the page is all white. Regards, Hans From rstrode at redhat.com Fri Apr 7 14:44:21 2006 From: rstrode at redhat.com (Ray Strode) Date: Fri, 07 Apr 2006 10:44:21 -0400 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> Message-ID: <1144421061.2894.4.camel@halflap> Hi, > Re: Presentations with xpdf. In Gnome, run "xpdf -fullscreen mumblefoo.pdf", > and get a window /with/ borders and menu etc, plus the taskbars aren't > hidden. In xfce the window at least fills the whole screen, but the > decorations remain. Also, acroread (AdobeReader_enu-7.0.5-1) [sorry for the > french] doesn't fill the screen in Gnome, but it does under xfce. You might be able to workaround the bug by doing something like: gconftool-2 --set /apps/metacity/window_keybindings/toggle_fullscreen --type string "F11" (all on one line) and then pressing alt F11. Also, evince might suit your needs better than xpdf. It has a "Presentation mode" that you can get to by pressing F5, so you might give it a try and see if it does what you want. --Ray From pjones at redhat.com Fri Apr 7 15:57:21 2006 From: pjones at redhat.com (Peter Jones) Date: Fri, 07 Apr 2006 11:57:21 -0400 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144351524.7336.22.camel@daxter.boston.redhat.com> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> <1144341331.26501.2.camel@localhost.localdomain> <1144351524.7336.22.camel@daxter.boston.redhat.com> Message-ID: <1144425442.3161.8.camel@localhost.localdomain> On Thu, 2006-04-06 at 15:25 -0400, David Zeuthen wrote: > It would probably be useful to start a thread about this on the new > fedora-laptop-list - I'm just not sure all the people we want on this > list (including pjones, davej, Alan Cox) is on it yet. I'm still not sure why we've got another list for this, but sure, why not... > I would start by collecting data about docking stations; ask people how > it works under Windows etc etc. Can I borrow your t41 dock for a couple of days sometime? -- Peter From vonbrand at inf.utfsm.cl Fri Apr 7 15:58:32 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 07 Apr 2006 11:58:32 -0400 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: Your message of "Fri, 07 Apr 2006 10:44:21 -0400." <1144421061.2894.4.camel@halflap> Message-ID: <200604071558.k37FwW4s012733@laptop11.inf.utfsm.cl> Ray Strode wrote: > > Re: Presentations with xpdf. In Gnome, run "xpdf -fullscreen mumblefoo.pdf", > > and get a window /with/ borders and menu etc, plus the taskbars aren't > > hidden. In xfce the window at least fills the whole screen, but the > > decorations remain. Also, acroread (AdobeReader_enu-7.0.5-1) [sorry for the > > french] doesn't fill the screen in Gnome, but it does under xfce. > You might be able to workaround the bug by doing something like: > gconftool-2 --set /apps/metacity/window_keybindings/toggle_fullscreen > --type string "F11" > (all on one line) > > and then pressing alt F11. OK, will look into that. > Also, evince might suit your needs better than xpdf. It has a > "Presentation mode" that you can get to by pressing F5, so you might > give it a try and see if it does what you want. evince has historically been less than adequate for LaTeX-generated presentations (via beamer). Will try again. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From rhallyx at mindspring.com Fri Apr 7 16:15:00 2006 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 07 Apr 2006 12:15:00 -0400 Subject: hesiod lib problem Message-ID: <44369004.7090907@mindspring.com> for several days, ldconfig has been throwing the following errors: Updating : subversion ##################### [ 19/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link Updating : libstdc++-devel ##################### [ 20/106] Updating : libgnat ##################### [ 21/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link Updating : libobjc ##################### [ 22/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link Updating : xorg-x11-server-Xorg ##################### [ 23/106] Updating : metacity ##################### [ 24/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link Updating : libgomp ##################### [ 25/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link Updating : cpp ##################### [ 26/106] Updating : gcc ##################### [ 27/106] Updating : libgfortran ##################### [ 28/106] /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link The pertinent part of /usr/lib looks like this: [root at LinuxNew2 lib]# ll libhe* -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> libhesiod.so.0.0.0 -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 [root at LinuxNew2 lib]# How should this be fixed? From fedora at adslpipe.co.uk Fri Apr 7 16:17:10 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Fri, 07 Apr 2006 17:17:10 +0100 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <1144425442.3161.8.camel@localhost.localdomain> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com><1144340373.7336.15.camel@daxter.boston.redhat.com><1144341331.26501.2.camel@localhost.localdomain><1144351524.7336.22.camel@daxter.boston.redhat.com> <1144425442.3161.8.camel@localhost.localdomain> Message-ID: <44369086.1060208@adslpipe.co.uk> Peter Jones wrote: > I'm still not sure why we've got another list for this, but sure, why > not... The list seems to have had zero activity .... From paul at city-fan.org Fri Apr 7 16:22:42 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 07 Apr 2006 17:22:42 +0100 Subject: hesiod lib problem In-Reply-To: <44369004.7090907@mindspring.com> References: <44369004.7090907@mindspring.com> Message-ID: <443691D2.4060004@city-fan.org> Richard Hally wrote: > for several days, ldconfig has been throwing the following errors: > > > Updating : subversion ##################### [ 19/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libstdc++-devel ##################### [ 20/106] > Updating : libgnat ##################### [ 21/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libobjc ##################### [ 22/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : xorg-x11-server-Xorg ##################### [ 23/106] > Updating : metacity ##################### [ 24/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libgomp ##################### [ 25/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : cpp ##################### [ 26/106] > Updating : gcc ##################### [ 27/106] > Updating : libgfortran ##################### [ 28/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > The pertinent part of /usr/lib looks like this: > > [root at LinuxNew2 lib]# ll libhe* > -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a > lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> > libhesiod.so.0.0.0 > -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 > -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 > [root at LinuxNew2 lib]# > > How should this be fixed? Hesiod appears to have moved to versioned sonames since FC5. Try moving libhesiod.so.0 out of the way and rerunning ldconfig. Paul. From sundaram at fedoraproject.org Fri Apr 7 16:23:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 07 Apr 2006 21:53:16 +0530 Subject: Fedora with laptops/networking/docking stations etc In-Reply-To: <44369086.1060208@adslpipe.co.uk> References: <5256d0b0604060425j4d8f8afch337a73a9f37e4b2b@mail.gmail.com> <1144340373.7336.15.camel@daxter.boston.redhat.com> <1144341331.26501.2.camel@localhost.localdomain> <1144351524.7336.22.camel@daxter.boston.redhat.com> <1144425442.3161.8.camel@localhost.localdomain> <44369086.1060208@adslpipe.co.uk> Message-ID: <1144426997.2294.15.camel@sundaram.pnq.redhat.com> On Fri, 2006-04-07 at 17:17 +0100, Andy Burns wrote: > Peter Jones wrote: > > > I'm still not sure why we've got another list for this, but sure, why > > not... > > The list seems to have had zero activity .... > Thats because it was only recently created. A dead list like say fedora- config-list is sometimes better than all the activity thats going on the list which is usually no better than background noise. Rahul From mailinglists at erwinrol.com Fri Apr 7 16:28:05 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 07 Apr 2006 18:28:05 +0200 Subject: hesiod lib problem In-Reply-To: <44369004.7090907@mindspring.com> References: <44369004.7090907@mindspring.com> Message-ID: <1144427285.2781.88.camel@xpc.home.erwinrol.com> On Fri, 2006-04-07 at 12:15 -0400, Richard Hally wrote: > for several days, ldconfig has been throwing the following errors: > Updating : cpp ##################### [ 26/106] > Updating : gcc ##################### [ 27/106] > Updating : libgfortran ##################### [ 28/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > The pertinent part of /usr/lib looks like this: > > [root at LinuxNew2 lib]# ll libhe* > -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a > lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> libhesiod.so.0.0.0 > -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 > -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 > [root at LinuxNew2 lib]# > > How should this be fixed? I saw this problem too, i guess at some point /usr/lib64/libhesiod.so.0 was a file and not a link. I solved it with brute force, rpm -e --nodeps and than reinstall it with yum. Simply deleting the libhesiod.so.0 and rerunning ldconfig might work too, but i wanted to be sure things where correct, so i did the remove reinstall thing. - Erwin From rhally at mindspring.com Fri Apr 7 16:32:57 2006 From: rhally at mindspring.com (Richard Hally) Date: Fri, 07 Apr 2006 12:32:57 -0400 Subject: hesiod lib problem In-Reply-To: <443691D2.4060004@city-fan.org> References: <44369004.7090907@mindspring.com> <443691D2.4060004@city-fan.org> Message-ID: <44369439.9030404@mindspring.com> Paul Howarth wrote: > Richard Hally wrote: >> for several days, ldconfig has been throwing the following errors: >> >> >> Updating : subversion ##################### [ >> 19/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libstdc++-devel ##################### [ >> 20/106] >> Updating : libgnat ##################### [ >> 21/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libobjc ##################### [ >> 22/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : xorg-x11-server-Xorg ##################### [ >> 23/106] >> Updating : metacity ##################### [ >> 24/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libgomp ##################### [ >> 25/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : cpp ##################### [ >> 26/106] >> Updating : gcc ##################### [ >> 27/106] >> Updating : libgfortran ##################### [ >> 28/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> The pertinent part of /usr/lib looks like this: >> >> [root at LinuxNew2 lib]# ll libhe* >> -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a >> lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> >> libhesiod.so.0.0.0 >> -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 >> -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 >> [root at LinuxNew2 lib]# >> >> How should this be fixed? > > Hesiod appears to have moved to versioned sonames since FC5. > Try moving libhesiod.so.0 out of the way and rerunning ldconfig. > > Paul. > Yup, that fixed it. Thanks! Richard From dragoran at feuerpokemon.de Fri Apr 7 16:53:15 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 07 Apr 2006 18:53:15 +0200 Subject: who is broken when buring is working with one burner and not with the other.... Message-ID: <443698FB.2030507@feuerpokemon.de> I have to burners installed 1,0,0 100) 'PLEXTOR ' 'DVDR PX-755A ' '1.02' Removable CD-ROM 1,1,0 101) 'LITE-ON ' 'LTR-52246S ' '6S0F' Removable CD-ROM the second one works fine the first one only as root. cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl why? is this because the plextor supports some command that kernel does not allow for non root users? (no messages in dmesg exept scsi: unknown opcode 0xe9 ) or is cdrecord simply broken? where should I fill a bug kernel or cdrecord? it was working fine on FC4 and it seems to work fine with growisofs (for dvds) now I am using FC5 x86_64 with kernel-2.6.16-1.2080_FC5 on a dual core opteron box. From mailinglists at erwinrol.com Fri Apr 7 16:54:26 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 07 Apr 2006 18:54:26 +0200 Subject: ATI DRI Message-ID: <1144428866.3037.2.camel@xpc.home.erwinrol.com> Hey all, Today i tried DRI on my ATI PCIe card, and it actually didn't hang my machine, as it used to do. But glxgears exits with an error, which is explained in the following bugzilla; https://bugs.freedesktop.org/show_bug.cgi?id=6241 Since we are now having CVS versions of the ATI drivers, would it be possible to get the fix from CVS, that is explained in the bugzilla, into the rawhide RPM's ? - Erwin From fedora at adslpipe.co.uk Fri Apr 7 17:04:51 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Fri, 07 Apr 2006 18:04:51 +0100 Subject: ATI DRI In-Reply-To: <1144428866.3037.2.camel@xpc.home.erwinrol.com> References: <1144428866.3037.2.camel@xpc.home.erwinrol.com> Message-ID: <44369BB3.7090508@adslpipe.co.uk> Erwin Rol wrote: > Today i tried DRI on my ATI PCIe card, and it actually didn't hang my > machine, as it used to do. But glxgears exits with an error, I saw the same thing yesterday > which is explained in the following bugzilla; > https://bugs.freedesktop.org/show_bug.cgi?id=6241 I've added a reference to that on the bug I logged for this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188228 > Since we are now having CVS versions of the ATI drivers, would it be > possible to get the fix from CVS, that is explained in the bugzilla, > into the rawhide RPM's ? That would be nice :-) From Lam at Lam.pl Fri Apr 7 17:36:02 2006 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 07 Apr 2006 19:36:02 +0200 Subject: who is broken when buring is working with one burner and not with the other.... In-Reply-To: <443698FB.2030507@feuerpokemon.de> References: <443698FB.2030507@feuerpokemon.de> Message-ID: <1144431362.2766.1.camel@pensja.lam.pl> Dnia 07-04-2006, pi? o godzinie 18:53 +0200, dragoran napisa?(a): > the second one works fine the first one only as root. > cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl (...) > where should I fill a bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179862 Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From smooge at gmail.com Fri Apr 7 18:14:55 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Fri, 7 Apr 2006 12:14:55 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144267053.6227.107.camel@pmac.infradead.org> References: <1144233606.9585.7.camel@coyote.rexursive.com> <80d7e4090604051200t7ac2f993w443cb3b740b00944@mail.gmail.com> <1144267053.6227.107.camel@pmac.infradead.org> Message-ID: <80d7e4090604071114t635bcb50o662746b0191cde93@mail.gmail.com> On 4/5/06, David Woodhouse wrote: > Quite why he thought that was an 'attack of the mailing list police' I > don't know. If this _was_ one of the mailing lists that I police, then > the offending mail wouldn't have got through in the first place -- I > filter and reject for that. > > Smooge, you no longer work in an environment where it's mandatory to > react harshly and negatively to simple technical requests -- I _know_ > you're only doing it for fun and for old times' sake now :) > Ve have not lost our vays! Actually I wasnt trying to be a prick and sorry if I came across that way. I was remembering the scorching that I got from not sending compliant emails at one point. I just remember that my proposal for getting you completely reassigned to IS for 6 months to fix all our problems got squashed by management. I figured everything would either be fixed, or you would have broken like the rest of us into gibbering horrors that live in the basement. -- Stephen J Smoogen. CSIRT/Linux System Administrator From shahms at shahms.com Fri Apr 7 20:38:23 2006 From: shahms at shahms.com (Shahms King) Date: Fri, 07 Apr 2006 13:38:23 -0700 Subject: Outrageous memory usage with cElementTree Message-ID: <4436CDBF.6010600@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was trying to figure out why my small python application was using outrageous amounts of memory on FC5 and managed to track it down to a single anonymous rw mapping that's 32380K. It only gets mapped after importing cElementTree but I can't figure out why. It doesn't happen under FC4 or FC3. Is this memory actually used or is it another artifact of Linux's often questionable RSS statistics? 32MB is a lot of memory to be using for no apparent reason, especially as it is per-process unshared memory. It's particularly vexing using mod_python and kid (which uses cElementTree, if available) as it means that every single httpd process uses ~50MB base memory, which is ridiculous. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFENs2//qs2NkWy11sRAjInAJ9hXBP8Yc2WrGJ4haBUzaK9EmipSwCgkgg2 Dv/WufOMY8c8Ce7qkkyR5CI= =Laie -----END PGP SIGNATURE----- From fedora at wir-sind-cool.org Fri Apr 7 22:37:19 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 8 Apr 2006 00:37:19 +0200 Subject: Outrageous memory usage with cElementTree In-Reply-To: <4436CDBF.6010600@shahms.com> References: <4436CDBF.6010600@shahms.com> Message-ID: <20060408003719.11399776.fedora@wir-sind-cool.org> On Fri, 07 Apr 2006 13:38:23 -0700, Shahms King wrote: > I was trying to figure out why my small python application was using > outrageous amounts of memory on FC5 and managed to track it down to a > single anonymous rw mapping that's 32380K. It only gets mapped after > importing cElementTree but I can't figure out why. It doesn't happen > under FC4 or FC3. Is this memory actually used or is it another > artifact of Linux's often questionable RSS statistics? 32MB is a lot of > memory to be using for no apparent reason, especially as it is > per-process unshared memory. It's particularly vexing using mod_python > and kid (which uses cElementTree, if available) as it means that every > single httpd process uses ~50MB base memory, which is ridiculous. With FC5 and Python repoquery I'm facing increased heap space usage by a factor of 7-10 compared with FC4 or older. Heap size of the repoquery process grows quickly to and beyond Size: 586796 kB Rss: 540100 kB compared with FC4: Size: 77632 kB Rss: 77628 kB I've stopped looking into it, but Yum is not the culprit and SQLite is not either. From shahms at shahms.com Fri Apr 7 22:50:48 2006 From: shahms at shahms.com (Shahms King) Date: Fri, 07 Apr 2006 15:50:48 -0700 Subject: Outrageous memory usage with cElementTree In-Reply-To: <20060408003719.11399776.fedora@wir-sind-cool.org> References: <4436CDBF.6010600@shahms.com> <20060408003719.11399776.fedora@wir-sind-cool.org> Message-ID: <4436ECC8.40406@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > On Fri, 07 Apr 2006 13:38:23 -0700, Shahms King wrote: > >> I was trying to figure out why my small python application was using >> outrageous amounts of memory on FC5 and managed to track it down to a >> single anonymous rw mapping that's 32380K. It only gets mapped after >> importing cElementTree but I can't figure out why. It doesn't happen >> under FC4 or FC3. Is this memory actually used or is it another >> artifact of Linux's often questionable RSS statistics? 32MB is a lot of >> memory to be using for no apparent reason, especially as it is >> per-process unshared memory. It's particularly vexing using mod_python >> and kid (which uses cElementTree, if available) as it means that every >> single httpd process uses ~50MB base memory, which is ridiculous. > > With FC5 and Python repoquery I'm facing increased heap space > usage by a factor of 7-10 compared with FC4 or older. > > Heap size of the repoquery process grows quickly to and beyond > > Size: 586796 kB > Rss: 540100 kB > > compared with FC4: > > Size: 77632 kB > Rss: 77628 kB > > I've stopped looking into it, but Yum is not the culprit and SQLite > is not either. > Thanks for the response, at least I know I'm not going crazy ;-) I'm looking into it more deeply. Bug #188327 (currently on the python-elementtree component) give a little more detail. I doubt that elementtree is to blame, but it's the only package I've found so far that triggers the problem. Specifically, elementtree.ElementTree causes the jump in memory usage. I've copied ElementTree.py into its own file and am trying to figure out what, exactly, causes it as the module doesn't appear to do anything special... - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFENuzI/qs2NkWy11sRAiG4AJ0eMXz6m0LNN8kdQV52unorW854TwCgvDFd prETxyVeU8KRT/onvWKqUlk= =62n9 -----END PGP SIGNATURE----- From shahms at shahms.com Fri Apr 7 23:18:00 2006 From: shahms at shahms.com (Shahms King) Date: Fri, 07 Apr 2006 16:18:00 -0700 Subject: Outrageous memory usage with cElementTree (found it) In-Reply-To: <4436ECC8.40406@shahms.com> References: <4436CDBF.6010600@shahms.com> <20060408003719.11399776.fedora@wir-sind-cool.org> <4436ECC8.40406@shahms.com> Message-ID: <4436F328.7040803@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The problem is not with ElementTree, but can be traced to a specific regular expression: _escape = re.compile(u'[&<>"\x80-\uffff]+') The memory usage doesn't go down after: >>> del _escape >>> re.purge() >>> gc.collect() either. I suspect it's a bug/misplaced optimization in the re module, but haven't investigated any further than that. The specific problem with the regular expression in the \x80-\uffff range. Changing that to '\ufffa-\uffff' gets rid of the astronomical memory usage. I'm going to keep looking into this as it's a particularly vexing bug ;-P I've updated the bugzilla bug to reflect these changes. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFENvMo/qs2NkWy11sRAkgUAKCiKIAgQK/2tZHLr9tQbRvErQpILQCeNue1 +yYKq95ChuYCcakFGWu9ZSA= =w3yL -----END PGP SIGNATURE----- From paul at permanentmail.com Sat Apr 8 03:40:27 2006 From: paul at permanentmail.com (Paul Dickson) Date: Fri, 7 Apr 2006 20:40:27 -0700 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060407163107.30cec776@soran.addix.net> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> Message-ID: <20060407204027.e7bf2926.paul@permanentmail.com> On Fri, 7 Apr 2006 16:31:07 +0200, Ralf Ertzinger wrote: > On Fri, 07 Apr 2006 10:03:18 -0400, Horst von Brand wrote: > > > Re: Printing: It doesn't work, period. From a x86_64 to a local > > paralell printer, or from a i386 notebook over the network (both are > > PostScript printers), the only things I can print are the testpage > > (via the CUPS control page) or text files (via lpr). If I try to > > print PostScript of PDF, CUPS claims the files get queued, are being > > printed, and then got printed normally, but nothing whatsoever does > > show up. > > Same here (cups to a PS printer via SMB). Cups test page works, and claims > that the imageable area is 260x367mm, which is plainly ridiculous (this is > an A4 printer), although I do now know where those numbers come from. > > Printing the A4 test page results in the printer spinning up (so something > is sent there), but no print is produced in the end. This sounds like the problem I had: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187991 It might be fixed (it is for me) in this morning's development update. -Paul From buildsys at redhat.com Sat Apr 8 07:17:29 2006 From: buildsys at redhat.com (Build System) Date: Sat, 8 Apr 2006 03:17:29 -0400 Subject: rawhide report: 20060408 changes Message-ID: <200604080717.k387HTdC014470@porkchop.devel.redhat.com> Updated Packages: audit-1.2-1 ----------- * Fri Apr 07 2006 Steve Grubb 1.2-1 - Add support for new file system auditing kernel subsystem beagle-0.2.4-2 -------------- * Fri Apr 07 2006 Matthias Clasen 0.2.4-2 - Update to 0.2.4 - Update patches cryptsetup-luks-1.0.3-1 ----------------------- * Fri Apr 07 2006 Bill Nottingham 1.0.3-1 - update to final 1.0.3 cups-1:1.2-0.4.rc2.1 -------------------- * Fri Apr 07 2006 Tim Waugh 1:1.2-0.4.rc2.1 - 1.2rc2. * Fri Apr 07 2006 Tim Waugh 1:1.2-0.2.rc1.9 - Sync scheduler/* with svn 5383. * Fri Apr 07 2006 Tim Waugh 1:1.2-0.2.rc1.8 - No longer need openssl-devel. - Build with LDAP_DEPRECATED=1, to pick up declarations of ldap_init() etc. - Only warn about ACLs once (STR #1532). - Fix imagetops filter (STR #1533). - Sync pstops.c with svn 5382. eclipse-bugzilla-1:0.2.2-4 -------------------------- * Tue Apr 04 2006 Andrew Overholt 0.2.2-4 - Add ia64. glib2-2.10.2-2 -------------- * Fri Apr 07 2006 Matthias Clasen - 2.10.2-2 - Update to 2.10.2 glibc-kernheaders-3.0-6 ----------------------- * Fri Apr 07 2006 David Woodhouse - 3.0-6 - Fix fstatat64 on i386 (it's not newfstatat) gtk2-2.8.17-2 ------------- * Fri Apr 07 2006 Matthias Clasen - 2.8.17-2 - Update to 2.8.17 * Thu Mar 30 2006 Matthias Clasen - 2.8.16-2 - Fix a multiscreen dnd crash * Wed Mar 15 2006 Matthias Clasen - 2.8.16-1 - Update to 2.8.16 gtkhtml3-3.10.0-2 ----------------- * Fri Apr 07 2006 Dan Williams - 3.10.0-2 - Fix crash with IM enabled libXcomposite-0.3-3 ------------------- * Fri Apr 07 2006 Adam Jackson 0.3-3 - Note the necessary -proto-devel version in BuildRequires. * Fri Apr 07 2006 Adam Jackson 0.3-2 - Rebuild to pick up new compositeproto headers. ntp-4.2.0.a.20050816-13 ----------------------- * Fri Apr 07 2006 Miroslav Lichvar - 4.2.0.a.20050816-13 - add option to sync hwclock after ntpdate (#179571) pango-1.12.1-2 -------------- * Fri Apr 07 2006 Matthias Clasen - 1.12.1-2 - Update to 1.12.1 python-2.4.3-1 -------------- * Thu Apr 06 2006 Mihai Ibanescu - 2.4.3-1 - Updated to 2.4.3 * Fri Feb 10 2006 Jesse Keating - 2.4.2-3.2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Mihai Ibanescu - 2.4.3-3.2 - rebuilt for newer tix setarch-2.0-1 ------------- * Fri Apr 07 2006 Jindrich Novy 2.0-1 - better error handling, thanks to Dmitry V. Levin (#187322) - understand --help vim-1:7.0c.000-3 ---------------- * Fri Apr 07 2006 Karsten Hopp 7.0c.000-3 - fix vimrc filename * Thu Apr 06 2006 Karsten Hopp 7.0c.000-2 - new snapshot xorg-x11-proto-devel-7.0-10 --------------------------- * Fri Apr 07 2006 Adam Jackson 7.0-10 - Update to compositeproto-0.3.1 to fix big-endian LP64. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.i686 requires kernel = 0:2.6.15-1.2054_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.17.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.17.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.17.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.i686 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.14.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.14.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.i686 requires kernel = 0:2.6.15-1.2054_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.23.i686 requires kernel-smp = 0:2.6.15-1.2054_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.23.i686 requires kernel-xen0 = 0:2.6.15-1.2054_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires /lib/modules/2.6.15-1.2054_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.23.i686 requires kernel-xenU = 0:2.6.15-1.2054_FC5 python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) mkbootdisk - 1.5.3-1.noarch requires syslinux python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 mkbootdisk - 1.5.3-1.noarch requires syslinux python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 GFS-kernel - 2.6.15.1-5.FC5.17.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 cman-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 dlm-kernel - 2.6.15.1-0.FC5.14.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires /lib/modules/2.6.15-1.2054_FC5 gnbd-kernel - 2.6.15-5.FC5.23.x86_64 requires kernel = 0:2.6.15-1.2054_FC5 python-docs - 2.4.2-1.1.noarch requires python = 0:2.4.2 From dragoran at feuerpokemon.de Sat Apr 8 07:52:46 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 08 Apr 2006 09:52:46 +0200 Subject: aiglx status Message-ID: <44376BCE.1020003@feuerpokemon.de> whats the current status of aiglx development? the FC5 binarys have not been updated since inital release. Is the x86_64 bug solved? Can it be added to rawhide to get more testing? Or is it still not ready for rawhide ? From dragoran at feuerpokemon.de Sat Apr 8 07:56:14 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 08 Apr 2006 09:56:14 +0200 Subject: who is broken when buring is working with one burner and not with the other.... In-Reply-To: <1144431362.2766.1.camel@pensja.lam.pl> References: <443698FB.2030507@feuerpokemon.de> <1144431362.2766.1.camel@pensja.lam.pl> Message-ID: <44376C9E.6090107@feuerpokemon.de> Leszek Matok wrote: > Dnia 07-04-2006, pi? o godzinie 18:53 +0200, dragoran napisa?(a): > >> the second one works fine the first one only as root. >> cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl >> > (...) > >> where should I fill a bug >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179862 > > Lam > ok added a me too. From twaugh at redhat.com Sat Apr 8 09:30:42 2006 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 8 Apr 2006 09:30:42 +0000 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060407163107.30cec776@soran.addix.net> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> Message-ID: <20060408093042.GA7105@redhat.com> On Fri, Apr 07, 2006 at 04:31:07PM +0200, Ralf Ertzinger wrote: > Same here (cups to a PS printer via SMB). Cups test page works, and claims > that the imageable area is 260x367mm, which is plainly ridiculous (this is > an A4 printer), although I do now know where those numbers come from. Are you still seeing this problem with cups 1.2rc2 (1.2-0.3.rc2.1 for FC-5 or 1.2-0.4.rc2.1 for devel)? FC-5 packages at ftp://people.redhat.com/twaugh/tmp/cups-1.2/FC-5. I'd like to find out if this is connected with some pstops filter problems that were fixed recently, or if there is some other cause. Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernd.bartmann at gmail.com Sat Apr 8 09:29:49 2006 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Sat, 8 Apr 2006 11:29:49 +0200 Subject: Missing update announcements In-Reply-To: <20060406050843.GA14736@tomservo.boston.redhat.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> <20060406050843.GA14736@tomservo.boston.redhat.com> Message-ID: <6c18a4f0604080229i95e71e2p69998be81226b5c0@mail.gmail.com> On 4/6/06, Luke Macken wrote: > On Wed, Apr 05, 2006 at 06:16:16PM +0200, Bernd Bartmann wrote: > > Now that FC5 final is out a problem seems to reappear that I thought > > was gone since FC4 came out: FC core updates appear on the download > > mirrors but some of them never get announced on fedora-announce-list. > > > > Since the release of FC5 the following announcments are missing: > > > > For FC4: > > anacron-2.3-36.FC4 > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01335.html > > > dia-0.94-13.fc4 > Claims to be sent. > > > dovecot-0.99.14-8.fc4 > Claims to be sent. > > > For FC5: > > cairo-1.0.4-1 > Developer chose not to have update mail sent. > > > GConf2-2.14.0-1 > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01319.html > > > xscreensaver-4.24-2 > Developer chose not to have update mail sent. > > > gnome-screensaver-2.14.0-1.fc5 > Update system was supposed to send, but for some reason it didn't. > > > liboil-0.3.8-1.fc5 > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01684.html > > > newt-0.52.2-6 > Update system was supposed to send, but for some reason it didn't. > > > xterm-211-4.FC5 > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01709.html > > > I've opened bugs for every missing announcements and tracker bugs to > > get an overview. For FC4 the tracker bug is #161106, for FC5 it is > > #188051. > > Please file bugs like this against Fedora Infrastructure under the > 'update system' component from now on. > > > Can someone @fedora or @redhat please look into this issue. I thought > > the process was somehow automated since FC4 came out. It would be > > helpful to get an explanation about the internal process how updates > > are released. > > This process is automated.. but where you have automation, you have a > fan waiting to be hit by shit. > > The update system already goes out and grabs the url for the archived > update mail, so I'll add periodic checks to make sure that all update > mails that were supposed to go out actually do. Thanks for your help Luke. The list is getting shorter. Remaining are: FC4: anacron-2.3-36.FC4, bug #188042 FC5: xterm-211-4.FC5, bug #188049 Best regards, Bernd. From lmacken at redhat.com Sat Apr 8 10:28:56 2006 From: lmacken at redhat.com (Luke Macken) Date: Sat, 8 Apr 2006 06:28:56 -0400 Subject: Missing update announcements In-Reply-To: <6c18a4f0604080229i95e71e2p69998be81226b5c0@mail.gmail.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> <20060406050843.GA14736@tomservo.boston.redhat.com> <6c18a4f0604080229i95e71e2p69998be81226b5c0@mail.gmail.com> Message-ID: <20060408102856.GA10440@tomservo.boston.redhat.com> On Sat, Apr 08, 2006 at 11:29:49AM +0200, Bernd Bartmann wrote: > Thanks for your help Luke. The list is getting shorter. Remaining are: > > FC4: > anacron-2.3-36.FC4, bug #188042 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01335.html > FC5: > xterm-211-4.FC5, bug #188049 http://www.redhat.com/archives/fedora-test-list/2006-March/msg01709.html luke From bernd.bartmann at gmail.com Sat Apr 8 10:38:23 2006 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Sat, 8 Apr 2006 12:38:23 +0200 Subject: Missing update announcements In-Reply-To: <20060408102856.GA10440@tomservo.boston.redhat.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> <20060406050843.GA14736@tomservo.boston.redhat.com> <6c18a4f0604080229i95e71e2p69998be81226b5c0@mail.gmail.com> <20060408102856.GA10440@tomservo.boston.redhat.com> Message-ID: <6c18a4f0604080338if0347e2x22a8f6681a0304b3@mail.gmail.com> On 4/8/06, Luke Macken wrote: > On Sat, Apr 08, 2006 at 11:29:49AM +0200, Bernd Bartmann wrote: > > Thanks for your help Luke. The list is getting shorter. Remaining are: > > > > FC4: > > anacron-2.3-36.FC4, bug #188042 > > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01335.html > > > FC5: > > xterm-211-4.FC5, bug #188049 > > http://www.redhat.com/archives/fedora-test-list/2006-March/msg01709.html Your mailing list archive references are from fedora-TEST-list not fedora-ANNOUNCE-list! Best regards, Bernd. From russell at coker.com.au Sat Apr 8 10:53:11 2006 From: russell at coker.com.au (Russell Coker) Date: Sat, 8 Apr 2006 21:53:11 +1100 Subject: xen in FC5 install Message-ID: <200604082053.14335.russell@coker.com.au> I have performed a basic FC5 install for the purpose of texting Xen. The machine is a Compaq Evo P4-1.5GHz with 384M of RAM. http://jailtime.org/download:centos:v4.3 I downloaded a CentOS 4.3 Xen image from the above URL for the purpose of testing, the CentOS image in question was designed for 128M of RAM so should run nicely on a machine with 384M. kernel = "/boot/vmlinuz-2.6.15-1.2054_FC5xenU" memory = 128 name = "centos.4-3" dhcp = "dhcp" disk = ['file:/xen/centos.4-3.img,sda1,w', 'file:/xen/centos.swap,sda2,w'] root = "/dev/sda1 ro" Above is the contents of my /etc/xen/centos config file. Below are the errors I get in my /var/log/xend-debug.log file. The command "xm create -c centos" gives the error "Error creating domain: The privileged domain did not balloon!". Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line 77, in op_create dominfo = self.xd.domain_create(config) File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line 226, in domain_create dominfo = XendDomainInfo.create(config) File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 182, in create vm.initDomain() File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1203, in initDomain balloon.free(m + fudge) File "/usr/lib/python2.4/site-packages/xen/xend/balloon.py", line 120, in free raise VmError('The privileged domain did not balloon!') VmError: The privileged domain did not balloon! Any suggestions on what I should try? I repeated the same situation on an identical machine (I have a set of identical Compaqs for testing) running FC5 with some packages upgraded to rawhide versions (but there seem to be no usable Xen updates in rawhide). I'm trying to fix the SE Linux policy bugs related to Xen but I can't even get Xen working in permissive mode. PS Please CC me on any replies as I have many unread messages in my lists folder. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jfrieben at freesurf.fr Sat Apr 8 10:57:41 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 8 Apr 2006 12:57:41 +0200 (CEST) Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060408093042.GA7105@redhat.com> References: <20060408093042.GA7105@redhat.com> Message-ID: <41974.194.94.224.254.1144493861.squirrel@jose.freesurf.fr> Printing works again for cups-1.2-0.4.rc2.1. Thanks! > > Are you still seeing this problem with cups 1.2rc2 (1.2-0.3.rc2.1 for > FC-5 or 1.2-0.4.rc2.1 for devel)? FC-5 packages at > ftp://people.redhat.com/twaugh/tmp/cups-1.2/FC-5. > > I'd like to find out if this is connected with some pstops filter > problems that were fixed recently, or if there is some other cause. > > Thanks, > Tim. > */ From avi at argo.co.il Sat Apr 8 11:08:47 2006 From: avi at argo.co.il (Avi Kivity) Date: Sat, 08 Apr 2006 14:08:47 +0300 Subject: xen in FC5 install In-Reply-To: <200604082053.14335.russell@coker.com.au> References: <200604082053.14335.russell@coker.com.au> Message-ID: <443799BF.3070304@argo.co.il> Russell Coker wrote: > I have performed a basic FC5 install for the purpose of texting Xen. The > machine is a Compaq Evo P4-1.5GHz with 384M of RAM. > > http://jailtime.org/download:centos:v4.3 > > I downloaded a CentOS 4.3 Xen image from the above URL for the purpose of > testing, the CentOS image in question was designed for 128M of RAM so should > run nicely on a machine with 384M. > > kernel = "/boot/vmlinuz-2.6.15-1.2054_FC5xenU" > memory = 128 > name = "centos.4-3" > dhcp = "dhcp" > disk = ['file:/xen/centos.4-3.img,sda1,w', 'file:/xen/centos.swap,sda2,w'] > root = "/dev/sda1 ro" > > Above is the contents of my /etc/xen/centos config file. Below are the errors > I get in my /var/log/xend-debug.log file. The command "xm create -c centos" > gives the error "Error creating domain: The privileged domain did not > balloon!". > domain 0 grabbed all of memory and isn't letting it go. try adding dom0_mem=128000 to the end of the kernel line in /etc/grub.conf (saying kernel /xen.gz ...) and rebooting. I'd suggest going to runlevel 3 to avoid starting up X with so little memory. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From emmanuel.seyman at club-internet.fr Sat Apr 8 11:17:21 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sat, 8 Apr 2006 13:17:21 +0200 Subject: Missing update announcements In-Reply-To: <6c18a4f0604080338if0347e2x22a8f6681a0304b3@mail.gmail.com> References: <6c18a4f0604050916h6507fd13k8022bf4285a5d7a9@mail.gmail.com> <20060406050843.GA14736@tomservo.boston.redhat.com> <6c18a4f0604080229i95e71e2p69998be81226b5c0@mail.gmail.com> <20060408102856.GA10440@tomservo.boston.redhat.com> <6c18a4f0604080338if0347e2x22a8f6681a0304b3@mail.gmail.com> Message-ID: <20060408111721.GA8839@orient.maison.moi> On Sat, Apr 08, 2006 at 12:38:23PM +0200, Bernd Bartmann wrote: > > Your mailing list archive references are from fedora-TEST-list not > fedora-ANNOUNCE-list! I think that what Luke is trying to say is that the updates were announced when they were released to updates-testing and that no new announcements were made when they moved to the updates repo. Whether this is good, bad or by design, I have no idea. Emmanuel From fedora at adslpipe.co.uk Sat Apr 8 11:32:13 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 08 Apr 2006 12:32:13 +0100 Subject: xen in FC5 install In-Reply-To: <200604082053.14335.russell@coker.com.au> References: <200604082053.14335.russell@coker.com.au> Message-ID: <44379F3D.3070909@adslpipe.co.uk> Russell Coker wrote: > I have performed a basic FC5 install for the purpose of texting Xen. I've never used the jailtime images, but I notice from the site "Prerequisites : Working installation of Xen 2" But FC5 includes xen 3 From lists at arctur.us Sat Apr 8 11:39:37 2006 From: lists at arctur.us (Mitch Skinner) Date: Sat, 08 Apr 2006 04:39:37 -0700 Subject: "expected gains in market share" In-Reply-To: <20060405233240.GE17814@thyrsus.com> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> Message-ID: <1144496377.5321.61.camel@firebolt> On Wed, 2006-04-05 at 19:32 -0400, Eric S. Raymond wrote: > Cam : > > Do you really think that a substantial population of adopters are ready > > and waiting but held back because mp3 isn't in Fedora? > > I think there is a very large population of potential users who would > consider lack of MP3 and other multimedia playback a showstopper -- > that it's one of the checklist features nontechnical users look for in > 2006. MP3 and DVD playback are clearly not checklist features for Windows use, as the stock version does not include either ability. There are scads of non-technical users out there with enough motivation and ability to find and install the required software. The effort required with Fedora is not that much greater, plus it's less likely to leave you with adware. Googling for "fedora mp3" brings up the fedorafaq as the first link. When your non-technical friends ask about linux, don't fear their scorn--say, "yes, some software is available that does what you want", and point them toward livna or whatever. You can even throw in a mention of how evil software patents are, but you don't necessarily have to dispense the Vorbis lecture. Of course, the actual install is more complex than it should be, and no one disputes that. This is where some useful work can be done: making it easier to add repositories and install packages (though pup and pirut have already made a difference here). The brick wall here isn't technical, though; it's legal, and banging your head against it (and all of our heads against it) is not productive. I have no doubt that the legal people have looked into it pretty thoroughly without coming up with a solution. OTOH, I have to agree with whoever brought up the flash repository. The flash plugin itself is clearly not redistributable the way Fedora wants, but a flash.repo file certainly is, and IMHO ought to be included in stock Fedora. Alan Cox's concern about the difficulty of deciding which third-parties to point to seems overblown--even in a contentious forum like fedora-devel, I bet one could get pretty substantial consensus about the top few things (flash, fluendo if they created a yum repo) to include. I'm a free-software believer (I tell people we're not ideologues--just pragmatists with a longer time horizon), but I certainly don't have a problem with including pointers to the stuff that's legal to point to. It makes sense to me that Fedora can't include pointers to places that include non-US-legal stuff, but I don't see the problem with the flash repo. Mitch From russell at coker.com.au Sat Apr 8 11:56:20 2006 From: russell at coker.com.au (Russell Coker) Date: Sat, 8 Apr 2006 21:56:20 +1000 Subject: xen in FC5 install In-Reply-To: <443799BF.3070304@argo.co.il> References: <200604082053.14335.russell@coker.com.au> <443799BF.3070304@argo.co.il> Message-ID: <200604082156.23869.russell@coker.com.au> On Saturday 08 April 2006 21:08, Avi Kivity wrote: > domain 0 grabbed all of memory and isn't letting it go. try adding > > dom0_mem=128000 Thanks for the suggestion. The dom0_mem parameter doesn't seem to do anything, but this suggestion led me to "xm mem-set 0 128" which works! I've now got the base Xen functionality working so I can fix the SE Linux policy. I should have a new policy available in about 24 hours to make Xen work properly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jfrieben at freesurf.fr Sat Apr 8 12:57:40 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 8 Apr 2006 14:57:40 +0200 (CEST) Subject: Update notification applet for FC? Message-ID: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> FC3 was the last release to include a working update notifier for the GNOME panel. This also holds in the case of current FC rawhide. Are there plans to fill this gap? Right now, this constitutes a major lack of functionality. From denis at poolshark.org Sat Apr 8 15:35:09 2006 From: denis at poolshark.org (Denis Leroy) Date: Sat, 08 Apr 2006 17:35:09 +0200 Subject: Outrageous memory usage with cElementTree (found it) In-Reply-To: <4436F328.7040803@shahms.com> References: <4436CDBF.6010600@shahms.com> <20060408003719.11399776.fedora@wir-sind-cool.org> <4436ECC8.40406@shahms.com> <4436F328.7040803@shahms.com> Message-ID: <4437D82D.3050402@poolshark.org> Shahms King wrote: > The problem is not with ElementTree, but can be traced to a specific > regular expression: > > _escape = re.compile(u'[&<>"\x80-\uffff]+') > I suspect it's a bug/misplaced optimization in the re module, > but haven't investigated any further than that. The specific problem > with the regular expression in the \x80-\uffff range. Changing that to > '\ufffa-\uffff' gets rid of the astronomical memory usage. I'm going to > keep looking into this as it's a particularly vexing bug ;-P > > I've updated the bugzilla bug to reflect these changes. nice catch From mandreiana.lists at gmail.com Sat Apr 8 15:53:25 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sat, 08 Apr 2006 18:53:25 +0300 Subject: Update notification applet for FC? In-Reply-To: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> References: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> Message-ID: <1144511606.13587.4.camel@localhost.localdomain> On Sat, 2006-04-08 at 14:57 +0200, Joachim Frieben wrote: > FC3 was the last release to include a working update notifier for the GNOME > panel. This also holds in the case of current FC rawhide. Are there plans to > fill this gap? Right now, this constitutes a major lack of functionality. You exaggerate. If you want automatic updates, enable yum in Services. If you want manual, open Software Updater. That's it. Yet another notifier is not needed. In older FC versions I always distributed a modified default gnome session to remove the update notification applet which annoys people during work. -- Marius Andreiana From katzj at redhat.com Sat Apr 8 16:02:50 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 08 Apr 2006 12:02:50 -0400 Subject: aiglx status In-Reply-To: <44376BCE.1020003@feuerpokemon.de> References: <44376BCE.1020003@feuerpokemon.de> Message-ID: <1144512170.2746.1.camel@aglarond.local> On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: > whats the current status of aiglx development? > the FC5 binarys have not been updated since inital release. > Is the x86_64 bug solved? > Can it be added to rawhide to get more testing? Or is it still not ready > for rawhide ? The aiglx code is already in the main trunk of xorg development being targeted for Xorg 7.1. Packages tracking that are already present in rawhide Jeremy From fedora at adslpipe.co.uk Sat Apr 8 19:23:03 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 08 Apr 2006 20:23:03 +0100 Subject: Update notification applet for FC? In-Reply-To: <1144511606.13587.4.camel@localhost.localdomain> References: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> <1144511606.13587.4.camel@localhost.localdomain> Message-ID: <44380D97.1040205@adslpipe.co.uk> Marius Andreiana wrote: > I always [snip] remove the update notification applet which annoys people during work. Exactly! From jfrieben at freesurf.fr Sat Apr 8 19:41:17 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 8 Apr 2006 21:41:17 +0200 (CEST) Subject: Update notification applet for FC? In-Reply-To: <1144511606.13587.4.camel@localhost.localdomain> References: <1144511606.13587.4.camel@localhost.localdomain> Message-ID: <2581.194.94.224.254.1144525277.squirrel@jose.freesurf.fr> > You exaggerate. If you want automatic updates, enable yum in Services. > If you want manual, open Software Updater. That's it. Yet another > notifier is not needed. ^^^^^^^ ^^^^^^^^ Wrong, right now, there is none. Period. > In older FC versions I always distributed a modified default gnome > session to remove the update notification applet which annoys people > during work. RHEL, Ubuntu, Suse, etc. -- all important distros offer this kind of feature. If you decide to remove an applet that you don't like, nobody will care about or even prevent you from doing so. At least you had the freedom of choice. But do not try to impose your very subjective preferences on others! From ianburrell at gmail.com Sat Apr 8 22:02:09 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Sat, 8 Apr 2006 15:02:09 -0700 Subject: Update notification applet for FC? In-Reply-To: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> References: <51528.194.94.224.254.1144501060.squirrel@arlette.freesurf.fr> Message-ID: On 4/8/06, Joachim Frieben wrote: > FC3 was the last release to include a working update notifier for the GNOME > panel. This also holds in the case of current FC rawhide. Are there plans to > fill this gap? Right now, this constitutes a major lack of functionality. > A replacement applet based on yum is a possibility for FC6. http://fedoraproject.org/wiki/FC6Future http://fedoraproject.org/wiki/YumApplet - Ian From russell at coker.com.au Sat Apr 8 23:55:26 2006 From: russell at coker.com.au (Russell Coker) Date: Sun, 9 Apr 2006 09:55:26 +1000 Subject: xen in FC5 install In-Reply-To: <44379F3D.3070909@adslpipe.co.uk> References: <200604082053.14335.russell@coker.com.au> <44379F3D.3070909@adslpipe.co.uk> Message-ID: <200604090955.30711.russell@coker.com.au> On Saturday 08 April 2006 21:32, Andy Burns wrote: > Russell Coker wrote: > > I have performed a basic FC5 install for the purpose of texting Xen. > > I've never used the jailtime images, but I notice from the site > "Prerequisites : Working installation of Xen 2" > > But FC5 includes xen 3 Jailtime just has images of Ext2/3 file systems with Linux installed. Since solving the memory issue I booted up the CentOS image in question and logged in to it. So it seems to be working OK. Someone reported a SE Linux policy bug when running Jailtime images. I will fix that bug shortly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dragoran at feuerpokemon.de Sun Apr 9 05:37:07 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 09 Apr 2006 07:37:07 +0200 Subject: aiglx status In-Reply-To: <1144512170.2746.1.camel@aglarond.local> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> Message-ID: <44389D83.5040403@feuerpokemon.de> Jeremy Katz wrote: > On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: > >> whats the current status of aiglx development? >> the FC5 binarys have not been updated since inital release. >> Is the x86_64 bug solved? >> Can it be added to rawhide to get more testing? Or is it still not ready >> for rawhide ? >> > > The aiglx code is already in the main trunk of xorg development being > targeted for Xorg 7.1. Packages tracking that are already present in > rawhide > > Jeremy > > thats means x86_64 is supported now? From katzj at redhat.com Sun Apr 9 06:00:18 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 09 Apr 2006 02:00:18 -0400 Subject: aiglx status In-Reply-To: <44389D83.5040403@feuerpokemon.de> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> Message-ID: <1144562418.3153.0.camel@aglarond.local> On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: > Jeremy Katz wrote: > > On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: > >> whats the current status of aiglx development? > >> the FC5 binarys have not been updated since inital release. > >> Is the x86_64 bug solved? > >> Can it be added to rawhide to get more testing? Or is it still not ready > >> for rawhide ? > >> > > The aiglx code is already in the main trunk of xorg development being > > targeted for Xorg 7.1. Packages tracking that are already present in > > rawhide > > > thats means x86_64 is supported now? Worked on my x86_64 box with a radeon at the office when I tried a few weeks ago. I haven't tried since between vacation and LinuxWorld/FUDCon Jeremy From daihardM3 at comcast.net Sun Apr 9 07:41:06 2006 From: daihardM3 at comcast.net (Daigoro Toyama) Date: Sun, 9 Apr 2006 00:41:06 -0700 Subject: MyODBC for FC5? Message-ID: <200604090041.06127.daihardM3@comcast.net> Hi. This is my first post to this mailing list. I hope this is an appropriate place to ask a question like this. If not, my apologies in advance. Is there any reason that MyODBC has been removed from Fedora Core 5? I was about to set it up so I can run my ODBC clien app to connect to my MySQL server running on a separate Linux computer, when I found that the package was missing. Any feedback would be appreciated. Thanks, Dai From buildsys at redhat.com Sun Apr 9 07:45:23 2006 From: buildsys at redhat.com (Build System) Date: Sun, 9 Apr 2006 03:45:23 -0400 Subject: rawhide report: 20060409 changes Message-ID: <200604090745.k397jN4Q031481@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.15.1-5.FC5.19 ---------------------------- * Fri Mar 31 2006 Chris Feist - Build xen for x86_64. cman-kernel-2.6.15.1-0.FC5.18 ----------------------------- * Fri Mar 31 2006 Chris Feist - Build xen for x86_64. dlm-kernel-2.6.15.1-0.FC5.16 ---------------------------- * Fri Mar 31 2006 Chris Feist - Build xen for x86_64. gaim-1:1.5.0-16.fc6 ------------------- * Sat Apr 08 2006 Warren Togami - 1:1.5.0-16 - MSN block crash (#185222 Stu Tomlinson) gnbd-kernel-2.6.15-5.FC5.25 --------------------------- * Fri Mar 31 2006 Chris Feist - Build xen for x86_64. python-docs-2.4.3-1 ------------------- * Sat Apr 08 2006 Mihai Ibanescu 2.4.3-1 - updated to 2.4.3 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) mkbootdisk - 1.5.3-1.noarch requires syslinux rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 mkbootdisk - 1.5.3-1.noarch requires syslinux Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mkbootdisk - 1.5.3-1.noarch requires syslinux rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From dragoran at feuerpokemon.de Sun Apr 9 08:03:55 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 09 Apr 2006 10:03:55 +0200 Subject: FC6 faster boot Message-ID: <4438BFEB.8010205@feuerpokemon.de> Before FC4 was released there was a disussion about how to make the boot process faster. But until now (FC5/FC6-rawhide) nothing has been done. Early login was in development but it stopped, Systemservices was never in a working state. Any plans on improving the boot process in FC6? I would suggest to use initng which is in review for extras now [1]. But to get it in the final release it would be better to have it in rawhide rather than in extras. [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 From sundaram at fedoraproject.org Sun Apr 9 08:08:25 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 09 Apr 2006 13:38:25 +0530 Subject: FC6 faster boot In-Reply-To: <4438BFEB.8010205@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> Message-ID: <1144570105.2294.104.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: > Before FC4 was released there was a disussion about how to make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. Why do you say so? Many things have been iteratively improved. The booting speed is much better now. Try http://bootchart.sf.net or http://people.redhat.com/berrange/systemtap/bootprobe/ to measure this. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras now [1]. > But to get it in the final release it would be better to have it in > rawhide rather than in extras. > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > Initng review has not been completed yet and doesnt work on many systems with a number of issues been highlighted and worked upon during the review process. If it ends up in Fedora Extras first, it would be easier to check how well it works and later move into Fedora Core if suitable. Rahul From dragoran at feuerpokemon.de Sun Apr 9 08:15:00 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 09 Apr 2006 10:15:00 +0200 Subject: FC6 faster boot In-Reply-To: <1144570105.2294.104.camel@sundaram.pnq.redhat.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> Message-ID: <4438C284.1030507@feuerpokemon.de> Rahul Sundaram wrote: > On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: > >> Before FC4 was released there was a disussion about how to make the boot >> process faster. >> But until now (FC5/FC6-rawhide) nothing has been done. >> > > Why do you say so? Many things have been iteratively improved. The > booting speed is much better now. Try http://bootchart.sf.net or > http://people.redhat.com/berrange/systemtap/bootprobe/ to measure this. > > > sure it has improved but not that much, for me FC4 booted faster than FC5 (because of early login) >> Early login was in development but it stopped, >> Systemservices was never in a working state. >> Any plans on improving the boot process in FC6? >> I would suggest to use initng which is in review for extras now [1]. >> But to get it in the final release it would be better to have it in >> rawhide rather than in extras. >> >> [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 >> >> > > Initng review has not been completed yet and doesnt work on many systems > with a number of issues been highlighted and worked upon during the > review process. I know this, because I am working on getting it working too (adding selinux support). > If it ends up in Fedora Extras first, it would be easier > to check how well it works and later move into Fedora Core if suitable. > > rawhide is the place to test new technolgies, if it turns out to be a bad idea we can remove it before FC6, but extras is not the place for such apps. > Rahul > > From sundaram at fedoraproject.org Sun Apr 9 08:22:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 09 Apr 2006 13:52:39 +0530 Subject: FC6 faster boot In-Reply-To: <4438C284.1030507@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> Message-ID: <1144570959.2294.113.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-09 at 10:15 +0200, dragoran wrote: > Rahul Sundaram wrote: > > On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: > > > >> Before FC4 was released there was a disussion about how to make the boot > >> process faster. > >> But until now (FC5/FC6-rawhide) nothing has been done. > >> > > > > Why do you say so? Many things have been iteratively improved. The > > booting speed is much better now. Try http://bootchart.sf.net or > > http://people.redhat.com/berrange/systemtap/bootprobe/ to measure this. > > > > > > > sure it has improved but not that much, for me FC4 booted faster than > FC5 (because of early login) Early login wasnt enabled by default so not many users would see that. If you can contribute towards fixing the problems in early login, that might help. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952 > upon during the > > review process. > I know this, because I am working on getting it working too (adding > selinux support). Lets get it working reasonably well and include it in extras-devel as a package that users can provide feedback easily. Replacing a init system is not a easy decision and boot speed shouldnt be the primary motivation to do that. > > If it ends up in Fedora Extras first, it would be easier > > to check how well it works and later move into Fedora Core if suitable. > > > > > rawhide is the place to test new technolgies, if it turns out to be a > bad idea we can remove it before FC6, > but extras is not the place for such apps. extras-devel is the equivalent of rawhide for Fedora Extras. It can very well be used to test new technologies. The problem with importing it into rawhide is that the external community cannot work directly work on packaging anymore at this point. Rahul From dragoran at feuerpokemon.de Sun Apr 9 08:34:37 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 09 Apr 2006 10:34:37 +0200 Subject: FC6 faster boot In-Reply-To: <1144570959.2294.113.camel@sundaram.pnq.redhat.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <1144570959.2294.113.camel@sundaram.pnq.redhat.com> Message-ID: <4438C71D.8050207@feuerpokemon.de> Rahul Sundaram wrote: > On Sun, 2006-04-09 at 10:15 +0200, dragoran wrote: > >> Rahul Sundaram wrote: >> >>> On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: >>> >>> >>>> Before FC4 was released there was a disussion about how to make the boot >>>> process faster. >>>> But until now (FC5/FC6-rawhide) nothing has been done. >>>> >>>> >>> Why do you say so? Many things have been iteratively improved. The >>> booting speed is much better now. Try http://bootchart.sf.net or >>> http://people.redhat.com/berrange/systemtap/bootprobe/ to measure this. >>> >>> >>> >>> >> sure it has improved but not that much, for me FC4 booted faster than >> FC5 (because of early login) >> > > Early login wasnt enabled by default so not many users would see that. > If you can contribute towards fixing the problems in early login, that > might help. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952 > > as far as I can see the only real problem are nfs mounted /usr or /home dirs. that can be solved by(starting network) and mounting them before starting gdm. a simple script could look into fstab to see if this is needed. or did I miss anything? >> upon during the >> >>> review process. >>> >> I know this, because I am working on getting it working too (adding >> selinux support). >> > > Lets get it working reasonably well and include it in extras-devel as a > package that users can provide feedback easily. Replacing a init system > is not a easy decision and boot speed shouldnt be the primary motivation > to do that. > > > the problem now is upstream, some changes are needed to get selinux working. it does not have to replace sysvinit you can have both installed at the same time. >>> If it ends up in Fedora Extras first, it would be easier >>> to check how well it works and later move into Fedora Core if suitable. >>> >>> >>> >> rawhide is the place to test new technolgies, if it turns out to be a >> bad idea we can remove it before FC6, >> but extras is not the place for such apps. >> > > extras-devel is the equivalent of rawhide for Fedora Extras. It can very > well be used to test new technologies. The problem with importing it > into rawhide is that the external community cannot work directly work on > packaging anymore at this point. > > this is also one thing that should be changed in the (near?) feature. > Rahul > > > From sundaram at fedoraproject.org Sun Apr 9 09:03:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 09 Apr 2006 14:33:04 +0530 Subject: FC6 faster boot In-Reply-To: <4438C700.5010308@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <1144570959.2294.113.camel@sundaram.pnq.redhat.com> <4438C700.5010308@feuerpokemon.de> Message-ID: <1144573384.2294.145.camel@sundaram.pnq.redhat.com> Hi > > > > Early login wasnt enabled by default so not many users would see that. > > If you can contribute towards fixing the problems in early login, that > > might help. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952 > > > > > as far as I can see the only real problem are nfs mounted /usr or /home > dirs. > that can be solved by(starting network) and mounting them before > starting gdm. > a simple script could look into fstab to see if this is needed. > or did I miss anything? Dont know enough details to answer that. > > > > > the problem now is upstream, some changes are needed to get selinux working. > it does not have to replace sysvinit you can have both installed at the > same time. I am aware that they can be installed at the same time. It is still a replacement as they cannot run in parallel. From my experiences trying out Initng, I am of the opinion that it it has pretty good potential but needs to cook in extras-devel for a while before it gets adopted within core. > > > > extras-devel is the equivalent of rawhide for Fedora Extras. It can very > > well be used to test new technologies. The problem with importing it > > into rawhide is that the external community cannot work directly work on > > packaging anymore at this point. > > > > > this is also one thing that should be changed in the (near?) feature. Yes. We are working on that. For now it needs to be in extras if you want to work on it. Rahul From fedora at camperquake.de Sun Apr 9 10:58:58 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 9 Apr 2006 12:58:58 +0200 Subject: "expected gains in market share" In-Reply-To: <1144496377.5321.61.camel@firebolt> References: <44344923.7070805@mesias.co.uk> <20060405233240.GE17814@thyrsus.com> <1144496377.5321.61.camel@firebolt> Message-ID: <20060409125858.18ae6408@lain> Hi. On Sat, 08 Apr 2006 04:39:37 -0700, Mitch Skinner wrote > MP3 and DVD playback are clearly not checklist features for Windows > use, as the stock version does not include either ability. The stock version of Windows XP does play MP3. From chitlesh at fedoraproject.org Sun Apr 9 11:59:48 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 9 Apr 2006 13:59:48 +0200 Subject: aiglx status In-Reply-To: <1144562418.3153.0.camel@aglarond.local> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> <1144562418.3153.0.camel@aglarond.local> Message-ID: <13dbfe4f0604090459i4b4c9d40sec7b177eedd2a007@mail.gmail.com> Does the new Nvidia driver support aiglx ? On 4/9/06, Jeremy Katz wrote: > On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: > > Jeremy Katz wrote: > > > On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: > > >> whats the current status of aiglx development? > > >> the FC5 binarys have not been updated since inital release. > > >> Is the x86_64 bug solved? > > >> Can it be added to rawhide to get more testing? Or is it still not ready > > >> for rawhide ? > > >> > > > The aiglx code is already in the main trunk of xorg development being > > > targeted for Xorg 7.1. Packages tracking that are already present in > > > rawhide > > > > > thats means x86_64 is supported now? > > Worked on my x86_64 box with a radeon at the office when I tried a few > weeks ago. I haven't tried since between vacation and LinuxWorld/FUDCon > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://clunixchit.blogspot.com From gilboad at gmail.com Sun Apr 9 14:32:38 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 09 Apr 2006 17:32:38 +0300 Subject: aiglx status In-Reply-To: <13dbfe4f0604090459i4b4c9d40sec7b177eedd2a007@mail.gmail.com> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> <1144562418.3153.0.camel@aglarond.local> <13dbfe4f0604090459i4b4c9d40sec7b177eedd2a007@mail.gmail.com> Message-ID: <1144593158.32374.9.camel@gilboa-work-dev> On Sun, 2006-04-09 at 13:59 +0200, Chitlesh GOORAH wrote: > Does the new Nvidia driver support aiglx ? > > On 4/9/06, Jeremy Katz wrote: > > On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: > > > Jeremy Katz wrote: > > > > On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: > > > >> whats the current status of aiglx development? > > > >> the FC5 binarys have not been updated since inital release. > > > >> Is the x86_64 bug solved? > > > >> Can it be added to rawhide to get more testing? Or is it still not ready > > > >> for rawhide ? > > > >> > > > > The aiglx code is already in the main trunk of xorg development being > > > > targeted for Xorg 7.1. Packages tracking that are already present in > > > > rawhide > > > > > > > thats means x86_64 is supported now? > > > > Worked on my x86_64 box with a radeon at the office when I tried a few > > weeks ago. I haven't tried since between vacation and LinuxWorld/FUDCon > > > > Jeremy > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > No. AFAIK, only the 9x.xx series (Which rumored to be released in Q3/06) will include Aiglx (GLX_EXT_texture_from_pixmap) support. Gilboa. From wtogami at redhat.com Sun Apr 9 16:47:28 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 09 Apr 2006 12:47:28 -0400 Subject: FC6 faster boot In-Reply-To: <4438C284.1030507@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> Message-ID: <44393AA0.6010501@redhat.com> dragoran wrote: > rawhide is the place to test new technolgies, if it turns out to be a > bad idea we can remove it before FC6, > but extras is not the place for such apps. Can most users handle their system getting stuck during boot? No. It isn't ready for rawhide. Warren Togami wtogami at redhat.com From stickster at gmail.com Sun Apr 9 16:51:37 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 09 Apr 2006 12:51:37 -0400 Subject: MyODBC for FC5? In-Reply-To: <200604090041.06127.daihardM3@comcast.net> References: <200604090041.06127.daihardM3@comcast.net> Message-ID: <1144601497.9440.46.camel@localhost.localdomain> On Sun, 2006-04-09 at 00:41 -0700, Daigoro Toyama wrote: > This is my first post to this mailing list. I hope this is an appropriate > place to ask a question like this. If not, my apologies in advance. > > Is there any reason that MyODBC has been removed from Fedora Core 5? I was > about to set it up so I can run my ODBC clien app to connect to my MySQL > server running on a separate Linux computer, when I found that the package > was missing. Any feedback would be appreciated. Are you looking for the mysql-connector-odbc package? This is new to FC5, IIRC. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Sun Apr 9 17:25:09 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 9 Apr 2006 19:25:09 +0200 Subject: FC6 faster boot In-Reply-To: <44393AA0.6010501@redhat.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <44393AA0.6010501@redhat.com> Message-ID: <20060409192509.7ac23bde@lain> Hi. On Sun, 09 Apr 2006 12:47:28 -0400, Warren Togami wrote > Can most users handle their system getting stuck during boot? > > No. > > It isn't ready for rawhide. I'm sure to remember that next time a glibc/kernel update blows up the rawhide tree. From david at lovesunix.net Sun Apr 9 17:32:48 2006 From: david at lovesunix.net (David Nielsen) Date: Sun, 09 Apr 2006 19:32:48 +0200 Subject: FC6 faster boot In-Reply-To: <4438BFEB.8010205@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> Message-ID: <1144603968.11909.69.camel@localhost.localdomain> s?n, 09 04 2006 kl. 10:03 +0200, skrev dragoran: > Before FC4 was released there was a disussion about how to make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras now [1]. > But to get it in the final release it would be better to have it in > rawhide rather than in extras. > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > While I would love to see the current Init system replaced for various reasons, I'm concerned if InitNG is the correct technical solution. Do we even have a clear spec for what we require from a replacement, so far the document with the most effort going into this seems to be Seth Nickell' SystemServices document. Just saying we should use initng reminds me of that old saying - when all you have is a hammer every problem looks like a nail. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From sundaram at fedoraproject.org Sun Apr 9 17:34:48 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 09 Apr 2006 23:04:48 +0530 Subject: FC6 faster boot In-Reply-To: <20060409192509.7ac23bde@lain> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <44393AA0.6010501@redhat.com> <20060409192509.7ac23bde@lain> Message-ID: <1144604088.2294.179.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-09 at 19:25 +0200, Ralf Ertzinger wrote: > Hi. > > On Sun, 09 Apr 2006 12:47:28 -0400, Warren Togami wrote > > > Can most users handle their system getting stuck during boot? > > > > No. > > > > It isn't ready for rawhide. > > I'm sure to remember that next time a glibc/kernel update blows > up the rawhide tree. If a kernel blows up, you can boot up back into the older kernel. Glibc hasnt made my rawhide system unbootable in a long long time. When was your last time? Rawhide is a development repository and not a push anything here one. Rahul From sundaram at fedoraproject.org Sun Apr 9 17:45:34 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 09 Apr 2006 23:15:34 +0530 Subject: FC6 faster boot In-Reply-To: <1144603968.11909.69.camel@localhost.localdomain> References: <4438BFEB.8010205@feuerpokemon.de> <1144603968.11909.69.camel@localhost.localdomain> Message-ID: <1144604734.2294.187.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-09 at 19:32 +0200, David Nielsen wrote: > s?n, 09 04 2006 kl. 10:03 +0200, skrev dragoran: > > Before FC4 was released there was a disussion about how to make the boot > > process faster. > > But until now (FC5/FC6-rawhide) nothing has been done. > > Early login was in development but it stopped, > > Systemservices was never in a working state. > > Any plans on improving the boot process in FC6? > > I would suggest to use initng which is in review for extras now [1]. > > But to get it in the final release it would be better to have it in > > rawhide rather than in extras. > > > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > > > While I would love to see the current Init system replaced for various > reasons, I'm concerned if InitNG is the correct technical solution. We would have evaluate it to know more. Right? What concerns do you have for initng? > > Do we even have a clear spec for what we require from a replacement, so > far the document with the most effort going into this seems to be Seth > Nickell' SystemServices document. Have you seen this? http://fedoraproject.org/wiki/FCNewInit ---------------- Proper *runtime* dependency support. Starting a service should start its dependencies, in-order. Changes to dependent services should be immediately handled. Out of this work, parallelization can easily fall out. Without this work, parallelization is pointless. :) Full backwards compatibility. Old-style init scripts aren't going to go away anytime soon. Full LSB support for LSB init scripts. Makes the spec groups happy, even though the number of LSB scripts is basically nil. D-BUS support. Services should be exposed via D-BUS, and should be available for querying to: * check what's configured * check what's actually running * start them * stop them * etc. The services should also post notifications via D-BUS when they've started successfully, and (more importantly) when they haven't, or when they've unexpectedly exited. Support for respawning services, if necessary. Complete with rate limits and other fun stuff. ------------------- How well does Initng fit into those requirements currently? > > Just saying we should use initng reminds me of that old saying - when > all you have is a hammer every problem looks like a nail. Unlike a hammer, Initng can potentially be modified to suit our requirements if it doesnt fit our specifications if it is a good base to start with and upstream is open to accepting changes if any is required. Rahul From k.georgiou at imperial.ac.uk Sun Apr 9 18:27:43 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Sun, 9 Apr 2006 19:27:43 +0100 Subject: FC6 faster boot In-Reply-To: <4438C71D.8050207@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <1144570959.2294.113.camel@sundaram.pnq.redhat.com> <4438C71D.8050207@feuerpokemon.de> Message-ID: <20060409182743.GA11722@imperial.ac.uk> On Sun, Apr 09, 2006 at 10:34:37AM +0200, dragoran wrote: > Rahul Sundaram wrote: > > On Sun, 2006-04-09 at 10:15 +0200, dragoran wrote: > > > > Early login wasnt enabled by default so not many users would see that. > > If you can contribute towards fixing the problems in early login, that > > might help. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952 > > > > > as far as I can see the only real problem are nfs mounted /usr or /home > dirs. > that can be solved by(starting network) and mounting them before > starting gdm. > a simple script could look into fstab to see if this is needed. > or did I miss anything? Well many (most?) people use autofs to mount home directories. In my systems since my home is an nfs4 automount with krb5 you need to start ntpd,rpcidmapd,rpcgssd,autofs before you can see /home. I know many places that have their home directories under /afs as well. Also keep in mind that a home directory can be anywhere (/usr/people for example will still be in use in many places I suspect) and you'll also find links like /home -> /foo/bar where /foo/bar is automounted. Simply checking fstab/auto.master isn't going to tell you anything about where the home directories are. Of course as long as the early startup can be disabled easily it isn't a problem. Kostas Georgiou From jspaleta at gmail.com Sun Apr 9 18:38:37 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 9 Apr 2006 14:38:37 -0400 Subject: FC6 faster boot In-Reply-To: <4438C284.1030507@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> Message-ID: <604aa7910604091138y44d785b8tfbdab9d01f5e2809@mail.gmail.com> On 4/9/06, dragoran wrote: > rawhide is the place to test new technolgies, if it turns out to be a > bad idea we can remove it before FC6, I'd suggest that lack of selinux support is a non-starter for any constructive discussion about moving initng into rawhide. Talking about other problems associated with the complexity of network mounts or other non-linear init scenario complexities is probably a bit premature. If we known this doesn't work with selinux I think its a waste of time to consider it for inclusion into rawhide. -jef From david at lovesunix.net Sun Apr 9 20:21:53 2006 From: david at lovesunix.net (David Nielsen) Date: Sun, 09 Apr 2006 22:21:53 +0200 Subject: FC6 faster boot In-Reply-To: <1144604734.2294.187.camel@sundaram.pnq.redhat.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144603968.11909.69.camel@localhost.localdomain> <1144604734.2294.187.camel@sundaram.pnq.redhat.com> Message-ID: <1144614113.11909.85.camel@localhost.localdomain> s?n, 09 04 2006 kl. 23:15 +0530, skrev Rahul Sundaram: > > Have you seen this? http://fedoraproject.org/wiki/FCNewInit That document has really grown since I read it last, however it still lacks the fundamental requirement pointed out by Jef - it must integrate well with SELinux or it is completely useless on a default FC setup. InitNG AFAIK doesn't do SELinux yet and the page mentions segfaulting (which is hopefully fixed now). > How well does Initng fit into those requirements currently? I'm sure it's a fine piece of software, don't get me wrong - but if InitNG is going to be hammered into shape we'll need to get it into rawhide as soon as humanly possible - I personally don't mind a bit of babyeating this is a development platform afterall. > Unlike a hammer, Initng can potentially be modified to suit our > requirements if it doesnt fit our specifications if it is a good base to > start with and upstream is open to accepting changes if any is > required. Some hammers aren't suitable for retrofitting, and if we are going to replace the old initsystem, we should do so with the best technical solution (if initng is this solution then fine) - I would hate to replace one bad system with another because it was readily available. What is the longterm maintainablity for InitNG look like, how easily can we adapt it to our needs, how much work would retrofitting InitNG be compared to building a system completely to the specs we have. Also how likely are other distros to replace their init system with initng, larger vendor buy-in would be nice if we are going with an "off the shelf" solution. Here I'm thinking a freedesktop.org like concensus on a standard, be that based off initng or whatever would be absolutely brilliant. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From wacker at octothorp.org Sun Apr 9 22:08:39 2006 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sun, 9 Apr 2006 16:08:39 -0600 (MDT) Subject: Unable to build the dlm-kernel source RPM Message-ID: Hi all, Since FC4, I have been unable to rebuild most of the external module packages for the global file system stuff. The cman packages build, but I can't get dlm-kernel to go. Here's the hopefully relevant part of the build log, followed by the output of "find . -name dlm.o" run in the BUILD directory. Any ideas? -- make[2]: Entering directory `/usr/src/kernels/2.6.16-1.2080_FC5-smp-i686' Building modules, stage 2. MODPOST make[2]: Leaving directory `/usr/src/kernels/2.6.16-1.2080_FC5-smp-i686' make[1]: Leaving directory `/home/wacker/rpmbuild/BUILD/smp/src' + /lib/modules/2.6.16-1.2080_FC5smp/build//scripts/mod/modpost -m -i /lib/modules/2.6.16-1.2080_FC5smp/kernel/cluster/cman.symvers src/dlm.o -o dlm.symvers src/dlm.o: No such file or directory /var/tmp/rpm-tmp.18141: line 32: 9579 Aborted $kernel_src/scripts/mod/modpost -m -i /lib/modules/2.6.16-1.2080_FC5$flavor/kernel/cluster/cman.symvers src/dlm.o -o dlm.symvers error: Bad exit status from /var/tmp/rpm-tmp.18141 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.18141 (%build) The output from find. ./xenU/dlm-kernel-2.6.15-0/src/dlm.o ./smp/dlm-kernel-2.6.15-0/src/dlm.o ./xen0/dlm-kernel-2.6.15-0/src/dlm.o ./dlm-kernel-2.6.15-0/src/dlm.o Bill in Denver From tgl at redhat.com Mon Apr 10 00:13:47 2006 From: tgl at redhat.com (Tom Lane) Date: Sun, 09 Apr 2006 20:13:47 -0400 Subject: MyODBC for FC5? In-Reply-To: <1144601497.9440.46.camel@localhost.localdomain> References: <200604090041.06127.daihardM3@comcast.net> <1144601497.9440.46.camel@localhost.localdomain> Message-ID: <15049.1144628027@sss.pgh.pa.us> "Paul W. Frields" writes: > On Sun, 2006-04-09 at 00:41 -0700, Daigoro Toyama wrote: >> Is there any reason that MyODBC has been removed from Fedora Core 5? > Are you looking for the mysql-connector-odbc package? This is new to > FC5, IIRC. Right, MyODBC has been renamed to mysql-connector-odbc. This is mostly to track the upstream naming of the package, but also because if you have some urgent reason to need the 2.x version of the package alongside the 3.x version, you can do it. I'm not intending to distribute RPMs for the 2.x version anymore, though. regards, tom lane From daihardM3 at comcast.net Mon Apr 10 04:10:26 2006 From: daihardM3 at comcast.net (Daigoro Toyama) Date: Sun, 9 Apr 2006 21:10:26 -0700 Subject: MyODBC for FC5? In-Reply-To: <15049.1144628027@sss.pgh.pa.us> References: <200604090041.06127.daihardM3@comcast.net> <1144601497.9440.46.camel@localhost.localdomain> <15049.1144628027@sss.pgh.pa.us> Message-ID: <200604092110.26935.daihardM3@comcast.net> Hi guys! On Sunday 09 April 2006 17:13, Tom Lane wrote: > "Paul W. Frields" writes: > > > > Are you looking for the mysql-connector-odbc package? This is new to > > FC5, IIRC. > > Right, MyODBC has been renamed to mysql-connector-odbc. This is mostly > to track the upstream naming of the package, but also because if you > have some urgent reason to need the 2.x version of the package alongside > the 3.x version, you can do it. I'm not intending to distribute RPMs > for the 2.x version anymore, though. Thank you for the information. That's exactly what I needed to know. Better yet, the 3.51 driver seems to be backward-compatible with 2.x APIs so I do not have to upgrade my code right away. Thanks again! Dai From naoki at valuecommerce.com Mon Apr 10 04:59:22 2006 From: naoki at valuecommerce.com (Naoki) Date: Mon, 10 Apr 2006 13:59:22 +0900 Subject: ntop in extras? Message-ID: <1144645162.15582.29.camel@dragon.valuecommerce.ne.jp> I'd like to see it. Anybody already working on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Mon Apr 10 06:01:44 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 10 Apr 2006 08:01:44 +0200 Subject: FC6 faster boot In-Reply-To: <604aa7910604091138y44d785b8tfbdab9d01f5e2809@mail.gmail.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <604aa7910604091138y44d785b8tfbdab9d01f5e2809@mail.gmail.com> Message-ID: <4439F4C8.5000204@feuerpokemon.de> Jeff Spaleta wrote: > On 4/9/06, dragoran wrote: > >> rawhide is the place to test new technolgies, if it turns out to be a >> bad idea we can remove it before FC6, >> > > I'd suggest that lack of selinux support is a non-starter for any > constructive discussion about moving initng into rawhide. Talking > about other problems associated with the complexity of network mounts > or other non-linear init scenario complexities is probably a bit > premature. If we known this doesn't work with selinux I think its a > waste of time to consider it for inclusion into rawhide. > > -jef > > its beeing worked on: http://initng.org/ticket/365 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761 if only this is a blocker for rawhide we can simply wait until it supports selinux (or help getting support faster) From pemboa at gmail.com Mon Apr 10 06:36:44 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 10 Apr 2006 01:36:44 -0500 Subject: FC6 faster boot In-Reply-To: <4438BFEB.8010205@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> Message-ID: <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> On 4/9/06, dragoran wrote: > > Before FC4 was released there was a disussion about how to make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras now [1]. > But to get it in the final release it would be better to have it in > rawhide rather than in extras. > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > First off I am sure you have a valid point. But I personally thing that booting has gotten faster from FC4 to FC5, and I know that I have a lot of services starting up. But with me, I do not boot that often, and when I do, i generally walk away (except for when I am busy, or botting the first few times). But tell me, what makes fast booting important to you? I ask because I often wonder if people really need fast booting or something else? I believe some are just over impatient, no idea if that in any way applies to you. Peace -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Mon Apr 10 06:48:03 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 10 Apr 2006 08:48:03 +0200 Subject: FC6 faster boot In-Reply-To: <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> References: <4438BFEB.8010205@feuerpokemon.de> <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> Message-ID: <4439FFA3.60801@feuerpokemon.de> Arthur Pemberton wrote: > > > On 4/9/06, *dragoran* > wrote: > > Before FC4 was released there was a disussion about how to make > the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras now [1]. > But to get it in the final release it would be better to have it in > rawhide rather than in extras. > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > First off I am sure you have a valid point. But I personally thing > that booting has gotten faster from FC4 to FC5, and I know that I have > a lot of services starting up. But with me, I do not boot that often, > and when I do, i generally walk away (except for when I am busy, or > botting the first few times). > > But tell me, what makes fast booting important to you? I ask because I > often wonder if people really need fast booting or something else? I > believe some are just over impatient, no idea if that in any way > applies to you. > > Peace > > > -- > As a boy I jumped through Windows, as a man I play with Penguins. I shutdown my box when I stop working on it, leaving it on is a waste of power (an money). When I boot it again (sometimes for simple tasks like prinitng a file). Its anoying to wait ages before I can do my work, for longer work it does not really matter, but booting faster would'nt hurt. Same is for laptop users, they want to open their laptops and start working... without waiting some minutes before they can start working. You can say just suspend your boxes... The problem is that it does not work on all hardware (for me after suspend network is dead, #187653) FC4 would have booted faster for you if you had enabled early-login.[1] [1]: if you don't have any nfs mounted dirs. From dragoran at feuerpokemon.de Mon Apr 10 06:49:16 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 10 Apr 2006 08:49:16 +0200 Subject: FC6 faster boot In-Reply-To: <20060409182743.GA11722@imperial.ac.uk> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <1144570959.2294.113.camel@sundaram.pnq.redhat.com> <4438C71D.8050207@feuerpokemon.de> <20060409182743.GA11722@imperial.ac.uk> Message-ID: <4439FFEC.2070500@feuerpokemon.de> Kostas Georgiou wrote: > On Sun, Apr 09, 2006 at 10:34:37AM +0200, dragoran wrote: > > >> Rahul Sundaram wrote: >> >>> On Sun, 2006-04-09 at 10:15 +0200, dragoran wrote: >>> >>> Early login wasnt enabled by default so not many users would see that. >>> If you can contribute towards fixing the problems in early login, that >>> might help. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151952 >>> >>> >>> >> as far as I can see the only real problem are nfs mounted /usr or /home >> dirs. >> that can be solved by(starting network) and mounting them before >> starting gdm. >> a simple script could look into fstab to see if this is needed. >> or did I miss anything? >> > > Well many (most?) people use autofs to mount home directories. In my > systems since my home is an nfs4 automount with krb5 you need to start > ntpd,rpcidmapd,rpcgssd,autofs before you can see /home. I know many > places that have their home directories under /afs as well. > > Also keep in mind that a home directory can be anywhere (/usr/people > for example will still be in use in many places I suspect) and you'll > also find links like /home -> /foo/bar where /foo/bar is automounted. > > Simply checking fstab/auto.master isn't going to tell you anything about > where the home directories are. Of course as long as the early startup > can be disabled easily it isn't a problem. > > Kostas Georgiou > > what about a config file? From pemboa at gmail.com Mon Apr 10 06:52:13 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 10 Apr 2006 01:52:13 -0500 Subject: FC6 faster boot In-Reply-To: <4439FFA3.60801@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> <4439FFA3.60801@feuerpokemon.de> Message-ID: <16de708d0604092352r21e141c1hcfb95dd6d4347655@mail.gmail.com> On 4/10/06, dragoran wrote: > > Arthur Pemberton wrote: > > > > > > On 4/9/06, *dragoran* > > wrote: > > > > Before FC4 was released there was a disussion about how to make > > the boot > > process faster. > > But until now (FC5/FC6-rawhide) nothing has been done. > > Early login was in development but it stopped, > > Systemservices was never in a working state. > > Any plans on improving the boot process in FC6? > > I would suggest to use initng which is in review for extras now [1]. > > But to get it in the final release it would be better to have it in > > rawhide rather than in extras. > > > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > > > First off I am sure you have a valid point. But I personally thing > > that booting has gotten faster from FC4 to FC5, and I know that I have > > a lot of services starting up. But with me, I do not boot that often, > > and when I do, i generally walk away (except for when I am busy, or > > botting the first few times). > > > > But tell me, what makes fast booting important to you? I ask because I > > often wonder if people really need fast booting or something else? I > > believe some are just over impatient, no idea if that in any way > > applies to you. > > > > Peace > > > > > > -- > > As a boy I jumped through Windows, as a man I play with Penguins. > I shutdown my box when I stop working on it, leaving it on is a waste of > power (an money). > When I boot it again (sometimes for simple tasks like prinitng a file). > Its anoying to wait ages before I can do my work, for longer work it > does not really matter, but booting faster would'nt hurt. > Same is for laptop users, they want to open their laptops and start > working... without waiting some minutes before they can start working. > You can say just suspend your boxes... > The problem is that it does not work on all hardware (for me after > suspend network is dead, #187653) > FC4 would have booted faster for you if you had enabled early-login.[1] > [1]: if you don't have any nfs mounted dirs. Ok, fair enough. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.canniot at laposte.net Mon Apr 10 07:01:30 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Mon, 10 Apr 2006 09:01:30 +0200 Subject: FC6 faster boot In-Reply-To: <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> References: <4438BFEB.8010205@feuerpokemon.de> <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> Message-ID: <1144652491.2478.6.camel@MrTomLinux.workstation> Le lundi 10 avril 2006 ? 01:36 -0500, Arthur Pemberton a ?crit : > > > On 4/9/06, dragoran wrote: > Before FC4 was released there was a disussion about how to > make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras > now [1]. > But to get it in the final release it would be better to have > it in > rawhide rather than in extras. > > [1]: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > First off I am sure you have a valid point. But I personally thing > that booting has gotten faster from FC4 to FC5, and I know that I have > a lot of services starting up. But with me, I do not boot that often, > and when I do, i generally walk away (except for when I am busy, or > botting the first few times). > > But tell me, what makes fast booting important to you? I ask because I > often wonder if people really need fast booting or something else? I > believe some are just over impatient, no idea if that in any way > applies to you. Well, imagine you're the big boss of a 2000 employee firm. When the OS you have on all the computers of your firm boots up one minute faster every morning, your employees can just work one more minute every day. And you've got 2000 employees, i.e. 2000 people can work one more minute every day, i.e. you earn 2000 minutes of work every day. Multiply it by the number of day work in a year, and then take into account the wages of your employees and then you'll understand how important it is for you to have a fast booting OS. Regards, Thomas > > Peace > > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From buildsys at redhat.com Mon Apr 10 07:08:54 2006 From: buildsys at redhat.com (Build System) Date: Mon, 10 Apr 2006 03:08:54 -0400 Subject: rawhide report: 20060410 changes Message-ID: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> Updated Packages: xorg-x11-drv-acecad-1.1.0-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Bump to 1.1.0 from 7.1RC1. xorg-x11-drv-aiptek-1.0.1-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 1.0.1-1 - Bump to 1.0.1 from 7.1RC1. xorg-x11-drv-apm-1.1.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 from 7.1RC1. xorg-x11-drv-ark-0.6.0-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 0.6.0-1 - Update to 0.6.0 from 7.1RC1. xorg-x11-drv-ati-6.6.0-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 6.6.0-1 - Update to 6.6.0 from 7.1RC1. xorg-x11-drv-calcomp-1.1.0-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-chips-1.1.1-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 from 7.1RC1. xorg-x11-drv-cirrus-1.1.0-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-citron-2.2.0-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 2.2.0-1 - Update to 2.2.0 from 7.1RC1. xorg-x11-drv-cyrix-1.1.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-digitaledge-1.1.0-1 -------------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-dmc-1.1.0-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-dummy-0.2.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 0.2.0-1 - Update to 0.2.0 from 7.1RC1. xorg-x11-drv-dynapro-1.1.0-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-elo2300-1.1.0-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Bump to 1.1.0 from 7.1RC1. xorg-x11-drv-elographics-1.1.0-1 -------------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1 xorg-x11-drv-evdev-1.1.0-2 -------------------------- * Mon Apr 10 2006 Adam Jackson 1.1.0-2 - Disable on ia64 until build issues are sorted. * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-fbdev-0.2.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 0.2.0-1 - Update to 0.2.0 from 7.1RC1. xorg-x11-drv-fpit-1.1.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Updatte to 1.1.0 from 7.1RC1. xorg-x11-drv-glint-1.1.1-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 from 7.1RC1. xorg-x11-drv-hyperpen-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-i128-1.2.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.2.0-1 - Update to 1.2.0 from 7.1RC1. xorg-x11-drv-i740-1.1.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-i810-1.6.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.6.0-1 - Update to 1.6.0 from 7.1RC1. xorg-x11-drv-jamstudio-1.1.0-1 ------------------------------ * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-joystick-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-keyboard-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-magellan-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-mga-1.4.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 1.4.1-1 - Update to 1.4.1 from 7.1RC1. xorg-x11-drv-microtouch-1.1.0-1 ------------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-mouse-1.1.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-mutouch-1.1.0-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-neomagic-1.1.1-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 from 7.1RC1. xorg-x11-drv-palmax-1.1.0-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-penmount-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-rendition-4.1.0-1 ------------------------------ * Sun Apr 09 2006 Adam Jackson 4.1.0-1 - Update to 4.1.0 from 7.1RC1. xorg-x11-drv-s3-0.4.1-1 ----------------------- * Sun Apr 09 2006 Adam Jackson 0.4.1-1 - Update to 0.4.1 from 7.1RC1. xorg-x11-drv-s3virge-1.9.1-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.9.1-1 - Update to 1.9.1 from 7.1RC1. xorg-x11-drv-savage-2.1.1-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 2.1.1-1 - Update to 2.1.1 from 7.1RC1. xorg-x11-drv-siliconmotion-1.4.1-1 ---------------------------------- * Sun Apr 09 2006 Adam Jackson 1.4.1-1 - Update to 1.4.1 from 7.1RC1. xorg-x11-drv-sis-0.9.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 0.9.1-1 - Update to 0.9.1 from 7.1RC1. xorg-x11-drv-spaceorb-1.1.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-summa-1.1.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-tdfx-1.2.1-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.2.1-1 - Update to 1.2.1 from 7.1RC1. xorg-x11-drv-tek4957-1.1.0-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-trident-1.2.1-1 ---------------------------- * Sun Apr 09 2006 Adam Jackson 1.2.1-1 - Update to 1.2.1 from 7.1RC1. xorg-x11-drv-tseng-1.1.0-1 -------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-ur98-1.1.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-v4l-0.1.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 0.1.1-1 - Update to 0.1.1 from 7.1RC1. xorg-x11-drv-vesa-1.1.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-vga-4.1.0-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 4.1.0-1 - Update to 4.1.0 from 7.1RC1. xorg-x11-drv-via-0.2.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 0.2.1-1 - Update to 0.2.1 from 7.1RC1. xorg-x11-drv-vmmouse-12.4.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 12.4.0-1 - Update to 12.4.0 from 7.1RC1. xorg-x11-drv-vmware-10.13.0-1 ----------------------------- * Sun Apr 09 2006 Adam Jackson 10.13.0-1 - Update to 10.13.0 from 7.1RC1. xorg-x11-drv-void-1.1.0-1 ------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-drv-voodoo-1.1.0-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 1.1.0-1 - Update to 1.1.0 from 7.1RC1. xorg-x11-server-1.0.99.901-1 ---------------------------- * Sat Apr 08 2006 Adam Jackson 1.0.99.901-1 - Update to 7.1 RC1. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From Jose-Marcio.Martins at ensmp.fr Mon Apr 10 07:43:32 2006 From: Jose-Marcio.Martins at ensmp.fr (Jose Marcio Martins da Cruz) Date: Mon, 10 Apr 2006 09:43:32 +0200 Subject: Problems setjmp.h on Fedora 5 Message-ID: <443A0CA4.7080502@ensmp.fr> Hello, Maybe this is out of topic, but it's related to developpement and I wasn't able to got the answer elsewhere. I'm having problem related to setjmp calls under a library (statethreads) on Fedora 5. When I try to compile the application using it, I get : depmode=gcc3 /bin/sh ./depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DLINUX -O -g -O2 -c `test -f 'sched.c' || echo './'`sched.c sched.c: In function ?st_thread_create?: sched.c:892: erreur: ?JB_SP? undeclared (first use in this function) sched.c:892: erreur: (Each undeclared identifier is reported only once sched.c:892: erreur: for each function it appears in.) make[3]: *** [sched.o] Erreur 1 make[3]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' make[2]: *** [all-recursive] Erreur 1 make[2]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' make[1]: *** [all] Erreur 2 make[1]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' make: *** [all-recursive] Erreur 1 [root at localhost smX-0.0.0.0]# Under Fedora 4, JB_SP was defined at /usr/include/bits/setjmp.h header. Fedora 5 doesn't define it anymore. It seems that this come from glibc. JB_SP is still defined in the last official glibc release (2.4), but in a different header : jmpbuf-offsets.h. I wasn't able to find any definition of JB_SP in any header of Fedora 5. I tried to define myself the value of JB_SP (4 - the same value found in Fedora 4 headers), but the application segfaults. Any idea ? Regards Jose-Marcio From bart.vanbrabant at zoeloelip.be Mon Apr 10 09:36:31 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Mon, 10 Apr 2006 11:36:31 +0200 Subject: rawhide report: 20060410 changes In-Reply-To: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> Message-ID: <443A271F.3030504@zoeloelip.be> [A lot of xorg updates] This update changes the ABI. This means that the drivers that aren't in this update, like the nv driver, can't be used anymore. X refuses to start. I fixed this by recompiling the nv driver srpm. But this should have been an update of all xorg-x11-drv-* packages. gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From russell at coker.com.au Mon Apr 10 09:55:06 2006 From: russell at coker.com.au (Russell Coker) Date: Mon, 10 Apr 2006 19:55:06 +1000 Subject: xen in FC5 install In-Reply-To: <200604082156.23869.russell@coker.com.au> References: <200604082053.14335.russell@coker.com.au> <443799BF.3070304@argo.co.il> <200604082156.23869.russell@coker.com.au> Message-ID: <200604101955.10165.russell@coker.com.au> On Saturday 08 April 2006 21:56, Russell Coker wrote: > On Saturday 08 April 2006 21:08, Avi Kivity wrote: > > domain 0 grabbed all of memory and isn't letting it go. try adding > > > > dom0_mem=128000 > > Thanks for the suggestion. The dom0_mem parameter doesn't seem to do > anything, but this suggestion led me to "xm mem-set 0 128" which works! > > I've now got the base Xen functionality working so I can fix the SE Linux > policy. I should have a new policy available in about 24 hours to make Xen > work properly. I made a mistake before. I had the dom0_mem parameter on the module line for the Linux kernel rather than the kernel line for Xen. Now it works as desired. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jkeating at j2solutions.net Mon Apr 10 12:33:04 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 10 Apr 2006 08:33:04 -0400 Subject: FC6 faster boot In-Reply-To: <4439F4C8.5000204@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <1144570105.2294.104.camel@sundaram.pnq.redhat.com> <4438C284.1030507@feuerpokemon.de> <604aa7910604091138y44d785b8tfbdab9d01f5e2809@mail.gmail.com> <4439F4C8.5000204@feuerpokemon.de> Message-ID: <1144672384.2538.26.camel@ender> On Mon, 2006-04-10 at 08:01 +0200, dragoran wrote: > if only this is a blocker for rawhide we can simply wait until it > supports selinux (or help getting support faster) This may not be the only blocker. This is the first big non-starter though. We are also going to be working on getting early login in a usable state, which would nullify the need for initng. I'm not entirely convinced that initng is a proper way to go, it still feels like change just for the sake of change. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Apr 10 12:34:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Apr 2006 08:34:27 -0400 Subject: rawhide report: 20060410 changes In-Reply-To: <443A271F.3030504@zoeloelip.be> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> <443A271F.3030504@zoeloelip.be> Message-ID: <1144672468.2538.28.camel@ender> On Mon, 2006-04-10 at 11:36 +0200, Bart Vanbrabant wrote: > > > This update changes the ABI. This means that the drivers that aren't in > this update, like the nv driver, can't be used anymore. X refuses to > start. I fixed this by recompiling the nv driver srpm. > But this should have been an update of all xorg-x11-drv-* packages. I do believe Ajax was working on all the drivers, and was in the process of building them when the rawhide push happened, so part got pushed, the rest were still building. I'll be chatting w/ him today to see if we need to make another push today, or just wait until tomorrow. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tla-ml at rasmil.dk Mon Apr 10 12:35:37 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 10 Apr 2006 14:35:37 +0200 Subject: Installation Wizard in Yumex Message-ID: <443A5119.6020105@rasmil.dk> Hi. I just stumbled over easyUbuntu [1] and got a idea to add some kind of installation Wizard in yumex, to make it easy to add all the extra stuff need to get your fedora running. * Nvidia drivers. * ATI Drivers * NTFS support. * MP3 support. * Movie player with codecs. (Mplayer, gstreamer etc). * Java * Flash I want to make some kind of XML format to creating the Wizard entries and the actions behind. The different people can make there own wizards and people can just drag and drop an URL to a wizard XML into yumex to add the wizard entries to the installation wizard. This could be a way to close the gap between a FOSS distribution and the non free or patent related stuff, there never can be included in Fedora. Let me now what you think, is it a totally lame idea or is it a way to go. Tim Yum Extender Developer. [1] : http://easyubuntu.freecontrib.org/overview.html From ivazquez at ivazquez.net Mon Apr 10 12:53:24 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 10 Apr 2006 08:53:24 -0400 Subject: Installation Wizard in Yumex In-Reply-To: <443A5119.6020105@rasmil.dk> References: <443A5119.6020105@rasmil.dk> Message-ID: <1144673604.14119.15.camel@ignacio.lan> On Mon, 2006-04-10 at 14:35 +0200, Tim Lauridsen wrote: > Hi. > > I just stumbled over easyUbuntu [1] and got a idea to add some kind of > installation Wizard in yumex, to make it easy to add all the > extra stuff need to get your fedora running. > > * Nvidia drivers. > * ATI Drivers > * NTFS support. > * MP3 support. > * Movie player with codecs. (Mplayer, gstreamer etc). > * Java > * Flash > > I want to make some kind of XML format to creating the Wizard entries > and the actions behind. The different people can make there own wizards > and people can just drag and drop an URL to a wizard XML into yumex to > add the wizard entries to the installation wizard. This could be a way > to close the gap between a FOSS distribution and the non free or patent > related stuff, there never can be included in Fedora. > Let me now what you think, is it a totally lame idea or is it a way to go. It's a nice idea, but... http://en.wikipedia.org/wiki/Patent_infringement#Active_inducement_of_infringement -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dionne at cs.wisc.edu Mon Apr 10 12:56:36 2006 From: dionne at cs.wisc.edu (Marc Dionne) Date: Mon, 10 Apr 2006 08:56:36 -0400 (EDT) Subject: Problems setjmp.h on Fedora 5 In-Reply-To: <443A0CA4.7080502@ensmp.fr> References: <443A0CA4.7080502@ensmp.fr> Message-ID: <8294.142.100.131.7.1144673796.squirrel@webmail.cs.wisc.edu> Hi, In recent versions of glibc, setjmp() now mangles the stack pointer when it stores it and unmangles it in longjmp(). I suspect your code is trying to change the stack pointer (since it uses the offset), which won't work unless it knows how to mangle it properly. Some options are to implement the mangling algorithm in the code (which is platform specific and will be a pain to maintain), or switch to using setcontext/makecontext/getcontext. That's what was done in OpenAFS to support FC5. Marc > Hello, > > Maybe this is out of topic, but it's related to developpement and I > wasn't able to got the answer elsewhere. > > I'm having problem related to setjmp calls under a library > (statethreads) on Fedora 5. > > When I try to compile the application using it, I get : > > depmode=gcc3 /bin/sh ./depcomp \ > cc -DHAVE_CONFIG_H -I. -I. -I. -I./../include -DLINUX -O -g -O2 -c `test > -f 'sched.c' || echo './'`sched.c > sched.c: In function ?st_thread_create?: > sched.c:892: erreur: ?JB_SP? undeclared (first use in this function) > sched.c:892: erreur: (Each undeclared identifier is reported only once > sched.c:892: erreur: for each function it appears in.) > make[3]: *** [sched.o] Erreur 1 > make[3]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' > make[2]: *** [all-recursive] Erreur 1 > make[2]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' > make[1]: *** [all] Erreur 2 > make[1]: Leaving directory `/home/smXinstall/smX-0.0.0.0/statethreads' > make: *** [all-recursive] Erreur 1 > [root at localhost smX-0.0.0.0]# > > Under Fedora 4, JB_SP was defined at /usr/include/bits/setjmp.h header. > Fedora 5 doesn't define it anymore. > > It seems that this come from glibc. JB_SP is still defined in the last > official glibc release (2.4), but in a different header : > jmpbuf-offsets.h. > > I wasn't able to find any definition of JB_SP in any header of Fedora 5. > > I tried to define myself the value of JB_SP (4 - the same value found in > Fedora 4 headers), but the application segfaults. > > Any idea ? > > Regards > > Jose-Marcio From tla-ml at rasmil.dk Mon Apr 10 13:14:22 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 10 Apr 2006 15:14:22 +0200 Subject: Installation Wizard in Yumex In-Reply-To: <1144673604.14119.15.camel@ignacio.lan> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> Message-ID: <443A5A2E.2070007@rasmil.dk> Ignacio Vazquez-Abrams wrote: > On Mon, 2006-04-10 at 14:35 +0200, Tim Lauridsen wrote: > >> Hi. >> >> I just stumbled over easyUbuntu [1] and got a idea to add some kind of >> installation Wizard in yumex, to make it easy to add all the >> extra stuff need to get your fedora running. >> >> * Nvidia drivers. >> * ATI Drivers >> * NTFS support. >> * MP3 support. >> * Movie player with codecs. (Mplayer, gstreamer etc). >> * Java >> * Flash >> >> I want to make some kind of XML format to creating the Wizard entries >> and the actions behind. The different people can make there own wizards >> and people can just drag and drop an URL to a wizard XML into yumex to >> add the wizard entries to the installation wizard. This could be a way >> to close the gap between a FOSS distribution and the non free or patent >> related stuff, there never can be included in Fedora. >> Let me now what you think, is it a totally lame idea or is it a way to go. >> > > It's a nice idea, but... > > http://en.wikipedia.org/wiki/Patent_infringement#Active_inducement_of_infringement > > I just want to code a easy way to install things, not try to break any patent, i will not include anything illegal into yumex, but people located i place where software patents don't exist, can make a wizard plugin to install the stuff hosted in places like livna or freshrpms. I same way as yum and rpm can be used to installed patent releated stuff, but it is not the purpose of the application. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Mon Apr 10 13:40:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Apr 2006 09:40:23 -0400 Subject: Installation Wizard in Yumex In-Reply-To: <443A5119.6020105@rasmil.dk> References: <443A5119.6020105@rasmil.dk> Message-ID: <604aa7910604100640o188786a9qad51c3cc69a2d46@mail.gmail.com> On 4/10/06, Tim Lauridsen wrote: > I want to make some kind of XML format to creating the Wizard entries > and the actions behind. The different people can make there own wizards > and people can just drag and drop an URL to a wizard XML into yumex to > add the wizard entries to the installation wizard. This could be a way > to close the gap between a FOSS distribution and the non free or patent > related stuff, there never can be included in Fedora. > Let me now what you think, is it a totally lame idea or is it a way to go. So if you don't include the wizard in yumex in Fedora Extras because of legal constraints... how exactly do people find the wizards? Google searches? I think you are overthinking the problem and coming up with pretty much the most complicated solution that you can think of. You don't need an extra layer of code... for some weird ass xml object that describes how to get an rpm....all you need is drag and drop support of rpm urls directly. You still have to rely on people finding something on the web so the xml installer plugin concept isn't solving the underlying problem. If people can google search to find these new xml object urls.. they can most certaintly google search and find the rpm urls. -jef From ajackson at redhat.com Mon Apr 10 14:17:51 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 10 Apr 2006 10:17:51 -0400 Subject: rawhide report: 20060410 changes In-Reply-To: <443A271F.3030504@zoeloelip.be> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> <443A271F.3030504@zoeloelip.be> Message-ID: <443A690F.9090504@redhat.com> Bart Vanbrabant wrote: > [A lot of xorg updates] > > This update changes the ABI. This means that the drivers that aren't in > this update, like the nv driver, can't be used anymore. X refuses to > start. I fixed this by recompiling the nv driver srpm. > But this should have been an update of all xorg-x11-drv-* packages. I'm aware. I tried to get them all in before the cutoff but the build system thwarted me. For the record, the following drivers were not updated: - nv - nsc - sisusb The first two were timing issues getting the build complete, the second was due to an upstream packaging screwup (empty tarball? how'd that happen). Also as mentioned in the report, the new ABI of the evdev driver is not built for ia64, due to a spontaneous build failure that I didn't have time to track down. The first three issues, and hopefully the fourth, should be resolved by tomorrow's rawhide. - ajax From notting at redhat.com Mon Apr 10 15:25:18 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Apr 2006 11:25:18 -0400 Subject: FC6 faster boot In-Reply-To: <4438BFEB.8010205@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> Message-ID: <20060410152518.GA7764@devserv.devel.redhat.com> dragoran (dragoran at feuerpokemon.de) said: > Before FC4 was released there was a disussion about how to make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. Well, actually, if you compare FC3 to FC5, I'd suspect you'd notice it *does* boot measurably faster. Those are evolutionary changes, though. Bill From gilboad at gmail.com Mon Apr 10 15:37:10 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 10 Apr 2006 18:37:10 +0300 Subject: FC6 faster boot In-Reply-To: <4438BFEB.8010205@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> Message-ID: <1144683430.2885.7.camel@gilboa-work-dev> On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: > Before FC4 was released there was a disussion about how to make the boot > process faster. > But until now (FC5/FC6-rawhide) nothing has been done. > Early login was in development but it stopped, > Systemservices was never in a working state. > Any plans on improving the boot process in FC6? > I would suggest to use initng which is in review for extras now [1]. > But to get it in the final release it would be better to have it in > rawhide rather than in extras. > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > It seems to me that having suspend/hibernate working on 99.99% of all machine will serve Fedora *much* better. While a new init system might shave 30 seconds (or even a minute) of FC6/7 startup time, working hibernate/suspend will cut the wake-up time to mere seconds... As I see it, a machine should only be rebooted -if- the kernel/glibc was upgraded. Everything else should be handled suspend/hibernate/service restart/DE/X restart/. Gilboa From drepper at redhat.com Mon Apr 10 15:38:20 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 10 Apr 2006 08:38:20 -0700 Subject: Problems setjmp.h on Fedora 5 In-Reply-To: <443A0CA4.7080502@ensmp.fr> References: <443A0CA4.7080502@ensmp.fr> Message-ID: <443A7BEC.1080709@redhat.com> Jose Marcio Martins da Cruz wrote: > I tried to define myself the value of JB_SP (4 - the same value found in > Fedora 4 headers), but the application segfaults. That value was never meant to be used by programs. It was a value needed in the implementation and unfortunately it was placed in the public header. This is fixed now. And for a good reason: you cannot access the values at all anymore today. The stored values are "encrypted". You can disable the encryption using the LD_POINTER_GUARD environment variable. Unfortunately the glibc version so far in FC5 has a little bug. The next update will allow you to specify LD_POINTER_GUARD=0. But this is really the wrong solution. The program should be rewritten to use __builtin_frame_address (see the gcc manual). -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: From david at lovesunix.net Mon Apr 10 15:46:57 2006 From: david at lovesunix.net (David Nielsen) Date: Mon, 10 Apr 2006 17:46:57 +0200 Subject: FC6 faster boot In-Reply-To: <1144683430.2885.7.camel@gilboa-work-dev> References: <4438BFEB.8010205@feuerpokemon.de> <1144683430.2885.7.camel@gilboa-work-dev> Message-ID: <1144684017.14869.18.camel@localhost.localdomain> man, 10 04 2006 kl. 18:37 +0300, skrev Gilboa Davara: > On Sun, 2006-04-09 at 10:03 +0200, dragoran wrote: > > Before FC4 was released there was a disussion about how to make the boot > > process faster. > > But until now (FC5/FC6-rawhide) nothing has been done. > > Early login was in development but it stopped, > > Systemservices was never in a working state. > > Any plans on improving the boot process in FC6? > > I would suggest to use initng which is in review for extras now [1]. > > But to get it in the final release it would be better to have it in > > rawhide rather than in extras. > > > > [1]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 > > > > It seems to me that having suspend/hibernate working on 99.99% of all > machine will serve Fedora *much* better. While a new init system might > shave 30 seconds (or even a minute) of FC6/7 startup time, working > hibernate/suspend will cut the wake-up time to mere seconds... > > As I see it, a machine should only be rebooted -if- the kernel/glibc was > upgraded. Everything else should be handled suspend/hibernate/service > restart/DE/X restart/. Working hibernation/suspend is nice but it will not restart services that crashed, it does not solve dependency problems, it also doesn't provide us with dbus methods of getting more information and control. I think we do need both. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jspaleta at gmail.com Mon Apr 10 16:01:20 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Apr 2006 12:01:20 -0400 Subject: FC6 faster boot In-Reply-To: <1144683430.2885.7.camel@gilboa-work-dev> References: <4438BFEB.8010205@feuerpokemon.de> <1144683430.2885.7.camel@gilboa-work-dev> Message-ID: <604aa7910604100901m34a439b5g9f74390e97a15e66@mail.gmail.com> On 4/10/06, Gilboa Davara wrote: > It seems to me that having suspend/hibernate working on 99.99% of all > machine will serve Fedora *much* better. While a new init system might > shave 30 seconds (or even a minute) of FC6/7 startup time, working > hibernate/suspend will cut the wake-up time to mere seconds... +1 jumping to a different init system will be a lesson in boottime corner-case shuffling... no matter what technology is chosen... there will be setups that become sub-optimal or more complicated to correctly configure and there will be some that will get a speed up. Considering the variety of system configurations that must be supported I simply can not see how worrying about the speed of boot up for a particular system configuration matters. A robust suspend/hibernate helps everyone. And if suspend/hibernate is not working for some hardware that should be fixed... not hacked around by complicating the init process for everyone else. Boottime can not be the leading motivator for a realistic discussion of an init system replacement. There is a wealth of new advanced functionality that init system replacements like initng bring to the table in terms of service management that are much more important than optimization of boot time by a few seconds. Whether or not an init replacement with advanced functionality is a net win or loss for system boottimes is simply not as important as that additional functionality. Suspend/hibernate is what matters if you need "instant on". > As I see it, a machine should only be rebooted -if- the kernel/glibc was > upgraded. Everything else should be handled suspend/hibernate/service > restart/DE/X restart/. Or a little less strictly... have room in the repodata so package maintainers can mark a package as requiring a reboot to function, and clientside package tools can then inform users as appropriate. I believe that pup has a hardwired list at the moment and has ui to notify about required reboots if those packages are updated. -jef From dnjinc at wowway.com Mon Apr 10 16:01:49 2006 From: dnjinc at wowway.com (Demond James) Date: Mon, 10 Apr 2006 12:01:49 -0400 Subject: FC6 faster boot In-Reply-To: <4439FFA3.60801@feuerpokemon.de> References: <4438BFEB.8010205@feuerpokemon.de> <16de708d0604092336n476840f2j49dd15d792971f96@mail.gmail.com> <4439FFA3.60801@feuerpokemon.de> Message-ID: <443A816D.7090201@wowway.com> dragoran wrote: > I shutdown my box when I stop working on it, leaving it on is a waste > of power (an money). > When I boot it again (sometimes for simple tasks like prinitng a > file). Its anoying to wait ages before I can do my work, for longer > work it does not really matter, but booting faster would'nt hurt. > Same is for laptop users, they want to open their laptops and start > working... without waiting some minutes before they can start working. > You can say just suspend your boxes... > The problem is that it does not work on all hardware (for me after > suspend network is dead, #187653) > FC4 would have booted faster for you if you had enabled early-login.[1] > [1]: if you don't have any nfs mounted dirs. > It seems that you should be advocating to get hibernate working on all hardware as this would serve the situation you described here best. Demond From jspaleta at gmail.com Mon Apr 10 16:05:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Apr 2006 12:05:24 -0400 Subject: FC6 faster boot In-Reply-To: <1144684017.14869.18.camel@localhost.localdomain> References: <4438BFEB.8010205@feuerpokemon.de> <1144683430.2885.7.camel@gilboa-work-dev> <1144684017.14869.18.camel@localhost.localdomain> Message-ID: <604aa7910604100905n4002081sa06107945a09e5d9@mail.gmail.com> On 4/10/06, David Nielsen wrote: > Working hibernation/suspend is nice but it will not restart services > that crashed, it does not solve dependency problems, it also doesn't > provide us with dbus methods of getting more information and control. > > I think we do need both. And these issues are completely orthogonal to speed of a full boot. An init system replacement should be focusing on exactly the problems you mention here.. and whether speed of a full boot is helped or suffers to fix these functionality issue is a secondary optimization issue. We need these functionality issues solved, we don't need boottime heavily optimized. -jef From dnjinc at wowway.com Mon Apr 10 16:05:47 2006 From: dnjinc at wowway.com (Demond James) Date: Mon, 10 Apr 2006 12:05:47 -0400 Subject: aiglx status In-Reply-To: <1144562418.3153.0.camel@aglarond.local> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> <1144562418.3153.0.camel@aglarond.local> Message-ID: <443A825B.2090504@wowway.com> Jeremy Katz wrote: > On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: > >> Jeremy Katz wrote: >> >>> On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: >>> >>>> whats the current status of aiglx development? >>>> the FC5 binarys have not been updated since inital release. >>>> Is the x86_64 bug solved? >>>> Can it be added to rawhide to get more testing? Or is it still not ready >>>> for rawhide ? >>>> >>>> >>> The aiglx code is already in the main trunk of xorg development being >>> targeted for Xorg 7.1. Packages tracking that are already present in >>> rawhide >>> >>> >> thats means x86_64 is supported now? >> > > Worked on my x86_64 box with a radeon at the office when I tried a few > weeks ago. I haven't tried since between vacation and LinuxWorld/FUDCon > > Jeremy > > Will this work with the new nvidia drivers? Version1.0.8756 released 04-07-06. http://www.nvnews.net/vbulletin/showthread.php?t=67864 Thanks, Demond From seanlkml at sympatico.ca Mon Apr 10 16:41:11 2006 From: seanlkml at sympatico.ca (sean) Date: Mon, 10 Apr 2006 12:41:11 -0400 Subject: Installation Wizard in Yumex In-Reply-To: <443A5A2E.2070007@rasmil.dk> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> Message-ID: On Mon, 10 Apr 2006 15:14:22 +0200 Tim Lauridsen wrote: > I just want to code a easy way to install things, not try to break any > patent, i will not include anything illegal into yumex, but people > located i place where software patents don't exist, can make a wizard > plugin to install the stuff hosted in places like livna or freshrpms. > I same way as yum and rpm can be used to installed patent releated > stuff, but it is not the purpose of the application. It's already possible for a user to click-install a rpm that adds many repo entries without the need for a wizard. After that calling up yumex to install whatever packages are desired is easy. However, AFAIK there isn't a graphical method to enable and disable yum repos. Adding that feature would help to make things easier and safer. It would then be reasonable for a single rpm to install multiple repos, and let the user individually enable them as desired. Perhaps any comments included in each repo file could be shown to the user as well. $0.02, Sean From katzj at redhat.com Mon Apr 10 18:32:59 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 10 Apr 2006 14:32:59 -0400 Subject: FC6 faster boot In-Reply-To: <604aa7910604100901m34a439b5g9f74390e97a15e66@mail.gmail.com> References: <4438BFEB.8010205@feuerpokemon.de> <1144683430.2885.7.camel@gilboa-work-dev> <604aa7910604100901m34a439b5g9f74390e97a15e66@mail.gmail.com> Message-ID: <1144693979.3287.19.camel@aglarond.local> On Mon, 2006-04-10 at 12:01 -0400, Jeff Spaleta wrote: > > As I see it, a machine should only be rebooted -if- the kernel/glibc was > > upgraded. Everything else should be handled suspend/hibernate/service > > restart/DE/X restart/. > > Or a little less strictly... have room in the repodata so package > maintainers can mark a package as requiring a reboot to function, and > clientside package tools can then inform users as appropriate. I > believe that pup has a hardwired list at the moment and has ui to > notify about required reboots if those packages are updated. Correct and having it in the update metadata is already the plan Jeremy From d.jacobfeuerborn at conversis.de Mon Apr 10 19:03:23 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 10 Apr 2006 21:03:23 +0200 Subject: rawhide report: 20060410 changes In-Reply-To: <1144672468.2538.28.camel@ender> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> <443A271F.3030504@zoeloelip.be> <1144672468.2538.28.camel@ender> Message-ID: <443AABFB.7050107@conversis.de> Jesse Keating wrote: > On Mon, 2006-04-10 at 11:36 +0200, Bart Vanbrabant wrote: >> >> This update changes the ABI. This means that the drivers that aren't in >> this update, like the nv driver, can't be used anymore. X refuses to >> start. I fixed this by recompiling the nv driver srpm. >> But this should have been an update of all xorg-x11-drv-* packages. > > I do believe Ajax was working on all the drivers, and was in the process > of building them when the rawhide push happened, so part got pushed, the > rest were still building. I'll be chatting w/ him today to see if we > need to make another push today, or just wait until tomorrow. Is it possible to get rid of the xorg-x11-drivers stub package now that fc5 is out and about or does this anything in addition to make sure all drivers are installed for the modular upgrade? Regards, Dennis From jspaleta at gmail.com Mon Apr 10 19:15:27 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Apr 2006 15:15:27 -0400 Subject: rawhide report: 20060410 changes In-Reply-To: <443AABFB.7050107@conversis.de> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> <443A271F.3030504@zoeloelip.be> <1144672468.2538.28.camel@ender> <443AABFB.7050107@conversis.de> Message-ID: <604aa7910604101215t2ae984c3l215995a2f305b546@mail.gmail.com> On 4/10/06, Dennis Jacobfeuerborn wrote: > Is it possible to get rid of the xorg-x11-drivers stub package now that fc5 > is out and about or does this anything in addition to make sure all drivers > are installed for the modular upgrade? If that package is removed... how do you propose that you make sure drivers are installed on the system so that changes in hardware can be handled post operating system installation? There is no mechanism currently available by which changes in hardware initiate a package installation process to pick up missing drivers... so all the drivers need to be on the system already. This stub packages serves exactly that role. -jef From che666 at gmail.com Mon Apr 10 23:04:30 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 11 Apr 2006 01:04:30 +0200 Subject: rawhide report: 20060410 changes In-Reply-To: <604aa7910604101215t2ae984c3l215995a2f305b546@mail.gmail.com> References: <200604100708.k3A78s2S030919@porkchop.devel.redhat.com> <443A271F.3030504@zoeloelip.be> <1144672468.2538.28.camel@ender> <443AABFB.7050107@conversis.de> <604aa7910604101215t2ae984c3l215995a2f305b546@mail.gmail.com> Message-ID: 2006/4/10, Jeff Spaleta : > On 4/10/06, Dennis Jacobfeuerborn wrote: > > Is it possible to get rid of the xorg-x11-drivers stub package now that fc5 > > is out and about or does this anything in addition to make sure all drivers > > are installed for the modular upgrade? > > If that package is removed... how do you propose that you make sure > drivers are installed on the system so that changes in hardware can be > handled post operating system installation? There is no mechanism > currently available by which changes in hardware initiate a package > installation process to pick up missing drivers... so all the drivers > need to be on the system already. This stub packages serves exactly > that role. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > well actually i would also be happier if the stub package wouldnt be required but i guess there are other things with more impact that should have more priority at this point. regards, rudolf kastl From gemi at bluewin.ch Tue Apr 11 01:31:17 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 11 Apr 2006 03:31:17 +0200 Subject: When do we get a more usable printer dialog for GNOME? Message-ID: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> The current printer dialog of GNOME applications (is this supplied by gnome-print?) is only usable for printer that do not have any important settings (mostly PostScript laser printers). Colour printers have many settings, most importantly print quality and paper type. These are all configurable via CUPS. But the GNOME print dialog only shows some standard options. Of course the options can be set globally using system-config-printer, which is not acceptable for such a task, which is independent of the system settings. After all cups is standard in most Linux distrbutions for quite a long time, a KDE *does* allow advanced settings (even if the dialog is not very well done). Are there plans by the Fedora Core development team to change this? Regards, G?rard -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From peter at thecodergeek.com Tue Apr 11 01:34:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 10 Apr 2006 18:34:53 -0700 Subject: When do we get a more usable printer dialog for GNOME? In-Reply-To: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> References: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> Message-ID: <443B07BD.8020206@thecodergeek.com> ? Milmeister wrote: > After all cups is standard in most Linux distrbutions > for quite a long time, a KDE *does* allow advanced > settings (even if the dialog is not very well done). > Are there plans by the Fedora Core development team to > change this? That's one of the things being worked on heavily in upstream development, as I understand it. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From dragoran at feuerpokemon.de Tue Apr 11 06:06:30 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 11 Apr 2006 08:06:30 +0200 Subject: aiglx status In-Reply-To: <443A825B.2090504@wowway.com> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> <1144562418.3153.0.camel@aglarond.local> <443A825B.2090504@wowway.com> Message-ID: <443B4766.2080505@feuerpokemon.de> Demond James wrote: > Jeremy Katz wrote: >> On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: >> >>> Jeremy Katz wrote: >>> >>>> On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: >>>> >>>>> whats the current status of aiglx development? >>>>> the FC5 binarys have not been updated since inital release. >>>>> Is the x86_64 bug solved? >>>>> Can it be added to rawhide to get more testing? Or is it still not >>>>> ready for rawhide ? >>>>> >>>> The aiglx code is already in the main trunk of xorg development being >>>> targeted for Xorg 7.1. Packages tracking that are already present in >>>> rawhide >>>> >>>> >>> thats means x86_64 is supported now? >>> >> >> Worked on my x86_64 box with a radeon at the office when I tried a few >> weeks ago. I haven't tried since between vacation and LinuxWorld/FUDCon >> >> Jeremy >> >> > Will this work with the new nvidia drivers? Version1.0.8756 released > 04-07-06. > http://www.nvnews.net/vbulletin/showthread.php?t=67864 > > > Thanks, > Demond > I haven't tryed yet but I would say no. http://www.nvnews.net/vbulletin/showthread.php?t=68104 From buildsys at redhat.com Tue Apr 11 07:26:12 2006 From: buildsys at redhat.com (Build System) Date: Tue, 11 Apr 2006 03:26:12 -0400 Subject: rawhide report: 20060411 changes Message-ID: <200604110726.k3B7QCFu030808@porkchop.devel.redhat.com> Updated Packages: amanda-2.5.0-2 -------------- * Fri Apr 07 2006 Jay Fenlason 2.5.0-2 - New upstream release: 2.5.0, with new features - Do not include our own amanda.conf anymore, use the one from the tarball. - Remove the static libraries. - Update the -pie patch - Turn on the new -with-ssh-security option. - Change the mode of ~amanda/.amandahosts to 600, since 2.5.0 requires it. - actually use the defconfig macro it this spec file. - Change the name of the index server to "amandahost" from localhost. Users should ensure that "amandahost.their-domain" points to their Amanda server. - Change amandahosts likewise. - Add dependency on /usr/bin/Mail - Ensure unversioned .so files are only in the -devel rpm. - Remove DUMPER_DIR and the files in it, as nothing seems to actually use them. - Include the -overflow patch from Jean-Louis Martineau control-center-1:2.14.1-2 ------------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 * Thu Apr 06 2006 Ray Strode - 2.14.0-2 - add missing build reqs (bug 188167) eel2-2.14.1-2 ------------- * Tue Apr 11 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 eog-2.14.1-2 ------------ * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 epiphany-2.14.1-2 ----------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 evolution-2.6.1-2 ----------------- * Mon Apr 10 2006 Matthias Clasen - 2.6.1-2 - Update to 2.6.1 evolution-connector-2.6.1-2 --------------------------- * Mon Apr 10 2006 Matthias Clasen - 2.6.1-2 - Update to 2.6.1 evolution-data-server-1.6.1-3 ----------------------------- * Mon Apr 10 2006 Matthias Clasen - 1.6.1-3 - Avoid a multilib conflict * Mon Apr 10 2006 Matthias Clasen - 1.6.1-2 - Update to 1.6.1 file-roller-2.14.1-2 -------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 gcc-4.1.0-7 ----------- * Mon Apr 10 2006 Jakub Jelinek 4.1.0-7 - update from gcc-4_1-branch (-r112727:112825) - PRs fortran/19101, fortran/25031, fortran/26779, fortran/26891, fortran/26976, target/26508, tree-optimization/26919 - fix libgfortran printing of REAL*16 for IEEE quad and IBM extended formats (PR libgfortran/24685) - fix Fortran -fbounds-check (Roger Sayle, #188409, PR middle-end/22375) - fix Java StackTraceElement.toString() (Mark Wielaard, #183212, PR classpath/27081) - fix -fopenmp -static gedit-1:2.14.2-2 ---------------- * Mon Apr 10 2006 Matthias Clasen 2.14.2-2 - Update to 2.14.2 ghostscript-8.15.1-9 -------------------- * Mon Apr 10 2006 Tim Waugh 8.15.1-9 - Add %{_datadir}/fonts/japanese to font path (bug #188448). - Spec file cleanups (bug #188066). * Sat Apr 08 2006 Tim Waugh - Build requires libtool (bug #188341). gnome-applets-1:2.14.1-2 ------------------------ * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 - Update patches gnome-desktop-2.14.1-2 ---------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 gnome-games-1:2.14.1-2 ---------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 gnome-panel-2.14.1-2 -------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 - Update patches gnome-screensaver-2.14.1-2 -------------------------- * Mon Apr 10 2006 Matthias Clasen 2.14.1-2 - Update to 2.14.1 - Drop upstreamed patch gnome-session-2.14.1-2 ---------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 gnome-system-monitor-2.14.1-2 ----------------------------- * Mon Apr 10 2006 Matthias Clasen 2.14.1-2 - Update to 2.14.1 gnome-terminal-2.14.1-2 ----------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 gnome-user-docs-2.14.2-2 ------------------------ * Tue Apr 11 2006 Matthias Clasen 2.14.2-2 - Update to 2.14.2 * Mon Apr 10 2006 Matthias Clasen 2.14.1-2 - Update to 2.14.1 gnopernicus-1.0.4-2 ------------------- * Mon Apr 10 2006 Matthias Clasen - 1.0.4-2 - Update to 1.0.4 gtk-doc-1.6-2 ------------- * Mon Apr 10 2006 Matthias Clasen 1.6-2 - Update to 1.6 gtkhtml3-3.10.1-2 ----------------- * Mon Apr 10 2006 Matthias Clasen - 3.10.1-2 - Update to 3.10.1 - Update patches gtksourceview-1.6.1-2 --------------------- * Mon Apr 10 2006 Matthias Clasen - 1.6.1-2 - Update to 1.6.1 initscripts-8.32-1 ------------------ * Mon Apr 10 2006 Bill Nottingham 8.32-1 - netfs: fix redirect (#187505) - rc.sysinit add forcequotacheck (#168118, ) - functions/pidof: various fixes (#182623, others ) - add support for DHCP on bridges (#125259, , anders at kaseorg.com>) - rc.sysinit: use pidof, not killall (#185429, ) - ppp fixes (#129195, #163950, #92023, , ) - ifup/ifdown: unset $WINDOW (#174336, ) isdn4k-utils-3.2-42 ------------------- * Thu Mar 30 2006 Than Ngo 3.2-42 - support pppd 2.4.3 #187218 * Fri Mar 10 2006 Than Ngo 3.2-41 - add missing symlink for capi plugins #165198 joe-3.3-3 --------- * Mon Apr 10 2006 Ivana Varekova 3.3-3 - fix problem with Polish characters - bug 188235 jpilot-0.99.8-5 --------------- * Mon Apr 10 2006 Ivana Varekova 0.99.8-5 - add upstream memory patch (#188425) - add upstream sync patch kernel-2.6.16-1.2128_FC6 ------------------------ * Mon Apr 10 2006 Dave Jones - 2.6.16rc1-git2 & git3 - Enable SMP on all x86 kernels. SMP_ALTERNATIVES disables the spinlocks etc at runtime. - setuid /proc/self/maps fix (#165351) libgnome-2.14.1-2 ----------------- * Tue Apr 11 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 * Mon Mar 13 2006 Matthias Clasen - 2.14.0-1 - Update to 2.14.0 * Mon Feb 27 2006 Matthias Clasen - 2.13.90-1 - Update to 2.13.90 - Drop obsolete patch libgnomeui-2.14.1-2 ------------------- * Tue Apr 11 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 libgtop2-2.14.1-2 ----------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 libsoup-2.2.92-2 ---------------- * Mon Apr 10 2006 Matthias Clasen - 2.2.92-2 - Update to 2.2.92 libvirt-0.1.0-1 --------------- * Mon Apr 10 2006 Daniel Veillard 0.1.0-1 - various fixes - new APIs: for Node information and Reboot - virsh improvements and extensions - documentation updates and man page - enhancement and fixes of the XML description format libwnck-2.14.1-2 ---------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 linuxwacom-0:0.7.2-3 -------------------- * Mon Apr 10 2006 Adam Jackson 0:0.7.2-3 - Delibcwrap and otherwise rebuild for 7.1RC1 ABI changes. mesa-6.5-3 ---------- * Mon Apr 10 2006 Kristian H??gsberg 6.5-3 - Add mesa-6.5-noexecstack.patch to prevent assembly files from making libGL.so have executable stack. * Mon Apr 10 2006 Kristian H??gsberg 6.5-2 - Bump for fc5 build. - Bump libdrm requires to 2.0.1. mkinitrd-5.0.34-1 ----------------- * Mon Apr 10 2006 Peter Jones - 5.0.34-1 - fix "!" handling for sysfs paths in mkblkdevs - fix argument checking for mknodCommand nautilus-2.14.1-2 ----------------- * Tue Apr 11 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 * Mon Mar 13 2006 Matthias Clasen - 2.14.0-1 - Update to 2.14.0 * Mon Mar 06 2006 Matthias Clasen - 2.13.92-2 - Reinstate the format patch which was accidentally dropped nautilus-cd-burner-2.14.1-2 --------------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 scim-1.4.4-14 ------------- * Mon Apr 10 2006 Jens Petersen - 1.4.4-14 - subpackage scim-bridge and add xinput.d file for scim-bridge - add scim_ver and scim_bridge_ver * Fri Apr 07 2006 Jens Petersen - 1.4.4-13 - update to scim-bridge-0.1.4 * Mon Apr 03 2006 Jens Petersen - 1.4.4-12 - update to scim-bridge-0.1.3 - no longer need to bootstrap selinux-policy-2.2.29-6 ----------------------- * Mon Apr 10 2006 Dan Walsh 2.2.29-6 - Allow secadm_t ability to relabel all files - Allow ftp to search xferlog_t directories - Allow mysql to communicate with ldap - Allow rsync to bind to rsync_port_t * Mon Apr 10 2006 Russell Coker 2.2.29-5 - Fixed mailman with Postfix #183928 - Allowed semanage to create file_context files. - Allowed amanda_t to access inetd_t TCP sockets and allowed amanda_recover_t to bind to reserved ports. #149030 - Don't allow devpts_t to be associated with tmp_t. - Allow hald_t to stat all mountpoints. - Added boolean samba_share_nfs to allow smbd_t full access to NFS mounts. - Make mount run in mount_t domain from unconfined_t to prevent mislabeling of /etc/mtab. - Changed the file_contexts to not have a regex before the first ^/[a-z]/ whenever possible, makes restorecon slightly faster. - Correct the label of /etc/named.caching-nameserver.conf - Now label /usr/src/kernels/.+/lib(/.*)? as usr_t instead of /usr/src(/.*)?/lib(/.*)? - I don't think we need anything else under /usr/src hit by this. - Granted xen access to /boot, allowed mounting on xend_var_lib_t, and allowed xenstored_t rw access to the xen device node. sound-juicer-2.14.2-2 --------------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 synaptics-0:0.14.4-5 -------------------- * Mon Apr 10 2006 Adam Jackson 0.42-3 - show localtime instead of GMT (#172274) xorg-x11-drv-evdev-1.1.0-3 -------------------------- * Mon Apr 10 2006 Adam Jackson 1.1.0-3 - Work around header pollution on ia64, re-add to arch list. xorg-x11-drv-nsc-2.8.1-1 ------------------------ * Sun Apr 09 2006 Adam Jackson 2.8.1-1 - Update to 2.8.1 from 7.1RC1. xorg-x11-drv-nv-1.1.1-2 ----------------------- * Mon Apr 10 2006 Adam Jackson 1.1.1-2 - Bump to appease beehive. * Sun Apr 09 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 from 7.1RC1. xorg-x11-drv-sisusb-0.8.1-1 --------------------------- * Sun Apr 09 2006 Adam Jackson 0.8.1-1 - Update to 0.8.1 from 7.1RC1. yelp-2.14.1-2 ------------- * Mon Apr 10 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 yum-2.6.0-2 ----------- * Mon Apr 10 2006 Jeremy Katz - 2.6.0-2 - add fix for xen0/xenU kernels in installonlyn (#187894) - add fix for proxies with the mirror list (#161190) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.i386 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.i386 requires libgnome.so.32 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ia64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ia64 requires libgnomeui.so.32()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gdk-pixbuf-devel - 1:0.22.0-22.ppc requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.ppc requires libgnome.so.32 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gdk-pixbuf-devel - 1:0.22.0-22.ppc64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.ppc64 requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomesupport.so.0 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnomeui.so.32 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libart_lgpl.so.2 gdk-pixbuf-gnome - 1:0.22.0-22.s390 requires libgnome.so.32 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 gdk-pixbuf-devel - 1:0.22.0-22.s390x requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.s390x requires libgnomeui.so.32()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gdk-pixbuf-devel - 1:0.22.0-22.x86_64 requires gnome-libs-devel gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomesupport.so.0()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libart_lgpl.so.2()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnome.so.32()(64bit) gdk-pixbuf-gnome - 1:0.22.0-22.x86_64 requires libgnomeui.so.32()(64bit) gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From dragoran at feuerpokemon.de Tue Apr 11 07:33:16 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 11 Apr 2006 09:33:16 +0200 Subject: rawhide report: 20060411 changes In-Reply-To: <200604110726.k3B7QCFu030808@porkchop.devel.redhat.com> References: <200604110726.k3B7QCFu030808@porkchop.devel.redhat.com> Message-ID: <443B5BBC.2060107@feuerpokemon.de> Build System wrote: > [..] > > kernel-2.6.16-1.2128_FC6 > ------------------------ > * Mon Apr 10 2006 Dave Jones > - 2.6.16rc1-git2 & git3 > - Enable SMP on all x86 kernels. > SMP_ALTERNATIVES disables the spinlocks etc at runtime. > - setuid /proc/self/maps fix (#165351) > > [..] > > typo? should'nt this be 2.6.*17*-rc1-git2? From mailinglists at erwinrol.com Tue Apr 11 12:18:20 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 11 Apr 2006 14:18:20 +0200 Subject: hesiod lib problem In-Reply-To: <44369004.7090907@mindspring.com> References: <44369004.7090907@mindspring.com> Message-ID: <1144757900.12092.79.camel@xpc.home.erwinrol.com> I don't know how, but the problem is back again today; Updating : libgnome ##################### [ 1/295] /sbin/ldconfig: /usr/lib64/libhesiod.so.0 is not a symbolic link - Erwin On Fri, 2006-04-07 at 12:15 -0400, Richard Hally wrote: > for several days, ldconfig has been throwing the following errors: > > > Updating : subversion ##################### [ 19/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libstdc++-devel ##################### [ 20/106] > Updating : libgnat ##################### [ 21/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libobjc ##################### [ 22/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : xorg-x11-server-Xorg ##################### [ 23/106] > Updating : metacity ##################### [ 24/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : libgomp ##################### [ 25/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > Updating : cpp ##################### [ 26/106] > Updating : gcc ##################### [ 27/106] > Updating : libgfortran ##################### [ 28/106] > /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link > > The pertinent part of /usr/lib looks like this: > > [root at LinuxNew2 lib]# ll libhe* > -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a > lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> libhesiod.so.0.0.0 > -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 > -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 > [root at LinuxNew2 lib]# > > How should this be fixed? > From katzj at redhat.com Tue Apr 11 12:37:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 11 Apr 2006 08:37:54 -0400 Subject: rawhide report: 20060411 changes In-Reply-To: <443B5BBC.2060107@feuerpokemon.de> References: <200604110726.k3B7QCFu030808@porkchop.devel.redhat.com> <443B5BBC.2060107@feuerpokemon.de> Message-ID: <1144759074.4150.6.camel@aglarond.local> On Tue, 2006-04-11 at 09:33 +0200, dragoran wrote: > Build System wrote: > > [..] > > > > kernel-2.6.16-1.2128_FC6 > > ------------------------ > > * Mon Apr 10 2006 Dave Jones > > - 2.6.16rc1-git2 & git3 > > - Enable SMP on all x86 kernels. > > SMP_ALTERNATIVES disables the spinlocks etc at runtime. > > - setuid /proc/self/maps fix (#165351) > > > > [..] > > > > > typo? should'nt this be 2.6.*17*-rc1-git2? Yep Jeremy From mclasen at redhat.com Tue Apr 11 12:50:56 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 11 Apr 2006 08:50:56 -0400 Subject: When do we get a more usable printer dialog for GNOME? In-Reply-To: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> References: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> Message-ID: <1144759857.10620.23.camel@golem.boston.redhat.com> On Tue, 2006-04-11 at 03:31 +0200, G?rard Milmeister wrote: > The current printer dialog of GNOME applications (is this > supplied by gnome-print?) is only usable for printer > that do not have any important settings (mostly PostScript > laser printers). Colour printers have many settings, most > importantly print quality and paper type. These are all > configurable via CUPS. But the GNOME print dialog only > shows some standard options. Of course the options can > be set globally using system-config-printer, which is > not acceptable for such a task, which is independent of > the system settings. > After all cups is standard in most Linux distrbutions > for quite a long time, a KDE *does* allow advanced > settings (even if the dialog is not very well done). > Are there plans by the Fedora Core development team to > change this? GTK+ 2.10 will have printing support. You can check out the current state of affairs in the gtk-printing branch in cvs. From clydekunkel7734 at cox.net Tue Apr 11 14:14:08 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Tue, 11 Apr 2006 10:14:08 -0400 Subject: hesiod lib problem In-Reply-To: <1144757900.12092.79.camel@xpc.home.erwinrol.com> References: <44369004.7090907@mindspring.com> <1144757900.12092.79.camel@xpc.home.erwinrol.com> Message-ID: <443BB9B0.5080908@cox.net> Erwin Rol wrote: > I don't know how, but the problem is back again today; > > Updating : libgnome ##################### [ > 1/295] > /sbin/ldconfig: /usr/lib64/libhesiod.so.0 is not a symbolic link > > > - Erwin > > > On Fri, 2006-04-07 at 12:15 -0400, Richard Hally wrote: >> for several days, ldconfig has been throwing the following errors: >> >> >> Updating : subversion ##################### [ 19/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libstdc++-devel ##################### [ 20/106] >> Updating : libgnat ##################### [ 21/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libobjc ##################### [ 22/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : xorg-x11-server-Xorg ##################### [ 23/106] >> Updating : metacity ##################### [ 24/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : libgomp ##################### [ 25/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> Updating : cpp ##################### [ 26/106] >> Updating : gcc ##################### [ 27/106] >> Updating : libgfortran ##################### [ 28/106] >> /sbin/ldconfig: /usr/lib/libhesiod.so.0 is not a symbolic link >> >> The pertinent part of /usr/lib looks like this: >> >> [root at LinuxNew2 lib]# ll libhe* >> -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a >> lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> libhesiod.so.0.0.0 >> -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 >> -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 >> [root at LinuxNew2 lib]# >> >> How should this be fixed? >> > I am seeing this also and don't see a bz on it. Should there be a bz? -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From fedora at camperquake.de Tue Apr 11 14:18:07 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 11 Apr 2006 16:18:07 +0200 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060408093042.GA7105@redhat.com> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> <20060408093042.GA7105@redhat.com> Message-ID: <20060411161807.3f8e8e1e@soran.addix.net> Hi. On Sat, 8 Apr 2006 09:30:42 +0000, Tim Waugh wrote: > Are you still seeing this problem with cups 1.2rc2 (1.2-0.3.rc2.1 for > FC-5 or 1.2-0.4.rc2.1 for devel)? FC-5 packages at > ftp://people.redhat.com/twaugh/tmp/cups-1.2/FC-5. No changes for me in the new version, I am afraid. From karsten at redhat.de Tue Apr 11 13:36:17 2006 From: karsten at redhat.de (Karsten Hopp) Date: Tue, 11 Apr 2006 15:36:17 +0200 Subject: hesiod lib problem In-Reply-To: <443BB9B0.5080908@cox.net> References: <44369004.7090907@mindspring.com> <1144757900.12092.79.camel@xpc.home.erwinrol.com> <443BB9B0.5080908@cox.net> Message-ID: <443BB0D1.2090402@redhat.de> >>> [root at LinuxNew2 lib]# ll libhe* >>> -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a >>> lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> >>> libhesiod.so.0.0.0 >>> -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 >>> -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 >>> [root at LinuxNew2 lib]# >>> >>> How should this be fixed? >>> >> > > I am seeing this also and don't see a bz on it. Should there be a bz? > Reinstalling hesiod-devel fixes this, but I'm not sure what is going on here. Karsten -- Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From mailinglists at erwinrol.com Tue Apr 11 14:44:45 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 11 Apr 2006 16:44:45 +0200 Subject: hesiod lib problem In-Reply-To: <443BB0D1.2090402@redhat.de> References: <44369004.7090907@mindspring.com> <1144757900.12092.79.camel@xpc.home.erwinrol.com> <443BB9B0.5080908@cox.net> <443BB0D1.2090402@redhat.de> Message-ID: <1144766685.12092.105.camel@xpc.home.erwinrol.com> On Tue, 2006-04-11 at 15:36 +0200, Karsten Hopp wrote: > >>> [root at LinuxNew2 lib]# ll libhe* > >>> -rw-r--r-- 1 root root 16846 Mar 30 17:40 libhesiod.a > >>> lrwxrwxrwx 1 root root 18 Mar 31 10:03 libhesiod.so -> > >>> libhesiod.so.0.0.0 > >>> -rw-r--r-- 1 root root 42747 Mar 30 17:40 libhesiod.so.0 > >>> -rw-r--r-- 1 root root 40863 Mar 30 17:40 libhesiod.so.0.0.0 > >>> [root at LinuxNew2 lib]# > >>> > >>> How should this be fixed? > > > > I am seeing this also and don't see a bz on it. Should there be a bz? > Reinstalling hesiod-devel fixes this, but I'm not sure what is going on here. It seems libhesiod.so.0 is an actual file in the rpm rpm -ql hesiod-3.1.0-3 /usr/lib/libhesiod.so.0 /usr/lib/libhesiod.so.0.0.0 /usr/share/doc/hesiod-3.1.0 /usr/share/doc/hesiod-3.1.0/NEWS /usr/share/doc/hesiod-3.1.0/README /usr/share/man/man5/hesiod.conf.5.gz /usr/lib64/libhesiod.so.0 /usr/lib64/libhesiod.so.0.0.0 /usr/share/doc/hesiod-3.1.0 /usr/share/doc/hesiod-3.1.0/NEWS /usr/share/doc/hesiod-3.1.0/README /usr/share/man/man5/hesiod.conf.5.gz From karsten at redhat.de Tue Apr 11 13:48:48 2006 From: karsten at redhat.de (Karsten Hopp) Date: Tue, 11 Apr 2006 15:48:48 +0200 Subject: hesiod lib problem In-Reply-To: <1144766685.12092.105.camel@xpc.home.erwinrol.com> References: <44369004.7090907@mindspring.com> <1144757900.12092.79.camel@xpc.home.erwinrol.com> <443BB9B0.5080908@cox.net> <443BB0D1.2090402@redhat.de> <1144766685.12092.105.camel@xpc.home.erwinrol.com> Message-ID: <443BB3C0.8090600@redhat.de> > It seems libhesiod.so.0 is an actual file in the rpm > > rpm -ql hesiod-3.1.0-3 > > /usr/lib/libhesiod.so.0 > > /usr/lib/libhesiod.so.0.0.0 > /usr/share/doc/hesiod-3.1.0 > /usr/share/doc/hesiod-3.1.0/NEWS > /usr/share/doc/hesiod-3.1.0/README > /usr/share/man/man5/hesiod.conf.5.gz > > /usr/lib64/libhesiod.so.0 > > /usr/lib64/libhesiod.so.0.0.0 > /usr/share/doc/hesiod-3.1.0 > /usr/share/doc/hesiod-3.1.0/NEWS > /usr/share/doc/hesiod-3.1.0/README > /usr/share/man/man5/hesiod.conf.5.gz > Wrong, you need to use rpm -qlv : >rpm -qlv hesiod-devel -r--r--r-- 1 root root 2835 M?r 31 00:40 /usr/include/hesiod.h -rw-r--r-- 1 root root 16846 M?r 31 00:40 /usr/lib/libhesiod.a lrwxrwxrwx 1 root root 18 M?r 31 00:40 /usr/lib/libhesiod.so -> libhesiod.so.0.0.0 ... Karsten -- Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From linux_4ever at yahoo.com Tue Apr 11 15:08:08 2006 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 11 Apr 2006 08:08:08 -0700 (PDT) Subject: hesiod lib problem In-Reply-To: <443BB9B0.5080908@cox.net> Message-ID: <20060411150808.84141.qmail@web51507.mail.yahoo.com> >I am seeing this also and don't see a bz on it. Should there be a bz? I think it is 188062. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From caillon at redhat.com Tue Apr 11 15:31:59 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 11 Apr 2006 11:31:59 -0400 Subject: Firefox Test Releases on Fedora In-Reply-To: References: Message-ID: <443BCBEF.6090703@redhat.com> On 04/05/2006 08:25 PM, Benjy Grogan wrote: > Dear Fedora Developers, > > I've noticed some funny problems with Firefox on Fedora. Nothing > catastrophic but not as user friendly as Firefox on Windows XP. I > list the problems below. But I think it would be a good idea to have > Firefox 2.0 test releases available in an experimental repository for > FC5 so that they could get testing before Firefox 2.0 is released in > September. This idea is similar to the AIGLX repository available for > AIGLX's testing, and also similar to the inclusion of Gnome > development branches in rawhide. I've been trying unsuccesfully to > get a CVS build of Firefox to work on FC5, but for whatever reason > after all is done it redirects to Firefox 1.5.0.1. > It has not been infrequent for Firefox releases to slip several months. If that should happen in this case, that would mean missing FC6. When I have a little more certainty this won't be the case, I will bump the rawhide version. From twaugh at redhat.com Tue Apr 11 16:01:41 2006 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 11 Apr 2006 16:01:41 +0000 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060411161807.3f8e8e1e@soran.addix.net> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> <20060408093042.GA7105@redhat.com> <20060411161807.3f8e8e1e@soran.addix.net> Message-ID: <20060411160141.GO7105@redhat.com> On Tue, Apr 11, 2006 at 04:18:07PM +0200, Ralf Ertzinger wrote: > Hi. > > On Sat, 8 Apr 2006 09:30:42 +0000, Tim Waugh wrote: > > > Are you still seeing this problem with cups 1.2rc2 (1.2-0.3.rc2.1 for > > FC-5 or 1.2-0.4.rc2.1 for devel)? FC-5 packages at > > ftp://people.redhat.com/twaugh/tmp/cups-1.2/FC-5. > > No changes for me in the new version, I am afraid. I think this is bug #188348: the 'fitplot' option now takes account of the page margins. Try removing the 'fitplot' option from the 'Queue options' screen of system-config-printer. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Tue Apr 11 16:23:25 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 11 Apr 2006 18:23:25 +0200 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060411160141.GO7105@redhat.com> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> <20060408093042.GA7105@redhat.com> <20060411161807.3f8e8e1e@soran.addix.net> <20060411160141.GO7105@redhat.com> Message-ID: <20060411182325.506932f2@soran.addix.net> Hi. On Tue, 11 Apr 2006 16:01:41 +0000, Tim Waugh wrote: > I think this is bug #188348: the 'fitplot' option now takes account of > the page margins. Try removing the 'fitplot' option from the 'Queue > options' screen of system-config-printer. That fixes the CUPS test page, the values displayed there look sane now. A4 test page still makes the printer spin up, but nothing is actually printed. I'll watch that bug. From twaugh at redhat.com Tue Apr 11 16:32:53 2006 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 11 Apr 2006 16:32:53 +0000 Subject: Rawhide woes: CUPS and xpdf In-Reply-To: <20060411182325.506932f2@soran.addix.net> References: <200604071403.k37E3IVE004717@laptop11.inf.utfsm.cl> <20060407163107.30cec776@soran.addix.net> <20060408093042.GA7105@redhat.com> <20060411161807.3f8e8e1e@soran.addix.net> <20060411160141.GO7105@redhat.com> <20060411182325.506932f2@soran.addix.net> Message-ID: <20060411163253.GP7105@redhat.com> On Tue, Apr 11, 2006 at 06:23:25PM +0200, Ralf Ertzinger wrote: > That fixes the CUPS test page, the values displayed there look sane > now. Good. > A4 test page still makes the printer spin up, but nothing is > actually printed. I'll watch that bug. That's certainly a separate bug -- would you mind filing a bugzilla report about that one? Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Tue Apr 11 17:26:13 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 11 Apr 2006 12:26:13 -0500 Subject: Installation Wizard in Yumex In-Reply-To: <20060410124111.1b9d28a9.seanlkml@sympatico.ca> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> <20060410124111.1b9d28a9.seanlkml@sympatico.ca> Message-ID: <1144776374.30844.18.camel@hamburger.booze> On Mon, 2006-04-10 at 12:41 -0400, sean wrote: > On Mon, 10 Apr 2006 15:14:22 +0200 > Tim Lauridsen wrote: > > > I just want to code a easy way to install things, not try to break any > > patent, i will not include anything illegal into yumex, but people > > located i place where software patents don't exist, can make a wizard > > plugin to install the stuff hosted in places like livna or freshrpms. > > I same way as yum and rpm can be used to installed patent releated > > stuff, but it is not the purpose of the application. > > It's already possible for a user to click-install a rpm that adds > many repo entries without the need for a wizard. After that > calling up yumex to install whatever packages are desired is easy. What you want is the package install metafile thingy I recommended in the long painful ESR thread. Just a text file with a list of packages to pull in. Give it an extension and a mime type, and associate it so you can click on one in a web browser and have it open in yumex/pirut. Then with two clicks you can install whatever. Something like this: [enablerepo] livna [install] xorg-x11-drv-nvidia kmod-nvidia Or maybe reduce it to a single click: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 releasepkg=http://rpm.livna.org/livna-release-5.rpm gpgkey=http://rpm.livna.org/RPM-LIVNA-GPG-KEY [enablerepo] livna [install] xorg-x11-drv-nvidia kmod-nvidia -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEO+YL2f3fe9ccxcsRAocgAJwLR+ZEsVoTxbCqUl32ea1jAMvloQCdEsa8 tzPFcrm33zSaYbXzzNtjhgg= =YgZH -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Apr 11 17:31:28 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 11 Apr 2006 12:31:28 -0500 Subject: Installation Wizard in Yumex In-Reply-To: <604aa7910604100640o188786a9qad51c3cc69a2d46@mail.gmail.com> References: <443A5119.6020105@rasmil.dk> <604aa7910604100640o188786a9qad51c3cc69a2d46@mail.gmail.com> Message-ID: <1144776690.30844.22.camel@hamburger.booze> On Mon, 2006-04-10 at 09:40 -0400, Jeff Spaleta wrote: > I think you are overthinking the problem and coming > up with pretty much the most complicated solution that you can think > of. You don't need an extra layer of code... for some weird ass xml > object that describes how to get an rpm....all you need is drag and > drop support of rpm urls directly. Direct linking to rpms bypasses everything yum does for you. It won't ensure its the latest version of the package, and it won't dep solve. And its not possible to install multiple packages with a single click. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Apr 11 17:48:03 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 11 Apr 2006 13:48:03 -0400 Subject: Installation Wizard in Yumex In-Reply-To: <1144776690.30844.22.camel@hamburger.booze> References: <443A5119.6020105@rasmil.dk> <604aa7910604100640o188786a9qad51c3cc69a2d46@mail.gmail.com> <1144776690.30844.22.camel@hamburger.booze> Message-ID: <604aa7910604111048n15dd3f3w4a6e952ca8e8cfc5@mail.gmail.com> On 4/11/06, Callum Lerwick wrote: > Direct linking to rpms bypasses everything yum does for you. It won't > ensure its the latest version of the package, and it won't dep solve. > And its not possible to install multiple packages with a single click. Installing multiple packages from multiple different repository locations with multiple different purposes which could in fact multiple overlap in and confuse the update mechanims.. with a single click... is bloody stupid and asking for problems specifically because you are delibrately hiding information as to the different places you are getting those different packages. If you want to make it drop dead simple to add additional repos..fine. But any single click mehod that delibrate goes out and configures several different repos to pull several different packages is asking for trouble when it comes to updates and upgrades. Once you have a single click url object that breaks repository boundaries to accomplish its actions.. all bets are off for reproducible behavior on the client side because 3rd party repos conflict and overlap. -jef From smooge at gmail.com Tue Apr 11 18:04:43 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 11 Apr 2006 12:04:43 -0600 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) Message-ID: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> This is more of a place-holder for people who might run into this problem with FC5 and not getting sound working with Intel ICH7 chipsets. I have a Dell 380 with a 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) sound card. It worked fine with Fedora Core 4 but after upgrading to Fedora Core 5 did not have sound anymore. The problem seems to be either with the kernel drivers or the alsa drivers. So far I have updated to the ones that the Fedora alsa maintainer keeps on his homepage but they did not fix the problem. It is an open bug with bugzilla in several cases... not sure of what the problem/fix will be. -- Stephen J Smoogen. CSIRT/Linux System Administrator From nicolas.mailhot at laposte.net Tue Apr 11 18:34:49 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 11 Apr 2006 20:34:49 +0200 Subject: When do we get a more usable printer dialog for GNOME? In-Reply-To: <1144759857.10620.23.camel@golem.boston.redhat.com> References: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> <1144759857.10620.23.camel@golem.boston.redhat.com> Message-ID: <1144780492.4051.3.camel@rousalka.dyndns.org> Le mardi 11 avril 2006 ? 08:50 -0400, Matthias Clasen a ?crit : > On Tue, 2006-04-11 at 03:31 +0200, G?rard Milmeister wrote: > > The current printer dialog of GNOME applications (is this > > supplied by gnome-print?) is only usable for printer > > that do not have any important settings (mostly PostScript > > laser printers). > > GTK+ 2.10 will have printing support. You can check out the > current state of affairs in the gtk-printing branch in cvs. I hope someone will take care of the A4 vs Letter problem before adding all sorts of advanced settings (printing an A4 page in evo through a PCL filter actually prints A4 ; printing an A4 page in postscript mode has always been printing letter for as long as I can remember) -- 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 fedora at adslpipe.co.uk Tue Apr 11 19:21:21 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Tue, 11 Apr 2006 20:21:21 +0100 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> Message-ID: <443C01B1.5070903@adslpipe.co.uk> Stephen J. Smoogen wrote: > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) > sound card. It worked fine with Fedora Core 4 but after upgrading to > Fedora Core 5 did not have sound anymore. My Intel D945GTPLR m/b has this same sound device, I had a brief problem with it in a few of the daily rawhide kernels a few months back, but it's never given me a problem in FC5 release ... From twaugh at redhat.com Tue Apr 11 21:04:25 2006 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 11 Apr 2006 21:04:25 +0000 Subject: When do we get a more usable printer dialog for GNOME? In-Reply-To: <1144780492.4051.3.camel@rousalka.dyndns.org> References: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> <1144759857.10620.23.camel@golem.boston.redhat.com> <1144780492.4051.3.camel@rousalka.dyndns.org> Message-ID: <20060411210425.GQ7105@redhat.com> On Tue, Apr 11, 2006 at 08:34:49PM +0200, Nicolas Mailhot wrote: > I hope someone will take care of the A4 vs Letter problem before adding > all sorts of advanced settings (printing an A4 page in evo through a PCL > filter actually prints A4 ; printing an A4 page in postscript mode has > always been printing letter for as long as I can remember) Got a bugzilla ID for that? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Tue Apr 11 23:08:14 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 11 Apr 2006 18:08:14 -0500 Subject: Installation Wizard in Yumex In-Reply-To: <604aa7910604111048n15dd3f3w4a6e952ca8e8cfc5@mail.gmail.com> References: <443A5119.6020105@rasmil.dk> <604aa7910604100640o188786a9qad51c3cc69a2d46@mail.gmail.com> <1144776690.30844.22.camel@hamburger.booze> <604aa7910604111048n15dd3f3w4a6e952ca8e8cfc5@mail.gmail.com> Message-ID: <1144796894.30844.40.camel@hamburger.booze> On Tue, 2006-04-11 at 13:48 -0400, Jeff Spaleta wrote: > Installing multiple packages from multiple different repository > locations with multiple different purposes which could in fact > multiple overlap in and confuse the update mechanims.. with a single > click... is bloody stupid and asking for problems specifically because > you are delibrately hiding information as to the different places you > are getting those different packages. This is no different than what already happens. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Apr 12 01:07:06 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 11 Apr 2006 19:07:06 -0600 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <443C01B1.5070903@adslpipe.co.uk> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> <443C01B1.5070903@adslpipe.co.uk> Message-ID: <80d7e4090604111807p52625fei208fd0b365288b65@mail.gmail.com> On 4/11/06, Andy Burns wrote: > Stephen J. Smoogen wrote: > > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > > Definition Audio Controller (rev 01) > > sound card. It worked fine with Fedora Core 4 but after upgrading to > > Fedora Core 5 did not have sound anymore. > > My Intel D945GTPLR m/b has this same sound device, I had a brief problem > with it in a few of the daily rawhide kernels a few months back, but > it's never given me a problem in FC5 release ... > > Are there any special settings that need to be set? I have checked that the audio isnt muted.. and tested it in windows just to make sure I hadnt burned it out. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From cjb at mrao.cam.ac.uk Wed Apr 12 02:21:53 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Tue, 11 Apr 2006 22:21:53 -0400 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> <443C01B1.5070903@adslpipe.co.uk> <80d7e4090604111807p52625fei208fd0b365288b65@mail.gmail.com> Message-ID: <87slojh6ta.fsf@mrao.cam.ac.uk> >> On Tue, 11 Apr 2006, Stephen J. Smoogen said: > Are there any special settings that need to be set? I have checked > that the audio isnt muted.. and tested it in windows just to make > sure I hadnt burned it out. You might try the headphone mixer, rather than master, to see if that's controlling the volume; it's a common misconfiguration on snd-hda-intel cards. (You can submit a quirk table patch to alsa-kernel if it is.) -- Chris Ball From thingsmith at comcast.net Wed Apr 12 02:29:03 2006 From: thingsmith at comcast.net (Harry Smith) Date: Tue, 11 Apr 2006 19:29:03 -0700 Subject: Bug or "Feature" Can not package manager gui with non-connected box Message-ID: <6.2.5.6.2.20060411192441.03336e88@comcast.net> I am setting up a system in an area where I can not connect to the Internet. I chose a minimal install from the GUI, i.e. don't make it any of the pre-defined options. I was planning to return after the install and add the packages I needed. The install finished, when I tried to add packages it failed immediately. I can add the rpms manually. So is this a bug or feature in FC 5. Harry Smith From jkeating at j2solutions.net Wed Apr 12 02:32:23 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 11 Apr 2006 22:32:23 -0400 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <6.2.5.6.2.20060411192441.03336e88@comcast.net> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> Message-ID: <1144809144.18861.157.camel@ender> On Tue, 2006-04-11 at 19:29 -0700, Harry Smith wrote: > when I tried to add packages it failed > immediately. I can add the rpms manually. I don't understand what you're saying here. Can you describe it a bit more? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Apr 12 03:00:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 08:30:11 +0530 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <6.2.5.6.2.20060411192441.03336e88@comcast.net> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> Message-ID: <1144810811.2294.246.camel@sundaram.pnq.redhat.com> On Tue, 2006-04-11 at 19:29 -0700, Harry Smith wrote: > I am setting up a system in an area where I can not connect to the > Internet. I chose a minimal install from the GUI, i.e. don't make it > any of the pre-defined options. I was planning to return after the > install and add the packages I needed. > > The install finished, when I tried to add packages it failed > immediately. I can add the rpms manually. > > So is this a bug or feature in FC 5. > > Harry Smith http://fedoraproject.org/wiki/Bugs/FC5Common Rahul From thingsmith at comcast.net Wed Apr 12 03:34:25 2006 From: thingsmith at comcast.net (Harry Smith) Date: Tue, 11 Apr 2006 20:34:25 -0700 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <1144810811.2294.246.camel@sundaram.pnq.redhat.com> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> <1144810811.2294.246.camel@sundaram.pnq.redhat.com> Message-ID: <6.2.5.6.2.20060411202911.03328820@comcast.net> At 08:00 PM 4/11/2006, you wrote: >On Tue, 2006-04-11 at 19:29 -0700, Harry Smith wrote: > > I am setting up a system in an area where I can not connect to the > > Internet. I chose a minimal install from the GUI, i.e. don't make it > > any of the pre-defined options. I was planning to return after the > > install and add the packages I needed. > > > > The install finished, when I tried to add packages it failed > > immediately. I can add the rpms manually. > > > > So is this a bug or feature in FC 5. > > > > Harry Smith > >http://fedoraproject.org/wiki/Bugs/FC5Common > >Rahul Rahul: I looked that the Bugs before I sent the message. I didn't see any bugs that I thought related. Can you tell me the bug number. Jesse: I build a FC 5 system that had ethernet cards but was not connected to the internet. (no could it be connected) During the installation, I said I would customize later. However, when I hit the add packages the add packages GUI messages failed immediately. BTW: I have also had problems with the nightly updates causing the machine to freeze. Harry >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list From sundaram at fedoraproject.org Wed Apr 12 03:42:30 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 09:12:30 +0530 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <6.2.5.6.2.20060411202911.03328820@comcast.net> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> <1144810811.2294.246.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411202911.03328820@comcast.net> Message-ID: <1144813350.2294.249.camel@sundaram.pnq.redhat.com> On Tue, 2006-04-11 at 20:34 -0700, Harry Smith wrote: > At 08:00 PM 4/11/2006, you wrote: > >On Tue, 2006-04-11 at 19:29 -0700, Harry Smith wrote: > > > I am setting up a system in an area where I can not connect to the > > > Internet. I chose a minimal install from the GUI, i.e. don't make it > > > any of the pre-defined options. I was planning to return after the > > > install and add the packages I needed. > > > > > > The install finished, when I tried to add packages it failed > > > immediately. I can add the rpms manually. > > > > > > So is this a bug or feature in FC 5. > > > > > > Harry Smith > > > >http://fedoraproject.org/wiki/Bugs/FC5Common > > > >Rahul > > Rahul: I looked that the Bugs before I sent the message. I didn't > see any bugs that I thought related. Can you tell me the bug number. Quoting from the above link. "hjttp://katzj.livejournal.com/380795.html - Pirut does not support installing packages from media out of the box. This is a planned feature. Look at http://www.city-fan.org/tips/YumRepoFromImages for a way to do this currently." Rahul From thingsmith at comcast.net Wed Apr 12 05:12:29 2006 From: thingsmith at comcast.net (Harry Smith) Date: Tue, 11 Apr 2006 22:12:29 -0700 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <1144813350.2294.249.camel@sundaram.pnq.redhat.com> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> <1144810811.2294.246.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411202911.03328820@comcast.net> <1144813350.2294.249.camel@sundaram.pnq.redhat.com> Message-ID: <6.2.5.6.2.20060411220245.032b2080@comcast.net> At 08:42 PM 4/11/2006, you wrote: >On Tue, 2006-04-11 at 20:34 -0700, Harry Smith wrote: > > At 08:00 PM 4/11/2006, you wrote: > > >On Tue, 2006-04-11 at 19:29 -0700, Harry Smith wrote: > > > > I am setting up a system in an area where I can not connect to the > > > > Internet. I chose a minimal install from the GUI, i.e. don't make it > > > > any of the pre-defined options. I was planning to return after the > > > > install and add the packages I needed. > > > > > > > > The install finished, when I tried to add packages it failed > > > > immediately. I can add the rpms manually. > > > > > > > > So is this a bug or feature in FC 5. > > > > > > > > Harry Smith > > > > > >http://fedoraproject.org/wiki/Bugs/FC5Common > > > > > >Rahul > > > > Rahul: I looked that the Bugs before I sent the message. I didn't > > see any bugs that I thought related. Can you tell me the bug number. > >Quoting from the above link. > >"hjttp://katzj.livejournal.com/380795.html - Pirut does not support >installing packages from media out of the box. This is a planned >feature. Look at http://www.city-fan.org/tips/YumRepoFromImages for a >way to do this currently." > >Rahul After reading the link, I now understand that Pirut (not sure how I would have know this ) is the name of the GUI front end for yum. While it have been planned, it does and will cause a lot of problems for people on isolated networks. I think this should be highlighted in the Wiki. >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-devel-list From sundaram at fedoraproject.org Wed Apr 12 06:25:49 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 11:55:49 +0530 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <6.2.5.6.2.20060411220245.032b2080@comcast.net> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> <1144810811.2294.246.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411202911.03328820@comcast.net> <1144813350.2294.249.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411220245.032b2080@comcast.net> Message-ID: <1144823149.2294.254.camel@sundaram.pnq.redhat.com> > > After reading the link, I now understand that Pirut (not sure how I > would have know this ) is the name of the GUI front end for yum. Yes. Mentioned in the release notes which I recommend every user to read. > > While it have been planned, it does and will cause a lot of problems > for people on isolated networks. I think this should be highlighted > in the Wiki. It is already in the wiki and referred to in many places including the frontpage of http://fedoraproject.org Rahul From buildsys at redhat.com Wed Apr 12 07:23:24 2006 From: buildsys at redhat.com (Build System) Date: Wed, 12 Apr 2006 03:23:24 -0400 Subject: rawhide report: 20060412 changes Message-ID: <200604120723.k3C7NN7t003014@porkchop.devel.redhat.com> Updated Packages: autofs-1:4.1.4-18 ----------------- * Tue Apr 11 2006 Ian Kent - 1:4.1.4-18 - Add patch to allow customization of arguments to the autofs-ldap-auto-master program (bz #187525). - Add patch to escap "#" characters in exports from auto.net program mount (bz#178304). gdk-pixbuf-1:0.22.0-23 ---------------------- * Tue Apr 11 2006 Matthias Clasen 0.22.0-23 - Build without gnome support, since Gnome 1 is on the way out gdm-1:2.14.1-3 -------------- * Tue Apr 11 2006 Ray Strode - 1:2.14.1-3 - Add gdmthemetester.in to the mix (upstream bug 338079) * Tue Apr 11 2006 Matthias Clasen - 1:2.14.1-2 - Update to 2.14.1 gnome-desktop-2.14.1.1-2 ------------------------ * Tue Apr 11 2006 Matthias Clasen - 2.14.1.1-2 - Update to 2.14.1.1 gnome-doc-utils-0.6.0-2 ----------------------- * Tue Apr 11 2006 Matthias Clasen - 0.6.0-2 - Add a missing Requires gnupg-1.4.3-3 ------------- * Tue Apr 11 2006 Nalin Dahyabhai - 1.4.3-3 - rebuild * Tue Apr 11 2006 Nalin Dahyabhai - 1.4.3-2 - apply patch from David Shaw to try multiple defaults if the the photo-viewer option isn't set (fixes #187880) * Fri Mar 10 2006 Nalin Dahyabhai - 1.4.3-1 - update to 1.4.3 libselinux-1.30.1-2 ------------------- * Mon Mar 27 2006 Dan Walsh 1.30.1-2 - Fix python bindings for matchpathcon - Fix booleans man page * Mon Mar 27 2006 Dan Walsh 1.30.1-1 * Merged Makefile PYLIBVER definition patch from Dan Walsh. mesa-6.5-4 ---------- * Tue Apr 11 2006 Adam Jackson 6.5-4 - Disable R300_FORCE_R300 hack for wider testing. ncpfs-2.2.6-3 ------------- * Tue Apr 11 2006 Martin Stransky - 2.2.6-3 - fix for #186683 - ncpmount needs downgrade to work properly, rpb_b[] needs to be aligned to 4 bytes with -fstack-protector enabled * Fri Feb 10 2006 Jesse Keating - 2.2.6-1.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.2.6-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes postfix-2:2.2.10-1 ------------------ * Tue Apr 11 2006 Thomas Woerner 2:2.2.10-1 - new version 2.2.10 - added option LDAP_DEPRECATED to support deprecated ldap functions for now - fixed build without pflogsumm support (#188470) selinux-policy-2.2.30-2 ----------------------- * Tue Apr 11 2006 Dan Walsh 2.2.30-2 - Change libraries.fc to stop shlib_t form overriding texrel_shlib_t * Tue Apr 11 2006 Dan Walsh 2.2.30-1 - Fix samba creating dirs in homedir - Fix NFS so its booleans would work synaptics-0:0.14.4-6 -------------------- * Tue Apr 11 2006 Kristian H??gsberg 0:0.14.4-6 - Build as a shared object. tog-pegasus-2:2.5.1-1.FC6 ------------------------- * Thu Apr 06 2006 Jason Vas Dias - 2:2.5.1-1 - Upgrade to version 2.5.1 (including new upstream .spec file). vim-1:7.0.d001-1 ---------------- * Tue Apr 11 2006 Karsten Hopp 7.0.d001-1 - vim-7.0d BETA Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From fedora at adslpipe.co.uk Wed Apr 12 08:04:16 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Wed, 12 Apr 2006 09:04:16 +0100 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <80d7e4090604111807p52625fei208fd0b365288b65@mail.gmail.com> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com><443C01B1.5070903@adslpipe.co.uk> <80d7e4090604111807p52625fei208fd0b365288b65@mail.gmail.com> Message-ID: <443CB480.7000405@adslpipe.co.uk> Stephen J. Smoogen wrote: > Are there any special settings that need to be set? I have checked > that the audio isnt muted.. once or twice (during rawhide before FC5) it seemed to pick the wrong device to control in the gnome mixer app, I went into "Open Volume Control" and "Preferences" and enabled every input/output/option in sight, this didn't happen with my FC5 release install. I'm currently just using a bog standard stero set of speakers, under Preferences the device I have set to track/control is "HDA Intel (ALSA mixer)" on the "Front" outputs, rather than "PCM" From tla-ml at rasmil.dk Wed Apr 12 10:09:54 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Wed, 12 Apr 2006 12:09:54 +0200 Subject: Installation Wizard in Yumex In-Reply-To: <1144776374.30844.18.camel@hamburger.booze> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> <20060410124111.1b9d28a9.seanlkml@sympatico.ca> <1144776374.30844.18.camel@hamburger.booze> Message-ID: <443CD1F2.2070701@rasmil.dk> Callum Lerwick wrote: > On Mon, 2006-04-10 at 12:41 -0400, sean wrote: > >> On Mon, 10 Apr 2006 15:14:22 +0200 >> Tim Lauridsen wrote: >> >> >>> I just want to code a easy way to install things, not try to break any >>> patent, i will not include anything illegal into yumex, but people >>> located i place where software patents don't exist, can make a wizard >>> plugin to install the stuff hosted in places like livna or freshrpms. >>> I same way as yum and rpm can be used to installed patent releated >>> stuff, but it is not the purpose of the application. >>> >> It's already possible for a user to click-install a rpm that adds >> many repo entries without the need for a wizard. After that >> calling up yumex to install whatever packages are desired is easy. >> > > What you want is the package install metafile thingy I recommended in > the long painful ESR thread. Just a text file with a list of packages to > pull in. Give it an extension and a mime type, and associate it so you > can click on one in a web browser and have it open in yumex/pirut. Then > with two clicks you can install whatever. Something like this: > > [enablerepo] > livna > > [install] > xorg-x11-drv-nvidia > kmod-nvidia > > Or maybe reduce it to a single click: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > releasepkg=http://rpm.livna.org/livna-release-5.rpm > gpgkey=http://rpm.livna.org/RPM-LIVNA-GPG-KEY > > [enablerepo] > livna > > [install] > xorg-x11-drv-nvidia > kmod-nvidia > It was something like that i was thinking of. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Wed Apr 12 11:00:27 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 07:00:27 -0400 Subject: how to check file is open In-Reply-To: References: Message-ID: <20060412110027.GB21404@devserv.devel.redhat.com> On Fri, Apr 07, 2006 at 03:07:48PM +0530, imcc wrote: > While taking the backup I want to exclude those files > Which are open. On Linux and Unix some files may always be open. A backup tool excluding such files would not be terribly useful. From sundaram at fedoraproject.org Wed Apr 12 11:24:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 16:54:46 +0530 Subject: Bug or "Feature" Can not package manager gui with non-connected box In-Reply-To: <6.2.5.6.2.20060412040344.032d4d78@comcast.net> References: <6.2.5.6.2.20060411192441.03336e88@comcast.net> <1144810811.2294.246.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411202911.03328820@comcast.net> <1144813350.2294.249.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060411220245.032b2080@comcast.net> <1144823149.2294.254.camel@sundaram.pnq.redhat.com> <6.2.5.6.2.20060412040344.032d4d78@comcast.net> Message-ID: <1144841086.2294.265.camel@sundaram.pnq.redhat.com> [did you mean to send this offlist?] On Wed, 2006-04-12 at 04:16 -0700, Harry Smith wrote: > I think this is getting to be a matter of opinion. > > I did a search on the release notes and did find that Pirut was a > replacement. However, nothing in the release notes said that Pirut > REQUIRED Internet connections to work correctly directly. The best > is that it mentions yum is used. Since you have already point out > that yum can be set to use local resources as well, This did not > trigger any bells indicated that required connections. > > This is a major change operating concepts and IMHO a mistake. > > While it would be interesting to understand the logic behind this > decision, nothing can be done about it. There are a lot of private > spaces where FC5 is being used. Anything package management tools like Pup, Pirut or YumEx requires a net connection by default. It was mentioned in the release notes that both Pup and Pirut uses yum as a backend. You can configure yum to point to local repositories and any tool based on yum should be able to use that information. The previous system-config-packages which Pirut replaces had no understanding of repositories and would only work on media and systems which werent updated through yum. Work is already being done to get Pirut to work with media disks which requires changes in yum itself. Subsequent releases of Fedora will likely have this feature too. I have already shown you to pointers to setup such local repositories where a net connection is unavailable. Rahul From alan at redhat.com Wed Apr 12 11:42:14 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 07:42:14 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060404131520.19567.qmail@hm196.locaweb.com.br> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> Message-ID: <20060412114214.GA28564@devserv.devel.redhat.com> On Tue, Apr 04, 2006 at 10:15:20AM -0300, Pedro Fernandes Macedo wrote: > However, moving evolution to extras may not be a good idea IMHO, since evolution is the only tool (that I know of) that supports Exchange servers. That is certainly an important feature for many people in corporate environments (or people who use FC at home and need evolution to use the work e-mail). Evolution in extras is a bad idea. Evolution in core is a worse idea. What other as good as unmaintained large buggy package exposed to external attack and with known unfixed DoS bugs (and probably worse yet to be found) do we ship. Evolution belongs in the bitbucket. From mailinglists at erwinrol.com Wed Apr 12 11:52:16 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 12 Apr 2006 13:52:16 +0200 Subject: Move Evolution to Extras? In-Reply-To: <20060412114214.GA28564@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> Message-ID: <1144842736.12092.173.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > On Tue, Apr 04, 2006 at 10:15:20AM -0300, Pedro Fernandes Macedo wrote: > > However, moving evolution to extras may not be a good idea IMHO, > since evolution is the only tool (that I know of) that supports > Exchange servers. That is certainly an important feature for many > people in corporate environments (or people who use FC at home and > need evolution to use the work e-mail). > > Evolution in extras is a bad idea. Evolution in core is a worse idea. What > other as good as unmaintained large buggy package exposed to external attack > and with known unfixed DoS bugs (and probably worse yet to be found) do > we ship. > > Evolution belongs in the bitbucket. And what are you suggesting as a replacement ? If Evolution ends up in the bitbucket, something else with the same functionality should replace it. So what other Gnome email+calendar+addressbook+task management application should i use instead of evolution ? And why is evolution unmaintained? I mean it seems to be important enough that expensive commercial Linux distributions like RHEL use it as a default email client. - Erwin From jorton at redhat.com Wed Apr 12 11:57:26 2006 From: jorton at redhat.com (Joe Orton) Date: Wed, 12 Apr 2006 12:57:26 +0100 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> Message-ID: <20060412115726.GA19971@redhat.com> On Tue, Apr 11, 2006 at 12:04:43PM -0600, Stephen J. Smoogen wrote: > This is more of a place-holder for people who might run into this > problem with FC5 and not getting sound working with Intel ICH7 > chipsets. I have a Dell 380 with a > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) I have the same machine and problem here, not sure why this is on-topic for fedora-devel though, it's just one of many kernel bugs AFAICT... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182940 joe From jkeating at redhat.com Wed Apr 12 12:01:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Apr 2006 08:01:54 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144842736.12092.173.camel@xpc.home.erwinrol.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> Message-ID: <1144843314.18861.162.camel@ender> On Wed, 2006-04-12 at 13:52 +0200, Erwin Rol wrote: > > And why is evolution unmaintained? I mean it seems to be important > enough that expensive commercial Linux distributions like RHEL use it > as > a default email client. We have an open job req for an evolution maintainer. The current maintainer is otherwise engaged in other projects within our company. So far, nobody has come through to take up the task of Evolution maintainership. Please somebody step up (; -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mailinglists at erwinrol.com Wed Apr 12 12:19:32 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 12 Apr 2006 14:19:32 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144843314.18861.162.camel@ender> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <1144843314.18861.162.camel@ender> Message-ID: <1144844372.12092.177.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 08:01 -0400, Jesse Keating wrote: > On Wed, 2006-04-12 at 13:52 +0200, Erwin Rol wrote: > > > > And why is evolution unmaintained? I mean it seems to be important > > enough that expensive commercial Linux distributions like RHEL use it > > as > > a default email client. > > We have an open job req for an evolution maintainer. The current > maintainer is otherwise engaged in other projects within our company. > So far, nobody has come through to take up the task of Evolution > maintainership. Please somebody step up (; Well Evolution maintainership takes a lot of Intelligent Design, not just everybody is up to that :-) - Erwin From jwboyer at jdub.homelinux.org Wed Apr 12 12:20:09 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 12 Apr 2006 07:20:09 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144843314.18861.162.camel@ender> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <1144843314.18861.162.camel@ender> Message-ID: <20060412122009.GA10844@yoda.jdub.homelinux.org> On Wed, Apr 12, 2006 at 08:01:54AM -0400, Jesse Keating wrote: > On Wed, 2006-04-12 at 13:52 +0200, Erwin Rol wrote: > > > > And why is evolution unmaintained? I mean it seems to be important > > enough that expensive commercial Linux distributions like RHEL use it > > as > > a default email client. > > We have an open job req for an evolution maintainer. The current > maintainer is otherwise engaged in other projects within our company. > So far, nobody has come through to take up the task of Evolution > maintainership. Please somebody step up (; Move it to Extras and you can pander for a maintainer you don't even have to pay. ;) josh From Lam at Lam.pl Wed Apr 12 13:08:13 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 12 Apr 2006 15:08:13 +0200 Subject: Move Evolution to Extras? In-Reply-To: <20060412122009.GA10844@yoda.jdub.homelinux.org> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <1144843314.18861.162.camel@ender> <20060412122009.GA10844@yoda.jdub.homelinux.org> Message-ID: <1144847293.2888.1.camel@pensja.lam.pl> Dnia 12-04-2006, ?ro o godzinie 07:20 -0500, Josh Boyer napisa?(a): > Move it to Extras and you can pander for a maintainer you don't even have to > pay. It's the program that needs a maintainer, not the package (which is actively maintained). Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From dimi at lattica.com Wed Apr 12 13:11:26 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 09:11:26 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060412114214.GA28564@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> Message-ID: <1144847486.6382.144.camel@dimi> On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > Evolution belongs in the bitbucket. Alan, This is pretty scary. Switching people off email clients like this is a big problem. People get really attached to their MUAs for lots of reasons, not in the least being that their mail archives can't be easily moved from client to client. Guys, Red Hat has been pushing Evo for a _long_ time now. It has to stay behind their choices, not force millions of users to switch at a drop of a hat (pun intended :)). This is a lot more serious than switching web browsers or other apps. Too many people will get affected, and rightfully pissed at RH. Silly excuses that you couldn't hire people to work on it will not fly. I'm really surprised that folks at RH throw around such scenarios without thinking a bit about consequences. How can enterprises trust you with any technological guidance/decision when you are willing to do things that would cost them untold millions without even blinking? -- Dimi Paun Lattica, Inc. From jkeating at redhat.com Wed Apr 12 13:13:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Apr 2006 09:13:12 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144847293.2888.1.camel@pensja.lam.pl> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <1144843314.18861.162.camel@ender> <20060412122009.GA10844@yoda.jdub.homelinux.org> <1144847293.2888.1.camel@pensja.lam.pl> Message-ID: <1144847593.18861.166.camel@ender> On Wed, 2006-04-12 at 15:08 +0200, Leszek Matok wrote: > It's the program that needs a maintainer, not the package (which is > actively maintained). No, the package is not actively maintained. Much more work could be done on it, including working with upstream. There is an upstream and they are accepting bugs, and supposedly working on them. Red Hat would love to pay someone to maintain our package and participate upstream in the program. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Apr 12 13:28:45 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 18:58:45 +0530 Subject: Move Evolution to Extras? In-Reply-To: <1144847486.6382.144.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> Message-ID: <1144848525.2294.274.camel@sundaram.pnq.redhat.com> On Wed, 2006-04-12 at 09:11 -0400, Dimi Paun wrote: > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > Evolution belongs in the bitbucket. > > Alan, > > This is pretty scary. Switching people off email clients like > this is a big problem. People get really attached to their MUAs > for lots of reasons, not in the least being that their mail > archives can't be easily moved from client to client. > > Guys, Red Hat has been pushing Evo for a _long_ time now. It has > to stay behind their choices, not force millions of users to switch > at a drop of a hat (pun intended :)). > > This is a lot more serious than switching web browsers or other > apps. Too many people will get affected, and rightfully pissed > at RH. Silly excuses that you couldn't hire people to work on it > will not fly. > > I'm really surprised that folks at RH throw around such scenarios > without thinking a bit about consequences. How can enterprises trust > you with any technological guidance/decision when you are willing to > do things that would cost them untold millions without even blinking? You are over over-dramatizing. This is not a place for enterprises to get technology guidance and nobody's personal opinions here is going to cost anyone untold millions. Rahul From smooge at gmail.com Wed Apr 12 13:29:33 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 07:29:33 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144847486.6382.144.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> Message-ID: <80d7e4090604120629i1b381efcy2b9c1e0418079fdd@mail.gmail.com> On 4/12/06, Dimi Paun wrote: > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > Evolution belongs in the bitbucket. > > Alan, > > This is pretty scary. Switching people off email clients like > this is a big problem. People get really attached to their MUAs ..... > I'm really surprised that folks at RH throw around such scenarios > without thinking a bit about consequences. How can enterprises trust > you with any technological guidance/decision when you are willing to > do things that would cost them untold millions without even blinking? > I think that would be a stiffling of free speech on this list. "Oh I work for Red Hat, I cant give my opinion about what a program does and where it should be." Alan said his opinion and several other people have too. Whether evolution is killed or not is the Fedora Execs decision. -- Stephen J Smoogen. CSIRT/Linux System Administrator From dimi at lattica.com Wed Apr 12 13:47:56 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 09:47:56 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144848525.2294.274.camel@sundaram.pnq.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> Message-ID: <1144849676.6382.155.camel@dimi> On Wed, 2006-04-12 at 18:58 +0530, Rahul Sundaram wrote: > You are over over-dramatizing. This is not a place for enterprises to > get technology guidance and nobody's personal opinions here is going > to cost anyone untold millions. Give me a break. Alan is just not anybody, and neither is dwmw2, and others in Red Hat. Also, we've just been told how Fedora is essential to Red Hat's business strategy, and why we can't have a Foundation. Which is fine by me, but this means you can not have this 100% separation between Fedora and Red Hat, which is conveniently waved whenever there are uncomfortable questions. And please don't tell me there's no connection with RHEL. We wouldn't have this conversation now if Evo would be maintained. If you can maintain it for RHEL, I can't see why it will not be maintained for Fedora. And if so, this discussion would be moot. But since lots of RH people call for its immediate demise, it can only mean that it's going to be dumped in RHEL as well. Dumping Evo now, after being pushed for years by RH, can not be a Good Thing (TM). -- Dimi Paun Lattica, Inc. From alan at redhat.com Wed Apr 12 14:05:04 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 10:05:04 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144847486.6382.144.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> Message-ID: <20060412140504.GE15794@devserv.devel.redhat.com> On Wed, Apr 12, 2006 at 09:11:26AM -0400, Dimi Paun wrote: > This is pretty scary. Switching people off email clients like > this is a big problem. People get really attached to their MUAs > for lots of reasons, not in the least being that their mail > archives can't be easily moved from client to client. It won't be the first time we dumped an email client (we've dropped nmh, exmh, elm, ...) before. > Guys, Red Hat has been pushing Evo for a _long_ time now. It has > to stay behind their choices, not force millions of users to switch > at a drop of a hat (pun intended :)). The question is whether Evolution is fixable in a sane timescale and whether it is fit to ship in FC5. I would put a 50/50 bet on a serious security flaw in evolution during FC5. Now how are we going to fix it ? > without thinking a bit about consequences. How can enterprises trust > you with any technological guidance/decision when you are willing to > do things that would cost them untold millions without even blinking? This is Fedora. Its a development project to produce leading edge stuff. It isn't a business product. Even if a future Red Hat Enterprise product dropped Evolutuion, or evolution imploded fatally upstream as appears quite possible there is already a commitment to support it on the existing enterprise product and if it was considered for dropping in a future product that would be the kind of thing that had a long long notice period and be subject to user views. Fedora we can do things that are technically right, or throw the ideas around for discussion and a chance to ask "what are the alternatives". RHEL has many other constraints. Alan From sundaram at fedoraproject.org Wed Apr 12 14:13:35 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 19:43:35 +0530 Subject: Move Evolution to Extras? In-Reply-To: <1144849676.6382.155.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> Message-ID: <1144851216.2294.291.camel@sundaram.pnq.redhat.com> On Wed, 2006-04-12 at 09:47 -0400, Dimi Paun wrote: > On Wed, 2006-04-12 at 18:58 +0530, Rahul Sundaram wrote: > > You are over over-dramatizing. This is not a place for enterprises to > > get technology guidance and nobody's personal opinions here is going > > to cost anyone untold millions. > > Give me a break. Alan is just not anybody, and neither is dwmw2, > and others in Red Hat. Also, we've just been told how Fedora is > essential to Red Hat's business strategy, and why we can't have > a Foundation. Which is fine by me, but this means you can not > have this 100% separation between Fedora and Red Hat, which is > conveniently waved whenever there are uncomfortable questions. Clarification: Administrative costs are far more of a important factor than business strategies in the decision to fold the foundation. Feel free to ask questions regardless of its comfort values. > > And please don't tell me there's no connection with RHEL. We > wouldn't have this conversation now if Evo would be maintained. > If you can maintain it for RHEL, I can't see why it will not > be maintained for Fedora. And if so, this discussion would be moot. > But since lots of RH people call for its immediate demise, it > can only mean that it's going to be dumped in RHEL as well. > > Dumping Evo now, after being pushed for years by RH, can not > be a Good Thing (TM). Artificially tying up this discussion to RHEL would be stifling up a open discussion on potential alternatives. RHEL customers have better channels to discuss their concerns. Rahul From paul at cypherpunks.ca Wed Apr 12 14:14:08 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 12 Apr 2006 16:14:08 +0200 (CEST) Subject: Move Evolution to Extras? In-Reply-To: <20060412140504.GE15794@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> Message-ID: On Wed, 12 Apr 2006, Alan Cox wrote: > It won't be the first time we dumped an email client (we've dropped nmh, > exmh, elm, ...) before. Don't forget pine! How could you guys! [ insert a million disputable reasons why i couldnt switch to mutt here ] Paul From jspaleta at gmail.com Wed Apr 12 14:18:41 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Apr 2006 10:18:41 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144849676.6382.155.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> Message-ID: <604aa7910604120718p710ab63l3b4854b58da100dd@mail.gmail.com> On 4/12/06, Dimi Paun wrote: > Give me a break. Alan is just not anybody, and neither is dwmw2, > and others in Red Hat. > Dumping Evo now, after being pushed for years by RH, can not > be a Good Thing (TM). Relying on a default application that does not have upstream development momentum and is accumulating security related issues which are not being fixed is also a problem. In a world with no perfect solution and no way to know the future, all choices are sub-optimal. For every reason you can think of to stick with an application choice over multiple releases for consistency, I can think of a circumstances where there is a detrimental effect..even for business users... when that codebase is no longer being appropriately supported by upstream. No one is suggesting that moving or dropping evo is a decision that will be painless. But there absolutely must be flexibility to review application inclusions decisions from time to time and modify the software that is offered based on concerns about maintainability and security over consistency. Clearly there needs to be a commitment to a piece of software that is included for more than oen release of fedora...but its absurd to think that its inappropriate to discuss the option of trading a piece of software out for something more secure and better maintained upstream... six releases into the process. -jef"here's what I don't get in dimi's post. He suggest that the opinions of alan and other red hatter engineers hold extras special weight just because they are employees, contrary to the statements made by a fedora board member. If dimi really really believes that, why is dimi bothering to be a part of this discussion at all, since by dimi's own logic his opinion doesn't count. You either accept that this is an open dialog where people have an equal access to explain and support their position or you don't. And if you don't well then don't bother wading into the discussion."spaleta From Axel.Thimm at ATrpms.net Wed Apr 12 14:31:07 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 12 Apr 2006 16:31:07 +0200 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> Message-ID: <20060412143107.GB13693@neu.nirvana> On Tue, Apr 11, 2006 at 12:04:43PM -0600, Stephen J. Smoogen wrote: > This is more of a place-holder for people who might run into this > problem with FC5 and not getting sound working with Intel ICH7 > chipsets. I have a Dell 380 with a > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > Definition Audio Controller (rev 01) > > sound card. It worked fine with Fedora Core 4 but after upgrading to > Fedora Core 5 did not have sound anymore. The problem seems to be > either with the kernel drivers or the alsa drivers. So far I have > updated to the ones that the Fedora alsa maintainer keeps on his > homepage but they did not fix the problem. It is an open bug with > bugzilla in several cases... not sure of what the problem/fix will be. There are known issues with Intel's HDA in 1.0.11rc2 which is what the FC5 kernel is equipped with. http://alsa-project.org/changes/v1-0-11rc3--v1-0-11rc4.txt Either wait for a kernel update or use the alsa-driver packages from ATrpms: http://atrpms.net/name/alsa-driver/ I wasn't going to package 1.0.11 before it went gold, but I had about 2-3 reports per day on this from the pvr community and now there is silence ... BTW should this be better asked on the fedora list? fedora-devel is now about FC6 I guess. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dimi at lattica.com Wed Apr 12 14:45:31 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 10:45:31 -0400 Subject: Move Evolution to Extras? In-Reply-To: <604aa7910604120718p710ab63l3b4854b58da100dd@mail.gmail.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <604aa7910604120718p710ab63l3b4854b58da100dd@mail.gmail.com> Message-ID: <1144853131.6382.172.camel@dimi> On Wed, 2006-04-12 at 10:18 -0400, Jeff Spaleta wrote: > > Relying on a default application that does not have upstream > development momentum and is accumulating security related issues which > are not being fixed is also a problem. In a world with no perfect > solution and no way to know the future, all choices are sub-optimal. This is understood, I know how free software works. But in this case it seems people are just venting against Evo. And let me tell you, I can so relate to that :) And please let me make this clear: I'm not arguing at all against people freely expressing opinions on this list. But it doesn't seem to be going anywhere. First, people simply suggested dropping Evo, nobody bothered to suggest a decent replacement. And for a good reason -- there aren't any. Second, looking at the bigger picture, it's clear that RH needs an inhouse developer for Evo whether they like it or not. At which point, I don't see why we would need to consider dropping Evo. Third, let's put things in perspective. It's one thing to drop nmh which affects a small group of mostly technical users, it's another matter to drop the main graphical client than everybody and their brother are using. Not to mention that said graphical client stores mail on disk in format that last I've checked is not recognized by other MUAs. > -jef"here's what I don't get in dimi's post. He suggest that the > opinions of alan and other red hatter engineers hold extras special > weight just because they are employees, contrary to the statements > made by a fedora board member. If dimi really really believes that, > why is dimi bothering to be a part of this discussion at all, since by > dimi's own logic his opinion doesn't count. You either accept that > this is an open dialog where people have an equal access to explain > and support their position or you don't. And if you don't well then > don't bother wading into the discussion."spaleta Please. I highly doubt my opinion weighs as much as Alan's within RH. And that's fine, not sure why you're trying to paint a black-or-white picture when there's obviously a ton of gray in between. :) -- Dimi Paun Lattica, Inc. From lists at ralii.com Wed Apr 12 14:52:20 2006 From: lists at ralii.com (Robert Locke) Date: Wed, 12 Apr 2006 10:52:20 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060412140504.GE15794@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> Message-ID: <1144853540.2754.6.camel@rltp40f5.ralii.com> But, the question remains: What is an alternative that includes not only email and contacts, but also calendaring and task lists for a Gnome oriented environment? I don't have a problem with contemplating the death of Evolution, but what do we use instead? --Rob From david at lovesunix.net Wed Apr 12 14:56:49 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 12 Apr 2006 16:56:49 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144853540.2754.6.camel@rltp40f5.ralii.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> Message-ID: <1144853809.2648.48.camel@localhost.localdomain> ons, 12 04 2006 kl. 10:52 -0400, skrev Robert Locke: > > > But, the question remains: > > What is an alternative that includes not only email and contacts, but > also calendaring and task lists for a Gnome oriented environment? > > I don't have a problem with contemplating the death of Evolution, but > what do we use instead? Maybe we could use Dates, Contacts and Tinymail as a complete replacement - although this would require some work I think the solution would be sufficent as it all integrates via e-d-s (the only excusable part of Evolution to be honest). FC6 is still a lont time away, I'm sure we could make this work by then - what I'm mostly worried about is upstream acceptance of the decision to dump Evolution. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jamatos at fc.up.pt Wed Apr 12 14:57:46 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 12 Apr 2006 15:57:46 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1144853131.6382.172.camel@dimi> References: <1144155199.2808.94.camel@dimi> <604aa7910604120718p710ab63l3b4854b58da100dd@mail.gmail.com> <1144853131.6382.172.camel@dimi> Message-ID: <200604121557.46110.jamatos@fc.up.pt> On Wednesday 12 April 2006 15:45, Dimi Paun wrote: > Not to mention that said graphical client stores > mail on disk in format that last I've checked is not recognized by > other MUAs. FWIW, kmail (that I am using embedded in kontact) claims otherwise. :-) -- Jos? Ab?lio From suttner at anduras.de Wed Apr 12 14:57:55 2006 From: suttner at anduras.de (Bernhard Suttner) Date: Wed, 12 Apr 2006 16:57:55 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144853540.2754.6.camel@rltp40f5.ralii.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> Message-ID: <20060412165755.6066b432.suttner@anduras.de> speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) Greets, Bernhard Suttner On Wed, 12 Apr 2006 10:52:20 -0400 Robert Locke wrote: > > > But, the question remains: > > What is an alternative that includes not only email and contacts, but > also calendaring and task lists for a Gnome oriented environment? > > I don't have a problem with contemplating the death of Evolution, but > what do we use instead? > > --Rob > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Bernhard Suttner ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Sch?n Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr?ger From jos at xos.nl Wed Apr 12 14:59:12 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 12 Apr 2006 16:59:12 +0200 Subject: Move Evolution to Extras? In-Reply-To: <20060412165755.6066b432.suttner@anduras.de>; from suttner@anduras.de on Wed, Apr 12, 2006 at 04:57:55PM +0200 References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> Message-ID: <20060412165912.F16253@xos037.xos.nl> On Wed, Apr 12, 2006 at 04:57:55PM +0200, Bernhard Suttner wrote: > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) As Open Source? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From suttner at anduras.de Wed Apr 12 15:01:09 2006 From: suttner at anduras.de (Bernhard Suttner) Date: Wed, 12 Apr 2006 17:01:09 +0200 Subject: Move Evolution to Extras? In-Reply-To: <20060412165912.F16253@xos037.xos.nl> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> <20060412165912.F16253@xos037.xos.nl> Message-ID: <20060412170109.782bc02d.suttner@anduras.de> On Wed, 12 Apr 2006 16:59:12 +0200 Jos Vos wrote: > On Wed, Apr 12, 2006 at 04:57:55PM +0200, Bernhard Suttner wrote: > > > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) > > As Open Source? would be really a god deal with IBM to release Lotus Notus as open source. > -- > -- Jos Vos > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Bernhard Suttner ANDURAS service solutions AG Innstra?e 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Sch?n Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr?ger From notting at redhat.com Wed Apr 12 15:04:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Apr 2006 11:04:19 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060412170109.782bc02d.suttner@anduras.de> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> <20060412165912.F16253@xos037.xos.nl> <20060412170109.782bc02d.suttner@anduras.de> Message-ID: <20060412150419.GB30579@devserv.devel.redhat.com> Bernhard Suttner (suttner at anduras.de) said: > > > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) > > > > As Open Source? > > would be really a god deal with IBM to release Lotus Notus as open source. You know, I've heard all the complaints mentioned in this thread.... I don't even *use* Evo, and I'd still prefer it to Notes. :) Bill From dimi at lattica.com Wed Apr 12 15:16:08 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 11:16:08 -0400 Subject: Move Evolution to Extras? In-Reply-To: <20060412150419.GB30579@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> <20060412165912.F16253@xos037.xos.nl> <20060412170109.782bc02d.suttner@anduras.de> <20060412150419.GB30579@devserv.devel.redhat.com> Message-ID: <1144854968.6382.176.camel@dimi> On Wed, 2006-04-12 at 11:04 -0400, Bill Nottingham wrote: > You know, I've heard all the complaints mentioned in this thread.... > I don't even *use* Evo, and I'd still prefer it to Notes. :) Hear, hear. Folks, if you get excited about Notes, you didn't use it. Or you're just trying to sabotage Fedora :) It's so bad it's not even funny. Lets not even think about it, please. -- Dimi Paun Lattica, Inc. From mailinglists at erwinrol.com Wed Apr 12 15:20:36 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 12 Apr 2006 17:20:36 +0200 Subject: Move Evolution to Extras? In-Reply-To: <20060412170109.782bc02d.suttner@anduras.de> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> <20060412165912.F16253@xos037.xos.nl> <20060412170109.782bc02d.suttner@anduras.de> Message-ID: <1144855236.12092.185.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 17:01 +0200, Bernhard Suttner wrote: > On Wed, 12 Apr 2006 16:59:12 +0200 > Jos Vos wrote: > > > On Wed, Apr 12, 2006 at 04:57:55PM +0200, Bernhard Suttner wrote: > > > > > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) > > > > As Open Source? > > would be really a god deal with IBM to release Lotus Notus as open source. Yeah so we can directly dump it in the bitbucket. Notes is nor Evolution nor Intelligent Design, it is simply a mistake. - Erwin From dimi at lattica.com Wed Apr 12 15:23:52 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 11:23:52 -0400 Subject: Move Evolution to Extras? In-Reply-To: <200604121557.46110.jamatos@fc.up.pt> References: <1144155199.2808.94.camel@dimi> <604aa7910604120718p710ab63l3b4854b58da100dd@mail.gmail.com> <1144853131.6382.172.camel@dimi> <200604121557.46110.jamatos@fc.up.pt> Message-ID: <1144855432.6382.181.camel@dimi> On Wed, 2006-04-12 at 15:57 +0100, Jose' Matos wrote: > FWIW, kmail (that I am using embedded in kontact) claims > otherwise. :-) kmail is a really good mail client. I've used it for years, and I do prefer it to Evo. The bug that dwmw2 pointed out is annoying, but not a show stopper for most people. However, it's not really an option for a GNOME desktop. Both GNOME and KDE are bloated pigs, you really can't force both environments in memory (with all their libs, daemons, etc) for everybody. -- Dimi Paun Lattica, Inc. From galibert at pobox.com Wed Apr 12 15:25:15 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 17:25:15 +0200 Subject: Where is my "everything" gone? Message-ID: <20060412152515.GA89988@dspnet.fr.eu.org> I don't see that choice anywhere in the text installer in fc5. That's a bug, right? Right? OG. From sundaram at fedoraproject.org Wed Apr 12 15:29:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 20:59:38 +0530 Subject: Where is my "everything" gone? In-Reply-To: <20060412152515.GA89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> Message-ID: <1144855778.2294.300.camel@sundaram.pnq.redhat.com> On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > I don't see that choice anywhere in the text installer in fc5. That's > a bug, right? Right? > > OG. NOTABUG. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 Rahul From galibert at pobox.com Wed Apr 12 15:33:56 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 17:33:56 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144855778.2294.300.camel@sundaram.pnq.redhat.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> Message-ID: <20060412153356.GB89988@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 08:59:38PM +0530, Rahul Sundaram wrote: > On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > > I don't see that choice anywhere in the text installer in fc5. That's > > a bug, right? Right? > > > > OG. > > NOTABUG. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 You guys are nuts. Time for me to find a way to migrate us out of fedora to something sane. OG. From nicolas.mailhot at laposte.net Wed Apr 12 15:36:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Apr 2006 17:36:55 +0200 (CEST) Subject: Move Evolution to Extras? In-Reply-To: <80d7e4090604120629i1b381efcy2b9c1e0418079fdd@mail.gmail.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <80d7e4090604120629i1b381efcy2b9c1e0418079fdd@mail.gmail.com> Message-ID: <36439.192.54.193.51.1144856215.squirrel@rousalka.dyndns.org> Le Mer 12 avril 2006 15:29, Stephen J. Smoogen a ?crit : > I think that would be a stiffling of free speech on this list. "Oh I > work for Red Hat, I cant give my opinion about what a program does and > where it should be." Alan said his opinion and several other people > have too. Whether evolution is killed or not is the Fedora Execs > decision. Also Alan's opinions carry a lot of weight because he has nothing to proove and is usually clueful and honest. The @rh tag is nothing compared to this. -- Nicolas Mailhot From jwboyer at jdub.homelinux.org Wed Apr 12 15:39:37 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 12 Apr 2006 10:39:37 -0500 Subject: Move Evolution to Extras? In-Reply-To: <20060412165755.6066b432.suttner@anduras.de> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> Message-ID: <20060412153937.GB10844@yoda.jdub.homelinux.org> On Wed, Apr 12, 2006 at 04:57:55PM +0200, Bernhard Suttner wrote: > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME like) I work for IBM. I wouldn't wish Notes on anyone. Ever. josh From nicolas.mailhot at laposte.net Wed Apr 12 15:40:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Apr 2006 17:40:01 +0200 (CEST) Subject: Move Evolution to Extras? In-Reply-To: <20060412150419.GB30579@devserv.devel.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <20060412165755.6066b432.suttner@anduras.de> <20060412165912.F16253@xos037.xos.nl> <20060412170109.782bc02d.suttner@anduras.de> <20060412150419.GB30579@devserv.devel.redhat.com> Message-ID: <45376.192.54.193.51.1144856401.squirrel@rousalka.dyndns.org> Le Mer 12 avril 2006 17:04, Bill Nottingham a ?crit : > Bernhard Suttner (suttner at anduras.de) said: >> > > speak with IBM and get a Lotus Notus nativ port to Linux (GNOME >> like) >> > >> > As Open Source? >> >> would be really a god deal with IBM to release Lotus Notus as open >> source. > > You know, I've heard all the complaints mentioned in this thread.... > I don't even *use* Evo, and I'd still prefer it to Notes. :) All the current fat mail clients deserve the barf bag unfortunately. -- Nicolas Mailhot From jamatos at fc.up.pt Wed Apr 12 15:42:39 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 12 Apr 2006 16:42:39 +0100 Subject: Where is my "everything" gone? In-Reply-To: <20060412153356.GB89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> Message-ID: <200604121642.40267.jamatos@fc.up.pt> On Wednesday 12 April 2006 16:33, Olivier Galibert wrote: > You guys are nuts. ?Time for me to find a way to migrate us out of > fedora to something sane. Last time in the discussion that lead to that decision "Everything" meant different things to different people. What is your definition of everything? :-) > ? OG. -- Jos? Ab?lio From jwboyer at jdub.homelinux.org Wed Apr 12 15:43:03 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 12 Apr 2006 10:43:03 -0500 Subject: Where is my "everything" gone? In-Reply-To: <20060412153356.GB89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> Message-ID: <20060412154303.GC10844@yoda.jdub.homelinux.org> On Wed, Apr 12, 2006 at 05:33:56PM +0200, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 08:59:38PM +0530, Rahul Sundaram wrote: > > On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > > > I don't see that choice anywhere in the text installer in fc5. That's > > > a bug, right? Right? > > > > > > OG. > > > > NOTABUG. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 > > You guys are nuts. Time for me to find a way to migrate us out of > fedora to something sane. Bye. We wish you well. josh From david at lovesunix.net Wed Apr 12 15:43:24 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 12 Apr 2006 17:43:24 +0200 Subject: Where is my "everything" gone? In-Reply-To: <20060412153356.GB89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> Message-ID: <1144856604.2648.56.camel@localhost.localdomain> ons, 12 04 2006 kl. 17:33 +0200, skrev Olivier Galibert: > On Wed, Apr 12, 2006 at 08:59:38PM +0530, Rahul Sundaram wrote: > > On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > > > I don't see that choice anywhere in the text installer in fc5. That's > > > a bug, right? Right? > > > > > > OG. > > > > NOTABUG. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 > > You guys are nuts. Time for me to find a way to migrate us out of > fedora to something sane. When I go to the local hot dog stand and ask for a hot dog with everything - I do not get every single item they carry, I get a defined subset that is "everything", namely bread, sausage, onions, ketchup, mustard and remolade. Now this is not one of each item they carry it is however the defined norm for a hotdog - Fedora is no different in this respect, an install with every single item is problematic in several areas and the potential use case where having every single package installed via the installer is next to non-existant. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From galibert at pobox.com Wed Apr 12 15:52:26 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 17:52:26 +0200 Subject: Where is my "everything" gone? In-Reply-To: <200604121642.40267.jamatos@fc.up.pt> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> Message-ID: <20060412155226.GA92603@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 04:42:39PM +0100, Jose' Matos wrote: > On Wednesday 12 April 2006 16:33, Olivier Galibert wrote: > > You guys are nuts. ?Time for me to find a way to migrate us out of > > fedora to something sane. > > Last time in the discussion that lead to that decision "Everything" meant > different things to different people. What is your definition of > everything? :-) The exact same thing it meant in fc3, everything in the repository barring obvious conflicts, which was at the time limited to the kernel wasn't it? Or in other words, as much as possible so that I don't have users asking for the software they happen to need every other day on the 200+ systems I have to install semi-automatically. Hard drives are cheap and I like having time for other things that sysadminning. OG. From n0dalus+redhat at gmail.com Wed Apr 12 15:55:48 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 13 Apr 2006 01:25:48 +0930 Subject: Where is my "everything" gone? In-Reply-To: <20060412153356.GB89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> Message-ID: <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> On 4/13/06, Olivier Galibert wrote: > > You guys are nuts. Time for me to find a way to migrate us out of > fedora to something sane. > There are plenty of people in the community who still think this is a bug. I personally don't care as long as they improve the installer to include important things such as how much space the install is going to use. The issue of everything installs has been discussed ad nauseam on the list. You might want to check the archives. n0dalus. From dwmw2 at infradead.org Wed Apr 12 15:58:11 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Apr 2006 11:58:11 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144849676.6382.155.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> Message-ID: <1144857491.2645.73.camel@shinybook.infradead.org> On Wed, 2006-04-12 at 09:47 -0400, Dimi Paun wrote: > Give me a break. Alan is just not anybody, and neither is dwmw2, > and others in Red Hat. If my opinion counted for anything we wouldn't have dropped our most capable and easy to use MTA just before FC4. We do need to have a serious discussion about what we're going to do with/about Evolution though... which is what seems to be happening. -- dwmw2 From theaton at lanl.gov Wed Apr 12 16:00:10 2006 From: theaton at lanl.gov (Tony Heaton) Date: Wed, 12 Apr 2006 10:00:10 -0600 Subject: Where is my "everything" gone? In-Reply-To: <20060412152515.GA89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> Message-ID: <1144857610.11528.38.camel@mlor> On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > I don't see that choice anywhere in the text installer in fc5. That's > a bug, right? Right? > > OG. This has been discussed to death 10 fold. Anyone that needs an everything install should be using a different OS. Sorry for being so blunt. -- Tony Heaton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Wed Apr 12 16:03:27 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 12:03:27 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412153356.GB89988@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> Message-ID: <20060412160327.GA22574@devserv.devel.redhat.com> On Wed, Apr 12, 2006 at 05:33:56PM +0200, Olivier Galibert wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 > > You guys are nuts. Time for me to find a way to migrate us out of > fedora to something sane. Not really. An "everything" install basically becomes impossible once you have external repositories like extras. It would be like doing an "everything" install in Debian.. not at all sane. Alan From galibert at pobox.com Wed Apr 12 16:04:21 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 18:04:21 +0200 Subject: Where is my "everything" gone? In-Reply-To: <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> Message-ID: <20060412160421.GA93853@dspnet.fr.eu.org> On Thu, Apr 13, 2006 at 01:25:48AM +0930, n0dalus wrote: > There are plenty of people in the community who still think this is a > bug. I personally don't care as long as they improve the installer to > include important things such as how much space the install is going > to use. Beautiful. That was in fc3 too. Interesting definition of progress we have here. > The issue of everything installs has been discussed ad nauseam on the > list. You might want to check the archives. Beautiful. That way I'll know why sysadmins got fucked over and why I have to write my own installer. Good thing it's not that hard in practice. OG. From jspaleta at gmail.com Wed Apr 12 16:12:22 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Apr 2006 12:12:22 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412160421.GA93853@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> <20060412160421.GA93853@dspnet.fr.eu.org> Message-ID: <604aa7910604120912k67c43424of93e90ee146d65f4@mail.gmail.com> On 4/12/06, Olivier Galibert wrote: > Beautiful. That way I'll know why sysadmins got fucked over and why I > have to write my own installer. Good thing it's not that hard in > practice. have you looked at kickstart yet, you might want to look into that as a sysadmin. -jef From sundaram at fedoraproject.org Wed Apr 12 16:14:51 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 12 Apr 2006 21:44:51 +0530 Subject: Where is my "everything" gone? In-Reply-To: <20060412160421.GA93853@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> <20060412160421.GA93853@dspnet.fr.eu.org> Message-ID: <1144858491.2294.310.camel@sundaram.pnq.redhat.com> On Wed, 2006-04-12 at 18:04 +0200, Olivier Galibert wrote: > On Thu, Apr 13, 2006 at 01:25:48AM +0930, n0dalus wrote: > > There are plenty of people in the community who still think this is a > > bug. I personally don't care as long as they improve the installer to > > include important things such as how much space the install is going > > to use. > > Beautiful. That was in fc3 too. Interesting definition of progress > we have here. The installer has been rewritten to use a yum backend and there are features that havent been implemented yet. Fedora Core 3 everything option didnt install every package on the media unlike what is being assumed here. > > > > The issue of everything installs has been discussed ad nauseam on the > > list. You might want to check the archives. > > Beautiful. That way I'll know why sysadmins got fucked over and why I > have to write my own installer. Good thing it's not that hard in > practice. Sysadmins who have to install 200+ systems should be using kickstart with @everything option if they want to dump everything from the media into the system. I dont think it makes much sense for sysadmins installing all that is available in the media including all the language packs and updating them constantly instead of tailoring the system to meet their specific requirements but kickstart does let you do that. They might even require some packages from Fedora Extras which a everything option wouldnt install anyway. Calling everyone who disagrees with you as insane and swearing isnt likely to help. Rahul From galibert at pobox.com Wed Apr 12 16:17:02 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 18:17:02 +0200 Subject: Where is my "everything" gone? In-Reply-To: <20060412160327.GA22574@devserv.devel.redhat.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> Message-ID: <20060412161702.GA94772@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 12:03:27PM -0400, Alan Cox wrote: > On Wed, Apr 12, 2006 at 05:33:56PM +0200, Olivier Galibert wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186007 > > > > You guys are nuts. Time for me to find a way to migrate us out of > > fedora to something sane. > > Not really. An "everything" install basically becomes impossible once you > have external repositories like extras. It would be like doing an > "everything" install in Debian.. not at all sane. Sure, but Fedora is not Debian. Having a reasonable core with a set of packages which provides decent functionality is, or was, one of the points of Fedora. The ability to throw them in a nfs install directory with whatever extra packages you locally need and some automatic configuration packages was very nice. Now you've thrown that away. "Everything" meant in practice "the package selection has been done in the repository itself". Now there is no easy way to do that anymore. But I really start to wonder why there is a core/extras distinction as that point. Why do you care, the user will have to select by hand what he wants anyway. When was it decided that computer farms, servers and remote administration was unimportant, and only the desktop user was interesting? Is it official, or just de facto? OG. From bruno at wolff.to Wed Apr 12 16:26:02 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 12 Apr 2006 11:26:02 -0500 Subject: Where is my "everything" gone? In-Reply-To: <200604121642.40267.jamatos@fc.up.pt> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> Message-ID: <20060412162602.GA900@wolff.to> On Wed, Apr 12, 2006 at 16:42:39 +0100, Jose' Matos wrote: > On Wednesday 12 April 2006 16:33, Olivier Galibert wrote: > > You guys are nuts. ?Time for me to find a way to migrate us out of > > fedora to something sane. > > Last time in the discussion that lead to that decision "Everything" meant > different things to different people. What is your definition of > everything? :-) I expected it would have included mt-st. I was a bit surprised when I tried to rewind my tape drive and there was no mt command. There was some other program I expected to be installed (I installed everything I could during the initial install), but wasn't, but I don't remember what it was. I was able to find an rpm for it as well (as mt) on the DVD.iso. So despite doing as close to an everything install as I could, I found there were two things that were on the DVD iso that I wanted to use that weren't installed. From alan at redhat.com Wed Apr 12 16:28:20 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 12:28:20 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412161702.GA94772@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> Message-ID: <20060412162820.GA642@devserv.devel.redhat.com> On Wed, Apr 12, 2006 at 06:17:02PM +0200, Olivier Galibert wrote: > When was it decided that computer farms, servers and remote > administration was unimportant, and only the desktop user was > interesting? Is it official, or just de facto? Kickstart is specifically dessigned to handle these cases. You can script the entire install and do the install "hands-off" From jspaleta at gmail.com Wed Apr 12 16:32:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 12 Apr 2006 12:32:19 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412161702.GA94772@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> Message-ID: <604aa7910604120932k230a12e6x8ce7d817784a8c35@mail.gmail.com> On 4/12/06, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 12:03:27PM -0400, Alan Cox wrote: > Sure, but Fedora is not Debian. Having a reasonable core with a set > of packages which provides decent functionality is, or was, one of the > points of Fedora. The ability to throw them in a nfs install > directory with whatever extra packages you locally need and some > automatic configuration packages was very nice. Now you've thrown > that away. "Everything" meant in practice "the package selection has > been done in the repository itself". Now there is no easy way to do > that anymore. > > But I really start to wonder why there is a core/extras distinction as > that point. Why do you care, the user will have to select by hand > what he wants anyway. > Think of it like this.... this is just one of the steps leading to a slimmer core. We are moving along a path when the default install options for the media sets could an everything install for the media sets.... for much slimmer media sets and a potential variety of media set under the fedora umbrella name. You are asking the wrong questions from the wrong point of view. The real question should be why are any optional applications provided on the Core media set at all. > When was it decided that computer farms, servers and remote > administration was unimportant, and only the desktop user was > interesting? Is it official, or just de facto? If need to become familiar with kickstart. -jef From jos at xos.nl Wed Apr 12 16:35:30 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 12 Apr 2006 18:35:30 +0200 Subject: Where is my "everything" gone? In-Reply-To: <20060412160327.GA22574@devserv.devel.redhat.com>; from alan@redhat.com on Wed, Apr 12, 2006 at 12:03:27PM -0400 References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> Message-ID: <20060412183530.G16253@xos037.xos.nl> On Wed, Apr 12, 2006 at 12:03:27PM -0400, Alan Cox wrote: > Not really. An "everything" install basically becomes impossible once you > have external repositories like extras. It would be like doing an > "everything" install in Debian.. not at all sane. As someone pointed out in the bug report: let's define "everything" as "everything on the standard CD set" (== core at the moment, I think), or everything in a base repository, or ... I don't see what the problem is for offering such a feature, more or less equivalent with the old "everything". -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From katzj at redhat.com Wed Apr 12 16:36:19 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Apr 2006 12:36:19 -0400 Subject: Where is my "everything" gone? In-Reply-To: <1144858491.2294.310.camel@sundaram.pnq.redhat.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <6280325c0604120855m5b81563cnfc7eb4bc5c726ab3@mail.gmail.com> <20060412160421.GA93853@dspnet.fr.eu.org> <1144858491.2294.310.camel@sundaram.pnq.redhat.com> Message-ID: <1144859779.3807.5.camel@aglarond.local> On Wed, 2006-04-12 at 21:44 +0530, Rahul Sundaram wrote: > Sysadmins who have to install 200+ systems should be using kickstart > with @everything option if they want to dump everything from the media > into the system. Note that while the @Everything syntax currently works and will for a few releases, it is deprecated in preference of actually just using a glob, eg, '*' @foo implies the group foo and since Everything isn't really a group, it's somewhat abusive of the semantics. Jeremy From smooge at gmail.com Wed Apr 12 16:37:07 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 10:37:07 -0600 Subject: FC5 Sound with snd-hda-intel not working. (alsa problem?) In-Reply-To: <20060412143107.GB13693@neu.nirvana> References: <80d7e4090604111104s5cc244c5h2aac76d850cf1a5f@mail.gmail.com> <20060412143107.GB13693@neu.nirvana> Message-ID: <80d7e4090604120937o6290d633wf9f656be28fa851@mail.gmail.com> On 4/12/06, Axel Thimm wrote: > On Tue, Apr 11, 2006 at 12:04:43PM -0600, Stephen J. Smoogen wrote: > > This is more of a place-holder for people who might run into this > > problem with FC5 and not getting sound working with Intel ICH7 > > chipsets. I have a Dell 380 with a > > > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High > > Definition Audio Controller (rev 01) > > > > sound card. It worked fine with Fedora Core 4 but after upgrading to > > Fedora Core 5 did not have sound anymore. The problem seems to be > > either with the kernel drivers or the alsa drivers. So far I have > > updated to the ones that the Fedora alsa maintainer keeps on his > > homepage but they did not fix the problem. It is an open bug with > > bugzilla in several cases... not sure of what the problem/fix will be. > > There are known issues with Intel's HDA in 1.0.11rc2 which is what the > FC5 kernel is equipped with. > > http://alsa-project.org/changes/v1-0-11rc3--v1-0-11rc4.txt > > Either wait for a kernel update or use the alsa-driver packages from > ATrpms: > > http://atrpms.net/name/alsa-driver/ > > I wasn't going to package 1.0.11 before it went gold, but I had about > 2-3 reports per day on this from the pvr community and now there is > silence ... > > BTW should this be better asked on the fedora list? fedora-devel is > now about FC6 I guess. My apologies. Will end of Life this thread ;) -- Stephen J Smoogen. CSIRT/Linux System Administrator From shahms at shahms.com Wed Apr 12 16:42:20 2006 From: shahms at shahms.com (Shahms King) Date: Wed, 12 Apr 2006 09:42:20 -0700 Subject: GCC optimization bug (was python memory usage) Message-ID: <443D2DEC.1010805@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub, I see that bug #188649 is fixed in rawhide. I just ran my test case and it is, indeed, fixed. Can this updated gcc and recompiled (possibly updated to 2.4.3) be pushed to updates-testing soon? I don't know how many other packages or people are affected by the bug, but it causes a pretty serious memory problem for python (bug #188327) and it would be nice to get this fixed. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEPS3r/qs2NkWy11sRAlLtAJ9oQVvN8Ul9vwqANjoAdj3e/2vZOQCdEuRe Ee6eIn3OEMJndQEUuXRoYDc= =ofrh -----END PGP SIGNATURE----- From galibert at pobox.com Wed Apr 12 16:50:55 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 18:50:55 +0200 Subject: Where is my "everything" gone? In-Reply-To: <20060412162820.GA642@devserv.devel.redhat.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412162820.GA642@devserv.devel.redhat.com> Message-ID: <20060412165055.GA97334@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 12:28:20PM -0400, Alan Cox wrote: > On Wed, Apr 12, 2006 at 06:17:02PM +0200, Olivier Galibert wrote: > > When was it decided that computer farms, servers and remote > > administration was unimportant, and only the desktop user was > > interesting? Is it official, or just de facto? > > Kickstart is specifically dessigned to handle these cases. You can script > the entire install and do the install "hands-off" I remember looking at kickstart a long time ago, and it sucked horribly when you didn't want to script the _entire_ install. Hopefully, it is better now. OG. From esm at logic.net Wed Apr 12 16:59:55 2006 From: esm at logic.net (Edward S. Marshall) Date: Wed, 12 Apr 2006 11:59:55 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144853540.2754.6.camel@rltp40f5.ralii.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> Message-ID: <1144861195.11823.15.camel@localhost> On Wed, 2006-04-12 at 10:52 -0400, Robert Locke wrote: > What is an alternative that includes not only email and contacts, but > also calendaring and task lists for a Gnome oriented environment? I use Evolution to integrate my home and work email and calendaring in a nice seamless interface. Without an Exchange-compatible MUA, I might as well go back to using mutt, because the only way I'll be able to see my work email or calendar is through the webmail interface. You can do all the handwringing you want about "proprietary software", but this is a real-world integration need for me as a desktop user who actually works for a living, and I have an open-source solution that works for me today. What software would you suggest I switch to that continues to meet this need? -- Edward S. Marshall http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. From smooge at gmail.com Wed Apr 12 17:00:57 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 11:00:57 -0600 Subject: Where is my "everything" gone? In-Reply-To: <1144857610.11528.38.camel@mlor> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144857610.11528.38.camel@mlor> Message-ID: <80d7e4090604121000h27445585r81691f11d4a6529e@mail.gmail.com> On 4/12/06, Tony Heaton wrote: > On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > > I don't see that choice anywhere in the text installer in fc5. That's > > a bug, right? Right? > > > > OG. > > This has been discussed to death 10 fold. Anyone that needs an > everything install should be using a different OS. Sorry for being so > blunt. > Tony?!? Ssshh I wont tell the Debian guys at LANL? And I thought you were much less blunt than usual :). Hope all is well in LANL these days for you.. slaving away in SNL > -- > Tony Heaton > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQBEPSQKmbNIt31btW8RAuIvAJ0RIrG6DL4/U74Li1KGPg3zI0kh9QCfTnm5 > 9DXCu9/SE8bAfl2luNa8lGw= > =NqtL > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From smooge at gmail.com Wed Apr 12 17:01:20 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 11:01:20 -0600 Subject: Where is my "everything" gone? In-Reply-To: <80d7e4090604121000h27445585r81691f11d4a6529e@mail.gmail.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144857610.11528.38.camel@mlor> <80d7e4090604121000h27445585r81691f11d4a6529e@mail.gmail.com> Message-ID: <80d7e4090604121001j3a2bd82bn872b2b430f56c6d3@mail.gmail.com> Crap.. My apologies for the spam On 4/12/06, Stephen J. Smoogen wrote: > On 4/12/06, Tony Heaton wrote: > > On Wed, 2006-04-12 at 17:25 +0200, Olivier Galibert wrote: > > > I don't see that choice anywhere in the text installer in fc5. That's > > > a bug, right? Right? > > > > > > OG. > > > > This has been discussed to death 10 fold. Anyone that needs an > > everything install should be using a different OS. Sorry for being so > > blunt. > > > > Tony?!? Ssshh I wont tell the Debian guys at LANL? > > And I thought you were much less blunt than usual :). Hope all is well > in LANL these days for you.. slaving away in SNL > > > -- > > Tony Heaton > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.1 (GNU/Linux) > > > > iD8DBQBEPSQKmbNIt31btW8RAuIvAJ0RIrG6DL4/U74Li1KGPg3zI0kh9QCfTnm5 > > 9DXCu9/SE8bAfl2luNa8lGw= > > =NqtL > > -----END PGP SIGNATURE----- > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > -- Stephen J Smoogen. CSIRT/Linux System Administrator From esr at thyrsus.com Wed Apr 12 16:42:55 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 12 Apr 2006 12:42:55 -0400 Subject: Caring about users In-Reply-To: <20060412161702.GA94772@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> Message-ID: <20060412164255.GA19877@thyrsus.com> Olivier Galibert : > When was it decided that computer farms, servers and remote > administration was unimportant, and only the desktop user was > interesting? Is it official, or just de facto? Heh. If most fedora-devel list members actually thought "only the desktop user was interesting", the thread about co-opting proprietary codecs would have gone rather differently. I conclude that most of this list doesn't think *any* class of users is interesting. That's not an attitude that bodes well for the future. -- Eric S. Raymond From dwmw2 at infradead.org Wed Apr 12 17:10:58 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Apr 2006 13:10:58 -0400 Subject: Where is my "everything" gone? In-Reply-To: <80d7e4090604121001j3a2bd82bn872b2b430f56c6d3@mail.gmail.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144857610.11528.38.camel@mlor> <80d7e4090604121000h27445585r81691f11d4a6529e@mail.gmail.com> <80d7e4090604121001j3a2bd82bn872b2b430f56c6d3@mail.gmail.com> Message-ID: <1144861859.2645.76.camel@shinybook.infradead.org> On Wed, 2006-04-12 at 11:01 -0600, Stephen J. Smoogen wrote: > Crap.. My apologies for the spam You forgot the obligatory link to http://www.unicom.com/pw/reply-to-harmful.html -- dwmw2 From jkeating at j2solutions.net Wed Apr 12 17:14:14 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 12 Apr 2006 13:14:14 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412183530.G16253@xos037.xos.nl> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> Message-ID: <1144862054.18861.179.camel@ender> On Wed, 2006-04-12 at 18:35 +0200, Jos Vos wrote: > "everything on the standard CD set" Do you really want every language installed on your system? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Apr 12 17:20:55 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 12 Apr 2006 12:20:55 -0500 Subject: Caring about users In-Reply-To: <20060412164255.GA19877@thyrsus.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> Message-ID: <20060412172055.GA12112@yoda.jdub.homelinux.org> On Wed, Apr 12, 2006 at 12:42:55PM -0400, Eric S. Raymond wrote: > Olivier Galibert : > > When was it decided that computer farms, servers and remote > > administration was unimportant, and only the desktop user was > > interesting? Is it official, or just de facto? > > Heh. If most fedora-devel list members actually thought "only the > desktop user was interesting", the thread about co-opting proprietary > codecs would have gone rather differently. No it wouldn't. It's against the goals of Fedora. The only thing worse than beating a dead horse is trying to ride it. > > I conclude that most of this list doesn't think *any* class of users is > interesting. We like the ones that read the archives, present an opinion, debate it, and realize at the end of the day some things aren't going to go they way they want them and some are. We especially like the ones that present patches to fix things they find broken. > > That's not an attitude that bodes well for the future. Fedora is a community project. If the majority of the community isn't griping about something, I doubt a few here and there will make a difference. If someone wants to sit there and bitch about things and expect someone else to go fix them all the time, they can kindly move the fuck on. Now, if they want to actually contribute, that is the attitude we want. And that is a great attitude for the future of Fedora. josh From lamont at gurulabs.com Wed Apr 12 16:32:26 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 10:32:26 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144855432.6382.181.camel@dimi> References: <1144155199.2808.94.camel@dimi> <200604121557.46110.jamatos@fc.up.pt> <1144855432.6382.181.camel@dimi> Message-ID: <200604121032.26913.lamont@gurulabs.com> On Wednesday 12 April 2006 09:23am, Dimi Paun wrote: > On Wed, 2006-04-12 at 15:57 +0100, Jose' Matos wrote: > > FWIW, kmail (that I am using embedded in kontact) claims > > otherwise. :-) Yup. In fact, I switched to Evolution for a while back with Evo 1.4 and then back to KMail with Evo 2.0 and KMail did all the conversion just fine. But I didn't have to convert much. Only one of my email accounts is POPed. I use IMAP for the rest so it doesn't matter what email client I use, conversion is as easy as connecting a new client to the IMAP server. > kmail is a really good mail client. I've used it for years, > and I do prefer it to Evo. The bug that dwmw2 pointed out is > annoying, but not a show stopper for most people. Well, I'm still not certain I would call that a "bug" :) . > However, it's not really an option for a GNOME desktop. Both > GNOME and KDE are bloated pigs, you really can't force both > environments in memory (with all their libs, daemons, etc) > for everybody. And you don't have to. You can run KMail and/or Kontact on GNOME without installing the whole environment. You only need a couple of libs. I use GNOME apps on KDE, too, and I don't have GNOME installed. I have a few dozen MB of GNOME libraries installed and it just works. OK. All that said, we can not suggest Kontact as a replacement GNOME app (since it isn't a GNOME app) for Evolution, which is a condition some have already expressed. Some people hate using GNOME apps, other hate using KDE apps. Me? I'm fine with using good tools, regardless of which environment's tools they are written in. Personally, I have found more stability and reliability with KDE. I have friends who spit out the work "KDE" like chitlets, vowing to never leave GNOME. That's fine. I just roll my eyes while they have printing and evince issues and I can print anything I want and have never seen KPDF crash or screw up rendering once. My point is, my experience is mine. YMMV. Don't flame me because my environment works and yours falls apart. To be totally fair, there are, of course, bugs in KDE apps that I use and love. It took a year for Konsole to finally get rid of the "reloading tabs with the same name causes renaming of tabs" bug, which annoyed me (but at least, it didn't break and crash). That's just one example, and there are others, but for me, on the whole, KDE is far more stable. Again, YMMV. That's *my* story and I'm not going to impose my opinion on any of you...even though I'm right :) hehe. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lamont at gurulabs.com Wed Apr 12 17:22:08 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 11:22:08 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144842736.12092.173.camel@xpc.home.erwinrol.com> References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> Message-ID: <200604121122.14148.lamont@gurulabs.com> On Wednesday 12 April 2006 05:52am, Erwin Rol wrote: > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > On Tue, Apr 04, 2006 at 10:15:20AM -0300, Pedro Fernandes Macedo wrote: [snip] > > Evolution belongs in the bitbucket. > > And what are you suggesting as a replacement ? If Evolution ends up in > the bitbucket, something else with the same functionality should replace > it. So what other Gnome email+calendar+addressbook+task management > application should i use instead of evolution ? Well, if you put that many specific requirements into pot, then of course you're going to be right. If you drop just GNOME from "Gnome email+calendar+addressbook+task management", then there are options. If you take out all the +s, then you can find individual GNOME apps that collectively provide all those capabilities, albeit not in a tightly integrated fashion. So, here's a suggestion: Take the best individual GNOME apps and glue them together, ala` Kontact. It would be quick (relatively speaking) to do and would give people who will only consider GNOME apps choice (and therefore, freedom) again; something they have not had in a while, as you so aptly pointed out. I would suggest that this could/should be done regardless of what happens to Evo. > And why is evolution unmaintained? I mean it seems to be important > enough that expensive commercial Linux distributions like RHEL use it as > a default email client. I'm wondering the same thing. I see some indications that there is still an active (though the pulse is weak?) upstream. What happened to those Evolution authors/developers/maintainers? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jos at xos.nl Wed Apr 12 17:25:07 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 12 Apr 2006 19:25:07 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144862054.18861.179.camel@ender>; from jkeating@j2solutions.net on Wed, Apr 12, 2006 at 01:14:14PM -0400 References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> Message-ID: <20060412192507.A18336@xos037.xos.nl> On Wed, Apr 12, 2006 at 01:14:14PM -0400, Jesse Keating wrote: > Do you really want every language installed on your system? AFAIK (unless this has changed recently): all languages are always installed, as Anaconda has commented out the RPM language selection since long ago. I was surprised to see this too, but it is true (again, unless changed back in the meantime). (This does not apply to language-specific packages, IIRC, but to language-specific files in a package.) But language and package selection are not related to each other, you can also do an "everything" install in one language :-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mclasen at redhat.com Wed Apr 12 17:27:50 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 12 Apr 2006 13:27:50 -0400 Subject: Move Evolution to Extras? In-Reply-To: <200604121122.14148.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> Message-ID: <1144862870.10620.58.camel@golem.boston.redhat.com> On Wed, 2006-04-12 at 11:22 -0600, Lamont R. Peterson wrote: > > And why is evolution unmaintained? I mean it seems to be important > > enough that expensive commercial Linux distributions like RHEL use it as > > a default email client. > > I'm wondering the same thing. I see some indications that there is still an > active (though the pulse is weak?) upstream. What happened to those > Evolution authors/developers/maintainers? Don't confuse some people voicing their personal frustration with evolution with factual information. Instead, go to http://mail.gnome.org/archives/evolution-patches/ or http://mail.gnome.org/archives/evolution-hackers/ and watch the upstream development, or better yet, help out. Matthias From galibert at pobox.com Wed Apr 12 17:29:12 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 19:29:12 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144862054.18861.179.camel@ender> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> Message-ID: <20060412172912.GA2795@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 01:14:14PM -0400, Jesse Keating wrote: > On Wed, 2006-04-12 at 18:35 +0200, Jos Vos wrote: > > "everything on the standard CD set" > > Do you really want every language installed on your system? Personally, yes. The lab has people coming and going from everywhere in the world, and half of the people I work with did studies in linguistics. And most of the research we do has "multilingual-able" as a requirement. OG. From jkeating at redhat.com Wed Apr 12 17:29:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Apr 2006 13:29:51 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412192507.A18336@xos037.xos.nl> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412192507.A18336@xos037.xos.nl> Message-ID: <1144862991.8994.1.camel@ender> On Wed, 2006-04-12 at 19:25 +0200, Jos Vos wrote: > > AFAIK (unless this has changed recently): all languages are always > installed, as Anaconda has commented out the RPM language selection > since long ago. I was surprised to see this too, but it is true > (again, unless changed back in the meantime). (This does not > apply to language-specific packages, IIRC, but to language-specific > files in a package.) > > But language and package selection are not related to each other, > you can also do an "everything" install in one language :-). No, not all languages are installed, nor fonts for all languages. And once you get to 'Everything, but in my language', you're not in Everything land again, you're in some weird "What I consider to be everything", and frankly, we're tired of playing that game. You can select packages, you can use globs in kickstart. You can get exactly what you want. End of story. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nmiell at comcast.net Wed Apr 12 17:15:51 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 12 Apr 2006 10:15:51 -0700 Subject: Caring about users In-Reply-To: <20060412164255.GA19877@thyrsus.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> Message-ID: <1144862151.2336.4.camel@entropy> On Wed, 2006-04-12 at 12:42 -0400, Eric S. Raymond wrote: > Olivier Galibert : > > When was it decided that computer farms, servers and remote > > administration was unimportant, and only the desktop user was > > interesting? Is it official, or just de facto? > > Heh. If most fedora-devel list members actually thought "only the > desktop user was interesting", the thread about co-opting proprietary > codecs would have gone rather differently. > > I conclude that most of this list doesn't think *any* class of users is > interesting. > > That's not an attitude that bodes well for the future. > -- > Eric S. Raymond > Damn it Eric, stop joerging the list. -- Nicholas Miell From che666 at gmail.com Wed Apr 12 17:33:31 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 12 Apr 2006 19:33:31 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144861195.11823.15.camel@localhost> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <20060412140504.GE15794@devserv.devel.redhat.com> <1144853540.2754.6.camel@rltp40f5.ralii.com> <1144861195.11823.15.camel@localhost> Message-ID: 2006/4/12, Edward S. Marshall : > On Wed, 2006-04-12 at 10:52 -0400, Robert Locke wrote: > > What is an alternative that includes not only email and contacts, but > > also calendaring and task lists for a Gnome oriented environment? > > I use Evolution to integrate my home and work email and calendaring in a > nice seamless interface. Without an Exchange-compatible MUA, I might as > well go back to using mutt, because the only way I'll be able to see my > work email or calendar is through the webmail interface. > > You can do all the handwringing you want about "proprietary software", > but this is a real-world integration need for me as a desktop user who > actually works for a living, and I have an open-source solution that > works for me today. What software would you suggest I switch to that > continues to meet this need? > > -- > Edward S. Marshall > http://esm.logic.net/ > Felix qui potuit rerum cognoscere causas. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > from what i have read i see the following pros and cons: pro: - evolution has user acceptance - evolution integrates nicely with gnome - evolution is a full featured groupware client - evolution has a nice plugin interface - evolution provides functionality that can not be compensated by another tool con: - evolution is unmaintained - evolution has potentially problematic code rewrite? redesign? but the question is... if theres no existing maintainer for it.. where does the workforce come from to integrate another client and get it that far? whats the scheduled time for a replacement? or rather... where are proper design docs for a well designed groupware client? i come to the conclusion that theres currently no other way than finding a maintainer for evo that starts kicking butt upstream. regards, rudolf kastl From galibert at pobox.com Wed Apr 12 17:36:33 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 19:36:33 +0200 Subject: Caring about users In-Reply-To: <20060412172055.GA12112@yoda.jdub.homelinux.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> <20060412172055.GA12112@yoda.jdub.homelinux.org> Message-ID: <20060412173633.GB2795@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 12:20:55PM -0500, Josh Boyer wrote: > We like the ones that read the archives, present an opinion, debate it, and > realize at the end of the day some things aren't going to go they way they > want them and some are. We especially like the ones that present patches to > fix things they find broken. And when they're told it's not broken, they just have to suck it? I'm not defending ESR here though. Legal issues are pretty much impossible to fix technically. > Fedora is a community project. If the majority of the community isn't griping > about something, I doubt a few here and there will make a difference. The majority of the community does not care either way. Which is true of pretty much any issue, the caring minority just changing. If you feel like driving people out just because they're a minority is not a problem you won't have much of a majority left after a while. > If someone wants to sit there and bitch about things and expect someone else > to go fix them all the time, they can kindly move the fuck on. Now, if they > want to actually contribute, that is the attitude we want. And that is a great > attitude for the future of Fedora. I'd be happy to patch anaconda to have "everything" again. I'm probably going to in practice. I will submit the patch if you want, but I know it will be rejected, so what's the point? OG. From jos at xos.nl Wed Apr 12 17:37:14 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 12 Apr 2006 19:37:14 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144862991.8994.1.camel@ender>; from jkeating@redhat.com on Wed, Apr 12, 2006 at 01:29:51PM -0400 References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412192507.A18336@xos037.xos.nl> <1144862991.8994.1.camel@ender> Message-ID: <20060412193714.A18434@xos037.xos.nl> On Wed, Apr 12, 2006 at 01:29:51PM -0400, Jesse Keating wrote: > No, not all languages are installed, nor fonts for all languages. And So, the *commented out* line (as in RHEL4 Anaconda): # rpm.addMacro("_install_langs", shortLinguas) is not commented out anymore (sorry, have no FC5 sources here now) or is replaced by some other code? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dimi at lattica.com Wed Apr 12 17:37:15 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 13:37:15 -0400 Subject: Move Evolution to Extras? In-Reply-To: <200604121032.26913.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <200604121557.46110.jamatos@fc.up.pt> <1144855432.6382.181.camel@dimi> <200604121032.26913.lamont@gurulabs.com> Message-ID: <1144863435.6382.186.camel@dimi> On Wed, 2006-04-12 at 10:32 -0600, Lamont R. Peterson wrote: > And you don't have to. You can run KMail and/or Kontact on GNOME > without installing the whole environment. You only need a couple of > libs. You are missing the point. Starting any KDE app loads a lot of sh*t in memory that need not be there. If I'm using only apps from one environment, they share the same infrastructure (including libs loaded in memory). It would be insane to go to a default where *both* KDE and GNOME need to be loaded in order to do anything useful in GNOME. -- Dimi Paun Lattica, Inc. From alan at redhat.com Wed Apr 12 17:40:43 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 12 Apr 2006 13:40:43 -0400 Subject: Caring about users In-Reply-To: <20060412164255.GA19877@thyrsus.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> Message-ID: <20060412174043.GA24727@devserv.devel.redhat.com> On Wed, Apr 12, 2006 at 12:42:55PM -0400, Eric S. Raymond wrote: > Heh. If most fedora-devel list members actually thought "only the > desktop user was interesting", the thread about co-opting proprietary > codecs would have gone rather differently. > > I conclude that most of this list doesn't think *any* class of users is > interesting. No Eric. We think that *you* aren't interesting - the classes of users we care about are those wanting to develop, use and play with a cutting edge open source distribution not those wanting proprietary codecs. Now Eric please don't try to muddle an important discussion about whether "Everything" should come back with your personal proprietary software agenda. The value and semantics of an "everything" install, is interesting. Alan From smooge at gmail.com Wed Apr 12 17:41:03 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 11:41:03 -0600 Subject: Caring about users In-Reply-To: <20060412173633.GB2795@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> <20060412172055.GA12112@yoda.jdub.homelinux.org> <20060412173633.GB2795@dspnet.fr.eu.org> Message-ID: <80d7e4090604121041q6953f004p9d5f615e49d67d0e@mail.gmail.com> On 4/12/06, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 12:20:55PM -0500, Josh Boyer wrote: > > We like the ones that read the archives, present an opinion, debate it, and > > realize at the end of the day some things aren't going to go they way they > > want them and some are. We especially like the ones that present patches to > > fix things they find broken. > > And when they're told it's not broken, they just have to suck it? > > I'm not defending ESR here though. Legal issues are pretty much > impossible to fix technically. > > > > Fedora is a community project. If the majority of the community isn't griping > > about something, I doubt a few here and there will make a difference. > > The majority of the community does not care either way. Which is true > of pretty much any issue, the caring minority just changing. If you > feel like driving people out just because they're a minority is not a > problem you won't have much of a majority left after a while. > > > > If someone wants to sit there and bitch about things and expect someone else > > to go fix them all the time, they can kindly move the fuck on. Now, if they > > want to actually contribute, that is the attitude we want. And that is a great > > attitude for the future of Fedora. > > I'd be happy to patch anaconda to have "everything" again. I'm > probably going to in practice. I will submit the patch if you want, > but I know it will be rejected, so what's the point? Ok ... look at it this way. You want an Everything install that you are going to do on 200 desktops. That sounds like a job for kickstart. So my plan of action would be to use system-config-kickstart, create a kickstart with the packages I wanted (all languages and %everything or a glob) and then either kickstart the boxes from the network or create a boot cdrom that has as its default action to run your laboratories Fedora Core 5 install. That way you can also add in any packages that FC5 does not ship with or point stuff to extras etc. -- Stephen J Smoogen. CSIRT/Linux System Administrator From jwboyer at jdub.homelinux.org Wed Apr 12 17:44:47 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 12 Apr 2006 12:44:47 -0500 Subject: Caring about users In-Reply-To: <20060412173633.GB2795@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> <20060412172055.GA12112@yoda.jdub.homelinux.org> <20060412173633.GB2795@dspnet.fr.eu.org> Message-ID: <20060412174447.GB12112@yoda.jdub.homelinux.org> On Wed, Apr 12, 2006 at 07:36:33PM +0200, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 12:20:55PM -0500, Josh Boyer wrote: > > We like the ones that read the archives, present an opinion, debate it, and > > realize at the end of the day some things aren't going to go they way they > > want them and some are. We especially like the ones that present patches to > > fix things they find broken. > > And when they're told it's not broken, they just have to suck it? > > I'm not defending ESR here though. Legal issues are pretty much > impossible to fix technically. Effectively, yes. That is where the "end of the day" part comes in. > > Fedora is a community project. If the majority of the community isn't griping > > about something, I doubt a few here and there will make a difference. > > The majority of the community does not care either way. Which is true > of pretty much any issue, the caring minority just changing. If you > feel like driving people out just because they're a minority is not a > problem you won't have much of a majority left after a while. I just said I doubt a few will make a difference. That doesn't mean they can't. > > If someone wants to sit there and bitch about things and expect someone else > > to go fix them all the time, they can kindly move the fuck on. Now, if they > > want to actually contribute, that is the attitude we want. And that is a great > > attitude for the future of Fedora. > > I'd be happy to patch anaconda to have "everything" again. I'm > probably going to in practice. I will submit the patch if you want, > but I know it will be rejected, so what's the point? The point is that you can open a bug for an RFE, and attach the patch there. If it gets accepted, great! If it's not something suitable to include in Core itself, at least the patch is in the bug. Other people looking for the same thing can find it and use it. Don't ever assume that sumbitting a patch isn't worth it. If that was the case nothing would ever get fixed. josh From lamont at gurulabs.com Wed Apr 12 17:45:24 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 11:45:24 -0600 Subject: Why Notes is either love it or hate it (Re: Move Evolution to Extras?) In-Reply-To: <1144854968.6382.176.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060412150419.GB30579@devserv.devel.redhat.com> <1144854968.6382.176.camel@dimi> Message-ID: <200604121145.24503.lamont@gurulabs.com> On Wednesday 12 April 2006 09:16am, Dimi Paun wrote: > On Wed, 2006-04-12 at 11:04 -0400, Bill Nottingham wrote: > > You know, I've heard all the complaints mentioned in this thread.... > > I don't even *use* Evo, and I'd still prefer it to Notes. :) > > Hear, hear. > > Folks, if you get excited about Notes, you didn't use it. > Or you're just trying to sabotage Fedora :) > > It's so bad it's not even funny. Lets not even think about > it, please. I've seen a few different organizations over the years that are using Notes. In some, everyone loves it; in others, everyone hates it. In my observations, it was clear that those who hated it just used it as a calendar and email client; they never use Notes for what Notes is designed. Those who love it, use the databases and so forth. Their use of Notes includes integrated use of most of it's capabilities. In these cases, they don't seem to feel overwhelmed either, as they use Notes the way it was designed to operate. No matter which side of this fence you find yourself on, it's clear to me that Notes is a very different kind of application. I think it has great value to many people and organizations. I would love to see a native Linux Notes client (Domino has run on Linux for years) and it would be 10 times better if that was open source. However, I don't think that Notes and Evolution quite fit into the same category. Therefore, I don't think Notes is a viable candidate in this thread. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From jkeating at j2solutions.net Wed Apr 12 17:46:10 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 12 Apr 2006 13:46:10 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412172912.GA2795@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> Message-ID: <1144863971.8994.4.camel@ender> On Wed, 2006-04-12 at 19:29 +0200, Olivier Galibert wrote: > Personally, yes. The lab has people coming and going from everywhere > in the world, and half of the people I work with did studies in > linguistics. And most of the research we do has "multilingual-able" > as a requirement. > Thank you for proving my point. Your everything includes languages, another user's everything does not. So, really, instead of playing symatics with what "everything" should mean to every user, we just let them select the packages they want and be done with hit. We give kickstart the ability to use globs. Problem solved. Gets even more fun when Extras is involved, or other repos. Then is it everything in the repo, everything in these repos, everything in these repos minus languages, so on and so forth. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Wed Apr 12 17:46:10 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Apr 2006 13:46:10 -0400 Subject: Move Evolution to Extras? In-Reply-To: <200604121122.14148.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> Message-ID: <1144863971.2645.80.camel@shinybook.infradead.org> On Wed, 2006-04-12 at 11:22 -0600, Lamont R. Peterson wrote: > > And why is evolution unmaintained? I mean it seems to be important > > enough that expensive commercial Linux distributions like RHEL use it as > > a default email client. > > I'm wondering the same thing. I see some indications that there is still an > active (though the pulse is weak?) upstream. What happened to those > Evolution authors/developers/maintainers? Evolution is unmaintained within Red Hat because we haven't managed to fill the open position for a maintainer. Upstream, there _is_ active development; it's just that it doesn't always seem to be _improvement_. There's been a change of guard recently, but that's not a bad thing. The new guys seem a _lot_ saner. -- dwmw2 From galibert at pobox.com Wed Apr 12 18:04:14 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 12 Apr 2006 20:04:14 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144863971.8994.4.camel@ender> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> <1144863971.8994.4.camel@ender> Message-ID: <20060412180414.GA5007@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 01:46:10PM -0400, Jesse Keating wrote: > Thank you for proving my point. Your everything includes languages, > another user's everything does not. So, really, instead of playing > symatics with what "everything" should mean to every user, we just let > them select the packages they want and be done with hit. No, you don't. If your user wants most things but remove some parts of it, be it languages or anything else, he can't. Well, he can, if he's ready to click his way through all of the lists, sublists and subsublists and select them one by one. And he has to be careful to never unselect the reselect a tree because that resets to the default sub-selection. "Select good default" isn't a bad thing, but "Select all" and "Select none" are needed to avoid frothing users going mad at you. At this point, installing is a lottery as to whether the applications you need will be there, because no sane human has the attention span to check every little submenu. Install everything was a way to win this lottery by throwing money, i.e. hard drive space, at it. You can always remove things afterwards, you don't need a media or a network connection for that. Or, with current hard drive sizes, just leave it that way and just don't start or configure what you don't need at a particular point in time. > We give kickstart the ability to use globs. Problem solved. So the only way to do real package selection or ensure that you won't have to move around with a bag of cds is to drop anaconda and use kickstart instead. Interesting. > Gets even more fun when Extras is involved, or other repos. Then is it > everything in the repo, everything in these repos, everything in these > repos minus languages, so on and so forth. Stop thinking blindly about "everything", and think about it in terms of "select all, user can deselect parts afterwards". OG. From theaton at lanl.gov Wed Apr 12 18:09:51 2006 From: theaton at lanl.gov (Tony Heaton) Date: Wed, 12 Apr 2006 12:09:51 -0600 Subject: Where is my "everything" gone? In-Reply-To: <20060412161702.GA94772@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> Message-ID: <1144865391.11528.69.camel@mlor> On Wed, 2006-04-12 at 18:17 +0200, Olivier Galibert wrote: > When was it decided that computer farms, servers and remote > administration was unimportant, and only the desktop user was > interesting? Is it official, or just de facto? > > OG. > How does not having an everything install translate to server farms etc. being unimportant. I have over 300 machines that I manage and I've never used an everything install. None of the system administrators that I work with or talk to on a regular basis use an everything install. This is a broad statement, but I don't imagine the majority of system administrators would consider an everything install as best practice. An everything install is inherently less secure. The system administrators that I work with that use FC/RH use kickstart and Cfengine. The ones that use Debian, use preseeds and Cfegine. By no means am I saying that this way is correct or the only way. It is at least in my world the best practice and has been shown here to be more secure out of the box. Your everything is not the next guys everything. Can you guarantee that everything contains the same subset of packages from release to release? I can guarantee that I install the same subset of packages from release to release and therefore know what is on my machines and I'm not surprised by something that might change in everything. However, I also feel that there should be some easy way of sharing a selections list. These lists would be submitted by users and be a subset of packages that they use for a certain task. This could include several examples of "everything" that others use as well as all the way down to minimal. This way if a user didn't want to take the time to pick and choose the packages they wanted they could just grab a list and apply it to an install. This work in the normal install method as well as the kickstart method. -- Tony Heaton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Wed Apr 12 18:14:24 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 12 Apr 2006 14:14:24 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412180414.GA5007@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> <1144863971.8994.4.camel@ender> <20060412180414.GA5007@dspnet.fr.eu.org> Message-ID: <1144865664.8994.9.camel@ender> On Wed, 2006-04-12 at 20:04 +0200, Olivier Galibert wrote: > At this point, installing is a lottery as to whether the applications > you need will be there, because no sane human has the attention span > to check every little submenu. Install everything was a way to win > this lottery by throwing money, i.e. hard drive space, at it. You can > always remove things afterwards, you don't need a media or a network > connection for that. Or, with current hard drive sizes, just leave it > that way and just don't start or configure what you don't need at a > particular point in time. Fresh users enjoy looking through the menus to see what all is there. I do it from time to time to see if there is anything new. Don't speak for all users. > > > We give kickstart the ability to use globs. Problem solved. > > So the only way to do real package selection or ensure that you won't > have to move around with a bag of cds is to drop anaconda and use > kickstart instead. Interesting. > Kickstart users anaconda. Kickstart is really a scripting method to anaconda installs. So no, we're not dropping anaconda, we're scripting it. For your environment, it makes TOTAL sense to use kickstart, and I'm shocked that you're not. Reproducable automated installs that are very fast and have pre install script and post install script support for doing last mile configurations. How could you possibly not see this as a time saving feature? You can even plug into network booting systems so that you can do this all w/out touching a single bit of media. > > Gets even more fun when Extras is involved, or other repos. Then is > it > > everything in the repo, everything in these repos, everything in > these > > repos minus languages, so on and so forth. > > Stop thinking blindly about "everything", and think about it in terms > of "select all, user can deselect parts afterwards". So if you want to talk about select all or deselect all options when doing package selections, that's a valid discussion. Not enough time to get it into FC5 given the rewrite of the underlying system, however we could look at this for FC6. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Apr 12 18:13:46 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 12 Apr 2006 13:13:46 -0500 Subject: Move Evolution to Extras? In-Reply-To: <200604121122.14148.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> Message-ID: <443D435A.9020905@haxxed.com> Lamont R. Peterson wrote: > Well, if you put that many specific requirements into pot, then of course > you're going to be right. If you drop just GNOME from "Gnome > email+calendar+addressbook+task management", then there are options. If you > take out all the +s, then you can find individual GNOME apps that > collectively provide all those capabilities, albeit not in a tightly > integrated fashion. If there are individual Gnome apps that provide these things, I am unaware of them. Please share! I'd gladly dump Evo for something(s) better, but I have yet to see anything with equivalent functionality. Evolution's monolithic nature is very un-unixlike, even Mozilla has been splitting things out. However the last thing we (Or I, at any rate) want to do is lose this: http://actsofvolition.com/archives/2004/july/simpledesktop From pnasrat at redhat.com Wed Apr 12 18:22:16 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 12 Apr 2006 14:22:16 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412165055.GA97334@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412162820.GA642@devserv.devel.redhat.com> <20060412165055.GA97334@dspnet.fr.eu.org> Message-ID: <1144866136.29397.20.camel@enki.eridu> On Wed, 2006-04-12 at 18:50 +0200, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 12:28:20PM -0400, Alan Cox wrote: > > On Wed, Apr 12, 2006 at 06:17:02PM +0200, Olivier Galibert wrote: > > > When was it decided that computer farms, servers and remote > > > administration was unimportant, and only the desktop user was > > > interesting? Is it official, or just de facto? > > > > Kickstart is specifically dessigned to handle these cases. You can script > > the entire install and do the install "hands-off" > > I remember looking at kickstart a long time ago, and it sucked > horribly when you didn't want to script the _entire_ install. > Hopefully, it is better now. Kickstart has for the longest time prompted you for information not contained with in the ks.cfg. Please define when you looked and what you tried more clearly so we can assist you. Statements like "it sucked" really aren't useful for pointing out potential solutions using kickstart. Paul From pnasrat at redhat.com Wed Apr 12 18:25:11 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 12 Apr 2006 14:25:11 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412193714.A18434@xos037.xos.nl> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412192507.A18336@xos037.xos.nl> <1144862991.8994.1.camel@ender> <20060412193714.A18434@xos037.xos.nl> Message-ID: <1144866312.29397.23.camel@enki.eridu> On Wed, 2006-04-12 at 19:37 +0200, Jos Vos wrote: > On Wed, Apr 12, 2006 at 01:29:51PM -0400, Jesse Keating wrote: > > > No, not all languages are installed, nor fonts for all languages. And > > So, the *commented out* line (as in RHEL4 Anaconda): > > # rpm.addMacro("_install_langs", shortLinguas) > > is not commented out anymore (sorry, have no FC5 sources here now) > or is replaced by some other code? That's not the language stuff we're discussing here - more the actual language groups that weren't installed in "everything" install. Paul From fedora at adrianoneill.com Wed Apr 12 18:34:08 2006 From: fedora at adrianoneill.com (Adrian O'Neill) Date: Wed, 12 Apr 2006 19:34:08 +0100 Subject: (no subject) Message-ID: <443D4820.9060708@adrianoneill.com> From lamont at gurulabs.com Wed Apr 12 18:44:29 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 12:44:29 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144863435.6382.186.camel@dimi> References: <1144155199.2808.94.camel@dimi> <200604121032.26913.lamont@gurulabs.com> <1144863435.6382.186.camel@dimi> Message-ID: <200604121244.33863.lamont@gurulabs.com> On Wednesday 12 April 2006 11:37am, Dimi Paun wrote: > On Wed, 2006-04-12 at 10:32 -0600, Lamont R. Peterson wrote: > > And you don't have to. You can run KMail and/or Kontact on GNOME > > without installing the whole environment. You only need a couple of > > libs. > > You are missing the point. No, I understand your viewpoint. Apparently, you did not understand mine ... go back and read my entire post. it looks like you replied without reading all of it. > Starting any KDE app loads a lot of sh*t > in memory that need not be there. If I'm using only apps from one > environment, they share the same infrastructure (including libs loaded > in memory). It would be insane to go to a default where *both* > KDE and GNOME need to be loaded in order to do anything useful in GNOME. Yup. That's what I said, only I didn't (and wouldn't) use the word "insane". IMO, it's not that insane to _run_ GNOME and KDE apps side by side on top of either KDE or GNOME. Yes, there are more libs loaded into memory, but have you looked to see how much RAM is actually being used in that case? It's not *that* much. However, I agree it's not a good idea to force all users to install both GNOME and KDE desktop environments. But to run KDE and GNOME apps on top of each other doesn't require you to install the whole of both desktop environments. In fact, it only requires a very few libs. If you had read my entire post, you would have seen that's what I was saying. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lamont at gurulabs.com Wed Apr 12 18:46:13 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 12:46:13 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144862870.10620.58.camel@golem.boston.redhat.com> References: <1144155199.2808.94.camel@dimi> <200604121122.14148.lamont@gurulabs.com> <1144862870.10620.58.camel@golem.boston.redhat.com> Message-ID: <200604121246.13794.lamont@gurulabs.com> On Wednesday 12 April 2006 11:27am, Matthias Clasen wrote: > On Wed, 2006-04-12 at 11:22 -0600, Lamont R. Peterson wrote: > > > And why is evolution unmaintained? I mean it seems to be important > > > enough that expensive commercial Linux distributions like RHEL use it > > > as a default email client. > > > > I'm wondering the same thing. I see some indications that there is still > > an active (though the pulse is weak?) upstream. What happened to those > > Evolution authors/developers/maintainers? > > Don't confuse some people voicing their personal frustration with > evolution with factual information. Instead, go to > > > http://mail.gnome.org/archives/evolution-patches/ or > http://mail.gnome.org/archives/evolution-hackers/ Thanks. That's what I meant, I wanted some facts ... not just perceptions. > and watch the upstream development, or better yet, help out. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From andy at warmcat.com Wed Apr 12 18:53:43 2006 From: andy at warmcat.com (Andy Green) Date: Wed, 12 Apr 2006 19:53:43 +0100 Subject: Co-opt or illegally annex? In-Reply-To: <20060412164255.GA19877@thyrsus.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> Message-ID: <443D4CB7.6070604@warmcat.com> Eric S. Raymond wrote: > Olivier Galibert : >> When was it decided that computer farms, servers and remote >> administration was unimportant, and only the desktop user was >> interesting? Is it official, or just de facto? > > Heh. If most fedora-devel list members actually thought "only the > desktop user was interesting", the thread about co-opting proprietary > codecs would have gone rather differently. Um.. what does "co-opting proprietary codecs" mean? You either agree not to redistribute and pay up (like this: http://www.linspire.com/lindows_products_details.php?product_id=11804 ) or you use unlicensed contraband. Maybe you should look at Linspire instead - seriously - so you can use their existing paid-for proprietary codecs to make the distro you think you want without geting legal trouble. Fedora is by definition not up for that game. > I conclude that most of this list doesn't think *any* class of users is > interesting. I think there is still a pretty strong membrane between folks inside RHAT and outside, I suppose this has to be to some extent. It would have been nice to get a chance to argue the busybox case for RHAT's OLPC work which is happening off the public radar AFAICT. > That's not an attitude that bodes well for the future. This general FUD ignores that whatever RHAT's attitude it has certainly done fine and generous work in the past with no sign of it reducing in strength. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From jon.nettleton at gmail.com Wed Apr 12 18:46:48 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 12 Apr 2006 14:46:48 -0400 Subject: (no subject) In-Reply-To: <443D4820.9060708@adrianoneill.com> References: <443D4820.9060708@adrianoneill.com> Message-ID: <1144867609.2303.12.camel@averatec> >On Wed, 2006-04-12 at 19:34 +0100, Adrian O'Neill wrote: > I think this has been the most constructive post on the development list today. Jon From jos at xos.nl Wed Apr 12 19:00:49 2006 From: jos at xos.nl (Jos Vos) Date: Wed, 12 Apr 2006 21:00:49 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144866312.29397.23.camel@enki.eridu>; from pnasrat@redhat.com on Wed, Apr 12, 2006 at 02:25:11PM -0400 References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412192507.A18336@xos037.xos.nl> <1144862991.8994.1.camel@ender> <20060412193714.A18434@xos037.xos.nl> <1144866312.29397.23.camel@enki.eridu> Message-ID: <20060412210049.A18476@xos037.xos.nl> On Wed, Apr 12, 2006 at 02:25:11PM -0400, Paul Nasrat wrote: > That's not the language stuff we're discussing here - more the actual > language groups that weren't installed in "everything" install. That's why I had added the comment "(This does not apply to language- specific packages, IIRC, but to language-specific files in a package.)" -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From n0dalus+redhat at gmail.com Wed Apr 12 19:06:14 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 13 Apr 2006 04:36:14 +0930 Subject: Where is my "everything" gone? In-Reply-To: <1144865664.8994.9.camel@ender> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> <1144863971.8994.4.camel@ender> <20060412180414.GA5007@dspnet.fr.eu.org> <1144865664.8994.9.camel@ender> Message-ID: <6280325c0604121206j722499ci1951b25c031e3f5@mail.gmail.com> On 4/13/06, Jesse Keating wrote: > On Wed, 2006-04-12 at 20:04 +0200, Olivier Galibert wrote: > > At this point, installing is a lottery as to whether the applications > > you need will be there, because no sane human has the attention span > > to check every little submenu. Install everything was a way to win > > this lottery by throwing money, i.e. hard drive space, at it. You can > > always remove things afterwards, you don't need a media or a network > > connection for that. Or, with current hard drive sizes, just leave it > > that way and just don't start or configure what you don't need at a > > particular point in time. > > Fresh users enjoy looking through the menus to see what all is there. I > do it from time to time to see if there is anything new. Don't speak > for all users. > I agree, but this doesn't mean that a 'select all/none' button is a terrible feature. n0dalus. From dimi at lattica.com Wed Apr 12 19:18:40 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 15:18:40 -0400 Subject: Move Evolution to Extras? In-Reply-To: <200604121244.33863.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <200604121032.26913.lamont@gurulabs.com> <1144863435.6382.186.camel@dimi> <200604121244.33863.lamont@gurulabs.com> Message-ID: <1144869520.6382.191.camel@dimi> On Wed, 2006-04-12 at 12:44 -0600, Lamont R. Peterson wrote: > However, I agree it's not a good idea to force all users to install > both GNOME and KDE desktop environments. Right. I think we agree (yes, I have read your entire post, sorry if that wasn't clear from my response). Indeed, I sometimes run apps from both desktops side-by-side (k3b comes to mind), and that's just fine. But I don't want to be forced to do that by default to get basic functionality out of my desktop. It's a big difference between the two use cases. -- Dimi Paun Lattica, Inc. From mailinglists at erwinrol.com Wed Apr 12 19:24:19 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 12 Apr 2006 21:24:19 +0200 Subject: Move Evolution to Extras? In-Reply-To: <200604121122.14148.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> Message-ID: <1144869860.12092.194.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 11:22 -0600, Lamont R. Peterson wrote: > Well, if you put that many specific requirements into pot, then of course > you're going to be right. If you drop just GNOME from "Gnome > email+calendar+addressbook+task management", then there are options. If you drop Linux I am sure you can use outlook. I use a Gnome desktop and no matter how ppl keep repeating the "you can use KDE apps" it does not work. Using KDE apps on a Gnome Desktop is like using a wine outlook on a Linux desktop, it works but there are zillion little things like cut and paste, default file browser, default web browser, system settings etc. that all are different. Using KDE apps in a Gnome desktop is just no option. > If you take out all the +s, then you can find individual GNOME apps that > collectively provide all those capabilities, albeit not in a tightly > integrated fashion. Can you please name the Gnome apps that offer all the functionality that Evolution offers ? > So, here's a suggestion: Take the best individual GNOME apps and glue them > together, ala` Kontact. It would be quick (relatively speaking) to do and > would give people who will only consider GNOME apps choice (and therefore, > freedom) again; something they have not had in a while, as you so aptly > pointed out. If those Apps existed it would be no problem, the thing is there is no 100% Gnome replacement for the functionality that Evolution offers. Also when you are connected to some sort of groupware system, it might be problematic when you have 4 or 5 completely separate applications, because they all will need a connection to the groupware server. - Erwin From katzj at redhat.com Wed Apr 12 19:31:15 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Apr 2006 15:31:15 -0400 Subject: Where is my "everything" gone? In-Reply-To: <6280325c0604121206j722499ci1951b25c031e3f5@mail.gmail.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> <1144863971.8994.4.camel@ender> <20060412180414.GA5007@dspnet.fr.eu.org> <1144865664.8994.9.camel@ender> <6280325c0604121206j722499ci1951b25c031e3f5@mail.gmail.com> Message-ID: <1144870275.3807.10.camel@aglarond.local> On Thu, 2006-04-13 at 04:36 +0930, n0dalus wrote: > On 4/13/06, Jesse Keating wrote: > > On Wed, 2006-04-12 at 20:04 +0200, Olivier Galibert wrote: > > > At this point, installing is a lottery as to whether the applications > > > you need will be there, because no sane human has the attention span > > > to check every little submenu. Install everything was a way to win > > > this lottery by throwing money, i.e. hard drive space, at it. You can > > > always remove things afterwards, you don't need a media or a network > > > connection for that. Or, with current hard drive sizes, just leave it > > > that way and just don't start or configure what you don't need at a > > > particular point in time. > > > > Fresh users enjoy looking through the menus to see what all is there. I > > do it from time to time to see if there is anything new. Don't speak > > for all users. > > > I agree, but this doesn't mean that a 'select all/none' button is a > terrible feature. What if, instead of a button, the lists allowed multi-selection and you can then select more at a time? (Note that you can already select all the optional packages in a group by right clicking and saying "select all optional packages") Jeremy From remco at rvt.com Wed Apr 12 19:47:22 2006 From: remco at rvt.com (Remco Treffkorn) Date: Wed, 12 Apr 2006 12:47:22 -0700 Subject: Where is my "everything" gone? In-Reply-To: <20060412172912.GA2795@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> Message-ID: <200604121247.22680.remco@rvt.com> Because it has been suggested a few times here, I looked at Kickstart. More specific: system-config-kickstart. This is basically a way to define your custom "everything" button. Very powerfull, and very simple. With this alternative, I can see why taking away the "everything" button is not a big deal. This is a more flexible replacement. Cheers, Remco On Wednesday 12 April 2006 10:29, Olivier Galibert wrote: > On Wed, Apr 12, 2006 at 01:14:14PM -0400, Jesse Keating wrote: > > On Wed, 2006-04-12 at 18:35 +0200, Jos Vos wrote: > > > "everything on the standard CD set" > > > > Do you really want every language installed on your system? > > Personally, yes. The lab has people coming and going from everywhere > in the world, and half of the people I work with did studies in > linguistics. And most of the research we do has "multilingual-able" > as a requirement. > > OG. -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From sopwith at redhat.com Wed Apr 12 19:52:05 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 12 Apr 2006 15:52:05 -0400 (EDT) Subject: CVS system migration done In-Reply-To: <442873EC.1050702@GreenKey.net> References: <442873EC.1050702@GreenKey.net> Message-ID: On Mon, 27 Mar 2006, Curtis Doty wrote: > Elliot Lee wrote: > > Hi all, > > > > cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to a > > new system. Please let me know if there are any problems that need > > fixing... > > > 404 http://cvs.fedora.redhat.com/webfiles/ > > That was awhile ago. Right this instant I'm getting timeouts, though. Hey guys, just wanted to let you know that this is up and working again now for extras & core... Best, -- Elliot From dcantrell at redhat.com Wed Apr 12 19:54:38 2006 From: dcantrell at redhat.com (David Cantrell) Date: Wed, 12 Apr 2006 15:54:38 -0400 Subject: (no subject) In-Reply-To: <1144867609.2303.12.camel@averatec> References: <443D4820.9060708@adrianoneill.com> <1144867609.2303.12.camel@averatec> Message-ID: <20060412195438.GB3172@mortise.boston.redhat.com> Jon Nettleton wrote: > >On Wed, 2006-04-12 at 19:34 +0100, Adrian O'Neill wrote: > > > > I think this has been the most constructive post on the development list > today. Maybe he was referring to the absence of the Everything install option. Or the absence of MP3 support. (fan fan fan) -- David Cantrell Red Hat / Westford, MA From dimi at lattica.com Wed Apr 12 20:37:15 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 12 Apr 2006 16:37:15 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144857491.2645.73.camel@shinybook.infradead.org> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> Message-ID: <1144874235.6382.212.camel@dimi> On Wed, 2006-04-12 at 11:58 -0400, David Woodhouse wrote: > If my opinion counted for anything we wouldn't have dropped our most > capable and easy to use MTA just before FC4. Hey, I just said it counts more than mine, not that's absolute :) BTW, is that exim? What's wrong with postfix? > We do need to have a serious discussion about what we're going to do > with/about Evolution though... which is what seems to be happening. Not sure we are having a serious discussion. A lot of ranting, not a single serious proposal. The more we talk about it, the more it seems that the only reasonable thing to do is for RH to get someone on Evo. -- Dimi Paun Lattica, Inc. From dwmw2 at infradead.org Wed Apr 12 21:12:08 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Apr 2006 17:12:08 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144874235.6382.212.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> <1144874235.6382.212.camel@dimi> Message-ID: <1144876329.2697.4.camel@shinybook.infradead.org> On Wed, 2006-04-12 at 16:37 -0400, Dimi Paun wrote: > On Wed, 2006-04-12 at 11:58 -0400, David Woodhouse wrote: > > If my opinion counted for anything we wouldn't have dropped our most > > capable and easy to use MTA just before FC4. > > Hey, I just said it counts more than mine, not that's absolute :) > BTW, is that exim? What's wrong with postfix? There's nothing _wrong_ with it per se -- it's just that it can't do half the things my Exim setup does with Exim out of the box. I did post a brief overview of my Exim setup at the time, asking how I'd go about doing it all in postfix. Most of the postfix people just went quiet, except for the one who said "Oh. I think I'll switch to Exim myself." :) > Not sure we are having a serious discussion. A lot of ranting, not > a single serious proposal. The more we talk about it, the more it seems > that the only reasonable thing to do is for RH to get someone on Evo. Underlining that need is not necessarily unproductive. -- dwmw2 From stickster at gmail.com Wed Apr 12 21:17:37 2006 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 12 Apr 2006 17:17:37 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060412180414.GA5007@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412183530.G16253@xos037.xos.nl> <1144862054.18861.179.camel@ender> <20060412172912.GA2795@dspnet.fr.eu.org> <1144863971.8994.4.camel@ender> <20060412180414.GA5007@dspnet.fr.eu.org> Message-ID: <1144876657.816.23.camel@localhost.localdomain> On Wed, 2006-04-12 at 20:04 +0200, Olivier Galibert wrote: > At this point, installing is a lottery as to whether the applications > you need will be there, because no sane human has the attention span > to check every little submenu. Install everything was a way to win > this lottery by throwing money, i.e. hard drive space, at it. You can > always remove things afterwards, you don't need a media or a network > connection for that. Or, with current hard drive sizes, just leave it > that way and just don't start or configure what you don't need at a > particular point in time. It seems to me that installing everything was mostly used as a way to avoid what folks used to call "RPM dependency hell" (although frankly, if you knew how to use RPM macros and a mirror, that was less a problem than it was made out to be). Now that we have yum, this is not a problem. You don't have to play the lottery at all; you can actually select what the user really wants. If the software which the users are asking for "every other day" is somewhat predictable, you don't even have to use "*" as your glob for package installation. > > We give kickstart the ability to use globs. Problem solved. > > So the only way to do real package selection or ensure that you won't > have to move around with a bag of cds is to drop anaconda and use > kickstart instead. Interesting. It's not a "drop this/use that instead" proposition. Kickstart is a method of anaconda, which allows you to do things in an automated fashion. I'm confused; I thought you knew about kickstart already. The only sane way to handle package selection IMHO is to class your systems/users in some logical fashion and do kickstart installations. If that class is to install "*", so be it. As someone who kept up with several classrooms full of workstations and servers, and a laboratory full of individual users, I don't see how you would want to do installations any other way. > > Gets even more fun when Extras is involved, or other repos. Then is it > > everything in the repo, everything in these repos, everything in these > > repos minus languages, so on and so forth. > > Stop thinking blindly about "everything", and think about it in terms > of "select all, user can deselect parts afterwards". Again, people have proffered the obvious, easy, well-supported, sane, and low-maintenance solution in kickstart. Sitting down at every (or *any*) station and clicking your way through an installation when you don't have to is just wasting valuable time. This is not to say that the multi-select button is wasteful either. But if you're looking to save time on administering "200+" systems, check out kickstart, like, yesterday. Cheers. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From michael.favia at insitesinc.com Wed Apr 12 20:48:24 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 12 Apr 2006 15:48:24 -0500 Subject: This is a development discussion list. Message-ID: <443D6798.7090402@insitesinc.com> While i recognize that many subscribers may feel that their tangential concerns and ideas are worthy of discussion on such a list i was under the impression that this was a "just the facts" type of list that concerned itself with the current actual development of the distribution. I dont blame them for posting their issues here though because they have no other official outlet for discussion. This extra noise, though well intentioned, is making it difficult for me (and i imagine many others) to justify the time necessary to weed out the "philosophical type" posts. And while i frown on the creation of yet another fedora list, perhaps the creation of a "sounder" style list would allow the discussion on the list to revert to a more focused state? I do think that the philosophical discussions are beneficial to the evolution of fedora as a distribution i just dont think that it relates to the actual development concerns any more then desktop or docs do (i.e. they have lists). Maybe im the only one with these issues but i have been considering unsubscribing from the list as a result of shear number of the OT discussions and wanted to know if others felt the same. So, any votes for a "fedora-socrates" list :)? -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From monakhos at gmail.com Wed Apr 12 21:50:30 2006 From: monakhos at gmail.com (Michael Young) Date: Wed, 12 Apr 2006 15:50:30 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144874235.6382.212.camel@dimi> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> <1144874235.6382.212.camel@dimi> Message-ID: On 4/12/06, Dimi Paun wrote: > > > Not sure we are having a serious discussion. A lot of ranting, not > a single serious proposal. The more we talk about it, the more it seems > that the only reasonable thing to do is for RH to get someone on Evo. Ok, here's a proposal. Someone with some influence talk to the Open Office folks, and ask them to adopt the Evo code, weave their magic on it, and roll it up with the rest of the OO.o stuff. Seems to me, an MUA is all thats missing from OO. That is all.. carry on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nomis80 at nomis80.org Wed Apr 12 21:52:34 2006 From: nomis80 at nomis80.org (Simon Perreault) Date: Wed, 12 Apr 2006 17:52:34 -0400 Subject: This is a development discussion list. In-Reply-To: <443D6798.7090402@insitesinc.com> References: <443D6798.7090402@insitesinc.com> Message-ID: <443D76A2.30801@nomis80.org> Michael Favia wrote: > This extra noise, though well intentioned, is making it difficult for > me (and i imagine many others) to justify the time necessary to weed > out the "philosophical type" posts. You need to learn about a magical feature named "Mark Thread as Read" that most of us have been using all along... Keep the flames burning, there are still some patches of snow around here... From david at lovesunix.net Wed Apr 12 22:20:45 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 13 Apr 2006 00:20:45 +0200 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> <1144874235.6382.212.camel@dimi> Message-ID: <1144880445.19844.17.camel@localhost.localdomain> ons, 12 04 2006 kl. 15:50 -0600, skrev Michael Young: > On 4/12/06, Dimi Paun wrote: > > Not sure we are having a serious discussion. A lot of ranting, > not > a single serious proposal. The more we talk about it, the more > it seems > that the only reasonable thing to do is for RH to get someone > on Evo. > > Ok, here's a proposal. Someone with some influence talk to the Open > Office folks, and ask them to adopt the Evo code, weave their magic on > it, and roll it up with the rest of the OO.o stuff. Seems to me, an > MUA is all thats missing from OO. > > That is all.. carry on. No.. just no - I beg you My brain nearly exploded when I read that to be honest, OpenOffice is maybe the single product I hate more than Evolution combining them would be so terrifying that even almighty Cthultu would be impressed with the evil act. I still favor a best of breed application approach with integration via evolution-data-server or a similar solution. We already have some components to work on: Contacts: http://chrislord.net/blog/Software/Contacts/ Dates: http://chrislord.net/blog/Software/Dates/ TinyMail: https://svn.cronos.be/svn/tinymail/trunk/ Hopefully that opens for the possibility of replacing Evolution down the road. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From kevin.kofler at chello.at Wed Apr 12 22:23:33 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 12 Apr 2006 22:23:33 +0000 (UTC) Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> <1144869860.12092.194.camel@xpc.home.erwinrol.com> Message-ID: > If you drop Linux I am sure you can use outlook. I use a Gnome desktop > and no matter how ppl keep repeating the "you can use KDE apps" it does > not work. Using KDE apps on a Gnome Desktop is like using a wine outlook > on a Linux desktop, it works but there are zillion little things like > cut and paste, Cut&paste is completely compatible between KDE and GNOME apps and has been for a long time now! The Qt clipboard bug where it mixed up PRIMARY (selection) and CLIPBOARD was fixed ages ago. > default file browser, default web browser, Run kcontrol and you can set your file associations. Getting Kontact to run your GNOME applications when you open a file or URL in it is not hard. The default browser for KDE apps is the setting for "text/html". > system settings etc. that all are different. Just set them to the same thing. KDE is very flexible, it's possible to get it to match the GNOME configuration very closely. Kevin Kofler From mailinglists at erwinrol.com Wed Apr 12 22:45:13 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 13 Apr 2006 00:45:13 +0200 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> <1144869860.12092.194.camel@xpc.home.erwinrol.com> Message-ID: <1144881914.12092.202.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 22:23 +0000, Kevin Kofler wrote: > > If you drop Linux I am sure you can use outlook. I use a Gnome desktop > > and no matter how ppl keep repeating the "you can use KDE apps" it does > > not work. Using KDE apps on a Gnome Desktop is like using a wine outlook > > on a Linux desktop, it works but there are zillion little things like > > cut and paste, > > Cut&paste is completely compatible between KDE and GNOME apps and has been for > a long time now! The Qt clipboard bug where it mixed up PRIMARY (selection) and > CLIPBOARD was fixed ages ago. Might just be me, but in kdevelop (the only kde application i use) i always end up screwing cut and paste up, since ctrl-c/v and middle-mouse-button seem to interact at random. > > default file browser, default web browser, > > Run kcontrol and you can set your file associations. Getting Kontact to run > your GNOME applications when you open a file or URL in it is not hard. The > default browser for KDE apps is the setting for "text/html". Why would i have to run kcontrol ? I mean i am using a Gnome desktop, not a KDE one. > > system settings etc. that all are different. > > Just set them to the same thing. KDE is very flexible, it's possible to get it > to match the GNOME configuration very closely. So you are suggesting that everybody will set all settings twice, one time for Gnome and one time for KDE? This is exactly the problem with a Gnome and KDE mix, it is a PITA. - Erwin From dwmw2 at infradead.org Wed Apr 12 22:58:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Apr 2006 18:58:25 -0400 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060412114214.GA28564@devserv.devel.redhat.com> <1144842736.12092.173.camel@xpc.home.erwinrol.com> <200604121122.14148.lamont@gurulabs.com> <1144869860.12092.194.camel@xpc.home.erwinrol.com> Message-ID: <1144882706.2697.18.camel@shinybook.infradead.org> On Wed, 2006-04-12 at 22:23 +0000, Kevin Kofler wrote: > Using KDE apps on a Gnome Desktop is like using a wine outlook > > on a Linux desktop, it works but there are zillion little things like > > cut and paste, > > Cut&paste is completely compatible between KDE and GNOME apps and has been for > a long time now! The Qt clipboard bug where it mixed up PRIMARY (selection) and > CLIPBOARD was fixed ages ago. We were talking about Evolution, so broken cut and paste wouldn't be a regression there anyway -- it's _already_ broken in Evolution. (#145314, filed 2005-01-17, state NEW) -- dwmw2 From michael.favia at insitesinc.com Wed Apr 12 23:02:49 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 12 Apr 2006 18:02:49 -0500 Subject: This is a development discussion list. In-Reply-To: <443D76A2.30801@nomis80.org> References: <443D6798.7090402@insitesinc.com> <443D76A2.30801@nomis80.org> Message-ID: <443D8719.4010804@insitesinc.com> Simon Perreault wrote: > Michael Favia wrote: > >> This extra noise, though well intentioned, is making it difficult for >> me (and i imagine many others) to justify the time necessary to weed >> out the "philosophical type" posts. > > You need to learn about a magical feature named "Mark Thread as Read" > that most of us have been using all along... > > Keep the flames burning, there are still some patches of snow around > here... > My message wasn't intended to be a flame at all. I think that the philosophical and theoretical discussions are good for the distro i just think they should have a proper home because it isnt exactly development discussion related. -mf -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From michael at knox.net.nz Wed Apr 12 23:16:08 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 13 Apr 2006 11:16:08 +1200 Subject: This is a development discussion list. In-Reply-To: <443D8719.4010804@insitesinc.com> References: <443D6798.7090402@insitesinc.com> <443D76A2.30801@nomis80.org> <443D8719.4010804@insitesinc.com> Message-ID: <443D8A38.1080200@knox.net.nz> Michael Favia wrote: > Simon Perreault wrote: >> Michael Favia wrote: >> >>> This extra noise, though well intentioned, is making it difficult for >>> me (and i imagine many others) to justify the time necessary to weed >>> out the "philosophical type" posts. >> >> You need to learn about a magical feature named "Mark Thread as Read" >> that most of us have been using all along... >> >> Keep the flames burning, there are still some patches of snow around >> here... >> > My message wasn't intended to be a flame at all. I think that the > philosophical and theoretical discussions are good for the distro i just > think they should have a proper home because it isnt exactly development > discussion related. -mf > Yes, but theoretical and philosophical discussion often have a place in development discussion.... I think people just need to "tune out" of subjects that they don't want to follow. Michael From jdogalt at yahoo.com Wed Apr 12 23:18:33 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Wed, 12 Apr 2006 16:18:33 -0700 (PDT) Subject: question on kickstart globs/everything Message-ID: <20060412231833.2401.qmail@web38410.mail.mud.yahoo.com> Even though today's messages started out with "@everything has been argued to death in the archives", it seems like the time for comments is still open- I have been a heavy user of (@)everything, (@)minimal, and kickstart for many years. Before throwing my opinions in the ring, I have one simple question- Is the globs(*) for package selection in kickstart documented anywhere (yet)? My question is, is that going to be as sufficiently smart as the old/current-but-deprecated @everything, as far as silently dropping those packages that have exclusional anti-dependencies? (picking the 'preferred default') Even if so (which I could just check by doing an install), I would throw in my opinion as being precisely one of those users that would like to do a non-kickstart everything install, just to have all the available core (on media) packages installed, including a hundred languages I would never use. Because yes, disk space is cheap. Not because I was worried about dependencies. I.e. I was using what the rh/fedora core decision makers decided to decide what I wanted to install. Nothing new here, but FYI, another person like that exists and appreciated the ability to do that (even in the non-kickstart case). It was always fun to do an everything install, and then just sit down in front of a fully populated gnome/redhat main menu and start trying all the new toys, whose package names would never have even clued me in as to what they do. Now, on to @minimal (dunno if that still exists). I used to generate livecd's from mandrake back when their @minimal yielded ~300MB. I was building appliance livecd's that even stripped some more files, getting it compressed down to 135M (fits on a 3" cdr, with X+windowmaker+mozilla+xmms). So @minimal was very useful for me, and as I'm now trying to do the same sorts of things with fedora, I would hope it still exists, though have been psyching up for having to more or less do lots of manual deinstallations as I figure out what packages aren't _really_ necessary (which I had to do anyway with the mandrake @minimal, to _really_ shave the install size down). Of course, now my target is looking more like a 3" 1.8G dvd, but still... I liked @minimal. a lot. I hope it lives. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From peter at thecodergeek.com Thu Apr 13 00:19:57 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 12 Apr 2006 17:19:57 -0700 Subject: This is a development discussion list. In-Reply-To: <443D8719.4010804@insitesinc.com> References: <443D6798.7090402@insitesinc.com> <443D76A2.30801@nomis80.org> <443D8719.4010804@insitesinc.com> Message-ID: <443D992D.60506@thecodergeek.com> Michael Favia wrote: > My message wasn't intended to be a flame at all. I think that the > philosophical and theoretical discussions are good for the distro i just > think they should have a proper home because it isnt exactly development > discussion related. -mf Are you so sure? Discussion about Fedora's philosophy and its direction surely seem like they would be appropriate on a list about its development and said development's reasoning. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From lamont at gurulabs.com Thu Apr 13 00:45:47 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 18:45:47 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144881914.12092.202.camel@xpc.home.erwinrol.com> References: <1144155199.2808.94.camel@dimi> <1144881914.12092.202.camel@xpc.home.erwinrol.com> Message-ID: <200604121845.51879.lamont@gurulabs.com> On Wednesday 12 April 2006 04:45pm, Erwin Rol wrote: > On Wed, 2006-04-12 at 22:23 +0000, Kevin Kofler wrote: > > > If you drop Linux I am sure you can use outlook. I use a Gnome desktop > > > and no matter how ppl keep repeating the "you can use KDE apps" it does > > > not work. Using KDE apps on a Gnome Desktop is like using a wine > > > outlook on a Linux desktop, it works but there are zillion little > > > things like cut and paste, > > > > Cut&paste is completely compatible between KDE and GNOME apps and has > > been for a long time now! The Qt clipboard bug where it mixed up PRIMARY > > (selection) and CLIPBOARD was fixed ages ago. > > Might just be me, but in kdevelop (the only kde application i use) i > always end up screwing cut and paste up, since ctrl-c/v and > middle-mouse-button seem to interact at random. It's not random. If you use +, it copies the item to the clipboard *and* marks that clipboard entry as the "checked" one. Using the mouse to select text does not "check" the entry in the clipboard. Either way, middle-clicking your mouse will paste from the "last mouse selection" unless another clipboard has been activated (i.e. "checked"). This is normal X with multiple clipboards available. GNOME has no mechanism to deal with multiple clipboards in X, but KDE does and uses it by default. klipper lets you manage the multiple clipboards. > > > default file browser, default web browser, > > > > Run kcontrol and you can set your file associations. Getting Kontact to > > run your GNOME applications when you open a file or URL in it is not > > hard. The default browser for KDE apps is the setting for "text/html". > > Why would i have to run kcontrol ? I mean i am using a Gnome desktop, > not a KDE one. kcontrol has lots of knobs and switches. However, you don't need to tweak very many of them at all. In this case, he's talking about changing the file launcher configurations so that you would get Firefox or Mozilla (or whatever) instead of Konqueror when you click a link in an email in Kontact. > > > system settings etc. that all are different. > > > > Just set them to the same thing. KDE is very flexible, it's possible to > > get it to match the GNOME configuration very closely. > > So you are suggesting that everybody will set all settings twice, one > time for Gnome and one time for KDE? This is exactly the problem with a > Gnome and KDE mix, it is a PITA. No, we're not talking about everyone setting all their settings twice. Just tweak the things you want for the apps you want. That's not going to be very much stuff. With KDE, once you've got that figured out, it's pretty easy to mass deploy such configuration changes, too, so you really will only *have* to do this once (unless you change your mind frequently :) ). -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From mailinglists at erwinrol.com Thu Apr 13 01:00:54 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 13 Apr 2006 03:00:54 +0200 Subject: Move Evolution to Extras? In-Reply-To: <200604121845.51879.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <1144881914.12092.202.camel@xpc.home.erwinrol.com> <200604121845.51879.lamont@gurulabs.com> Message-ID: <1144890054.12092.210.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 18:45 -0600, Lamont R. Peterson wrote: > > > > system settings etc. that all are different. > > > > > > Just set them to the same thing. KDE is very flexible, it's possible to > > > get it to match the GNOME configuration very closely. > > > > So you are suggesting that everybody will set all settings twice, one > > time for Gnome and one time for KDE? This is exactly the problem with a > > Gnome and KDE mix, it is a PITA. > > No, we're not talking about everyone setting all their settings twice. Just > tweak the things you want for the apps you want. That's not going to be very > much stuff. With KDE, once you've got that figured out, it's pretty easy to > mass deploy such configuration changes, too, so you really will only *have* > to do this once (unless you change your mind frequently :) ). I still have to deal with two different "configuration" tools, that do about the same thing but a bit different. If i want to tune app K i need the KDE configuration tool, if i need to tune app G i need the gnome configuration tool. When kde apps and gnome apps look exactly like each other (which is an other problem, different look and feel) how do i know that i need kconfig when i want to tune app K? KDE and Gnome are two different things, even though they do almost the same thing. It is like using Honda parts to fix a Fort, a handy mechaninc might make it work, but it would be way easier to use Fort parts to fix a Fort. - Erwin From lamont at gurulabs.com Thu Apr 13 01:07:49 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 19:07:49 -0600 Subject: This is a development discussion list. In-Reply-To: <443D8719.4010804@insitesinc.com> References: <443D6798.7090402@insitesinc.com> <443D76A2.30801@nomis80.org> <443D8719.4010804@insitesinc.com> Message-ID: <200604121907.49886.lamont@gurulabs.com> On Wednesday 12 April 2006 05:02pm, Michael Favia wrote: > Simon Perreault wrote: > > Michael Favia wrote: > >> This extra noise, though well intentioned, is making it difficult for > >> me (and i imagine many others) to justify the time necessary to weed > >> out the "philosophical type" posts. > > > > You need to learn about a magical feature named "Mark Thread as Read" > > that most of us have been using all along... > > > > Keep the flames burning, there are still some patches of snow around > > here... > > My message wasn't intended to be a flame at all. I think that the > philosophical and theoretical discussions are good for the distro i just > think they should have a proper home because it isnt exactly development > discussion related. -mf I think perhaps you are using the word "development" a little too narrowly. To me, the topic of this list being "Development discussions related to Fedora Core" is not limited to writing/hacking code. Developing a distribution is a complex matter. I might even go so far as to suggest that most of the work is *not* found in the code. The conversations that are about code things have obvious place here. Perhaps there could be merit in splitting *all* the other things into another list. However, I feel that the current situation with this list is the correct way for things go. I do not feel that these discussions (including this one :) ) have been OT for this list. There are plenty of threads on here within which I have not read all the posts. As another already pointed out, your MUA should let you flag such threads so that future posts are marked as read. I don't do that, myself. Instead, I glance at most of the messages to be sure something new hasn't come into the conversation that would interest me (this takes like .1 seconds per post, if that, on average). If it does, I read; if it bores me, I move on. I don't have to read every word ever written (not that I'm suggesting that you do or that you suggested such). Personally, I would prefer to not have YAL to subscribe too. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lamont at gurulabs.com Thu Apr 13 01:12:50 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 12 Apr 2006 19:12:50 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1144890054.12092.210.camel@xpc.home.erwinrol.com> References: <1144155199.2808.94.camel@dimi> <200604121845.51879.lamont@gurulabs.com> <1144890054.12092.210.camel@xpc.home.erwinrol.com> Message-ID: <200604121912.50912.lamont@gurulabs.com> On Wednesday 12 April 2006 07:00pm, Erwin Rol wrote: > On Wed, 2006-04-12 at 18:45 -0600, Lamont R. Peterson wrote: [snip] > I still have to deal with two different "configuration" tools, that do > about the same thing but a bit different. If i want to tune app K i need > the KDE configuration tool, if i need to tune app G i need the gnome > configuration tool. When kde apps and gnome apps look exactly like each > other (which is an other problem, different look and feel) how do i know > that i need kconfig when i want to tune app K? KDE and Gnome are two > different things, even though they do almost the same thing. How is that different from normal operations? I have to use the configuration dialog in KMail (Kontact) to configure my email client and the one in Konqueror for that app and the one in Xchat for that app, etc., etc., etc., etc. You *do not have* to use kcontrol every day. I use KDE as my desktop and I only look at kcontrol about once a month because I *want* to change something. It wouldn't even be that frequently if it weren't for the nature of my profession (and of my nature, I'll admit :) ). > It is like > using Honda parts to fix a Fort, a handy mechaninc might make it work, > but it would be way easier to use Fort parts to fix a Fort. Interesting analogy. Of course, I've never driven a Fort, though I've stood on a couple of walls :) . -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From mailinglists at erwinrol.com Thu Apr 13 01:34:01 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 13 Apr 2006 03:34:01 +0200 Subject: Move Evolution to Extras? In-Reply-To: <200604121912.50912.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <200604121845.51879.lamont@gurulabs.com> <1144890054.12092.210.camel@xpc.home.erwinrol.com> <200604121912.50912.lamont@gurulabs.com> Message-ID: <1144892041.12092.215.camel@xpc.home.erwinrol.com> On Wed, 2006-04-12 at 19:12 -0600, Lamont R. Peterson wrote: > > It is like > > using Honda parts to fix a Fort, a handy mechaninc might make it work, > > but it would be way easier to use Fort parts to fix a Fort. > > Interesting analogy. Of course, I've never driven a Fort, though I've stood > on a couple of walls :) . OK that was an interesting repeated typo/thinko :-) But think how hard it would be the fix a castle with Ford parts :-) - Erwin From cmadams at hiwaay.net Thu Apr 13 02:48:27 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 Apr 2006 21:48:27 -0500 Subject: Where is my "everything" gone? In-Reply-To: <20060412155226.GA92603@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> <20060412155226.GA92603@dspnet.fr.eu.org> Message-ID: <20060413024826.GB1024729@hiwaay.net> Once upon a time, Olivier Galibert said: > The exact same thing it meant in fc3, everything in the repository > barring obvious conflicts, which was at the time limited to the kernel > wasn't it? Nope, FC3 "Everything" didn't install every installable package. > Or in other words, as much as possible so that I don't have users > asking for the software they happen to need every other day on the > 200+ systems I have to install semi-automatically. Hard drives are > cheap and I like having time for other things that sysadminning. If you want to take less time, then why are you doing manual installs? Try kickstart. In any case, if you really want everything, "yum install *" after install works IIRC (but be prepared for what you get). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Thu Apr 13 02:53:15 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 Apr 2006 21:53:15 -0500 Subject: Where is my "everything" gone? In-Reply-To: <20060412161702.GA94772@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> Message-ID: <20060413025315.GC1024729@hiwaay.net> Once upon a time, Olivier Galibert said: > The ability to throw them in a nfs install > directory with whatever extra packages you locally need and some > automatic configuration packages was very nice. It will be easier to manage with the new yum-backed installer. You'll be able to pull in external repos at install time in the future, so instead of having to add your packages to the base install image and rebuild the tree, you'll be able to dump your packages in a directory, createrepo, and install. At that point, "Everything" doesn't really make sense. Assuming Fedora Extras is included in the installer, "Everything" would about double. > When was it decided that computer farms, servers and remote > administration was unimportant, and only the desktop user was > interesting? Is it official, or just de facto? Well, most large installations don't like to have to do an OS upgrade (with all the testing etc. that entails) every 6-9 months, so they don't use Fedora. However, for the couple of servers I use it on, it works great (with kickstart installs). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Thu Apr 13 03:45:03 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Apr 2006 23:45:03 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060413024826.GB1024729@hiwaay.net> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> <20060412155226.GA92603@dspnet.fr.eu.org> <20060413024826.GB1024729@hiwaay.net> Message-ID: <20060413034503.GB18164@devserv.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > In any case, if you really want everything, "yum install *" after > install works IIRC (but be prepared for what you get). Heck, '%packages *' works in kickstart. Bill From kevin.kofler at chello.at Thu Apr 13 04:11:47 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 13 Apr 2006 04:11:47 +0000 (UTC) Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <1144881914.12092.202.camel@xpc.home.erwinrol.com> <200604121845.51879.lamont@gurulabs.com> <1144890054.12092.210.camel@xpc.home.erwinrol.com> Message-ID: Erwin Rol erwinrol.com> writes: > (which is an other problem, different look and feel) That's what Bluecurve is for. :-) Kevin Kofler From buildsys at redhat.com Thu Apr 13 07:24:14 2006 From: buildsys at redhat.com (Build System) Date: Thu, 13 Apr 2006 03:24:14 -0400 Subject: rawhide report: 20060413 changes Message-ID: <200604130724.k3D7OEhk024368@porkchop.devel.redhat.com> Updated Packages: gdm-1:2.14.1-4 -------------- * Wed Apr 12 2006 Ray Strode - 1:2.14.1-4 - fix libexecdir substitution problem in configuration file kernel-2.6.16-1.2131_FC6 ------------------------ * Wed Apr 12 2006 David Woodhouse - Add include/{mtd,rdma,keys} directories to kernel-devel package * Tue Apr 11 2006 Dave Jones - 2.6.17rc1-git4 perl-DBD-Pg-1.48-1.FC6 ---------------------- * Wed Apr 12 2006 Jason Vas Dias - 1.48-1 - Upgrade to upstream version 1.48 perl-XML-Dumper-0.81-1.FC6 -------------------------- * Wed Apr 12 2006 Jason Vas Dias - 0.81-1 - upgrade to 0.81 pirut-1.0.2-1 ------------- * Wed Apr 12 2006 Jeremy Katz - 1.0.2-1 - Fix traceback with no groups defined (#186545) - Mark desktop files for translation (#188319) - Catch mirror error (#184326) - Change display name for package installer (#185169) - Improve progress bar updating a little - Require rhpl (#186796) - Add status bar and progress for searching from James Bowes (#186977) - Grab focus for search entry by default (#187597) - Give better error message about no network (#188529) python-2.4.3-2 -------------- * Wed Apr 12 2006 Jeremy Katz - 2.4.3-2 - rebuild with new gcc to fix #188649 * Thu Apr 06 2006 Mihai Ibanescu - 2.4.3-1 - Updated to 2.4.3 * Fri Feb 10 2006 Jesse Keating - 2.4.2-3.2.1 - bump again for double-long bug on ppc(64) rpm-4.4.2-18 ------------ * Wed Apr 12 2006 Paul Nasrat - 4.4.2-18 - Resurrect doxygen (#187714) * Tue Apr 11 2006 Jeremy Katz - 4.4.2-17 - remove redundant elfutils-libelf buildrequires - rpm-python doesn't require elfutils (related to #188495) system-config-printer-0.7.4-1 ----------------------------- * Wed Apr 12 2006 Tim Waugh 0.7.4-1 - Updated to system-config-printer-0.7.4. * Fri Apr 07 2006 Tim Waugh 0.7.3-1 - Added threads patch from pycups CVS. - Updated to system-config-printer-0.7.3. * Tue Apr 04 2006 Tim Waugh - Updated to pycups-1.9.6. valgrind-1:3.1.1-2 ------------------ * Wed Apr 12 2006 Jakub Jelinek 3.1.1-2 - handle many syscalls that were unhandled before, especially on ppc valgrind-callgrind-0.10.1-3 --------------------------- * Wed Apr 12 2006 Jakub Jelinek 0.10.1-3 - build also on ppc xorg-x11-server-1.0.99.901-4 ---------------------------- * Wed Apr 12 2006 Kristian H??gsberg 1.0.99.901-4 - Bump for rawhide build. * Wed Apr 12 2006 Kristian H??gsberg 1.0.99.901-3 - Add xorg-x11-server-1.0.99.901-cow-fix.patch to fix crash when releasing the COW. * Tue Apr 11 2006 Kristian H??gsberg 1.0.99.901-2 - Bump for fc5 build. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From lists at wilsonet.com Thu Apr 13 07:58:31 2006 From: lists at wilsonet.com (Jarod Wilson) Date: Thu, 13 Apr 2006 00:58:31 -0700 Subject: Intel iMac booting FC5 Message-ID: <200604130058.34252.lists@wilsonet.com> Anybody else playing with a new Intel Mac trying to get Fedora Core working on it? I'm happy to report that I've got my wife's 20" iMac booting under its own power as of a few minutes ago. Still looking into what it takes to get X working -- it works fine in the installer if you've got the latest firmware, since syslinux uses the bios emulation layer, which provides some basic vga support that allows you to use the vesa driver for install, but I'm trying to stick to pure efi. At the moment, I'm using elilo to load my initrd and kernel, which are from a custom kernel build, because the stock i686 kernels have no efi goodies enabled. In theory, enabling the necessary bits and adding patches to the latest FC kernel should work, but going that route, the HD wasn't getting picked up, so I still need to figure out exactly why that is, comparing the kernel config from mactel-linux.org to the one I hacked together based on the 2080 FC kernel (both had EFI stuff flipped on and the iMac patch added). I'll bend a few ears in IRC tomorrow too... -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From billcrawford1970 at gmail.com Thu Apr 13 08:10:08 2006 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 13 Apr 2006 09:10:08 +0100 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <20060405212215.GC16936@thyrsus.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <443400B4.2030706@redhat.com> <20060405212215.GC16936@thyrsus.com> Message-ID: <200604130910.10684.billcrawford1970@googlemail.com> On Wednesday 05 April 2006 22:22, Eric S. Raymond wrote: > What is it with the zeolots on this list, anyway? No contact with reality > at *all*... > -- > Eric S. Raymond ... thus disproving the claim that all americans do not understand irony ;) Eric, you *should* go talk to Fraunh?fer, among others. Although it certainly would be cool for Red Hat (and/or others) to negotiate too. However as has been mentioned several times, what is really needed is complete freedom, and as such this negotiation (or at least the initial approach) does seem more appropriate for a non-commercial representative (well, not a corporate one). -- From jon.nettleton at gmail.com Thu Apr 13 11:01:02 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 13 Apr 2006 07:01:02 -0400 Subject: Where am I? Do we need a Location Profiler? Message-ID: <1144926062.5527.25.camel@averatec> My bittorrents for the recordings of FUDcon finally finished downloading yesterday and I was able to catch up on what happened. After watching the Fedora Core 6 session I started thinking about what would make my Fedora using life simpler, ( No, it is not included mp3 support, or a different email client ). With me using my laptop more and more at different places I think a Location Profile system would be a nice addition. Here are some ideas. 1) catch Network state changes, obviously through the NetworkManager. Base different locations off of default route ip and hardware address, if wireless maybe essid? 2) Needs a privileged and unprivileged interface. Some apps like ntpd, iptables, cups, network filesystems, general services, all need to be setup by root. Others, gweather, default printer, network servers (gnome-vfs), mail settings, screensaver timeout, are user specific. 3) No reason to be a daemon running all the time. We have NetworkManagerDispatcher already running, why not use that? This also doesn't need to be super fast or small, allowing higher level languages to be used. Does this interest anyone else? It seems that with the right design it is a project that could be built pretty quickly. Jon From pnasrat at redhat.com Thu Apr 13 12:27:42 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 13 Apr 2006 08:27:42 -0400 Subject: Move Evolution to Extras? In-Reply-To: <1144880445.19844.17.camel@localhost.localdomain> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> <1144874235.6382.212.camel@dimi> <1144880445.19844.17.camel@localhost.localdomain> Message-ID: <1144931262.29397.48.camel@enki.eridu> On Thu, 2006-04-13 at 00:20 +0200, David Nielsen wrote: > We already have some components to work on: > > Contacts: > http://chrislord.net/blog/Software/Contacts/ > > Dates: > http://chrislord.net/blog/Software/Dates/ > > TinyMail: > https://svn.cronos.be/svn/tinymail/trunk/ > > Hopefully that opens for the possibility of replacing Evolution down the > road. Can I suggest you (or someone else who cares) package these up for extras so we can test it out. It looks as if tinymail will require gunit first. Paul From clumens at redhat.com Thu Apr 13 14:14:25 2006 From: clumens at redhat.com (Chris Lumens) Date: Thu, 13 Apr 2006 10:14:25 -0400 Subject: question on kickstart globs/everything In-Reply-To: <20060412231833.2401.qmail@web38410.mail.mud.yahoo.com> References: <20060412231833.2401.qmail@web38410.mail.mud.yahoo.com> Message-ID: <20060413141425.GO3137@exeter.boston.redhat.com> > Is the globs(*) for package selection in kickstart documented anywhere (yet)? Sadly, no. However if you use @everything in your kickstart file, it will still work and you'll get a deprecation warning in the log file. This does need documentation. Thanks for reminding me - I'll work on that today. > My question is, is that going to be as sufficiently smart as the > old/current-but-deprecated @everything, as far as silently dropping those > packages that have exclusional anti-dependencies? (picking the 'preferred > default') This should have the same (or almost the same - not a yum expert) behavior as if you did "yum install \*". That is, it should install all packages in whatever repos are configured (currently just the media you're installing from), minus anything that has dependancy problems. > Now, on to @minimal (dunno if that still exists). I used to generate livecd's > from mandrake back when their @minimal yielded ~300MB. I was building > appliance livecd's that even stripped some more files, getting it compressed > down to 135M (fits on a 3" cdr, with X+windowmaker+mozilla+xmms). So @minimal > was very useful for me, and as I'm now trying to do the same sorts of things > with fedora, I would hope it still exists, though have been psyching up for > having to more or less do lots of manual deinstallations as I figure out what > packages aren't _really_ necessary (which I had to do anyway with the mandrake > @minimal, to _really_ shave the install size down). Of course, now my target > is looking more like a 3" 1.8G dvd, but still... I liked @minimal. a lot. I > hope it lives. Well, there's @core and @base each of which installs some smallish amount of stuff. It's actually more like 800 megs, which is a long way from where you want to be. But we've had a problem with an ill-defined minimal install for a while now so perhaps you are used to this. You can just start with that and remove things you don't want. - Chris From skvidal at linux.duke.edu Thu Apr 13 14:20:23 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 13 Apr 2006 10:20:23 -0400 Subject: question on kickstart globs/everything In-Reply-To: <20060413141425.GO3137@exeter.boston.redhat.com> References: <20060412231833.2401.qmail@web38410.mail.mud.yahoo.com> <20060413141425.GO3137@exeter.boston.redhat.com> Message-ID: <1144938023.10731.8.camel@cutter> > Well, there's @core and @base each of which installs some smallish > amount of stuff. It's actually more like 800 megs, which is a long way > from where you want to be. But we've had a problem with an ill-defined > minimal install for a while now so perhaps you are used to this. You > can just start with that and remove things you don't want. To be fair - if you know what you're doing you can yum remove a lot of stuff in %post to make your installs very minimal. You can get an install stripped pretty far down, actually. -sv From gmaxwell at gmail.com Thu Apr 13 15:10:30 2006 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 13 Apr 2006 11:10:30 -0400 Subject: Red Hat's "Cowardice" against Software Patents In-Reply-To: <200604130910.10684.billcrawford1970@googlemail.com> References: <200603280950.k2S9oqre022074@snark.thyrsus.com> <443400B4.2030706@redhat.com> <20060405212215.GC16936@thyrsus.com> <200604130910.10684.billcrawford1970@googlemail.com> Message-ID: On 4/13/06, Bill Crawford wrote: > On Wednesday 05 April 2006 22:22, Eric S. Raymond wrote: > > > What is it with the zeolots on this list, anyway? No contact with reality > > at *all*... > > -- > > Eric S. Raymond > > ... thus disproving the claim that all americans do not understand irony ;) > > Eric, you *should* go talk to Fraunh?fer, among others. Although it certainly > would be cool for Red Hat (and/or others) to negotiate too. However as has > been mentioned several times, what is really needed is complete freedom, and > as such this negotiation (or at least the initial approach) does seem more > appropriate for a non-commercial representative (well, not a corporate one). And of the encoder too... a free player is only of marginal use without a free encoder. Unless we are to think that free software users should be content to only consume content. From rhally at mindspring.com Thu Apr 13 15:37:38 2006 From: rhally at mindspring.com (Richard Hally) Date: Thu, 13 Apr 2006 11:37:38 -0400 Subject: yum rudeness Message-ID: <443E7042.7070200@mindspring.com> When did the behavior of yum WRT its cache change? Is it documented anywhere that by default it no longer keeps packages in its cache. rh From skvidal at linux.duke.edu Thu Apr 13 15:41:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 13 Apr 2006 11:41:54 -0400 Subject: yum rudeness In-Reply-To: <443E7042.7070200@mindspring.com> References: <443E7042.7070200@mindspring.com> Message-ID: <1144942914.10731.35.camel@cutter> On Thu, 2006-04-13 at 11:37 -0400, Richard Hally wrote: > When did the behavior of yum WRT its cache change? Is it documented > anywhere that by default it no longer keeps packages in its cache. > man yum.conf keepcache Either ?1? or ?0?. Determines whether or not yum keeps the cache of headers and packages after successful installation. Default is ?1? (keep files) Then in /etc/yum.conf for fc5 keepcache=0 I thought, but I can't find the note, that this was mentioned in the release notes. -sv From n0dalus+redhat at gmail.com Thu Apr 13 15:40:58 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 14 Apr 2006 01:10:58 +0930 Subject: yum rudeness In-Reply-To: <443E7042.7070200@mindspring.com> References: <443E7042.7070200@mindspring.com> Message-ID: <6280325c0604130840l8b4c323mff39d410e39d931d@mail.gmail.com> On 4/14/06, Richard Hally wrote: > When did the behavior of yum WRT its cache change? Is it documented > anywhere that by default it no longer keeps packages in its cache. > It might be in the release notes. I think it's great. Now I don't have to explain to people the idea of having to sometimes clean their package cache. n0dalus. From sundaram at fedoraproject.org Thu Apr 13 15:42:25 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 13 Apr 2006 21:12:25 +0530 Subject: yum rudeness In-Reply-To: <1144942914.10731.35.camel@cutter> References: <443E7042.7070200@mindspring.com> <1144942914.10731.35.camel@cutter> Message-ID: <1144942945.2294.347.camel@sundaram.pnq.redhat.com> On Thu, 2006-04-13 at 11:41 -0400, seth vidal wrote: > On Thu, 2006-04-13 at 11:37 -0400, Richard Hally wrote: > > When did the behavior of yum WRT its cache change? Is it documented > > anywhere that by default it no longer keeps packages in its cache. > > > > man yum.conf > > keepcache > Either ?1? or ?0?. Determines whether or not yum keeps the > cache > of headers and packages after successful installation. > Default > is ?1? (keep files) > > Then in /etc/yum.conf for fc5 keepcache=0 > > I thought, but I can't find the note, that this was mentioned in the > release notes. Missed the string freeze. Will be in an errata http://fedoraproject.org/wiki/Docs/Beats/PackageNotes Rahul From jcliburn at gmail.com Thu Apr 13 15:42:25 2006 From: jcliburn at gmail.com (J. K. Cliburn) Date: Thu, 13 Apr 2006 10:42:25 -0500 Subject: yum rudeness In-Reply-To: <443E7042.7070200@mindspring.com> References: <443E7042.7070200@mindspring.com> Message-ID: <3400f2f60604130842j2578486as70cf8d4c45e8527a@mail.gmail.com> On 4/13/06, Richard Hally wrote: > When did the behavior of yum WRT its cache change? Is it documented > anywhere that by default it no longer keeps packages in its cache. http://fedoraproject.org/wiki/Docs/Beats/PackageNotes From katzj at redhat.com Thu Apr 13 15:46:32 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Apr 2006 11:46:32 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060413034503.GB18164@devserv.devel.redhat.com> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> <20060412155226.GA92603@dspnet.fr.eu.org> <20060413024826.GB1024729@hiwaay.net> <20060413034503.GB18164@devserv.devel.redhat.com> Message-ID: <1144943192.3016.0.camel@aglarond.local> On Wed, 2006-04-12 at 23:45 -0400, Bill Nottingham wrote: > Chris Adams (cmadams at hiwaay.net) said: > > In any case, if you really want everything, "yum install *" after > > install works IIRC (but be prepared for what you get). > > Heck, '%packages *' works in kickstart. I might suggest a new line in there ;) Jeremy From jspaleta at gmail.com Thu Apr 13 15:46:28 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Apr 2006 11:46:28 -0400 Subject: yum rudeness In-Reply-To: <443E7042.7070200@mindspring.com> References: <443E7042.7070200@mindspring.com> Message-ID: <604aa7910604130846l6ecf80eesc7d9c68fa3c84ac2@mail.gmail.com> On 4/13/06, Richard Hally wrote: > When did the behavior of yum WRT its cache change? Is it documented > anywhere that by default it no longer keeps packages in its cache. the only reference in the yum changlog seems to indicate the intention was to keep things. If a change in judgement was made upstream or at the fedora package level after march 4th I can't find a reference in either the package or yum changelog. I'd have to look at the cvs revisions to track it down further. -jef /usr/share/doc/yum-2.6.0/ChangeLog 2006-03-04 11:09 katzj * docs/yum.conf.5, etc/yum.conf, yum/__init__.py, yum/config.py: new option 'keepcache' to allow the cache of packages and headers to be automatically purged after successful package installation. the default behavior remains to keep things (as previously) From katzj at redhat.com Thu Apr 13 15:52:12 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Apr 2006 11:52:12 -0400 Subject: question on kickstart globs/everything In-Reply-To: <20060413141425.GO3137@exeter.boston.redhat.com> References: <20060412231833.2401.qmail@web38410.mail.mud.yahoo.com> <20060413141425.GO3137@exeter.boston.redhat.com> Message-ID: <1144943532.3016.6.camel@aglarond.local> On Thu, 2006-04-13 at 10:14 -0400, Chris Lumens wrote: > > Now, on to @minimal (dunno if that still exists). I used to generate livecd's > > from mandrake back when their @minimal yielded ~300MB. I was building > > appliance livecd's that even stripped some more files, getting it compressed > > down to 135M (fits on a 3" cdr, with X+windowmaker+mozilla+xmms). So @minimal > > was very useful for me, and as I'm now trying to do the same sorts of things > > with fedora, I would hope it still exists, though have been psyching up for > > having to more or less do lots of manual deinstallations as I figure out what > > packages aren't _really_ necessary (which I had to do anyway with the mandrake > > @minimal, to _really_ shave the install size down). Of course, now my target > > is looking more like a 3" 1.8G dvd, but still... I liked @minimal. a lot. I > > hope it lives. > > Well, there's @core and @base each of which installs some smallish > amount of stuff. It's actually more like 800 megs, which is a long way > from where you want to be. But we've had a problem with an ill-defined > minimal install for a while now so perhaps you are used to this. You > can just start with that and remove things you don't want. @core is actually pretty small. It'll get you to a login prompt and not much else and so probably is pretty easily less than 300 megs. @base is more of a "provide the tools most people actually expect to be present on a linux system", and thus, yeah, starts getting a little bigger. It's still not huge, though Jeremy From rhallyx at mindspring.com Thu Apr 13 16:06:06 2006 From: rhallyx at mindspring.com (Richard Hally) Date: Thu, 13 Apr 2006 12:06:06 -0400 Subject: s-c-printer GUI ? Message-ID: <443E76EE.8030408@mindspring.com> what is the correct fix for the following? todays update from rawhide: > [root at LinuxNew2 headers]# yum update > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > development [1/1] > development 100% |=========================| 1.1 kB 00:00 > Reading repository metadata in from local files > Excluding Packages in global exclude list > Finished > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for system-config-printer to pack into transaction set. > system-config-printer-0.7 100% |=========================| 8.4 kB 00:00 > ---> Package system-config-printer.i386 0:0.7.4-1 set to be updated > --> Running transaction check > --> Processing Dependency: system-config-printer = 0.6.151.2-1 for package: system-config-printer-gui > --> Finished Dependency Resolution > Error: Missing Dependency: system-config-printer = 0.6.151.2-1 is needed by package system-config-printer-gui thanks, rh From robert.chiodini-1 at ksc.nasa.gov Thu Apr 13 16:11:21 2006 From: robert.chiodini-1 at ksc.nasa.gov (Bob Chiodini) Date: Thu, 13 Apr 2006 12:11:21 -0400 Subject: s-c-printer GUI ? In-Reply-To: <443E76EE.8030408@mindspring.com> References: <443E76EE.8030408@mindspring.com> Message-ID: <1144944681.5828.137.camel@tweedy.ksc.nasa.gov> On Thu, 2006-04-13 at 12:06 -0400, Richard Hally wrote: > what is the correct fix for the following? > > todays update from rawhide: > > > [root at LinuxNew2 headers]# yum update > > Loading "installonlyn" plugin > > Setting up Update Process > > Setting up repositories > > development [1/1] > > development 100% |=========================| 1.1 kB 00:00 > > Reading repository metadata in from local files > > Excluding Packages in global exclude list > > Finished > > Resolving Dependencies > > --> Populating transaction set with selected packages. Please wait. > > ---> Downloading header for system-config-printer to pack into transaction set. > > system-config-printer-0.7 100% |=========================| 8.4 kB 00:00 > > ---> Package system-config-printer.i386 0:0.7.4-1 set to be updated > > --> Running transaction check > > --> Processing Dependency: system-config-printer = 0.6.151.2-1 for package: system-config-printer-gui > > --> Finished Dependency Resolution > > Error: Missing Dependency: system-config-printer = 0.6.151.2-1 is needed by package system-config-printer-gui > > thanks, > rh > To get past this dependency problem: yum --exclude=system-config-printer* update will exclude it for now. I imagine the GUI will get picked up later. Obviously not the right solution if this is the only update :-) Bob... From rhally at mindspring.com Thu Apr 13 16:30:49 2006 From: rhally at mindspring.com (Richard Hally) Date: Thu, 13 Apr 2006 12:30:49 -0400 Subject: yum rudeness In-Reply-To: <1144942914.10731.35.camel@cutter> References: <443E7042.7070200@mindspring.com> <1144942914.10731.35.camel@cutter> Message-ID: <443E7CB9.60909@mindspring.com> seth vidal wrote: > On Thu, 2006-04-13 at 11:37 -0400, Richard Hally wrote: >> When did the behavior of yum WRT its cache change? Is it documented >> anywhere that by default it no longer keeps packages in its cache. >> > > man yum.conf > > keepcache > Either ?1? or ?0?. Determines whether or not yum keeps the > cache > of headers and packages after successful installation. > Default > is ?1? (keep files) > > Then in /etc/yum.conf for fc5 keepcache=0 > > I thought, but I can't find the note, that this was mentioned in the > release notes. > > > -sv > > > > OK, so you blew one. It just goes to show that even top notch guys screw up once in a while. ;-) Thanks for the excellent work, Seth. rh From rhally at mindspring.com Thu Apr 13 16:37:16 2006 From: rhally at mindspring.com (Richard Hally) Date: Thu, 13 Apr 2006 12:37:16 -0400 Subject: s-c-printer GUI ? In-Reply-To: <1144944681.5828.137.camel@tweedy.ksc.nasa.gov> References: <443E76EE.8030408@mindspring.com> <1144944681.5828.137.camel@tweedy.ksc.nasa.gov> Message-ID: <443E7E3C.7090700@mindspring.com> Bob Chiodini wrote: > On Thu, 2006-04-13 at 12:06 -0400, Richard Hally wrote: >> what is the correct fix for the following? >> >> todays update from rawhide: >> >>> [root at LinuxNew2 headers]# yum update >>> Loading "installonlyn" plugin >>> Setting up Update Process >>> Setting up repositories >>> development [1/1] >>> development 100% |=========================| 1.1 kB 00:00 >>> Reading repository metadata in from local files >>> Excluding Packages in global exclude list >>> Finished >>> Resolving Dependencies >>> --> Populating transaction set with selected packages. Please wait. >>> ---> Downloading header for system-config-printer to pack into transaction set. >>> system-config-printer-0.7 100% |=========================| 8.4 kB 00:00 >>> ---> Package system-config-printer.i386 0:0.7.4-1 set to be updated >>> --> Running transaction check >>> --> Processing Dependency: system-config-printer = 0.6.151.2-1 for package: system-config-printer-gui >>> --> Finished Dependency Resolution >>> Error: Missing Dependency: system-config-printer = 0.6.151.2-1 is needed by package system-config-printer-gui >> thanks, >> rh >> > > To get past this dependency problem: > > yum --exclude=system-config-printer* update > > will exclude it for now. I imagine the GUI will get picked up later. > > Obviously not the right solution if this is the only update :-) > > Bob... > Thanks Bob, it was a poorly framed question. What I really wanted to know was, has the GUI part been incorporated into the main package or did the gui just not get built? Or is there some other explanation? rh From gianluca.cecchi at gmail.com Thu Apr 13 16:58:18 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 13 Apr 2006 18:58:18 +0200 Subject: rawhide report: 20060413 changes Message-ID: <561c252c0604130958x40ffc8dcie87721663a25b1be@mail.gmail.com> On Thu, 13 Apr 2006 03:24:14 -0400 Build System wrote: >python-2.4.3-2 >-------------- >* Wed Apr 12 2006 Jeremy Katz - 2.4.3-2 >- rebuild with new gcc to fix #188649 > >* Thu Apr 06 2006 Mihai Ibanescu - 2.4.3-1 >- Updated to 2.4.3 > >* Fri Feb 10 2006 Jesse Keating - 2.4.2-3.2.1 >- bump again for double-long bug on ppc(64) In general is it supposed that minor version upgrades like this, from 2.4.2 to 2.4.3 for python, converge after some days to official fc5 too? In this particular case I'm interested on testing plone 2.5 beta 1 with Zope 2.9.2 http://plone.org/products/plone/releases/2.5 for furhter adoption of upcoming offical 2.5 release, so that I'd prefer to stay with fc5, but eventually I can also shift to fc5-devel.... Thanks in advance. Bye, Gianluca From twaugh at redhat.com Thu Apr 13 17:15:16 2006 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 13 Apr 2006 17:15:16 +0000 Subject: s-c-printer GUI ? In-Reply-To: <443E76EE.8030408@mindspring.com> References: <443E76EE.8030408@mindspring.com> Message-ID: <20060413171516.GZ7105@redhat.com> On Thu, Apr 13, 2006 at 12:06:06PM -0400, Richard Hally wrote: > >Error: Missing Dependency: system-config-printer = 0.6.151.2-1 is needed > >by package system-config-printer-gui Oops, fixing. You can just remove system-config-printer-gui first, as a work-around. The new system-config-printer includes the GUI (the only interface, actually) in the main package. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Apr 13 17:26:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Apr 2006 19:26:20 +0200 Subject: When do we get a more usable printer dialog for GNOME? In-Reply-To: <20060411210425.GQ7105@redhat.com> References: <1144719077.32256.0.camel@scriabin.tannenrauch.ch> <1144759857.10620.23.camel@golem.boston.redhat.com> <1144780492.4051.3.camel@rousalka.dyndns.org> <20060411210425.GQ7105@redhat.com> Message-ID: <1144949184.11911.0.camel@rousalka.dyndns.org> Le mardi 11 avril 2006 ? 21:04 +0000, Tim Waugh a ?crit : > On Tue, Apr 11, 2006 at 08:34:49PM +0200, Nicolas Mailhot wrote: > > > I hope someone will take care of the A4 vs Letter problem before adding > > all sorts of advanced settings (printing an A4 page in evo through a PCL > > filter actually prints A4 ; printing an A4 page in postscript mode has > > always been printing letter for as long as I can remember) > > Got a bugzilla ID for that? Will do. I only noticed it worked in PCL mode this week -- 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 nicolas.mailhot at laposte.net Thu Apr 13 18:07:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 13 Apr 2006 20:07:08 +0200 Subject: Why Notes is either love it or hate it (Re: Move Evolution to Extras?) In-Reply-To: <200604121145.24503.lamont@gurulabs.com> References: <1144155199.2808.94.camel@dimi> <20060412150419.GB30579@devserv.devel.redhat.com> <1144854968.6382.176.camel@dimi> <200604121145.24503.lamont@gurulabs.com> Message-ID: <1144951637.11911.3.camel@rousalka.dyndns.org> Le mercredi 12 avril 2006 ? 11:45 -0600, Lamont R. Peterson a ?crit : > I would love to see a native Linux Notes client (Domino has run on Linux for > years) and it would be 10 times better if that was open source. IBM is supposed to be prepping an eclipse-based Notes linux client. It will include a bunch of old code though so I doubt they'll open-source it. -- 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 ianburrell at gmail.com Thu Apr 13 18:08:18 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 13 Apr 2006 11:08:18 -0700 Subject: Where is my "everything" gone? In-Reply-To: <20060413024826.GB1024729@hiwaay.net> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <200604121642.40267.jamatos@fc.up.pt> <20060412155226.GA92603@dspnet.fr.eu.org> <20060413024826.GB1024729@hiwaay.net> Message-ID: On 4/12/06, Chris Adams wrote: > > In any case, if you really want everything, "yum install *" after > install works IIRC (but be prepared for what you get). > It is possible to do an install everything from core with yum: yum --disablerepo=\* --enablerepo=core --enablerepo=updates install \* - Ian From dhollis at davehollis.com Thu Apr 13 18:11:42 2006 From: dhollis at davehollis.com (David Hollis) Date: Thu, 13 Apr 2006 14:11:42 -0400 Subject: Where am I? Do we need a Location Profiler? In-Reply-To: <1144926062.5527.25.camel@averatec> References: <1144926062.5527.25.camel@averatec> Message-ID: <1144951902.2465.15.camel@dhollis-lnx.sunera.com> On Thu, 2006-04-13 at 07:01 -0400, Jon Nettleton wrote: > 1) catch Network state changes, obviously through the NetworkManager. > Base different locations off of default route ip and hardware address, > if wireless maybe essid? > 2) Needs a privileged and unprivileged interface. Some apps like ntpd, > iptables, cups, network filesystems, general services, all need to be > setup by root. Others, gweather, default printer, network servers > (gnome-vfs), mail settings, screensaver timeout, are user specific. > 3) No reason to be a daemon running all the time. We have > NetworkManagerDispatcher already running, why not use that? This also > doesn't need to be super fast or small, allowing higher level languages > to be used. A similar app on the Windows side (for IBM systems anyway) would be IBM Access Connections. It's actually a pretty evil app, but it's intentions are pretty good. Based on your location profile, you can specify your default printer, drive mappings, whether or not to enable File & Print sharing, etc. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu Apr 13 18:16:45 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 13 Apr 2006 14:16:45 -0400 Subject: rawhide report: 20060413 changes In-Reply-To: <561c252c0604130958x40ffc8dcie87721663a25b1be@mail.gmail.com> References: <561c252c0604130958x40ffc8dcie87721663a25b1be@mail.gmail.com> Message-ID: <1144952205.3016.13.camel@aglarond.local> On Thu, 2006-04-13 at 18:58 +0200, Gianluca Cecchi wrote: > In general is it supposed that minor version upgrades like this, from > 2.4.2 to 2.4.3 > for python, converge after some days to official fc5 too? It tends to depend on the package, what the changes are and the package maintainer. In the case of python 2.4.3, the plan is that we're going to end up pushing it as an FC5 update as well but we're hoping to get a new gcc pushed as an update first so that we can fix #188649 as well Jeremy From jwboyer at jdub.homelinux.org Thu Apr 13 18:33:59 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 13 Apr 2006 13:33:59 -0500 Subject: Why Notes is either love it or hate it (Re: Move Evolution to Extras?) In-Reply-To: <1144951637.11911.3.camel@rousalka.dyndns.org> References: <1144155199.2808.94.camel@dimi> <20060412150419.GB30579@devserv.devel.redhat.com> <1144854968.6382.176.camel@dimi> <200604121145.24503.lamont@gurulabs.com> <1144951637.11911.3.camel@rousalka.dyndns.org> Message-ID: <1144953239.19908.3.camel@yoda.jdub.homelinux.org> On Thu, 2006-04-13 at 20:07 +0200, Nicolas Mailhot wrote: > Le mercredi 12 avril 2006 ? 11:45 -0600, Lamont R. Peterson a ?crit : > > > I would love to see a native Linux Notes client (Domino has run on Linux for > > years) and it would be 10 times better if that was open source. > > IBM is supposed to be prepping an eclipse-based Notes linux client. > It will include a bunch of old code though so I doubt they'll > open-source it. It's called IBM Workplace http://www-142.ibm.com/software/workplace/products/product5.nsf/wdocs/workplaceoverview Just think for a second... take Notes, and all of the crap that comes with it. Now, wrap eclipse around it and all of the overhead that incurs. That doesn't really make you excited, does it? josh From david at lovesunix.net Thu Apr 13 20:38:10 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 13 Apr 2006 22:38:10 +0200 Subject: Move Evolution to Extras? In-Reply-To: <1144931262.29397.48.camel@enki.eridu> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1144849676.6382.155.camel@dimi> <1144857491.2645.73.camel@shinybook.infradead.org> <1144874235.6382.212.camel@dimi> <1144880445.19844.17.camel@localhost.localdomain> <1144931262.29397.48.camel@enki.eridu> Message-ID: <1144960690.19844.27.camel@localhost.localdomain> tor, 13 04 2006 kl. 08:27 -0400, skrev Paul Nasrat: > On Thu, 2006-04-13 at 00:20 +0200, David Nielsen wrote: > > > We already have some components to work on: > > > > Contacts: > > http://chrislord.net/blog/Software/Contacts/ > > > > Dates: > > http://chrislord.net/blog/Software/Dates/ > > > > TinyMail: > > https://svn.cronos.be/svn/tinymail/trunk/ > > > > Hopefully that opens for the possibility of replacing Evolution down the > > road. > > Can I suggest you (or someone else who cares) package these up for > extras so we can test it out. It looks as if tinymail will require > gunit first. I started packaging these up, so far I've submitted contacts for review - the remaining programs have yet to make releases I think and my opinion sways against encouraging users running SVN/CVS snapshots. Don't laugh to hard please, my very first SPEC battle. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188946 - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jos at xos.nl Thu Apr 13 20:59:19 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 13 Apr 2006 22:59:19 +0200 Subject: Ruby on Rails and Fedora Message-ID: <200604132059.k3DKxJq26437@xos037.xos.nl> Hi, I was surprised to see that Ruby on Rails is not in Core or Extras. But I found a nice set of RPMs: . Is this the recommended set of packages to use/rebuilt for FC5? Isn't it a good idea to include them in FC6 (Core or Extras)? This stuff becomes pretty popular (I also hope to see it back in RHEL5). Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mitr at volny.cz Thu Apr 13 21:08:36 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 13 Apr 2006 23:08:36 +0200 Subject: Ruby on Rails and Fedora In-Reply-To: <200604132059.k3DKxJq26437@xos037.xos.nl> References: <200604132059.k3DKxJq26437@xos037.xos.nl> Message-ID: <443EBDD4.6030206@volny.cz> Hello, Jos Vos napsal(a): > I was surprised to see that Ruby on Rails is not in Core or Extras. > But I found a nice set of RPMs: . > > Isn't it a good idea to include them in FC6 (Core or Extras)? Those packages were intended as a preview before adding them to Extras. AFAIK including them is currently blocked on #184199. Mirek From gianluca.cecchi at gmail.com Thu Apr 13 21:49:27 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 13 Apr 2006 23:49:27 +0200 Subject: xorg from 1.0.1-9 to 1.0.1-9.fc5 Message-ID: <561c252c0604131449w7f181f20p926c667de23a9d4c@mail.gmail.com> Running yum update today on my fc5 x86 system I see that it wants to upgrade xorg-x11-server-Xorg from 1.0.1-9 to 1.0.1-9.fc5. Quering the changelog of the proposed update rpm file, after simply downloading it, I get: * Mon Apr 10 2006 Ray Strode - 1.0.1-9.fc5 - Fix small overflow that causes crash on vt switch on ppc. Patch by David Woodhouse (bug 187083). * Wed Mar 15 2006 Ray Strode - 1.0.1-9 - CVE-2006-0745 (bug 185084) Is the "fc5" postfix to tell that the update is only needed for a particular architecture or what does it mean? In that case why does yum try to update it anyway on x86? Wouldn't be better to name it 1.0.1-10? Going through bug 187083 thread doesn't help me to understand the "fc5" meaning.... Any pointer? Thanks, Gianluca From david at fubar.dk Thu Apr 13 22:53:26 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 13 Apr 2006 18:53:26 -0400 Subject: Intel iMac booting FC5 In-Reply-To: <200604130058.34252.lists@wilsonet.com> References: <200604130058.34252.lists@wilsonet.com> Message-ID: <1144968806.3301.3.camel@daxter.boston.redhat.com> On Thu, 2006-04-13 at 00:58 -0700, Jarod Wilson wrote: > Anybody else playing with a new Intel Mac trying to get Fedora Core working on > it? I'm happy to report that I've got my wife's 20" iMac booting under its > own power as of a few minutes ago. I've got a Macbook Pro with Rawhide, but I'm using the kernel from mactel-linux.org together with a Fedora initrd. > Still looking into what it takes to get X working -- it works fine in the > installer if you've got the latest firmware, since syslinux uses the bios > emulation layer, which provides some basic vga support that allows you to use > the vesa driver for install, but I'm trying to stick to pure efi. Yea, X.org bails for me with (EE) FBDEV(0): FBIOBLANK: Invalid Argument I haven't tried that hard yet to coerce our resident X hackers to look at it... > At the moment, I'm using elilo to load my initrd and kernel, which are from a > custom kernel build, because the stock i686 kernels have no efi goodies > enabled. In theory, enabling the necessary bits and adding patches to the > latest FC kernel should work, but going that route, the HD wasn't getting > picked up, so I still need to figure out exactly why that is, comparing the > kernel config from mactel-linux.org to the one I hacked together based on the > 2080 FC kernel (both had EFI stuff flipped on and the iMac patch added). Any chance you can post the diff on the config? And exactly what patches to use (I'm using the imac-2.6.16-rc4 one with CONFIG_FB_IMAC set)? It would probably be worthwhile to patch Rawhide kernels too, cuz then it's probably easier talking davej into taking the changes :-) Thanks, David From davej at redhat.com Thu Apr 13 23:41:58 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 13 Apr 2006 18:41:58 -0500 Subject: Intel iMac booting FC5 In-Reply-To: <1144968806.3301.3.camel@daxter.boston.redhat.com> References: <200604130058.34252.lists@wilsonet.com> <1144968806.3301.3.camel@daxter.boston.redhat.com> Message-ID: <20060413234158.GA1040@redhat.com> On Thu, Apr 13, 2006 at 06:53:26PM -0400, David Zeuthen wrote: > On Thu, 2006-04-13 at 00:58 -0700, Jarod Wilson wrote: > > Anybody else playing with a new Intel Mac trying to get Fedora Core working on > > it? I'm happy to report that I've got my wife's 20" iMac booting under its > > own power as of a few minutes ago. > > I've got a Macbook Pro with Rawhide, but I'm using the kernel from > mactel-linux.org together with a Fedora initrd. > > > Still looking into what it takes to get X working -- it works fine in the > > installer if you've got the latest firmware, since syslinux uses the bios > > emulation layer, which provides some basic vga support that allows you to use > > the vesa driver for install, but I'm trying to stick to pure efi. > > Yea, X.org bails for me with > > (EE) FBDEV(0): FBIOBLANK: Invalid Argument > > I haven't tried that hard yet to coerce our resident X hackers to look > at it... Can you try adding DefaultFBbpp 32 to the screen section of your xorg.conf under the default depth ? Dave -- http://www.codemonkey.org.uk From david at fubar.dk Fri Apr 14 00:51:29 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 13 Apr 2006 20:51:29 -0400 Subject: Intel iMac booting FC5 In-Reply-To: <20060413234158.GA1040@redhat.com> References: <200604130058.34252.lists@wilsonet.com> <1144968806.3301.3.camel@daxter.boston.redhat.com> <20060413234158.GA1040@redhat.com> Message-ID: <1144975889.3301.39.camel@daxter.boston.redhat.com> On Thu, 2006-04-13 at 18:41 -0500, Dave Jones wrote: > Can you try adding DefaultFBbpp 32 to the screen section of your > xorg.conf under the default depth ? Already using that one (see below) but it still failed with the same error. Thanks anyway. http://svn.sourceforge.net/viewcvs.cgi/mactel-linux/trunk/misc/misc/xorg.conf?view=markup&rev=14 Cheers, David From mattdm at mattdm.org Fri Apr 14 03:39:20 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Apr 2006 23:39:20 -0400 Subject: xorg from 1.0.1-9 to 1.0.1-9.fc5 In-Reply-To: <561c252c0604131449w7f181f20p926c667de23a9d4c@mail.gmail.com> References: <561c252c0604131449w7f181f20p926c667de23a9d4c@mail.gmail.com> Message-ID: <20060414033920.GA9422@jadzia.bu.edu> On Thu, Apr 13, 2006 at 11:49:27PM +0200, Gianluca Cecchi wrote: > Running yum update today on my fc5 x86 system I see that it wants to > upgrade xorg-x11-server-Xorg from 1.0.1-9 to 1.0.1-9.fc5. > Quering the changelog of the proposed update rpm file, after simply > downloading it, I get: > * Mon Apr 10 2006 Ray Strode - 1.0.1-9.fc5 > - Fix small overflow that causes crash on vt switch on ppc. > Patch by David Woodhouse (bug 187083). > > * Wed Mar 15 2006 Ray Strode - 1.0.1-9 > - CVE-2006-0745 (bug 185084) > > Is the "fc5" postfix to tell that the update is only needed for a > particular architecture or what does it mean? In that case why does > yum try to update it anyway on x86? Well, "fc5" is "Fedora Core 5". I notice you use the exact same abbreviation above. :) There's no real standard for how updates like this are numbered/labeled; "-9.1.fc5" might have been more clear. In any case, "9.fc5" sorts as higher than "9", so RPM knows it's a new version. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mmcgrath at fedoraproject.org Fri Apr 14 03:47:12 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 13 Apr 2006 22:47:12 -0500 Subject: Kickstart and roles Message-ID: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> So I've been kicking around this idea for a while and wanted to see what others thought. Who knows maybe someone will be interested in helping. This may already exist so if it does please let me know but I would like to setup a bunch of kickstart scripts for server and workstation roles using only official Fedora software. For example, lets say someone wants a xen workstation. We could setup a kickstart script with everything they need, only the minimals and at the end, yum update, configure what we can and on reboot, that user has a working xen machine. Perhaps a better example, lets say somene needs an email server that supports SMTP, imaps and webmail. We could create a kickstart script that installs and configures as much of it as possible in a way that we deem secure. All the user would have to do is fill out a fiew variables at the top of the ks script (like domain or something). Anaconda would ask for things like partitions and network. When the machine reboots, they have a working email server. Ultimately it'd be nice to have this little project sponsored by Fedora. We could even have some that automatically work with Fedora's directory server. Clearly this isn't for everyone. I have a hunch there's a market out there for it, and if every ks script came with clear "What to do next" instructions we might be able to save some chatter on the lists and open Fedora up to many more users out there who want to do more with Fedora but just don't know how. Thoughts, opinions, suggestions? -Mike From loony at loonybin.org Fri Apr 14 04:12:07 2006 From: loony at loonybin.org (Peter Arremann) Date: Fri, 14 Apr 2006 00:12:07 -0400 Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <200604140012.07541.loony@loonybin.org> On Thursday 13 April 2006 23:47, Mike McGrath wrote: > Ultimately it'd be nice to have this little project sponsored by > Fedora. We could even have some that automatically work with Fedora's > directory server. Clearly this isn't for everyone. I have a hunch > there's a market out there for it, and if every ks script came with > clear "What to do next" instructions we might be able to save some > chatter on the lists and open Fedora up to many more users out there > who want to do more with Fedora but just don't know how. > > Thoughts, opinions, suggestions? I'm a little confused on what kind of environment you are targeting with this... If its larger corporations (as I quite possibly misinterpret your email) then you need to do some more serious work than just have some kickstart scripts. You don't want everyone to be able to install a developers image that would require you to have licenses for MQ and DB2 from IBM... What you would really need is a server based anaconda. The installer on the client only posts data from the local client - like user input or harddisk sizes - to the server who will then in turn respond with a script for the next screen. That way, the first screen can be a input screen for a user id / password to identify the potential user. Then the next screen offers you what type of setup you want - that's basically where you would then go ahead and determine most of the setup parameters. If needed, it might then ask you some more questions and so on. Of course that would require anaconda to have support to take a server location on the boot line and load screen definitions from a remote server - something I don't think it can do right now... Peter. From skvidal at linux.duke.edu Fri Apr 14 05:23:56 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 14 Apr 2006 01:23:56 -0400 Subject: Kickstart and roles In-Reply-To: <200604140012.07541.loony@loonybin.org> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <200604140012.07541.loony@loonybin.org> Message-ID: <1144992236.14377.13.camel@cutter> > That way, the first screen can be a input screen for a user id / password to > identify the potential user. Then the next screen offers you what type of > setup you want - that's basically where you would then go ahead and determine > most of the setup parameters. If needed, it might then ask you some more > questions and so on. > > Of course that would require anaconda to have support to take a server > location on the boot line and load screen definitions from a remote server - > something I don't think it can do right now... > or, fairly simply: You setup a web app that takes the info on what the user wants on the box and stores it in a db. Then it returns a url encoded to retrieve a ks.cfg from a cgi based on the info in the db. Then for the ks you specify the location of the ks.cfg as the aforementioned url. That's it. -sv From gianluca.cecchi at gmail.com Fri Apr 14 05:26:48 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 14 Apr 2006 07:26:48 +0200 Subject: xorg from 1.0.1-9 to 1.0.1-9.fc5 Message-ID: <561c252c0604132226u141339dbpbd93325cbccc57dc@mail.gmail.com> On Thu, 13 Apr 2006 23:39:20 -0400 Matthew Miller wrote: > There's no real standard for how updates like this are numbered/labeled; > "-9.1.fc5" might have been more clear. > In any case, "9.fc5" sorts as higher than "9", so RPM knows it's a new > version. I think you are under estimating hard job of package mantainers... There is also a wiki on this, but I didn't find it useful to understand this "fc5" appended to an already fc5 previous package...: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines?action=show&redirect=PackageNamingGuidelines From jdogalt at yahoo.com Fri Apr 14 04:38:09 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Thu, 13 Apr 2006 21:38:09 -0700 (PDT) Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <20060414043809.40336.qmail@web38409.mail.mud.yahoo.com> --- Mike McGrath wrote: > So I've been kicking around this idea for a while and wanted to see > what others thought. Who knows maybe someone will be interested in > helping. > > This may already exist so if it does please let me know but I would > like to setup a bunch of kickstart scripts for server and workstation > roles using only official Fedora software. For example, lets say ... > > Thoughts, opinions, suggestions? This is a great idea and something I was planning on doing myself. But for simplicity, it seems like this could be implemented dirt-simply (from an infrastructure impact point of view) via rpms. I.e. rpms that are heavy on specifying dependencies and pre/post scripts, but probably very light on files (if not in fact lacking any rpm owned files). Therefore each role gets packaged as an rpm and placed in your yum repo, so that you just do a yum install of it. That picks up all the package dependencies to install, and does all the system config in the (rather more invasive than usual) pre/post script. Hopefully you write the rpm uninstall scripts with enough intelligence to revert the system exactly back to the preinstall state. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tibbs at math.uh.edu Fri Apr 14 05:38:23 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 14 Apr 2006 00:38:23 -0500 Subject: Ruby on Rails and Fedora In-Reply-To: <443EBDD4.6030206@volny.cz> (Miloslav Trmac's message of "Thu, 13 Apr 2006 23:08:36 +0200") References: <200604132059.k3DKxJq26437@xos037.xos.nl> <443EBDD4.6030206@volny.cz> Message-ID: >>>>> "MT" == Miloslav Trmac writes: MT> AFAIK including them is currently blocked on #184199. It is true that it isn't possible to build noarch Ruby packages at the moment, but it's still quite possible to just build them as arch-dependent. Ruby packages aren't being kept out of Extras because of this. - J< From n0dalus+redhat at gmail.com Fri Apr 14 06:17:48 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 14 Apr 2006 15:47:48 +0930 Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <6280325c0604132317i4f83868bha3b55c22fc6122b5@mail.gmail.com> On 4/14/06, Mike McGrath wrote: > > This may already exist so if it does please let me know but I would > like to setup a bunch of kickstart scripts for server and workstation > roles using only official Fedora software. For example, lets say > someone wants a xen workstation. We could setup a kickstart script > with everything they need, only the minimals and at the end, yum > update, configure what we can and on reboot, that user has a working > xen machine. > I have often thought it would be helpful if a bunch of kickstart files were distributed on the CDs. That way people with uncommon use cases can still be catered for without having to put confusing or over-complicated gui options. For example, kickstarts could be provided for: - Everything installs - Everything installs minus languages - Very minimal install - Different server installs - Etc Not only does this provide a good way to introduce people to kickstart and give them example files to modify, it would help make various use cases a bit easier to implement. I'm not sure if this is the kind of thing the original poster meant, but I think it would be nice to try for FC6. n0dalus. From buildsys at redhat.com Fri Apr 14 07:39:24 2006 From: buildsys at redhat.com (Build System) Date: Fri, 14 Apr 2006 03:39:24 -0400 Subject: rawhide report: 20060414 changes Message-ID: <200604140739.k3E7dOPA008167@porkchop.devel.redhat.com> Updated Packages: anacron-2.3-38.FC6 ------------------ * Thu Apr 13 2006 Jason Vas Dias - 2.3-38.1 - fix bug 188403: anacron SysVinit locking: Since anacron just exits when it has no more work to do, the initscript cannot do normal /var/lock/subsys/anacron lock file creation, else messages such as 'anacron dead but subsys locked' will appear when changing init levels. Now, the anacron process itself creates its own /var/lock/subsys/anacron SysVinit lock file and /var/run/anacron.pid pid file to co-operate more gracefully with the initscript system. bash-3.1-12 ----------- * Thu Apr 13 2006 Tim Waugh 3.1-12 - Patchlevel 17. gnome-terminal-2.14.1-4 ----------------------- * Thu Apr 13 2006 Kristian H??gsberg 2.14.1-4 - Bump for rawhide build. * Thu Apr 13 2006 Kristian H??gsberg 2.14.1-3 - Add vte-0.12.0-real-transparency.patch for extra bling points. kde-i18n-1:3.5.2-2 ------------------ * Thu Apr 13 2006 Than Ngo 1:3.5.2-2 - fix file conflict metacity-2.15.0-5 ----------------- * Thu Apr 13 2006 Soren Sandmann 2.15.0-5 - Update to libcm 0.0.19 * Wed Apr 12 2006 Kristian H??gsberg 2.15.0-4 - Bump for fc5-bling rebuild. net-tools-1.60-67 ----------------- * Thu Apr 13 2006 Radek Vok??l - 1.60-67 - fix wrong definition of _PATH_PROCNET_X25_ROUTE (#188786) netpbm-10.33-2 -------------- * Fri Apr 14 2006 Jindrich Novy 10.33-2 - fix image corruption in ppmtogif, thanks to Gilles Detillieux (#188597) - fix nsting.h to let pnmtopng and other utilities using seekable opening mode work on x86_64 (#188594) * Wed Apr 05 2006 Jindrich Novy 10.33-1 - update to 10.33 - drop upstreamed .ppmdepth patch - fix segfault in ppmtompeg when encoding jpeg images (#185970) * Mon Apr 03 2006 Jindrich Novy 10.32-2 - fix broken symlink in upstream: pnmsdepth -> pamdepth (#187667) openoffice.org-1:2.0.2-5.9.3 ---------------------------- * Wed Apr 12 2006 Caolan McNamara - 1:2.0.2-5.9 - rh#187939# not detecting changes to CUPS printers during execution - rh#188467# set printer font-handling defaults - ooo#59997# opensymbol font metrics changed - rh#161530# new South African locales exist in glibc now * Mon Apr 10 2006 Caolan McNamara - 1:2.0.2-5.8 - rh#188053# more a11y fixes - ooo#63583# committed to workspace.atkbridge parted-1.6.25.1-1 ----------------- * Thu Apr 13 2006 David Cantrell - 1.6.25.1-1 - Upgraded to parted-1.6.25.1 - BuildRequires libtool selinux-policy-2.2.31-1 ----------------------- * Fri Apr 14 2006 Dan Walsh 2.2.31-1 - Update to latest from upstream - Allow mono and unconfined to talk to initrc_t dbus objects system-config-printer-0.7.4-2 ----------------------------- * Thu Apr 13 2006 Tim Waugh 0.7.4-2 - Obsoletes: system-config-printer-gui <= 0.6.152 tar-1.15.1-15 ------------- * Thu Apr 13 2006 Peter Vrabec 1.15.1-15 - fix segmentation faul introduced with hugeSparse.patch udev-089-1 ---------- * Thu Apr 13 2006 Harald Hoyer - 089-1 - version 089 - do not force loading of parport_pc (bug #186850) - manually load snd-powermac (bug #176761) - added usb floppy symlink (bug #185171) - start_udev uses udevtrigger now instead of udevstart vte-0.12.0-3 ------------ * Thu Apr 13 2006 Kristian H??gsberg 0.12.0-3 - Bump for rawhide build. * Thu Apr 13 2006 Kristian H??gsberg 0.12.0-2 - Add vte-0.12.0-real-transparency.patch for extra bling points. xorg-x11-server-1.0.99.901-5 ---------------------------- * Thu Apr 13 2006 Kristian H??gsberg 1.0.99.901-5 - Update spiffiffity patch to only suppress move damage events for manually redirected windows. * Wed Apr 12 2006 Kristian H??gsberg 1.0.99.901-4 - Bump for rawhide build. * Wed Apr 12 2006 Kristian H??gsberg 1.0.99.901-3 - Add xorg-x11-server-1.0.99.901-cow-fix.patch to fix crash when releasing the COW. xterm-212-1.FC6 --------------- * Thu Apr 13 2006 Jason Vas Dias - 212-1 - Upgrade to upstream version 212 - fix bug 188031 : paths in man-page Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU pyparted - 1.6.10-1.2.1.i386 requires libparted-1.6.so.14 Broken deps for ia64 ---------------------------------------------------------- pyparted - 1.6.10-1.2.1.ia64 requires libparted-1.6.so.14()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- pyparted - 1.6.10-1.2.1.ppc requires libparted-1.6.so.14 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.ppc64 requires libparted-1.6.so.14()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.s390 requires libparted-1.6.so.14 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.s390x requires libparted-1.6.so.14()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU pyparted - 1.6.10-1.2.1.x86_64 requires libparted-1.6.so.14()(64bit) From jarod at wilsonet.com Fri Apr 14 08:18:23 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 14 Apr 2006 01:18:23 -0700 Subject: Intel iMac booting FC5 In-Reply-To: <1144968806.3301.3.camel@daxter.boston.redhat.com> References: <200604130058.34252.lists@wilsonet.com> <1144968806.3301.3.camel@daxter.boston.redhat.com> Message-ID: <200604140118.27141.jarod@wilsonet.com> On Thursday 13 April 2006 15:53, David Zeuthen wrote: > On Thu, 2006-04-13 at 00:58 -0700, Jarod Wilson wrote: > > Anybody else playing with a new Intel Mac trying to get Fedora Core > > working on it? I'm happy to report that I've got my wife's 20" iMac > > booting under its own power as of a few minutes ago. > > I've got a Macbook Pro with Rawhide, but I'm using the kernel from > mactel-linux.org together with a Fedora initrd. Very similar to my setup then. Are you booting via lilo or elilo? > > Still looking into what it takes to get X working -- it works fine in the > > installer if you've got the latest firmware, since syslinux uses the bios > > emulation layer, which provides some basic vga support that allows you to > > use the vesa driver for install, but I'm trying to stick to pure efi. > > Yea, X.org bails for me with > > (EE) FBDEV(0): FBIOBLANK: Invalid Argument > > I haven't tried that hard yet to coerce our resident X hackers to look > at it... I'll have to finally tinker with X some tomorrow w/the day off and all. Got some pointers from ajax, though it looks like you're already doing what he suggested... (imacfb w/fbdev for X) > > At the moment, I'm using elilo to load my initrd and kernel, which are > > from a custom kernel build, because the stock i686 kernels have no efi > > goodies enabled. In theory, enabling the necessary bits and adding > > patches to the latest FC kernel should work, but going that route, the HD > > wasn't getting picked up, so I still need to figure out exactly why that > > is, comparing the kernel config from mactel-linux.org to the one I hacked > > together based on the 2080 FC kernel (both had EFI stuff flipped on and > > the iMac patch added). > > Any chance you can post the diff on the config? I'll work on that some tomorrow. Its pretty hefty. > And exactly what patches > to use (I'm using the imac-2.6.16-rc4 one with CONFIG_FB_IMAC set)? I took a stock 2.6.16.5 kernel and patched in the imac-2.6.16.1.patch from mactel-linux.org, also using the 2.6.16 config from there. Same patch applies cleanly to the 2080 FC kernel, builds and installs fine, but no love on boot. > It would probably be worthwhile to patch Rawhide kernels too, cuz then it's > probably easier talking davej into taking the changes :-) It'll be even easier in two weeks, when I'm sitting just down the hall from him... (Well, at least on the days when he's working from the office. :) I'm hoping we'll get some mactel hardware in the office sooner than later to play with also. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pemboa at gmail.com Fri Apr 14 09:30:56 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 14 Apr 2006 04:30:56 -0500 Subject: Missing system config tools? Message-ID: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> Are there any popular administrative tasks for which a system-config-* tool is missing from Fedora? My last attempt to make one has already been made redundant. Thanks. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heretic at ihug.co.nz Fri Apr 14 09:31:11 2006 From: heretic at ihug.co.nz (David Mohring) Date: Fri, 14 Apr 2006 21:31:11 +1200 Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <1145007071.16571.3.camel@heretic.grobb.org> On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > So I've been kicking around this idea for a while and wanted to see > what others thought. ... > Thoughts, opinions, suggestions? Now and Xen:Complexities of Fedora,Grub,LVM and Xen https://www.redhat.com/archives/fedora-devel-list/2005-April/msg00545.html See the "Thirdly, so-so ideas" under run levels and roles. -- David Mohring From nicolas.mailhot at laposte.net Fri Apr 14 09:52:38 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Apr 2006 11:52:38 +0200 (CEST) Subject: Missing system config tools? In-Reply-To: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> Message-ID: <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> Le Ven 14 avril 2006 11:30, Arthur Pemberton a ?crit : > Are there any popular administrative tasks for which a system-config-* > tool > is missing from Fedora? My last attempt to make one has already been made > redundant. Last time I looked, the lvm conf tool was a bit simplisitic and a great way to destroy a system (hint try it with lvm root) -- Nicolas Mailhot From ggw at wolves.durham.nc.us Fri Apr 14 10:35:05 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Fri, 14 Apr 2006 06:35:05 -0400 Subject: IT821x force pass through mode incantation? Message-ID: <20060414103505.GA2687@wolves.durham.nc.us> I'm trying to force the it8212 raid controller into noraid mode and am having problems figuring out the proper incantation on the kernel command line. I'm running FC5 kernel 2080. I've tried "it821x=noraid" "it8212=noraid" "it821x.noraid" and a few other variations. Does anyone have the proper information? I'm detecting failure to force "pass through" mode from the dmesg line that the driver tosses out always having "smart" mode printed. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From stickster at gmail.com Fri Apr 14 11:46:52 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 14 Apr 2006 07:46:52 -0400 Subject: Where am I? Do we need a Location Profiler? In-Reply-To: <1144951902.2465.15.camel@dhollis-lnx.sunera.com> References: <1144926062.5527.25.camel@averatec> <1144951902.2465.15.camel@dhollis-lnx.sunera.com> Message-ID: <1145015212.2035.19.camel@localhost.localdomain> On Thu, 2006-04-13 at 14:11 -0400, David Hollis wrote: > On Thu, 2006-04-13 at 07:01 -0400, Jon Nettleton wrote: > > > 1) catch Network state changes, obviously through the NetworkManager. > > Base different locations off of default route ip and hardware address, > > if wireless maybe essid? > > 2) Needs a privileged and unprivileged interface. Some apps like ntpd, > > iptables, cups, network filesystems, general services, all need to be > > setup by root. Others, gweather, default printer, network servers > > (gnome-vfs), mail settings, screensaver timeout, are user specific. > > 3) No reason to be a daemon running all the time. We have > > NetworkManagerDispatcher already running, why not use that? This also > > doesn't need to be super fast or small, allowing higher level languages > > to be used. > > A similar app on the Windows side (for IBM systems anyway) would be IBM > Access Connections. It's actually a pretty evil app, but it's > intentions are pretty good. Based on your location profile, you can > specify your default printer, drive mappings, whether or not to enable > File & Print sharing, etc. Being able to switch yum{, repo} configurations comes to mind as a useful function along the same lines. I have local mirrors available on some networks, not on others. These can be handled with dispatcher.d scripts, but would a user helper be beneficial? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From camilo at mesias.co.uk Fri Apr 14 12:18:58 2006 From: camilo at mesias.co.uk (Cam) Date: Fri, 14 Apr 2006 13:18:58 +0100 Subject: Where am I? Do we need a Location Profiler? In-Reply-To: <1145015212.2035.19.camel@localhost.localdomain> References: <1144926062.5527.25.camel@averatec> <1144951902.2465.15.camel@dhollis-lnx.sunera.com> <1145015212.2035.19.camel@localhost.localdomain> Message-ID: <443F9332.6030004@mesias.co.uk> Paul > Being able to switch yum{, repo} configurations comes to mind as a > useful function along the same lines. I have local mirrors available on > some networks, not on others. These can be handled with dispatcher.d > scripts, but would a user helper be beneficial? There must be lots of configurations that could be usefully set: I can think of things like default printer, network proxy configuration, outgoing mail server etc. For every app that uses these, there should be a framework for the app to be notified of change. For example a weather applet should notice if the http proxy changes after I suspend my machine at home and resume it at work... You might even want to run your security in a stricter mode when you are eg. at a public hot-spot vs. at work or at home with trusted peers; or have different screensaver / lock settings... -Cam -- camilo at mesias.co.uk <-- From dwmw2 at infradead.org Fri Apr 14 12:32:07 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Apr 2006 08:32:07 -0400 Subject: xorg from 1.0.1-9 to 1.0.1-9.fc5 In-Reply-To: <561c252c0604131449w7f181f20p926c667de23a9d4c@mail.gmail.com> References: <561c252c0604131449w7f181f20p926c667de23a9d4c@mail.gmail.com> Message-ID: <1145017928.2697.90.camel@shinybook.infradead.org> On Thu, 2006-04-13 at 23:49 +0200, Gianluca Cecchi wrote: > Is the "fc5" postfix to tell that the update is only needed for a > particular architecture or what does it mean? In that case why does > yum try to update it anyway on x86? No, the 'fc5' postfix was just a poor choice of name. The bug exists on all architectures and scribbles on random memory. The mention of PPC is just because it happens to cause this particular crash on PPC fairly reliably -- we're not entirely sure how it manifests itself on other architectures. -- dwmw2 From mmcgrath at fedoraproject.org Fri Apr 14 13:40:55 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 14 Apr 2006 08:40:55 -0500 Subject: Kickstart and roles In-Reply-To: <1144992236.14377.13.camel@cutter> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <200604140012.07541.loony@loonybin.org> <1144992236.14377.13.camel@cutter> Message-ID: <443FA667.8030900@fedoraproject.org> seth vidal wrote: > or, fairly simply: > > You setup a web app that takes the info on what the user wants on the > box and stores it in a db. Then it returns a url encoded to retrieve a > ks.cfg from a cgi based on the info in the db. > > Then for the ks you specify the location of the ks.cfg as the > aforementioned url. > > That's it. > > -sv I have a script similar to this setup already (one I was thinking about using too). It reads configs from ini files on the back end and takes flags so users can manually change some things. -Mike From cjb at mrao.cam.ac.uk Fri Apr 14 15:01:04 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Fri, 14 Apr 2006 11:01:04 -0400 Subject: IT821x force pass through mode incantation? References: <20060414103505.GA2687@wolves.durham.nc.us> Message-ID: <87fykggq1b.fsf@mrao.cam.ac.uk> >> On Fri, 14 Apr 2006 06:35:05 -0400, "G.Wolfe Woodbury said: > I'm trying to force the it8212 raid controller into noraid mode and > am having problems figuring out the proper incantation on the > kernel command line. I'd expect: it821x.noraid=1 to be the correct incantation. You should hit the following if the setting is successful: printk(KERN_INFO "it8212: forcing bypass mode.\n"); -- Chris Ball From galibert at pobox.com Fri Apr 14 14:40:23 2006 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 14 Apr 2006 16:40:23 +0200 Subject: Where is my "everything" gone? In-Reply-To: <1144866136.29397.20.camel@enki.eridu> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412162820.GA642@devserv.devel.redhat.com> <20060412165055.GA97334@dspnet.fr.eu.org> <1144866136.29397.20.camel@enki.eridu> Message-ID: <20060414144023.GA75835@dspnet.fr.eu.org> On Wed, Apr 12, 2006 at 02:22:16PM -0400, Paul Nasrat wrote: > On Wed, 2006-04-12 at 18:50 +0200, Olivier Galibert wrote: > > On Wed, Apr 12, 2006 at 12:28:20PM -0400, Alan Cox wrote: > > > On Wed, Apr 12, 2006 at 06:17:02PM +0200, Olivier Galibert wrote: > > > > When was it decided that computer farms, servers and remote > > > > administration was unimportant, and only the desktop user was > > > > interesting? Is it official, or just de facto? > > > > > > Kickstart is specifically dessigned to handle these cases. You can script > > > the entire install and do the install "hands-off" > > > > I remember looking at kickstart a long time ago, and it sucked > > horribly when you didn't want to script the _entire_ install. > > Hopefully, it is better now. > > Kickstart has for the longest time prompted you for information not > contained with in the ks.cfg. Please define when you looked and what > you tried more clearly so we can assist you. Statements like "it > sucked" really aren't useful for pointing out potential solutions using > kickstart. "long time ago" means in this case around redhat 7 or so. I'm looking at system-config-kickstart, and unless I misunderstand the (required) tags, you can't get a prompt for what I need to have install-time locally configurable. Specifically: - keyboard type (50% fr, 50% us here) - root password - partitioning With fc3 I had savagely hacked anaconda/loader2 to only ask these and the network configuration. Very useful, it allowed me to give the install CD to pretty much anybody and they ended up with a working system[1]. Anyway, I'll try removing the entries from the ks.cfg and see how it goes. OG. [1] Yes, they *are* smart enough to partition correctly :-) From jkeating at j2solutions.net Fri Apr 14 15:40:00 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 14 Apr 2006 11:40:00 -0400 Subject: Where is my "everything" gone? In-Reply-To: <20060414144023.GA75835@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412162820.GA642@devserv.devel.redhat.com> <20060412165055.GA97334@dspnet.fr.eu.org> <1144866136.29397.20.camel@enki.eridu> <20060414144023.GA75835@dspnet.fr.eu.org> Message-ID: <1145029200.12197.6.camel@ender> On Fri, 2006-04-14 at 16:40 +0200, Olivier Galibert wrote: > > "long time ago" means in this case around redhat 7 or so. > > I'm looking at system-config-kickstart, and unless I misunderstand the > (required) tags, you can't get a prompt for what I need to have > install-time locally configurable. Specifically: > - keyboard type (50% fr, 50% us here) > - root password > - partitioning I'm almost certain you can get prompted for these, especially when using interactive, a flag to tell anaconda to use the kickstart info as a default, but still show each screen for the user to click through. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caolanm at redhat.com Fri Apr 14 15:50:58 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 14 Apr 2006 16:50:58 +0100 Subject: yet another x86_64 OOo milestone build Message-ID: <1145029858.21443.5.camel@localhost.localdomain> Latest upstream style rpms of an x86_64 OOo from the latest milestone of SRC680_m163 now available from: http://people.redhat.com/caolanm/x86_64 If you find yourself compelled to test them and find something seriously broken, log a bug on qa.openoffice.org and assign to cmc at openoffice.org C. From pnasrat at redhat.com Fri Apr 14 15:52:53 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 14 Apr 2006 11:52:53 -0400 Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <1145029974.2804.6.camel@enki.eridu> On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > So I've been kicking around this idea for a while and wanted to see > what others thought. Who knows maybe someone will be interested in > helping. > > This may already exist so if it does please let me know but I would > like to setup a bunch of kickstart scripts for server and workstation > roles using only official Fedora software. For example, lets say > someone wants a xen workstation. We could setup a kickstart script > with everything they need, only the minimals and at the end, yum > update, configure what we can and on reboot, that user has a working > xen machine. For the kickstart side you should checkout pykickstart that's a great start, as we now have a library for reading/writing ks files. Paul From florin at andrei.myip.org Fri Apr 14 16:01:25 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 14 Apr 2006 09:01:25 -0700 Subject: yum rudeness In-Reply-To: <1144942945.2294.347.camel@sundaram.pnq.redhat.com> References: <443E7042.7070200@mindspring.com> <1144942914.10731.35.camel@cutter> <1144942945.2294.347.camel@sundaram.pnq.redhat.com> Message-ID: <1145030485.7140.2.camel@stantz.corp.sgi.com> On Thu, 2006-04-13 at 21:12 +0530, Rahul Sundaram wrote: > On Thu, 2006-04-13 at 11:41 -0400, seth vidal wrote: > > > > Then in /etc/yum.conf for fc5 keepcache=0 > > > > I thought, but I can't find the note, that this was mentioned in the > > release notes. > > Missed the string freeze. Will be in an errata > > http://fedoraproject.org/wiki/Docs/Beats/PackageNotes IMO, a better policy would be to leave keepcache=1 in place, but then add to the daily or weekly cron job: yum clean packages Long-term it's the same, but it's better for those who actually use the cache for various purposes. It might also reduce the load on the Fedora yum mirrors in cases some people are playing with repeated package install/deinstall. -- Florin Andrei http://florin.myip.org/ From ggw at wolves.durham.nc.us Fri Apr 14 16:29:13 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Fri, 14 Apr 2006 12:29:13 -0400 Subject: IT821x force pass through mode incantation? In-Reply-To: <87fykggq1b.fsf@mrao.cam.ac.uk> References: <20060414103505.GA2687@wolves.durham.nc.us> <87fykggq1b.fsf@mrao.cam.ac.uk> Message-ID: <20060414162913.GA2693@wolves.durham.nc.us> On Fri, Apr 14, 2006 at 11:01:04AM -0400, Chris Ball wrote: > >> On Fri, 14 Apr 2006 06:35:05 -0400, "G.Wolfe Woodbury said: > > > I'm trying to force the it8212 raid controller into noraid mode and > > am having problems figuring out the proper incantation on the > > kernel command line. > > I'd expect: > > it821x.noraid=1 > > to be the correct incantation. You should hit the following if the > setting is successful: > > printk(KERN_INFO "it8212: forcing bypass mode.\n"); > -- > Chris Ball Thank you Chris. That forced it into pass through mode. Now, the device/driver is consistently dropping interrupts and having DMA timeouts. It is in sore need of some work. Thanks muchly for the assistance. Wolfe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From alan at redhat.com Fri Apr 14 16:37:01 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 14 Apr 2006 12:37:01 -0400 Subject: IT821x force pass through mode incantation? In-Reply-To: <20060414162913.GA2693@wolves.durham.nc.us> References: <20060414103505.GA2687@wolves.durham.nc.us> <87fykggq1b.fsf@mrao.cam.ac.uk> <20060414162913.GA2693@wolves.durham.nc.us> Message-ID: <20060414163701.GB30624@devserv.devel.redhat.com> On Fri, Apr 14, 2006 at 12:29:13PM -0400, G.Wolfe Woodbury wrote: > Now, the device/driver is consistently dropping interrupts and having DMA > timeouts. It is in sore need of some work. If it is missing all the IRQs then that sounds like a board level IRQ routing problem not a driver one. If it only misses some then it may be driver level. I'm working on a new it821x driver for libata but I'd appreciate a detailed report of the problem you have and maybe can chase down old driver bugs too. Alan From mmcgrath at fedoraproject.org Fri Apr 14 16:42:23 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 14 Apr 2006 11:42:23 -0500 Subject: Kickstart and roles In-Reply-To: <1145029974.2804.6.camel@enki.eridu> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145029974.2804.6.camel@enki.eridu> Message-ID: <443FD0EF.1020107@fedoraproject.org> Paul Nasrat wrote: > On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > >> So I've been kicking around this idea for a while and wanted to see >> what others thought. Who knows maybe someone will be interested in >> helping. >> >> This may already exist so if it does please let me know but I would >> like to setup a bunch of kickstart scripts for server and workstation >> roles using only official Fedora software. For example, lets say >> someone wants a xen workstation. We could setup a kickstart script >> with everything they need, only the minimals and at the end, yum >> update, configure what we can and on reboot, that user has a working >> xen machine. >> > > For the kickstart side you should checkout pykickstart that's a great > start, as we now have a library for reading/writing ks files. > > Paul > Thats a good idea, I guess I kind of envision this as being a way to A) showcase what Fedora's become using only Fedora software. And B) allow others to have easy access to things like an email server or a Xen workstation. -Mike From david at fubar.dk Fri Apr 14 17:05:39 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 14 Apr 2006 13:05:39 -0400 Subject: Intel iMac booting FC5 In-Reply-To: <200604140118.27141.jarod@wilsonet.com> References: <200604130058.34252.lists@wilsonet.com> <1144968806.3301.3.camel@daxter.boston.redhat.com> <200604140118.27141.jarod@wilsonet.com> Message-ID: <1145034340.2461.1.camel@daxter.boston.redhat.com> On Fri, 2006-04-14 at 01:18 -0700, Jarod Wilson wrote: > Very similar to my setup then. Are you booting via lilo or elilo? Via rEFIt on a separate partition so elilo I guess. > I'll have to finally tinker with X some tomorrow w/the day off and all. Got > some pointers from ajax, though it looks like you're already doing what he > suggested... (imacfb w/fbdev for X) Yea, that's what the live cd at mactel-linux does. > I took a stock 2.6.16.5 kernel and patched in the imac-2.6.16.1.patch from > mactel-linux.org, also using the 2.6.16 config from there. Same patch applies > cleanly to the 2080 FC kernel, builds and installs fine, but no love on boot. Same for me. > I'm hoping we'll get some mactel hardware in the office sooner than later to > play with also. Sounds good, thanks. David From pemboa at gmail.com Fri Apr 14 17:26:07 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 14 Apr 2006 12:26:07 -0500 Subject: Missing system config tools? In-Reply-To: <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> Message-ID: <16de708d0604141026t2ee685fcv929649a5935b1c6d@mail.gmail.com> On 4/14/06, Nicolas Mailhot wrote: > > > Le Ven 14 avril 2006 11:30, Arthur Pemberton a ?crit : > > Are there any popular administrative tasks for which a system-config-* > > tool > > is missing from Fedora? My last attempt to make one has already been > made > > redundant. > > Last time I looked, the lvm conf tool was a bit simplisitic and a great > way to destroy a system (hint try it with lvm root) > Destroy a system you say huh. I don't think I have enough Karma to spare for that. Any other suggestions? -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.nettleton at gmail.com Fri Apr 14 17:43:17 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 14 Apr 2006 13:43:17 -0400 Subject: Missing system config tools? In-Reply-To: <16de708d0604141026t2ee685fcv929649a5935b1c6d@mail.gmail.com> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> <16de708d0604141026t2ee685fcv929649a5935b1c6d@mail.gmail.com> Message-ID: <1145036598.5527.54.camel@averatec> On Fri, 2006-04-14 at 12:26 -0500, Arthur Pemberton wrote: > > > On 4/14/06, Nicolas Mailhot wrote: > > Le Ven 14 avril 2006 11:30, Arthur Pemberton a ?crit : > > Are there any popular administrative tasks for which a > system-config-* > > tool > > is missing from Fedora? My last attempt to make one has > already been made > > redundant. > > Last time I looked, the lvm conf tool was a bit simplisitic > and a great > way to destroy a system (hint try it with lvm root) > > Destroy a system you say huh. I don't think I have enough Karma to > spare for that. Any other suggestions? > I have been toying around with updating the users and groups control panel to be able to administer users and groups on an ldap server. I also have a mock up of adding a security tab that allows you to add groups to the UGROUP setting in /etc/security/console.apps. This would allow us the "power user functionality" for certain configuration items without needing the root password. If that interests you I would be more than happy to pass it along. Jon From sundaram at fedoraproject.org Fri Apr 14 18:00:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 14 Apr 2006 23:30:46 +0530 Subject: Missing system config tools? In-Reply-To: <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> Message-ID: <1145037646.2294.394.camel@sundaram.pnq.redhat.com> On Fri, 2006-04-14 at 11:52 +0200, Nicolas Mailhot wrote: > Le Ven 14 avril 2006 11:30, Arthur Pemberton a ?crit : > > Are there any popular administrative tasks for which a system-config-* > > tool > > is missing from Fedora? My last attempt to make one has already been made > > redundant. > > Last time I looked, the lvm conf tool was a bit simplisitic and a great > way to destroy a system (hint try it with lvm root) Bug report? Rahul From nicolas.mailhot at laposte.net Fri Apr 14 18:27:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Apr 2006 20:27:00 +0200 Subject: Missing system config tools? In-Reply-To: <1145037646.2294.394.camel@sundaram.pnq.redhat.com> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> <1145037646.2294.394.camel@sundaram.pnq.redhat.com> Message-ID: <1145039228.7323.3.camel@rousalka.dyndns.org> Le vendredi 14 avril 2006 ? 23:30 +0530, Rahul Sundaram a ?crit : > On Fri, 2006-04-14 at 11:52 +0200, Nicolas Mailhot wrote: > > Le Ven 14 avril 2006 11:30, Arthur Pemberton a ?crit : > > > Are there any popular administrative tasks for which a system-config-* > > > tool > > > is missing from Fedora? My last attempt to make one has already been made > > > redundant. > > > > Last time I looked, the lvm conf tool was a bit simplisitic and a great > > way to destroy a system (hint try it with lvm root) > > Bug report? Not before I reproduce it with latest version, and I'm not in my system-eating phase right now. For those interested the procedure was to install / on an lvm, then try to move the lvm to a pvm (on another raid volume in my case, don't know if it's important) -- 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 mandreiana.lists at gmail.com Fri Apr 14 19:37:17 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Fri, 14 Apr 2006 22:37:17 +0300 Subject: FC5 (lack of) quality Message-ID: <1145043438.2709.31.camel@localhost.localdomain> Greetings, I've installed FC5 in the same week it was released (as usual), after using FC5test on one of my systems. After almost a month I'd like to share my impressions, not as a rant, but as sign of warning regarding release quality. There are a lot of regressions from FC4. First, the replicable ones: * webdav in nautilus is very slow, unusable for daily usage (made bug, no reply) * TV tuner no longer working (made bug, seems like udev issue after some research, no reply) * totem subtitles no longer work properly (lots of "???" instead of letters) * on a 256mb RAM system GNOME it's hardly usable due to swapping with more than 2 applications opened (firefox and another small one, no ooo). Only minimal services (network, xfs..) are started automatically. These wouldn't have been much of a problem, but there are also several un-replicable issues: * window borders disappear sometimes and then all GNOME freezes. It's possible to go to console with alt+Fn and kill some processes, but no effect. X must be killed and restarted. * once any application trying to output sound (including play on command line) hanged (must use kill -9). Rebooting fixed it. * starting udev gives sometimes "wait timeout. Switching to background [failed]". Due to this, network start failed and bluetooth hanged. Rebooting fixed it. * mplayer complains sometimes that XVideo can't be opened. I know mplayer isn't part of fedora, but the problem is with X. Restarting X makes it work. To conclude, there are many issues impacting user productivity and also a worrying trend "reboot and it should work" (sounds familiar?) I know Fedora is very fast moving and we should expect bugs, but the FC5 release feels like rawhide. Is this intended and daily users should better look to RHEL? (Lack of Fedora Extras for RHEL prevents me to switch right now, the licensing it's not an issue) Do you have any advices for developers? I don't see any real-world solutions (unlike "developers should be more careful when writing code" or make test cases for every function with every use case possible), but still, the number of bugs is growing. Anyway, thanks for FC5 and the important technical developments which were included :) -- Marius Andreiana From jspaleta at gmail.com Fri Apr 14 19:39:26 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 14 Apr 2006 15:39:26 -0400 Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> On 4/14/06, Marius Andreiana wrote: > * TV tuner no longer working (made bug, seems like udev issue after some > research, no reply) what video driver? -jef From mandreiana.lists at gmail.com Fri Apr 14 20:01:54 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Fri, 14 Apr 2006 23:01:54 +0300 Subject: FC5 (lack of) quality In-Reply-To: <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> Message-ID: <1145044916.2709.48.camel@localhost.localdomain> On Fri, 2006-04-14 at 15:39 -0400, Jeff Spaleta wrote: > On 4/14/06, Marius Andreiana wrote: > > * TV tuner no longer working (made bug, seems like udev issue after some > > research, no reply) > > what video driver? (this would be best moved to fedora-list as it doesn't belong here) i810, motherboard chipset i845GL Bug with more details about the tv tuner (separate PCI card) : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187650 Weird, not lsmod|grep bttv doesn't give anything, it used to show the bttv modules loaded automatically. -- Marius "anyway there's nothing interesting on TV" Andreiana From seg at haxxed.com Fri Apr 14 20:40:21 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 14 Apr 2006 15:40:21 -0500 Subject: Missing system config tools? In-Reply-To: <1145039228.7323.3.camel@rousalka.dyndns.org> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> <1145037646.2294.394.camel@sundaram.pnq.redhat.com> <1145039228.7323.3.camel@rousalka.dyndns.org> Message-ID: <1145047222.4360.35.camel@hamburger.booze> On Fri, 2006-04-14 at 20:27 +0200, Nicolas Mailhot wrote: > For those interested the procedure was to install / on an lvm, then try > to move the lvm to a pvm (on another raid volume in my case, don't know > if it's important) Errr. Do you mean moving an LV to another PV? As in using pvmove? I had rather serious system eating (but ultimately recoverable) problems with pvmove when I moved my system to LVM using an FC5 rescue disk. It may not just be system-config-lvm. For no reason I could figure out, about half the time pvmove would crash and totally eat the PV metadata. This happened several times. Trying to do anything would just result in messages such as: Incorrect metadata area header checksum Inconsistent metadata copies found - updating to use version 8 Automatic metadata correction failed A full verbose log: http://fedora.pastebin.com/634358 (Note, piping the log to a file seemed to have messed up the order a bit from how it appears on screen) The trick to recovering: 1) Back up the VG metadata 2) Rewrite the PV metadata on *every* pv like so: http://www.tldp.org/HOWTO/LVM-HOWTO/recovermetadata.html You will be told you have to use -ff. Do it. 3) You will now find your VG is completely gone. Don't panic, restore the backup. Your VG should be back now. My googling couldn't find anyone with quite the same problem. The best I could find was "Back up the metadata then restore", which wasn't quite enough here. As usual I'm slacking about bugzilla-ing. I wanted to be more sure about what was causing it to mess up, but that hasn't happened. Its entirely random near as I can tell. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Fri Apr 14 20:43:47 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 14 Apr 2006 15:43:47 -0500 Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: <16de708d0604141343x301f0b65p7481906b53dc7e0a@mail.gmail.com> On 4/14/06, Marius Andreiana wrote: > > Greetings, > > I've installed FC5 in the same week it was released (as usual), after > using FC5test on one of my systems. After almost a month I'd like to > share my impressions, not as a rant, but as sign of warning regarding > release quality. > > There are a lot of regressions from FC4. First, the replicable ones: > * webdav in nautilus is very slow, unusable for daily usage (made bug, > no reply) > * TV tuner no longer working (made bug, seems like udev issue after some > research, no reply) > * totem subtitles no longer work properly (lots of "???" instead of > letters) > * on a 256mb RAM system GNOME it's hardly usable due to swapping with > more than 2 applications opened (firefox and another small one, no ooo). > Only minimal services (network, xfs..) are started automatically. > > These wouldn't have been much of a problem, but there are also several > un-replicable issues: > * window borders disappear sometimes and then all GNOME freezes. It's > possible to go to console with alt+Fn and kill some processes, but no > effect. X must be killed and restarted. > * once any application trying to output sound (including play on command > line) hanged (must use kill -9). Rebooting fixed it. > * starting udev gives sometimes "wait timeout. Switching to background > [failed]". Due to this, network start failed and bluetooth hanged. > Rebooting fixed it. > * mplayer complains sometimes that XVideo can't be opened. I know > mplayer isn't part of fedora, but the problem is with X. Restarting X > makes it work. > > To conclude, there are many issues impacting user productivity and also > a worrying trend "reboot and it should work" (sounds familiar?) I know > Fedora is very fast moving and we should expect bugs, but the FC5 > release feels like rawhide. Is this intended and daily users should > better look to RHEL? (Lack of Fedora Extras for RHEL prevents me to > switch right now, the licensing it's not an issue) > > Do you have any advices for developers? I don't see any real-world > solutions (unlike "developers should be more careful when writing code" > or make test cases for every function with every use case possible), but > still, the number of bugs is growing. > > Anyway, thanks for FC5 and the important technical developments which > were included :) > > -- > Marius Andreiana > > Pity. I'm sorry to hear that. Things workd perfectly (almost) with me for FC5 and KDE. Ironically the other day a poster called KDE a second class citizen in Fedora. I think I am doing more with my desktop in FC5 than in FC4. The only issues I am having is with my wificard and the madwifi drivers from livna. I hope you gets your issues resolved. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seg at haxxed.com Fri Apr 14 20:52:46 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 14 Apr 2006 15:52:46 -0500 Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: <1145047967.4360.41.camel@hamburger.booze> On Fri, 2006-04-14 at 22:37 +0300, Marius Andreiana wrote: > I know Fedora is very fast moving and we should expect bugs, but the FC5 > release feels like rawhide. You clearly haven't used rawhide. But in all seriousness, the number of bugs that popped up post test3, *during* the code freeze, was rather unsettling. I didn't even have time to get things bugzilled before release. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Apr 14 20:17:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 14 Apr 2006 22:17:01 +0200 Subject: FC5 (lack of) quality In-Reply-To: <1145044916.2709.48.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> <1145044916.2709.48.camel@localhost.localdomain> Message-ID: <1145045824.8039.5.camel@rousalka.dyndns.org> Le vendredi 14 avril 2006 ? 23:01 +0300, Marius Andreiana a ?crit : > On Fri, 2006-04-14 at 15:39 -0400, Jeff Spaleta wrote: > > On 4/14/06, Marius Andreiana wrote: > > > * TV tuner no longer working (made bug, seems like udev issue after some > > > research, no reply) > > > > what video driver? > (this would be best moved to fedora-list as it doesn't belong here) > i810, motherboard chipset i845GL > > Bug with more details about the tv tuner (separate PCI card) : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187650 > > Weird, not lsmod|grep bttv doesn't give anything, it used to show the > bttv modules loaded automatically. v4l has been changing at a fast rate upstream lately, with some old stuff being phased out, and other restructured, so it's perfectly possible udev has not caught up yet. You're paying all the years v4l was developed mainly in an external CVS. Hopefully it'll soon become a boring kernel subsystem like networking. But there is some pain ahead this year -- 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 mandreiana.lists at gmail.com Fri Apr 14 21:12:03 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sat, 15 Apr 2006 00:12:03 +0300 Subject: FC5 (lack of) quality In-Reply-To: <1145045824.8039.5.camel@rousalka.dyndns.org> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> <1145044916.2709.48.camel@localhost.localdomain> <1145045824.8039.5.camel@rousalka.dyndns.org> Message-ID: <1145049123.2709.56.camel@localhost.localdomain> On Fri, 2006-04-14 at 22:17 +0200, Nicolas Mailhot wrote: > v4l has been changing at a fast rate upstream lately, with some old > stuff being phased out, and other restructured, so it's perfectly > possible udev has not caught up yet. > > You're paying all the years v4l was developed mainly in an external CVS. > Hopefully it'll soon become a boring kernel subsystem like networking. > But there is some pain ahead this year Would have been nice to have this in release notes, so users which really want TV stick to FC4 and users which choose to upgrade ignore their tv tuners (I will now). I've updated the bug with this info, moved to udev and put severity from normal to low. Thanks, -- Marius Andreiana From fedora at camperquake.de Fri Apr 14 21:31:06 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 14 Apr 2006 23:31:06 +0200 Subject: Missing system config tools? In-Reply-To: <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> Message-ID: <20060414233106.419462f4@nausicaa.camperquake.de> Hi. "Nicolas Mailhot" wrote: > Last time I looked, the lvm conf tool was a bit simplisitic and a great > way to destroy a system (hint try it with lvm root) I've migrated my LVM root system to a different disk using it during the FC5 test cycle. It can't be that bad :) -- Civilization is the agreement to have gaps between wars. From Lam at Lam.pl Fri Apr 14 21:58:52 2006 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 14 Apr 2006 23:58:52 +0200 Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: <1145051933.10886.23.camel@pensja.lam.pl> Dnia 14-04-2006, pi? o godzinie 22:37 +0300, Marius Andreiana napisa?(a): > * window borders disappear sometimes and then all GNOME freezes. It's > possible to go to console with alt+Fn and kill some processes, but no > effect. X must be killed and restarted. This happened every time I tried to minimize XMMS without WM decorations. Try: rpm -Fvh http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/5/i386/metacity-2.14.2-1.fc5.2.i386.rpm I don't know what's stopping it from being pushed to updates (non-testing), works for me (at the moment ;)) and the crashes are gone. > * once any application trying to output sound (including play on command > line) hanged (must use kill -9). Rebooting fixed it. XMMS suspected again :) Every time any program is playing something with OSS emulation (most likely the Flash plugin or mplayerplug-in with its default setting (hint to Anvil or someone other from livna)) and XMMS wants to play using ALSA device "default", something weird happens - XMMS correctly (or not - where's dmix when we need it?) reports it cannot play, but then locks ALSA "default" - hanging every other program until I close XMMS. In my case, I wouldn't even notice because I use hw:0,1 in XMMS anyhow, but there are people using "default" and someone let me know. So, the first thing is fixed in updates-testing and the other, well, for me it's not only XMMS' fault - blocking of whole ALSA (e.g. sox -t alsa default - that's what `play` runs) when there's one OSS ABI program playing (sox -t ossdsp /dev/dsp on another vt) - even if my sound card has hardware mixing - is wrong. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From pemboa at gmail.com Fri Apr 14 22:04:50 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 14 Apr 2006 17:04:50 -0500 Subject: FC5 (lack of) quality In-Reply-To: <1145049123.2709.56.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> <1145044916.2709.48.camel@localhost.localdomain> <1145045824.8039.5.camel@rousalka.dyndns.org> <1145049123.2709.56.camel@localhost.localdomain> Message-ID: <16de708d0604141504p573b5eefke66eb4e167d3ffa0@mail.gmail.com> On 4/14/06, Marius Andreiana wrote: > > On Fri, 2006-04-14 at 22:17 +0200, Nicolas Mailhot wrote: > > v4l has been changing at a fast rate upstream lately, with some old > > stuff being phased out, and other restructured, so it's perfectly > > possible udev has not caught up yet. > > > > You're paying all the years v4l was developed mainly in an external CVS. > > Hopefully it'll soon become a boring kernel subsystem like networking. > > But there is some pain ahead this year > Would have been nice to have this in release notes, so users which > really want TV stick to FC4 and users which choose to upgrade ignore > their tv tuners (I will now). > > I've updated the bug with this info, moved to udev and put severity from > normal to low. > > Thanks, > -- > Marius Andreiana Just to let you know all is not lost, my tv card works (almost) as well as in FC4 and didn't require any confiugration. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjy.grogan at gmail.com Fri Apr 14 22:51:23 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 14 Apr 2006 18:51:23 -0400 Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: On 4/14/06, Marius Andreiana wrote: > Greetings, > > I've installed FC5 in the same week it was released (as usual), after > using FC5test on one of my systems. After almost a month I'd like to > share my impressions, not as a rant, but as sign of warning regarding > release quality. > > There are a lot of regressions from FC4. First, the replicable ones: > * webdav in nautilus is very slow, unusable for daily usage (made bug, > no reply) > * TV tuner no longer working (made bug, seems like udev issue after some > research, no reply) Not getting a reply has been my experience with Fedora Extras. As soon as I have time I'm going to see if I can help out with some of the packages that I've found poorly maintained. It's hard to tell if a package is being poorly maintained, or if the maintainer has gone into stealth mode to resurface at a later date with all kinds of work done. Question: How to find out if an Extras package is being worked on, and if further work is being done on it (such as adding SELInux policy, upgrading version, etc...)? Benjy > * totem subtitles no longer work properly (lots of "???" instead of > letters) > * on a 256mb RAM system GNOME it's hardly usable due to swapping with > more than 2 applications opened (firefox and another small one, no ooo). > Only minimal services (network, xfs..) are started automatically. > > These wouldn't have been much of a problem, but there are also several > un-replicable issues: > * window borders disappear sometimes and then all GNOME freezes. It's > possible to go to console with alt+Fn and kill some processes, but no > effect. X must be killed and restarted. > * once any application trying to output sound (including play on command > line) hanged (must use kill -9). Rebooting fixed it. > * starting udev gives sometimes "wait timeout. Switching to background > [failed]". Due to this, network start failed and bluetooth hanged. > Rebooting fixed it. > * mplayer complains sometimes that XVideo can't be opened. I know > mplayer isn't part of fedora, but the problem is with X. Restarting X > makes it work. > > To conclude, there are many issues impacting user productivity and also > a worrying trend "reboot and it should work" (sounds familiar?) I know > Fedora is very fast moving and we should expect bugs, but the FC5 > release feels like rawhide. Is this intended and daily users should > better look to RHEL? (Lack of Fedora Extras for RHEL prevents me to > switch right now, the licensing it's not an issue) > > Do you have any advices for developers? I don't see any real-world > solutions (unlike "developers should be more careful when writing code" > or make test cases for every function with every use case possible), but > still, the number of bugs is growing. > > Anyway, thanks for FC5 and the important technical developments which > were included :) > > -- > Marius Andreiana > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lamont at gurulabs.com Fri Apr 14 21:30:46 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 14 Apr 2006 15:30:46 -0600 Subject: Missing system config tools? In-Reply-To: <1145047222.4360.35.camel@hamburger.booze> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <1145039228.7323.3.camel@rousalka.dyndns.org> <1145047222.4360.35.camel@hamburger.booze> Message-ID: <200604141530.57653.lamont@gurulabs.com> On Friday 14 April 2006 02:40pm, Callum Lerwick wrote: > On Fri, 2006-04-14 at 20:27 +0200, Nicolas Mailhot wrote: > > For those interested the procedure was to install / on an lvm, then try > > to move the lvm to a pvm (on another raid volume in my case, don't know > > if it's important) > > Errr. Do you mean moving an LV to another PV? As in using pvmove? I had > rather serious system eating (but ultimately recoverable) problems with > pvmove when I moved my system to LVM using an FC5 rescue disk. It may > not just be system-config-lvm. For no reason I could figure out, about > half the time pvmove would crash and totally eat the PV metadata. Since you were in a rescue environment, did you activate the Volume Group (VG)? pvmove has always worked perfectly for me on a *running* system. It is designed to migrate your data to free PEs not on the PV that you specify, and to do so while everything is online, mounted and in use. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From seandarcy2 at gmail.com Sat Apr 15 01:43:11 2006 From: seandarcy2 at gmail.com (sean) Date: Fri, 14 Apr 2006 21:43:11 -0400 Subject: yet another x86_64 OOo milestone build In-Reply-To: <1145029858.21443.5.camel@localhost.localdomain> References: <1145029858.21443.5.camel@localhost.localdomain> Message-ID: Caolan McNamara wrote: > Latest upstream style rpms of an x86_64 OOo from the latest milestone of > SRC680_m163 now available from: > > http://people.redhat.com/caolanm/x86_64 > > > If you find yourself compelled to test them and find something seriously > broken, log a bug on qa.openoffice.org and assign to cmc at openoffice.org > > C. > Any srpms? sean From ggw at wolves.durham.nc.us Sat Apr 15 02:52:08 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Fri, 14 Apr 2006 22:52:08 -0400 Subject: IT821x force pass through mode incantation? In-Reply-To: <20060414163701.GB30624@devserv.devel.redhat.com> References: <20060414103505.GA2687@wolves.durham.nc.us> <87fykggq1b.fsf@mrao.cam.ac.uk> <20060414162913.GA2693@wolves.durham.nc.us> <20060414163701.GB30624@devserv.devel.redhat.com> Message-ID: <20060415025208.GA7919@wolves.durham.nc.us> On Fri, Apr 14, 2006 at 12:37:01PM -0400, Alan Cox wrote: > On Fri, Apr 14, 2006 at 12:29:13PM -0400, G.Wolfe Woodbury wrote: > > Now, the device/driver is consistently dropping interrupts and having DMA > > timeouts. It is in sore need of some work. > > If it is missing all the IRQs then that sounds like a board level IRQ routing > problem not a driver one. If it only misses some then it may be driver level. > I'm working on a new it821x driver for libata but I'd appreciate a detailed > report of the problem you have and maybe can chase down old driver bugs too. > > Alan It obviously doesn't miss all the interrupts, since it manages to get information from the drive. The situation is that under heavy load the system apparently loses some interrupts an freezes the system. There are no remains to post mortem, as the system has to be reset to recover. I can reliably make the system lock up by adding BOINC(SETI at Home) to the mix. This is with the card in smart mode, but no RAID setup on the attached disks. That is, two Hitachi DeskStar 400GB drives are attached, but they are not configured as members of a RAID set. When I add the it821x.noraid=1 to the kernel command line, then the system won't even boot because all the interrupts get lost somewhere. It is a little odd, since "hde" will eventually work, but "hdf" (an identical drive) drops nearly every interrupt in pass through mode. I may be able to arrange to capture the dmesg traces of the failed boots, but it will be difficult. G.Wolfe Woodbury -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From stickster at gmail.com Sat Apr 15 02:56:01 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 14 Apr 2006 22:56:01 -0400 Subject: FC5 (lack of) quality In-Reply-To: <1145049123.2709.56.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> <1145044916.2709.48.camel@localhost.localdomain> <1145045824.8039.5.camel@rousalka.dyndns.org> <1145049123.2709.56.camel@localhost.localdomain> Message-ID: <1145069761.8934.15.camel@localhost.localdomain> On Sat, 2006-04-15 at 00:12 +0300, Marius Andreiana wrote: > On Fri, 2006-04-14 at 22:17 +0200, Nicolas Mailhot wrote: > > v4l has been changing at a fast rate upstream lately, with some old > > stuff being phased out, and other restructured, so it's perfectly > > possible udev has not caught up yet. > > > > You're paying all the years v4l was developed mainly in an external CVS. > > Hopefully it'll soon become a boring kernel subsystem like networking. > > But there is some pain ahead this year > Would have been nice to have this in release notes, so users which > really want TV stick to FC4 and users which choose to upgrade ignore > their tv tuners (I will now). The release notes process was (and will continue to be) open and community-driven. If you have a particular interest, I would encourage you to get involved in the process. A single "beat" (subject matter area) does not take very much time or effort to run and has a huge impact on thousands of users. The release notes for FC5 were -- I think -- one of the most successful ever, thanks to the work of editor Bob Jensen and dozens of Fedora contributors. We do issue errata after the official release, so just because there's nothing in the "static" distro version about your favorite issue doesn't mean we can't add it later to the web-based updates. We look forward to your participation. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Sat Apr 15 05:48:57 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 15 Apr 2006 00:48:57 -0500 Subject: No yum GUI in core? Message-ID: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> Is it just me or is there no GUI to make use of Yum available from the CD installtion? If so, would the GUI be preferable for people not comfortable with using the command line ? Just wondering. Peace -- As a boy I jumped through Windows, as a man I play with Penguins. From rhally at mindspring.com Sat Apr 15 06:42:12 2006 From: rhally at mindspring.com (Richard Hally) Date: Sat, 15 Apr 2006 02:42:12 -0400 Subject: No yum GUI in core? In-Reply-To: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> Message-ID: <444095C4.7020603@mindspring.com> Arthur Pemberton wrote: > Is it just me or is there no GUI to make use of Yum available from the > CD installtion? If so, would the GUI be preferable for people not > comfortable with using the command line ? > > Just wondering. > > Peace > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > It is in the "applications" or "main" menu as Add/Remove Software. The name of the package/program is pirut. rh From michael at knox.net.nz Sat Apr 15 06:46:54 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 15 Apr 2006 18:46:54 +1200 Subject: No yum GUI in core? In-Reply-To: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> Message-ID: <444096DE.2060508@knox.net.nz> Arthur Pemberton wrote: > Is it just me or is there no GUI to make use of Yum available from the > CD installtion? If so, would the GUI be preferable for people not > comfortable with using the command line ? There is "yumex" but its in extras and does require to install it from a shell. However, once its installed, you're set. Michael From buildsys at redhat.com Sat Apr 15 07:17:50 2006 From: buildsys at redhat.com (Build System) Date: Sat, 15 Apr 2006 03:17:50 -0400 Subject: rawhide report: 20060415 changes Message-ID: <200604150717.k3F7HokQ025766@porkchop.devel.redhat.com> Removed package liblbxutil Updated Packages: firefox-1.5.0.2-2 ----------------- * Thu Apr 13 2006 Christopher Aillon - 1.5.0.2-2 - Firefox 1.5.0.2 gcc-4.1.0-8 ----------- * Fri Apr 14 2006 Jakub Jelinek 4.1.0-8 - update from gcc-4_1-branch (-r112825:112951) - PRs c++/26122, c++/26295, fortran/23634, fortran/25619, fortran/26257, libgcj/23829, libgcj/26522, libgfortran/26890, target/27006 - merge gomp changes from trunk (-r112934:112935) - PR libgomp/26651 - fix ICE in gomp handling of EH regions (PR middle-end/26823) gdb-6.3.0.0-1.128.FC6 --------------------- * Fri Apr 14 2006 Alexandre Oliva - 6.3.0.0-1.128 - Avoid race conditions caused by exceptions messing with signal masks. (BZ 175270, BZ 175083, maybe BZ 172938). - Hardcode /bin and /usr/bin paths into gstack (BZ 179829). - Build in a subdir of the source tree instead of in a sibling directory. - Switch to versioning scheme that uses the same base revision number for all OSes, and uses a suffix to tell the builds apart and ensure upgradability. * Thu Apr 13 2006 Stepan Kasal - 6.3.0.0-1.127 - Bump up release number. * Thu Apr 13 2006 Stepan Kasal - 6.3.0.0-1.123 - Use fopen64 where available. Fixes BZ 178796. - Use bigger numbers than int. Fixes BZ 171783. libselinux-1.30.3-1 ------------------- * Fri Apr 14 2006 Dan Walsh 1.30.3-1 - Upgrade to latest from NSA * Added distclean target to Makefile. * Regenerated swig files. * Changed matchpathcon_init to verify that the spec file is a regular file. * Merged python binding t_output_helper removal patch from Dan Walsh. libsemanage-1.6.6-1 ------------------- * Fri Apr 14 2006 Dan Walsh - 1.6.6-1 - Upgrade to latest from NSA * Merged updated file context sorting patch from Christopher Ashworth, with bug fix for escaped character flag. * Merged file context sorting code from Christopher Ashworth (Tresys Technology), based on fc_sort.c code in refpolicy. * Merged python binding t_output_helper removal patch from Dan Walsh. * Regenerated swig files. * Wed Mar 29 2006 Dan Walsh - 1.6.3-1 - Fix to work with new version of swig - Upgrade to latest from NSA * Merged corrected fix for descriptor leak from Dan Walsh. * Wed Mar 29 2006 Dan Walsh - 1.6.2-2 - Fix leaky descriptor net-tools-1.60-68 ----------------- * Fri Apr 14 2006 Radek Vok??l - 1.60-68 - display sctp connections using netstat -S openssh-4.3p2-5 --------------- * Fri Apr 14 2006 Tomas Mraz - 4.3p2-5 - don't request pseudoterminal allocation if stdin is not tty (#188983) policycoreutils-1.30.6-1 ------------------------ * Fri Apr 14 2006 Dan Walsh 1.30.6-1 - Add /etc/samba/secrets.tdb to restorecond.conf - Update from upstream * Merged semanage prefix support from Russell Coker. * Added a test to setfiles to check that the spec file is a regular file. selinux-policy-2.2.32-1 ----------------------- * Fri Apr 14 2006 Dan Walsh 2.2.32-1 - Update to latest from upstream tog-pegasus-2:2.5.1-2.FC6 ------------------------- * Fri Apr 14 2006 Jason Vas Dias - 2:2.5.1-2 - Apply patches for the two '2.5.2_APPROVED' upstream bugzillas 4934(4943) and 4945 : (http://cvs.opengroup.org/bugzilla/buglist.cgi?bug_id=4943%2C4945) - Fix the PATH_MAX and MAXHOSTNAMELEN issues (again) xorg-x11-server-utils-1.0.1-2 ----------------------------- * Fri Apr 14 2006 Adam Jackson 1.0.1-2 - Drop lbxproxy, LBX is deprecated upstream - Update to xhost 1.0.1 * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU pyparted - 1.6.10-1.2.1.i386 requires libparted-1.6.so.14 Broken deps for ia64 ---------------------------------------------------------- pyparted - 1.6.10-1.2.1.ia64 requires libparted-1.6.so.14()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- pyparted - 1.6.10-1.2.1.ppc requires libparted-1.6.so.14 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.ppc64 requires libparted-1.6.so.14()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.s390 requires libparted-1.6.so.14 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 pyparted - 1.6.10-1.2.1.s390x requires libparted-1.6.so.14()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU pyparted - 1.6.10-1.2.1.x86_64 requires libparted-1.6.so.14()(64bit) From pmatilai at laiskiainen.org Sat Apr 15 07:39:38 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 15 Apr 2006 00:39:38 -0700 (PDT) Subject: FC5 (lack of) quality In-Reply-To: <1145043438.2709.31.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: On Fri, 14 Apr 2006, Marius Andreiana wrote: > Greetings, > > I've installed FC5 in the same week it was released (as usual), after > using FC5test on one of my systems. After almost a month I'd like to > share my impressions, not as a rant, but as sign of warning regarding > release quality. > > There are a lot of regressions from FC4. First, the replicable ones: > * on a 256mb RAM system GNOME it's hardly usable due to swapping with > more than 2 applications opened (firefox and another small one, no ooo). > Only minimal services (network, xfs..) are started automatically. Mm.. GNOME in FC5 was supposed to use *less* memory than in previous versions. Have you looked at where exactly does the memory go to - is it really GNOME or something else, like Firefox? (I have a feeling that FF 1.5 is somewhat slower than 1.0.x but that's merely a gut feeling, not measured) I've been planning to update my old T21 with 256M memory to FC5 in hopes of making it work faster, not slower :-/ - Panu - From pemboa at gmail.com Sat Apr 15 08:00:43 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 15 Apr 2006 03:00:43 -0500 Subject: No yum GUI in core? In-Reply-To: <444095C4.7020603@mindspring.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> Message-ID: <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> On 4/15/06, Richard Hally wrote: > Arthur Pemberton wrote: > > Is it just me or is there no GUI to make use of Yum available from the > > CD installtion? If so, would the GUI be preferable for people not > > comfortable with using the command line ? > > > > Just wondering. > > > > Peace > > > > -- > > As a boy I jumped through Windows, as a man I play with Penguins. > > > It is in the "applications" or "main" menu as Add/Remove Software. The > name of the package/program is pirut. > > rh I just loaded that up. It seems to be what it has always has been, a manager of the software available from the install media, ie. no real connection to yum. Correct me if I am wrong. -- As a boy I jumped through Windows, as a man I play with Penguins. From pemboa at gmail.com Sat Apr 15 08:05:14 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 15 Apr 2006 03:05:14 -0500 Subject: No yum GUI in core? In-Reply-To: <444096DE.2060508@knox.net.nz> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444096DE.2060508@knox.net.nz> Message-ID: <16de708d0604150105l40d4216fnba195435d0d33340@mail.gmail.com> On 4/15/06, Michael J Knox wrote: > Arthur Pemberton wrote: > > Is it just me or is there no GUI to make use of Yum available from the > > CD installtion? If so, would the GUI be preferable for people not > > comfortable with using the command line ? > > There is "yumex" but its in extras and does require to install it from a > shell. However, once its installed, you're set. > > Michael > That's what I thought. Don't get me wrong, I prefer using the command line myself. But doesn't having to install yumex via the console, in order to not have to use the console (esp. in the case of newbies) kinda take away from the whole point? I say this because there seems to be a perception outside of Fedora that we (Fedora) has no package management, far less a GUI for the package management. And I see this on public tech forums. (from supposed geeks) Is there any particular reason why yumex does not come on the install media? I think it is fair to say that people new to Fedora (or linux for that matter) would appreciate that. And on a side note, Fedora could do with some better PR. Peace -- As a boy I jumped through Windows, as a man I play with Penguins. From dragoran at feuerpokemon.de Sat Apr 15 08:05:18 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 15 Apr 2006 10:05:18 +0200 Subject: No yum GUI in core? In-Reply-To: <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> Message-ID: <4440A93E.20303@feuerpokemon.de> Arthur Pemberton wrote: > On 4/15/06, Richard Hally wrote: > >> Arthur Pemberton wrote: >> >>> Is it just me or is there no GUI to make use of Yum available from the >>> CD installtion? If so, would the GUI be preferable for people not >>> comfortable with using the command line ? >>> >>> Just wondering. >>> >>> Peace >>> >>> -- >>> As a boy I jumped through Windows, as a man I play with Penguins. >>> >>> >> It is in the "applications" or "main" menu as Add/Remove Software. The >> name of the package/program is pirut. >> >> rh >> > > I just loaded that up. It seems to be what it has always has been, a > manager of the software available from the install media, ie. no real > connection to yum. Correct me if I am wrong. > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > > you are wrong ... it does not even supports media it uses yum for software installation. you can also install packages that aren't on the install media like the extras packages or any other repo you set up in yum. From nicolas.mailhot at laposte.net Sat Apr 15 08:17:37 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 15 Apr 2006 10:17:37 +0200 Subject: Missing system config tools? In-Reply-To: <20060414233106.419462f4@nausicaa.camperquake.de> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <51888.192.54.193.51.1145008358.squirrel@rousalka.dyndns.org> <20060414233106.419462f4@nausicaa.camperquake.de> Message-ID: <1145089060.2578.0.camel@rousalka.dyndns.org> Le vendredi 14 avril 2006 ? 23:31 +0200, Ralf Ertzinger a ?crit : > Hi. > > "Nicolas Mailhot" wrote: > > > Last time I looked, the lvm conf tool was a bit simplisitic and a great > > way to destroy a system (hint try it with lvm root) > > I've migrated my LVM root system to a different disk using it during the > FC5 test cycle. It can't be that bad :) I tried it a few months before, so it may have been fixed since -- 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 pemboa at gmail.com Sat Apr 15 08:20:16 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 15 Apr 2006 03:20:16 -0500 Subject: No yum GUI in core? In-Reply-To: <4440A93E.20303@feuerpokemon.de> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> Message-ID: <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> On 4/15/06, dragoran wrote: > Arthur Pemberton wrote: > > On 4/15/06, Richard Hally wrote: > > > >> Arthur Pemberton wrote: > >> > >>> Is it just me or is there no GUI to make use of Yum available from the > >>> CD installtion? If so, would the GUI be preferable for people not > >>> comfortable with using the command line ? > >>> > >>> Just wondering. > >>> > >>> Peace > >>> > >>> -- > >>> As a boy I jumped through Windows, as a man I play with Penguins. > >>> > >>> > >> It is in the "applications" or "main" menu as Add/Remove Software. The > >> name of the package/program is pirut. > >> > >> rh > >> > > > > I just loaded that up. It seems to be what it has always has been, a > > manager of the software available from the install media, ie. no real > > connection to yum. Correct me if I am wrong. > > > > -- > > As a boy I jumped through Windows, as a man I play with Penguins. > > > > > > you are wrong ... > it does not even supports media it uses yum for software installation. > you can also install packages that aren't on the install media like the > extras packages or any other repo you set up in yum. > Okay, you are most certainly right. I suppose I was misled by it's browse feature which looks exactly like the package selectory in Anaconda. I must say though, the tool isn't very helpful at first look. But thanks for clearing that up. -- As a boy I jumped through Windows, as a man I play with Penguins. From nicolas.mailhot at laposte.net Sat Apr 15 08:20:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 15 Apr 2006 10:20:28 +0200 Subject: Missing system config tools? In-Reply-To: <200604141530.57653.lamont@gurulabs.com> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <1145039228.7323.3.camel@rousalka.dyndns.org> <1145047222.4360.35.camel@hamburger.booze> <200604141530.57653.lamont@gurulabs.com> Message-ID: <1145089231.2578.4.camel@rousalka.dyndns.org> Le vendredi 14 avril 2006 ? 15:30 -0600, Lamont R. Peterson a ?crit : > On Friday 14 April 2006 02:40pm, Callum Lerwick wrote: > > On Fri, 2006-04-14 at 20:27 +0200, Nicolas Mailhot wrote: > > > For those interested the procedure was to install / on an lvm, then try > > > to move the lvm to a pvm (on another raid volume in my case, don't know > > > if it's important) > > > > Errr. Do you mean moving an LV to another PV? As in using pvmove? I had > > rather serious system eating (but ultimately recoverable) problems with > > pvmove when I moved my system to LVM using an FC5 rescue disk. It may > > not just be system-config-lvm. For no reason I could figure out, about > > half the time pvmove would crash and totally eat the PV metadata. > > Since you were in a rescue environment, did you activate the Volume Group > (VG)? > > pvmove has always worked perfectly for me on a *running* system. It is > designed to migrate your data to free PEs not on the PV that you specify, and > to do so while everything is online, mounted and in use. There was a strange problem it got stuck somewhere (and the sc-lvm display would stop refreshing, which was a big help :(), and then after rebooting the kernel would get confused between the original lv and the partially moved one. Like I said, it's the king of problem which needs a lof of hardware and time to pinpoint, so I didn't open a bug then -- 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 nicolas.mailhot at laposte.net Sat Apr 15 08:45:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 15 Apr 2006 10:45:46 +0200 Subject: FC5 (lack of) quality In-Reply-To: <1145049123.2709.56.camel@localhost.localdomain> References: <1145043438.2709.31.camel@localhost.localdomain> <604aa7910604141239g6f070284k95df6a463419691e@mail.gmail.com> <1145044916.2709.48.camel@localhost.localdomain> <1145045824.8039.5.camel@rousalka.dyndns.org> <1145049123.2709.56.camel@localhost.localdomain> Message-ID: <1145090753.2578.12.camel@rousalka.dyndns.org> Le samedi 15 avril 2006 ? 00:12 +0300, Marius Andreiana a ?crit : > On Fri, 2006-04-14 at 22:17 +0200, Nicolas Mailhot wrote: > > v4l has been changing at a fast rate upstream lately, with some old > > stuff being phased out, and other restructured, so it's perfectly > > possible udev has not caught up yet. > > > > You're paying all the years v4l was developed mainly in an external CVS. > > Hopefully it'll soon become a boring kernel subsystem like networking. > > But there is some pain ahead this year > Would have been nice to have this in release notes, so users which > really want TV stick to FC4 and users which choose to upgrade ignore > their tv tuners (I will now). This is really more a kernel matter than a Fedora matter. And Linus has repeatedly wirtten about "big v4l patches" in his changelogs these past months -- 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 seg at haxxed.com Sat Apr 15 09:16:45 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 15 Apr 2006 04:16:45 -0500 Subject: Missing system config tools? In-Reply-To: <200604141530.57653.lamont@gurulabs.com> References: <16de708d0604140230s782f0829u6649be0e4616f208@mail.gmail.com> <1145039228.7323.3.camel@rousalka.dyndns.org> <1145047222.4360.35.camel@hamburger.booze> <200604141530.57653.lamont@gurulabs.com> Message-ID: <1145092606.4360.56.camel@hamburger.booze> On Fri, 2006-04-14 at 15:30 -0600, Lamont R. Peterson wrote: > On Friday 14 April 2006 02:40pm, Callum Lerwick wrote: > > On Fri, 2006-04-14 at 20:27 +0200, Nicolas Mailhot wrote: > > Errr. Do you mean moving an LV to another PV? As in using pvmove? I had > > rather serious system eating (but ultimately recoverable) problems with > > pvmove when I moved my system to LVM using an FC5 rescue disk. It may > > not just be system-config-lvm. For no reason I could figure out, about > > half the time pvmove would crash and totally eat the PV metadata. > > Since you were in a rescue environment, did you activate the Volume Group > (VG)? The first pvmove I did, no they weren't. I figured the lvm tools are smart enough to tell me if it was the wrong thing to do. And it ended up crashing and burning. So the next time around, I did it with the LV activated. It happened again. So I don't think that's it. I suspected it might have been the fact I used --metadatacopies 2 with pvcreate, because when I rewrote the PVs with the default it worked. But on a second pvmove it crashed and burned again. So I don't think its that either. I tried it with both an i386 and an x86_64 rescue disk. Didn't make a difference. It honestly seems to be completely random. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From dragoran at feuerpokemon.de Sat Apr 15 09:31:31 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 15 Apr 2006 11:31:31 +0200 Subject: No yum GUI in core? In-Reply-To: <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> Message-ID: <4440BD73.80206@feuerpokemon.de> Arthur Pemberton wrote: > On 4/15/06, dragoran wrote: > >> Arthur Pemberton wrote: >> >>> On 4/15/06, Richard Hally wrote: >>> >>> >>>> Arthur Pemberton wrote: >>>> >>>> >>>>> Is it just me or is there no GUI to make use of Yum available from the >>>>> CD installtion? If so, would the GUI be preferable for people not >>>>> comfortable with using the command line ? >>>>> >>>>> Just wondering. >>>>> >>>>> Peace >>>>> >>>>> -- >>>>> As a boy I jumped through Windows, as a man I play with Penguins. >>>>> >>>>> >>>>> >>>> It is in the "applications" or "main" menu as Add/Remove Software. The >>>> name of the package/program is pirut. >>>> >>>> rh >>>> >>>> >>> I just loaded that up. It seems to be what it has always has been, a >>> manager of the software available from the install media, ie. no real >>> connection to yum. Correct me if I am wrong. >>> >>> -- >>> As a boy I jumped through Windows, as a man I play with Penguins. >>> >>> >>> >> you are wrong ... >> it does not even supports media it uses yum for software installation. >> you can also install packages that aren't on the install media like the >> extras packages or any other repo you set up in yum. >> >> > Okay, you are most certainly right. I suppose I was misled by it's > browse feature which looks exactly like the package selectory in > Anaconda. > > I must say though, the tool isn't very helpful at first look. > > But thanks for clearing that up. > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > > both pirut and pup seems not to update the gui when correctly.. sometimes it takes up to 2min to redraw everything, maybe because it waits for something else to finish (yum). This looks broken to me, it should have a thread for gui and one for the backend. From dragoran at feuerpokemon.de Sat Apr 15 10:05:57 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 15 Apr 2006 12:05:57 +0200 Subject: aiglx status In-Reply-To: <443B4766.2080505@feuerpokemon.de> References: <44376BCE.1020003@feuerpokemon.de> <1144512170.2746.1.camel@aglarond.local> <44389D83.5040403@feuerpokemon.de> <1144562418.3153.0.camel@aglarond.local> <443A825B.2090504@wowway.com> <443B4766.2080505@feuerpokemon.de> Message-ID: <4440C585.4090504@feuerpokemon.de> dragoran wrote: > Demond James wrote: >> Jeremy Katz wrote: >>> On Sun, 2006-04-09 at 07:37 +0200, dragoran wrote: >>> >>>> Jeremy Katz wrote: >>>> >>>>> On Sat, 2006-04-08 at 09:52 +0200, dragoran wrote: >>>>> >>>>>> whats the current status of aiglx development? >>>>>> the FC5 binarys have not been updated since inital release. >>>>>> Is the x86_64 bug solved? >>>>>> Can it be added to rawhide to get more testing? Or is it still >>>>>> not ready for rawhide ? >>>>>> >>>>> The aiglx code is already in the main trunk of xorg development being >>>>> targeted for Xorg 7.1. Packages tracking that are already present in >>>>> rawhide >>>>> >>>>> >>>> thats means x86_64 is supported now? >>>> >>> >>> Worked on my x86_64 box with a radeon at the office when I tried a few >>> weeks ago. I haven't tried since between vacation and >>> LinuxWorld/FUDCon >>> >>> Jeremy >>> >>> >> Will this work with the new nvidia drivers? Version1.0.8756 released >> 04-07-06. >> http://www.nvnews.net/vbulletin/showthread.php?t=67864 >> >> >> Thanks, >> Demond >> > I haven't tryed yet but I would say no. > http://www.nvnews.net/vbulletin/showthread.php?t=68104 > http://www.nvnews.net/vbulletin/showpost.php?p=866581&postcount=5 Can someone update the wiki and note this? From simon3z at yahoo.com Sat Apr 15 09:14:36 2006 From: simon3z at yahoo.com (Federico) Date: Sat, 15 Apr 2006 02:14:36 -0700 (PDT) Subject: Init scritps timeout Message-ID: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> Yesterday my server had a power failure and the ldap database got corrupted. The weird thing is that the corruption caused the ldap init script to hang and it stopped the server boot. Today I corrupted the database on purpose to reproduce the problem but it's not happening anymore. Beside all the precautions (ups, raid, journaled filesystems, etc...) and beside the fact it probably was a really particoular database corruption, shouldn't the init scripts have a timeout? If any of the scripts hangs the whole boot process stops. Isn't this a really dangerous behaviour? -- Federico. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mike at miketc.com Sat Apr 15 11:25:32 2006 From: mike at miketc.com (Mike Chambers) Date: Sat, 15 Apr 2006 06:25:32 -0500 Subject: No yum GUI in core? In-Reply-To: <4440A93E.20303@feuerpokemon.de> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> Message-ID: <1145100332.4678.2.camel@scrappy.miketc.com> On Sat, 2006-04-15 at 10:05 +0200, dragoran wrote: > Arthur Pemberton wrote: > > I just loaded that up. It seems to be what it has always has been, a > > manager of the software available from the install media, ie. no real > > connection to yum. Correct me if I am wrong. > you are wrong ... > it does not even supports media it uses yum for software installation. > you can also install packages that aren't on the install media like the > extras packages or any other repo you set up in yum. If he did indeed pull up the add/remove software, then he is correct, in that it ONLY gives you info from Fedora Core (which is the media or install files), not from any other repo. Then System Tools/Software Updater is pup, which does use all the repos (that are enabled) to update your software. But AFAIK it won't let you add or remove software? Mike From dragoran at feuerpokemon.de Sat Apr 15 11:28:57 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 15 Apr 2006 13:28:57 +0200 Subject: No yum GUI in core? In-Reply-To: <1145100332.4678.2.camel@scrappy.miketc.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> <1145100332.4678.2.camel@scrappy.miketc.com> Message-ID: <4440D8F9.9040305@feuerpokemon.de> Mike Chambers wrote: > On Sat, 2006-04-15 at 10:05 +0200, dragoran wrote: > >> Arthur Pemberton wrote: >> > > >>> I just loaded that up. It seems to be what it has always has been, a >>> manager of the software available from the install media, ie. no real >>> connection to yum. Correct me if I am wrong. >>> > > >> you are wrong ... >> it does not even supports media it uses yum for software installation. >> you can also install packages that aren't on the install media like the >> extras packages or any other repo you set up in yum. >> > > If he did indeed pull up the add/remove software, then he is correct, in > that it ONLY gives you info from Fedora Core (which is the media or > install files), not from any other repo. > > it does include all enabled repos not only the fedora one. use list/search to install the software which is not in groups. > Then System Tools/Software Updater is pup, which does use all the repos > (that are enabled) to update your software. But AFAIK it won't let you > add or remove software? > > Mike > > From mitr at volny.cz Sat Apr 15 12:00:39 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 15 Apr 2006 14:00:39 +0200 Subject: Init scritps timeout In-Reply-To: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> Message-ID: <4440E067.7000309@volny.cz> Hello, Federico napsal(a): > Beside all the precautions (ups, raid, journaled filesystems, etc...) and > beside the fact it probably was a really particoular database corruption, > shouldn't the init scripts have a timeout? If any of the scripts hangs the > whole boot process stops. Isn't this a really dangerous behaviour? Ignoring initscript timeouts could be even more dangerous, e.g. when starting iptables or auditd. Mirek From n0dalus+redhat at gmail.com Sat Apr 15 12:31:58 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 15 Apr 2006 22:01:58 +0930 Subject: Init scritps timeout In-Reply-To: <4440E067.7000309@volny.cz> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> <4440E067.7000309@volny.cz> Message-ID: <6280325c0604150531k16f0de2cnfdbcc43e4143fdb7@mail.gmail.com> On 4/15/06, Miloslav Trmac wrote: > Hello, > Federico napsal(a): > > Beside all the precautions (ups, raid, journaled filesystems, etc...) and > > beside the fact it probably was a really particoular database corruption, > > shouldn't the init scripts have a timeout? If any of the scripts hangs the > > whole boot process stops. Isn't this a really dangerous behaviour? > Ignoring initscript timeouts could be even more dangerous, e.g. when > starting iptables or auditd. Ideally, services depending on network, even things like web servers, should not fail when there is no connection and instead wait for one. With laptops, having to wait while it figures out you're not connected to any networks is very time-consuming and frustrating. Network startup shouldn't delay the boot process, and services depending on it should wait until it's started (though possibly connect to any available networks like loopback in the meantime). Of course, some of this is not possible with the current init system, so a new system that allows for this kind of thing would be a good thing. If a system is dependent on a network to even be usable (eg when an important partition is network mounted), it should wait, but for most people waiting for networks to connect is not needed. n0dalus. From caillon at redhat.com Sat Apr 15 18:28:27 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 15 Apr 2006 14:28:27 -0400 Subject: No yum GUI in core? In-Reply-To: <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> Message-ID: <44413B4B.7010209@redhat.com> Arthur Pemberton wrote: > Okay, you are most certainly right. I suppose I was misled by it's > browse feature which looks exactly like the package selectory in > Anaconda. > > I must say though, the tool isn't very helpful at first look. > > But thanks for clearing that up. Anaconda embeds pirut for its package selecting. It's still very new and will likely undergo more work in the FC6 timeframe. It works with the CD/DVD because yum supports local repositories, which is effectively what the discs are, AIUI. From sdl.web at gmail.com Sat Apr 15 19:18:15 2006 From: sdl.web at gmail.com (Leon) Date: Sat, 15 Apr 2006 20:18:15 +0100 Subject: i810 bug in X11? Message-ID: Dear users of i810s, I810 driver is always very buggy. I regret very much that I bought a laptop with it. I hope anyone considering buying laptop think carefully of the graph card. It's of great importance for your work and amusement. For i810, suspend to RAM/DISK has never been reliable. You don't know when it's going to crash. I have moved to fedora from ubuntu because of it hoping that the best engineers can fix this bug. Now I am confidant that this bug has existed for over a year in upstream Xorg. Ubuntu has recognized its importance and work actively to fix it. What I'm asking here is anybody know of the same issue or maybe has a fix for fc? A picture is better than a thousand words: screenshot of corrupted ubuntu by other user: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=127784 screenshot of gnome-terminal by me: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=127780 (*NB*: this is gnome-terminal, it's not the whole desktop, you can see it is `transparent' and has some residual pixels from firefox) Bug report I filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189074 Bug report in Ubuntu: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-i810/+bug/29880. Regards, -- Leon From ggw at wolves.durham.nc.us Sat Apr 15 21:20:31 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Sat, 15 Apr 2006 17:20:31 -0400 Subject: IT821x force pass through mode incantation? In-Reply-To: <20060415025208.GA7919@wolves.durham.nc.us> References: <20060414103505.GA2687@wolves.durham.nc.us> <87fykggq1b.fsf@mrao.cam.ac.uk> <20060414162913.GA2693@wolves.durham.nc.us> <20060414163701.GB30624@devserv.devel.redhat.com> <20060415025208.GA7919@wolves.durham.nc.us> Message-ID: <20060415212031.GA2814@wolves.durham.nc.us> On Fri, Apr 14, 2006 at 10:52:08PM -0400, G.Wolfe Woodbury wrote: > On Fri, Apr 14, 2006 at 12:37:01PM -0400, Alan Cox wrote: > > On Fri, Apr 14, 2006 at 12:29:13PM -0400, G.Wolfe Woodbury wrote: > > > Now, the device/driver is consistently dropping interrupts and having DMA > > > timeouts. It is in sore need of some work. > > > > If it is missing all the IRQs then that sounds like a board level IRQ routing > > problem not a driver one. If it only misses some then it may be driver level. > > I'm working on a new it821x driver for libata but I'd appreciate a detailed > > report of the problem you have and maybe can chase down old driver bugs too. > > > > Alan > > It obviously doesn't miss all the interrupts, since it manages to get information from > the drive. > > The situation is that under heavy load the system apparently loses some interrupts > an freezes the system. There are no remains to post mortem, as the system has to > be reset to recover. I can reliably make the system lock up by adding BOINC(SETI at Home) > to the mix. > > This is with the card in smart mode, but no RAID setup on the attached disks. > That is, two Hitachi DeskStar 400GB drives are attached, but they are not configured > as members of a RAID set. > > When I add the it821x.noraid=1 to the kernel command line, then the system won't even boot > because all the interrupts get lost somewhere. It is a little odd, since "hde" will eventually > work, but "hdf" (an identical drive) drops nearly every interrupt in pass through mode. I need to follow myself up to note that the kernel is the xen0 kernel that is getting all these errors! 2080 without xen is working quite well in pass through mode. In smart mode, however, there are load related problems. G.Wolfe Woodbury -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From buildsys at redhat.com Sun Apr 16 07:49:43 2006 From: buildsys at redhat.com (Build System) Date: Sun, 16 Apr 2006 03:49:43 -0400 Subject: rawhide report: 20060416 changes Message-ID: <200604160749.k3G7nh8b008891@porkchop.devel.redhat.com> Updated Packages: net-snmp-5.3-8 -------------- * Sat Apr 15 2006 Radek Vok??l 5.3-8 - fix missing IF-MIB::ifNumber.0 (#189007) pyparted-1.6.10-2 ----------------- * Sat Apr 15 2006 Caolan McNamara - 1.6.10-2 - rebuild for new parted Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From nman64 at n-man.com Sun Apr 16 08:49:23 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 16 Apr 2006 03:49:23 -0500 Subject: Fedora Bounties (seeking ideas) Message-ID: <200604160349.25854.nman64@n-man.com> Last year, after Fedora applied to participate in Google's Summer of Code 2005, we created the FedoraBounties page on the wiki: http://fedoraproject.org/wiki/FedoraBounties This page features specific ideas for new projects that the Fedora Project would like to see completed. Several of these ideas were selected by students for the Summer of Code event. Now, Google has just announced the Summer of Code 2006. Although the Fedora Project has not yet applied to participate this year, I suspect we are likely to do so. However, our Fedora Bounties list is now quite short. We need fresh ideas. If there are any projects that you would like to see, please add them to the FedoraBounties page. These can include ideas that you may have had but don't have time to work on, problems that you have encountered that need attention, or tools you really wish we had. Assuming we do participate in this year's event, we can expect several of the project ideas to be selected again, so this is an excellent opportunity to suggest long-missed projects. Students will be able to apply for this year's event after May 1st, so there isn't much time to get your ideas listed. http://fedoraproject.org/wiki/SummerOfCode -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Apr 16 10:57:50 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Apr 2006 16:27:50 +0530 Subject: No yum GUI in core? In-Reply-To: <1145100332.4678.2.camel@scrappy.miketc.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> <1145100332.4678.2.camel@scrappy.miketc.com> Message-ID: <1145185070.349.20.camel@sundaram.pnq.redhat.com> On Sat, 2006-04-15 at 06:25 -0500, Mike Chambers wrote: > On Sat, 2006-04-15 at 10:05 +0200, dragoran wrote: > > Arthur Pemberton wrote: > > > > I just loaded that up. It seems to be what it has always has been, a > > > manager of the software available from the install media, ie. no real > > > connection to yum. Correct me if I am wrong. > > > you are wrong ... > > it does not even supports media it uses yum for software installation. > > you can also install packages that aren't on the install media like the > > extras packages or any other repo you set up in yum. > > If he did indeed pull up the add/remove software, then he is correct, in > that it ONLY gives you info from Fedora Core (which is the media or > install files), not from any other repo. > It does show Fedora Extras packages along with Fedora Core ones by default. > Then System Tools/Software Updater is pup, which does use all the repos > (that are enabled) to update your software. But AFAIK it won't let you > add or remove software? Thats what Pirut (Add/Remove software program) is for. Rahul From pnasrat at redhat.com Sun Apr 16 13:04:48 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Sun, 16 Apr 2006 09:04:48 -0400 Subject: No yum GUI in core? In-Reply-To: <44413B4B.7010209@redhat.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444095C4.7020603@mindspring.com> <16de708d0604150100r296ce741qdbc2cf454eba5cf1@mail.gmail.com> <4440A93E.20303@feuerpokemon.de> <16de708d0604150120g6faa22caq64b17282c15f750d@mail.gmail.com> <44413B4B.7010209@redhat.com> Message-ID: <1145192689.2769.19.camel@enki.eridu> On Sat, 2006-04-15 at 14:28 -0400, Christopher Aillon wrote: > Arthur Pemberton wrote: > > Okay, you are most certainly right. I suppose I was misled by it's > > browse feature which looks exactly like the package selectory in > > Anaconda. > > > > I must say though, the tool isn't very helpful at first look. > > > > But thanks for clearing that up. > Anaconda embeds pirut for its package selecting. It's still very new > and will likely undergo more work in the FC6 timeframe. It works with > the CD/DVD because yum supports local repositories, which is effectively > what the discs are, AIUI. No the CD support uses some unique code to anaconda which is going to be pushed into yum. It's not the standard local repo code path. Paul From david at lovesunix.net Sun Apr 16 13:22:58 2006 From: david at lovesunix.net (David Nielsen) Date: Sun, 16 Apr 2006 15:22:58 +0200 Subject: Google Summer of Code 2006 Message-ID: <1145193778.2594.5.camel@localhost.localdomain> Google just kicked off SoC 2006 and I don't see The Fedora Project anywhere on the mentor list, isn't anyone planning on taking advantage of this to better our beloved OS? http://code.google.com/soc/ Just off the top of my head I would love to see someone work on system data collection via HAL, a set of basic SystemTap scripts and getting the system ready to default to --as-needed linking Of course that might just be me being utterly nuts. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From nman64 at n-man.com Sun Apr 16 15:47:14 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 16 Apr 2006 10:47:14 -0500 Subject: Google Summer of Code 2006 In-Reply-To: <1145193778.2594.5.camel@localhost.localdomain> References: <1145193778.2594.5.camel@localhost.localdomain> Message-ID: <200604161047.18129.nman64@n-man.com> On Sunday 16 April 2006 08:22, David Nielsen wrote: > Google just kicked off SoC 2006 and I don't see The Fedora Project > anywhere on the mentor list, isn't anyone planning on taking advantage > of this to better our beloved OS? > > http://code.google.com/soc/ > > Just off the top of my head I would love to see someone work on system > data collection via HAL, a set of basic SystemTap scripts and getting > the system ready to default to --as-needed linking > > Of course that might just be me being utterly nuts. > > - David We'll most likely be applying as a mentoring organization shortly. You can add your ideas to the FedoraBounties page: http://fedoraproject.org/wiki/FedoraBounties You can also review our SoC section of the wiki: http://fedoraproject.org/wiki/SummerOfCode -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From mandreiana.lists at gmail.com Sun Apr 16 17:14:05 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sun, 16 Apr 2006 20:14:05 +0300 Subject: memory usage analysis (was Re: FC5 (lack of) quality) In-Reply-To: References: <1145043438.2709.31.camel@localhost.localdomain> Message-ID: <1145207646.2728.4.camel@localhost.localdomain> On Sat, 2006-04-15 at 00:39 -0700, Panu Matilainen wrote: > On Fri, 14 Apr 2006, Marius Andreiana wrote: > > Greetings, > > * on a 256mb RAM system GNOME it's hardly usable due to swapping with > > more than 2 applications opened (firefox and another small one, no ooo). > > Only minimal services (network, xfs..) are started automatically. > > Mm.. GNOME in FC5 was supposed to use *less* memory than in previous > versions. Have you looked at where exactly does the memory go to - is it > really GNOME or something else, like Firefox? after GNOME login, with gnome-terminal and gedit started: $ free total used free shared buffers cached Mem: 248168 239816 8352 0 8012 108060 -/+ buffers/cache: 123744 124424 Swap: 514072 0 514072 The top apps listed in GNOME system monitor (clearer than "top" for me) sorted by Resident Memory are: nautilus (16.5m), gnome-panel, mixer-applet (14.8m!), gedit, gnome-system-monitor, gnome-terminal (12.7mb, a single tab), wnck-applet, nm-applet, gnome-session, clock-applet (9.6mb!), metacity (9.2mb). Started firefox (28mb in g-system-monitor) $ free total used free shared buffers cached Mem: 248168 240804 7364 0 7320 87576 -/+ buffers/cache: 145908 102260 Swap: 514072 0 514072 Started totem on a video file: 54.6mb ! swap usage >0 now: $ free total used free shared buffers cached Mem: 248168 243360 4808 0 156 48968 -/+ buffers/cache: 194236 53932 Swap: 514072 120 513952 So it looks like totem does have a problem, but some of the applications listed shows quite a high memory usage too, is it normal? Thanks, Marius From mandreiana.lists at gmail.com Sun Apr 16 17:23:36 2006 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sun, 16 Apr 2006 20:23:36 +0300 Subject: FC5 (lack of) quality In-Reply-To: <1145051933.10886.23.camel@pensja.lam.pl> References: <1145043438.2709.31.camel@localhost.localdomain> <1145051933.10886.23.camel@pensja.lam.pl> Message-ID: <1145208216.2728.9.camel@localhost.localdomain> On Fri, 2006-04-14 at 23:58 +0200, Leszek Matok wrote: > Dnia 14-04-2006, pi? o godzinie 22:37 +0300, Marius Andreiana > napisa?(a): > > * window borders disappear sometimes and then all GNOME freezes. It's > > possible to go to console with alt+Fn and kill some processes, but no > > effect. X must be killed and restarted. > This happened every time I tried to minimize XMMS without WM > decorations. Try: > rpm -Fvh > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/5/i386/metacity-2.14.2-1.fc5.2.i386.rpm > I don't know what's stopping it from being pushed to updates > (non-testing), works for me (at the moment ;)) and the crashes are gone. I do use XMMS. I'll update metacity, thanks for the hint! -- Marius Andreiana http://marius.andreiana.googlepages.com From gajownik at fedora.pl Sun Apr 16 17:26:28 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sun, 16 Apr 2006 19:26:28 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <44427E44.7080304@fedora.pl> Dnia 04/16/2006 10:49 AM, U?ytkownik Patrick W. Barnes napisa?: > Although the Fedora Project has not yet applied to participate this > year, I suspect we are likely to do so. However, our Fedora Bounties > list is now quite short. We need fresh ideas. What do you think about porting nVidia driver from BeOS? https://bugs.freedesktop.org/show_bug.cgi?id=5190#c6 This is just a proposition because, unfortunately, I don't have such a skills (I can only help testing) :/ Regards, Dawid -- ^_* From walovaton at yahoo.com.mx Sun Apr 16 14:09:48 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sun, 16 Apr 2006 09:09:48 -0500 Subject: speed up Firefox start by a factor of 3 on x86 In-Reply-To: <20060320161206.GF29589@redhat.com> References: <561c252c0603162338g4dc56dc4md55e7bd2d05c6a3b@mail.gmail.com> <1142612623.3033.119.camel@laptopd505.fenrus.org> <20060320161206.GF29589@redhat.com> Message-ID: <1145196588.2326.7.camel@athlon2000> El lun, 20-03-2006 a las 11:12 -0500, Dave Jones escribi??: > On Mon, Mar 20, 2006 at 10:27:47AM +0100, Rudolf Kastl wrote: > > 2006/3/17, Arjan van de Ven : > > > On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote: > > > > On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote: > > > > >In contrast, Firefox always starts in 5 seconds or less on a kernel > > > > which places > > > > >the vDSO intelligently: > > > > I read the long list of your reports at the bugzilla page, with the > > > > many details and test cases provided, but apart the beginning, you > > > > pratically received no feedback at all (at least inside bugzilla > > > > itself): only periodically that "having merged with upstream kernel, > > > > more than thousands of changes, so please test again and let know..." > > > > I think you had better to submit your considerations to upstream kernel list. > > > > In this way if accepted, they would be naturally incorporated also in fedora. > > > > I'm not a kernel expert so sorry if this doesn't fit for you. > > > > Juest my 0.02 euros... > > > > > > > > > > that's not going to fly since this is a fix to a fedora specific > > > patch ;) > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > more comments on the fix would be nice. will it be merged? > > I'll throw it into rawhide soon, and if nothing breaks, > then I'll backport it to the other releases. Hi Dave, Is this patch going into Fedora? I hope it is a good idea, it's a bit disappointing to lose prelinking benefits in such an important piece of software like firefox. Thanks, -William __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From walovaton at yahoo.com.mx Sun Apr 16 14:05:13 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sun, 16 Apr 2006 09:05:13 -0500 Subject: which gstreamer versions in official fc5? In-Reply-To: <1142544513.24422.6.camel@orodruin.boston.redhat.com> References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com> <1142520282.10076.1.camel@halflap> <1142544133.22487.0.camel@otto.amantes> <1142544513.24422.6.camel@orodruin.boston.redhat.com> Message-ID: <1145196313.2326.2.camel@athlon2000> Hi Jeremy, El jue, 16-03-2006 a las 16:28 -0500, Jeremy Katz escribi??: > On Thu, 2006-03-16 at 22:22 +0100, Thomas Vander Stichele wrote: > > On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote: > > > > It seems in final gnome 2.14 the optimum is: > > > > gstreamer 0.10.4 and gst-plugins-base 0.10.5 > > > I believe the plan is to upgrade in FC5 updates, within a few days of > > > the FC5 release. > > > > I asked around and I didn't really get an answer on how come everything > > that is in GNOME's release got upgraded to the actual released versions, > > except GStreamer. Any logic to that ? Can someone shed some light ? > > Not everything got upgraded. It was basically a matter of looking at > diffs and trying to decide what was "safe". I don't think that anyone > is 100% happy with how that process went. > > The plan is definitely to get the rest of the 2.14 final packages out as > an update ASAP after Monday and there's also going to be an effort to > actually track the stable releases as they're done this time around :-) Is this still the plan? are there going to be updates for new releases of Gnome 2.14.x?? Cheers, -William __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From steve at silug.org Sun Apr 16 21:29:28 2006 From: steve at silug.org (Steven Pritchard) Date: Sun, 16 Apr 2006 16:29:28 -0500 Subject: Init scritps timeout In-Reply-To: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> Message-ID: <20060416212927.GA4842@osiris.silug.org> On Sat, Apr 15, 2006 at 02:14:36AM -0700, Federico wrote: > Yesterday my server had a power failure and the ldap database got corrupted. > The weird thing is that the corruption caused the ldap init script to hang and > it stopped the server boot. Today I corrupted the database on purpose to > reproduce the problem but it's not happening anymore. > Beside all the precautions (ups, raid, journaled filesystems, etc...) and > beside the fact it probably was a really particoular database corruption, > shouldn't the init scripts have a timeout? If any of the scripts hangs the > whole boot process stops. Isn't this a really dangerous behaviour? I personally think using Berkeley DB is dangerous behavior, but what can you do? Fortunately db_recover seems to be taking care of these issues pretty reliably. I wonder if a quick call to it at the beginning of the ldap init script might be a good idea... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From cmadams at hiwaay.net Sun Apr 16 21:31:20 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 16 Apr 2006 16:31:20 -0500 Subject: Init scritps timeout In-Reply-To: <20060416212927.GA4842@osiris.silug.org> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> <20060416212927.GA4842@osiris.silug.org> Message-ID: <20060416213120.GA855985@hiwaay.net> Once upon a time, Steven Pritchard said: > I personally think using Berkeley DB is dangerous behavior, but what > can you do? Yeah, that's why I'm planning to skip /var/db/*.db, put everything in /etc/{passwd,shadow}, and let nscd cache it all for me. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From brent at linux.wku.edu Sun Apr 16 22:27:51 2006 From: brent at linux.wku.edu (Brent) Date: Sun, 16 Apr 2006 17:27:51 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <4442C4E7.2000203@linux.wku.edu> What about a resurrection of something like cheops? Companies like FlukeNetworks charge big money for a program that maps a network like cheops used to do and it would seem that there are a lot of things that could be added to it to make it a really spectacular program. Things like SNMP polling of switches and routers so that that links between objects could also show traffic stats in near real time. Source RPMS of the old cheops can be compiled on FC4, but it was really hacky and very prone to crashes. I thinking having a network mapping tool like that for Linux could really be a nice app. I guess it might not be along Fedora's lines though. Brent Patrick W. Barnes wrote: > Last year, after Fedora applied to participate in Google's Summer of Code > 2005, we created the FedoraBounties page on the wiki: > > http://fedoraproject.org/wiki/FedoraBounties > > This page features specific ideas for new projects that the Fedora Project > would like to see completed. Several of these ideas were selected by > students for the Summer of Code event. > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. > > Assuming we do participate in this year's event, we can expect several of the > project ideas to be selected again, so this is an excellent opportunity to > suggest long-missed projects. Students will be able to apply for this year's > event after May 1st, so there isn't much time to get your ideas listed. > > http://fedoraproject.org/wiki/SummerOfCode > From ulissesf at gmail.com Sun Apr 16 22:45:04 2006 From: ulissesf at gmail.com (Ulisses Furquim) Date: Sun, 16 Apr 2006 19:45:04 -0300 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4442C4E7.2000203@linux.wku.edu> References: <200604160349.25854.nman64@n-man.com> <4442C4E7.2000203@linux.wku.edu> Message-ID: Hi, I think that a really nice SoC 2006 project could be something related to a new init system [1]. What do you think? Best, -- Ulisses [1] http://fedoraproject.org/wiki/FCNewInit From seg at haxxed.com Mon Apr 17 00:15:36 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 16 Apr 2006 19:15:36 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44427E44.7080304@fedora.pl> References: <200604160349.25854.nman64@n-man.com> <44427E44.7080304@fedora.pl> Message-ID: <1145232937.5173.3.camel@hamburger.booze> On Sun, 2006-04-16 at 19:26 +0200, Dawid Gajownik wrote: > What do you think about porting nVidia driver from BeOS? > https://bugs.freedesktop.org/show_bug.cgi?id=5190#c6 > This is just a proposition because, unfortunately, I don't have such a > skills (I can only help testing) :/ http://nouveau.sourceforge.net/ Pouring some money/manpower into nouveau couldn't hurt. Though I dunno if it would really be under Fedora's scope. Does Xorg itself do SoC? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From tjb at unh.edu Mon Apr 17 01:42:21 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Sun, 16 Apr 2006 21:42:21 -0400 Subject: Google Summer of Code 2006 In-Reply-To: <200604161047.18129.nman64@n-man.com> References: <1145193778.2594.5.camel@localhost.localdomain> <200604161047.18129.nman64@n-man.com> Message-ID: <1145238141.2663.8.camel@continuity> On Sun, 2006-04-16 at 10:47 -0500, Patrick W. Barnes wrote: > On Sunday 16 April 2006 08:22, David Nielsen wrote: > > Google just kicked off SoC 2006 and I don't see The Fedora Project > > anywhere on the mentor list, isn't anyone planning on taking advantage > > of this to better our beloved OS? > > > > http://code.google.com/soc/ > > > > Just off the top of my head I would love to see someone work on system > > data collection via HAL, a set of basic SystemTap scripts and getting > > the system ready to default to --as-needed linking > > > > Of course that might just be me being utterly nuts. > > > > - David > > We'll most likely be applying as a mentoring organization shortly. You can > add your ideas to the FedoraBounties page: > > http://fedoraproject.org/wiki/FedoraBounties > > You can also review our SoC section of the wiki: > > http://fedoraproject.org/wiki/SummerOfCode > I can't edit the page (just added my wiki account) but how about a Evolution filters to procmail export plugin. The plugin could just write a .procmail.evolution file and then .procmailrc could include it. Evolution provides a nice interface for creating the filters but procmail doing the filtering at delivery time would be great. It's a smaller scale project but I've searched everywhere and only found people asking for such a feature, never finding any implementations. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From dimi at lattica.com Mon Apr 17 02:50:21 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 16 Apr 2006 22:50:21 -0400 Subject: Init scritps timeout In-Reply-To: <6280325c0604150531k16f0de2cnfdbcc43e4143fdb7@mail.gmail.com> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> <4440E067.7000309@volny.cz> <6280325c0604150531k16f0de2cnfdbcc43e4143fdb7@mail.gmail.com> Message-ID: <1145242221.6382.328.camel@dimi> On Sat, 2006-04-15 at 22:01 +0930, n0dalus wrote: > Ideally, services depending on network, even things like web servers, > should not fail when there is no connection and instead wait for one. Indeed. Now we have this static order for services initialization which sucks. The new schemes will (hopefully) introduce dynamic dependencies. But I feel that this is still too inflexible -- we need a well defined API to be able to programmatically wait for a service to start/stop/etc For example, say we have service A (networking), and service B (httpd) that depends on service A. Lets also assume that B needs A only towards the end of its startup. With a 'services' API, the startup sequence for B could be written as: //do time consuming part that does not depend on A service_wait(A) //do part that depends on A Then we can start A & B in parallel and things will (A) sort themselves automagically, and (B) achieve the fastest possible startup time, especially on the new multicore boxes coming our way. -- Dimi Paun Lattica, Inc. From hhoffman at ip-solutions.net Mon Apr 17 03:22:10 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sun, 16 Apr 2006 23:22:10 -0400 Subject: Init scritps timeout In-Reply-To: <1145242221.6382.328.camel@dimi> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> <4440E067.7000309@volny.cz> <6280325c0604150531k16f0de2cnfdbcc43e4143fdb7@mail.gmail.com> <1145242221.6382.328.camel@dimi> Message-ID: <444309E2.60608@ip-solutions.net> Why should httpd depend on networking? what is the network comes up later... do you not want httpd to already be running? I'd vote for a trap for init scripts, where (like the BSDs) you could ctrl-c out of a script if it's taking too long Dimi Paun wrote: > On Sat, 2006-04-15 at 22:01 +0930, n0dalus wrote: >> Ideally, services depending on network, even things like web servers, >> should not fail when there is no connection and instead wait for one. > > Indeed. Now we have this static order for services initialization which > sucks. The new schemes will (hopefully) introduce dynamic dependencies. > But I feel that this is still too inflexible -- we need a well defined > API to be able to programmatically wait for a service to start/stop/etc > > For example, say we have service A (networking), and service B (httpd) > that depends on service A. Lets also assume that B needs A only towards > the end of its startup. With a 'services' API, the startup sequence for > B could be written as: > //do time consuming part that does not depend on A > service_wait(A) > //do part that depends on A > > Then we can start A & B in parallel and things will (A) sort themselves > automagically, and (B) achieve the fastest possible startup time, > especially on the new multicore boxes coming our way. > -- Harry Hoffman Integrated Portable Solutions, LLC 877.846.5927 ext 1000 http://www.ip-solutions.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: hhoffman.vcf Type: text/x-vcard Size: 185 bytes Desc: not available URL: From dimi at lattica.com Mon Apr 17 03:33:43 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 16 Apr 2006 23:33:43 -0400 Subject: Init scritps timeout In-Reply-To: <444309E2.60608@ip-solutions.net> References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> <4440E067.7000309@volny.cz> <6280325c0604150531k16f0de2cnfdbcc43e4143fdb7@mail.gmail.com> <1145242221.6382.328.camel@dimi> <444309E2.60608@ip-solutions.net> Message-ID: <1145244823.6382.340.camel@dimi> On Sun, 2006-04-16 at 23:22 -0400, Harry Hoffman wrote: > Why should httpd depend on networking? what is the network comes up > later... do you not want httpd to already be running? You're reading to much in the exact example there :) Just use A and B. But I admit, I was a bit off-topic regarding the timeout problem. I was commenting on the need to have greater control of these inter service dependencies. As for the timeout, that would have to be handled by the services manager that starts the services up. Ctrl-C is fine if you're in front of the console, but the reboot may be unattended, we need to have a system that is able to handle things by itself as well. -- Dimi Paun Lattica, Inc. From ihok at hotmail.com Mon Apr 17 04:12:42 2006 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 17 Apr 2006 00:12:42 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: Patrick W. Barnes wrote: > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. I don't have wiki access, but here's an idea: integrate FreeNX into GNOME in a way that's comparable to how VNC is integrated into GNOME via Vino. The result would support GNOME session sharing/suspending/resuming via NX. From sundaram at fedoraproject.org Mon Apr 17 05:16:58 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 17 Apr 2006 10:46:58 +0530 Subject: which gstreamer versions in official fc5? In-Reply-To: <1145196313.2326.2.camel@athlon2000> References: <561c252c0603160517t5b9efb54u7541fb409ce43f43@mail.gmail.com> <1142520282.10076.1.camel@halflap> <1142544133.22487.0.camel@otto.amantes> <1142544513.24422.6.camel@orodruin.boston.redhat.com> <1145196313.2326.2.camel@athlon2000> Message-ID: <1145251018.349.37.camel@sundaram.pnq.redhat.com> On Sun, 2006-04-16 at 09:05 -0500, William Lovaton wrote: > Hi Jeremy, > > El jue, 16-03-2006 a las 16:28 -0500, Jeremy Katz escribi?: > > On Thu, 2006-03-16 at 22:22 +0100, Thomas Vander Stichele wrote: > > > On Thu, 2006-03-16 at 09:44 -0500, Ray Strode wrote: > > > > > It seems in final gnome 2.14 the optimum is: > > > > > gstreamer 0.10.4 and gst-plugins-base 0.10.5 > > > > I believe the plan is to upgrade in FC5 updates, within a few days of > > > > the FC5 release. > > > > > > I asked around and I didn't really get an answer on how come everything > > > that is in GNOME's release got upgraded to the actual released versions, > > > except GStreamer. Any logic to that ? Can someone shed some light ? > > > > Not everything got upgraded. It was basically a matter of looking at > > diffs and trying to decide what was "safe". I don't think that anyone > > is 100% happy with how that process went. > > > > The plan is definitely to get the rest of the 2.14 final packages out as > > an update ASAP after Monday and there's also going to be an effort to > > actually track the stable releases as they're done this time around :-) > > Is this still the plan? are there going to be updates for new releases > of Gnome 2.14.x?? updates have already been pushed into fedora updates-testing repository. Rahul From buildsys at redhat.com Mon Apr 17 07:19:26 2006 From: buildsys at redhat.com (Build System) Date: Mon, 17 Apr 2006 03:19:26 -0400 Subject: rawhide report: 20060417 changes Message-ID: <200604170719.k3H7JQD3021755@porkchop.devel.redhat.com> Updated Packages: audit-1.2.1-1 ------------- * Sun Apr 16 2006 Steve Grubb 1.2.1-1 - New message type for trusted apps - Add new keywords today, yesterday, now for ausearch and aureport - Make audit_log_user_avc_message really send to syslog on error - Updated syscall tables in auditctl - Deprecated the 'possible' action for syscall rules in auditctl - Update watch code to use file syscalls instead of 'all' in auditctl kernel-2.6.16-1.2134_FC6 ------------------------ * Sun Apr 16 2006 Dave Jones - Big rebase to 2.6.17-rc1-git12 * Fri Apr 14 2006 Juan Quintela - Enable xen again. - Update xen hypervisor to cset 9638. - Update xen patch to linux-2.6.tip-xen.hg cset 26602. - Remove/rediff lots of patches. - x86_64 xen don't work, fixing that. ruby-1.8.4-4.fc6 ---------------- * Mon Apr 17 2006 Akira TAGOH - 1.8.4-4 - correct sitelibdir. (#184198) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From pemboa at gmail.com Mon Apr 17 08:09:43 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 17 Apr 2006 03:09:43 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <16de708d0604170109t3d311d0ewe09170c4948435bc@mail.gmail.com> On 4/16/06, Patrick W. Barnes wrote: > Last year, after Fedora applied to participate in Google's Summer of Code > 2005, we created the FedoraBounties page on the wiki: > > http://fedoraproject.org/wiki/FedoraBounties > > This page features specific ideas for new projects that the Fedora Project > would like to see completed. Several of these ideas were selected by > students for the Summer of Code event. > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. > > Assuming we do participate in this year's event, we can expect several of the > project ideas to be selected again, so this is an excellent opportunity to > suggest long-missed projects. Students will be able to apply for this year's > event after May 1st, so there isn't much time to get your ideas listed. > > http://fedoraproject.org/wiki/SummerOfCode > What became of the Backup tool from last year's SOC? -- As a boy I jumped through Windows, as a man I play with Penguins. From nman64 at n-man.com Mon Apr 17 08:23:15 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Mon, 17 Apr 2006 03:23:15 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604170109t3d311d0ewe09170c4948435bc@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604170109t3d311d0ewe09170c4948435bc@mail.gmail.com> Message-ID: <200604170323.18200.nman64@n-man.com> On Monday 17 April 2006 03:09, "Arthur Pemberton" wrote: > > What became of the Backup tool from last year's SOC? > https://sucs.org/~davea/trac/ The developer disappeared. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From pemboa at gmail.com Mon Apr 17 08:39:37 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 17 Apr 2006 03:39:37 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604170323.18200.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604170109t3d311d0ewe09170c4948435bc@mail.gmail.com> <200604170323.18200.nman64@n-man.com> Message-ID: <16de708d0604170139h69f7fa4fgd58800a4076f8bcd@mail.gmail.com> On 4/17/06, Patrick W. Barnes wrote: > On Monday 17 April 2006 03:09, "Arthur Pemberton" wrote: > > > > What became of the Backup tool from last year's SOC? > > > > https://sucs.org/~davea/trac/ > > The developer disappeared. Does that mean I can apply to do this? I am a freshman (I found out about SOC-2005 when it was too late) and I think Fedora is desperately in need of a backup/restoration tool, esp. since fresh installs are so..fresh. Also it is a lot harder for me to dissappear. www.pembo13.com > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > > http://www.n-man.com/ > > Have I been helpful? Rate my assistance! > http://rate.affero.net/nman64/ > -- > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- As a boy I jumped through Windows, as a man I play with Penguins. From stickster at gmail.com Mon Apr 17 12:01:51 2006 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 17 Apr 2006 08:01:51 -0400 Subject: No yum GUI in core? In-Reply-To: <16de708d0604150105l40d4216fnba195435d0d33340@mail.gmail.com> References: <16de708d0604142248t33583a2bte5ce1d4e26ff0abb@mail.gmail.com> <444096DE.2060508@knox.net.nz> <16de708d0604150105l40d4216fnba195435d0d33340@mail.gmail.com> Message-ID: <1145275312.6247.8.camel@localhost.localdomain> On Sat, 2006-04-15 at 03:05 -0500, Arthur Pemberton wrote: > On 4/15/06, Michael J Knox wrote: > > Arthur Pemberton wrote: > > > Is it just me or is there no GUI to make use of Yum available from the > > > CD installtion? If so, would the GUI be preferable for people not > > > comfortable with using the command line ? > > > > There is "yumex" but its in extras and does require to install it from a > > shell. However, once its installed, you're set. > > > > Michael > > > That's what I thought. Don't get me wrong, I prefer using the command > line myself. But doesn't having to install yumex via the console, in > order to not have to use the console (esp. in the case of newbies) > kinda take away from the whole point? > > I say this because there seems to be a perception outside of Fedora > that we (Fedora) has no package management, far less a GUI for the > package management. And I see this on public tech forums. (from > supposed geeks) For the first few releases, Fedora didn't have a good built-in GUI for software management. The {system,redhat}-config-packages tool acted in the manner you were talking about earlier in this thread -- i.e. it worked only with the shipped distro CDs, and lost functionality as you updated the system. The up2date tool worked to supplant a lot of this functionality, but was broken by FC4; fortunately yum solved a lot of problems and people naturally migrated to it. > Is there any particular reason why yumex does not come on the install > media? I think it is fair to say that people new to Fedora (or linux > for that matter) would appreciate that. My take on it, part empirical and part opinion, is that its GUI is poorly designed, too complex for new users. It does expose a lot of useful yum features, which is why many experienced users like it. It is simply too confusing for a new user, though, and I'm pretty sure it's not very adherent to the GNOME HIG. (The pirut and/or pup tools might have specific HIG problems too, but they seem better designed in that respect at first blush.) Plus, yumex duplicates a lot of the functionality in pirut and pup, so by definition that kind of strikes it from being considered for Core, AIUI. > And on a side note, Fedora could do with some better PR. Your help is needed in the Marketing group, then: http://fedoraproject.org/wiki/Marketing -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Mon Apr 17 13:29:23 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 17 Apr 2006 06:29:23 -0700 (PDT) Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4442C4E7.2000203@linux.wku.edu> Message-ID: <20060417132923.1434.qmail@web51514.mail.yahoo.com> >What about a resurrection of something like cheops? FWIW, I've got a copy of cheops forward ported. You can get it from here: http://www.web-insights.net/cheops-0.59c.tar.gz It has a specfile in the tarball and puts itself into the gnome menu for easy access. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dhollis at davehollis.com Mon Apr 17 14:13:06 2006 From: dhollis at davehollis.com (David Hollis) Date: Mon, 17 Apr 2006 10:13:06 -0400 Subject: Where am I? Do we need a Location Profiler? In-Reply-To: <443F9332.6030004@mesias.co.uk> References: <1144926062.5527.25.camel@averatec> <1144951902.2465.15.camel@dhollis-lnx.sunera.com> <1145015212.2035.19.camel@localhost.localdomain> <443F9332.6030004@mesias.co.uk> Message-ID: <1145283186.2435.6.camel@dhollis-lnx.sunera.com> On Fri, 2006-04-14 at 13:18 +0100, Cam wrote: > Paul > > > Being able to switch yum{, repo} configurations comes to mind as a > > useful function along the same lines. I have local mirrors available on > > some networks, not on others. These can be handled with dispatcher.d > > scripts, but would a user helper be beneficial? > > There must be lots of configurations that could be usefully set: I can > think of things like default printer, network proxy configuration, > outgoing mail server etc. For every app that uses these, there should be > a framework for the app to be notified of change. For example a weather > applet should notice if the http proxy changes after I suspend my > machine at home and resume it at work... > > You might even want to run your security in a stricter mode when you are > eg. at a public hot-spot vs. at work or at home with trusted peers; or > have different screensaver / lock settings... Some of these things are already just about in place, probably just need a little bit of quick glue. For example, Gnome already has a setting for HTTP proxy, though it's hard to say how many apps actually make use of it. I would presume that if the app uses Gnome libraries for accessing URLs it would apply but if they do their own network access, you are on your own. Then there is the case of the http_proxy environment variable that most CLI apps make use of. If the Gnome preference could be dup'ed to the environment variable, we'd almost have a winner. Tracking on location can be a tougher nut than some folks might think though. It would most likely be a somewhat manual effort IMHO. The easiest method is to make the decision based on ESSID, but if you are hard-wired, it's not so simple. Basing it on the local network or gateway address is a bit goofy and could easily lead to things not working out how you expected. As an example, suppose I use 192.168.1.0/24 at home, with .1 as my gateway - a rather common setup - and I go to some hotel that doesn't have wireless yet, and they use the same scheme. Should my "I'm at home, provide unfettered access to all" profile apply, probably not. And please nobody suggest that you key of the MAC of the gateway or something dumb like that. You try and handle cases of people changing their routers and now their profiles don't work or worse - changing an L3 switch on the 7th floor makes all the users profiles behave differently etc. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gauret at free.fr Mon Apr 17 18:13:13 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 17 Apr 2006 20:13:13 +0200 Subject: Where am I? Do we need a Location Profiler? References: <1144926062.5527.25.camel@averatec> <1144951902.2465.15.camel@dhollis-lnx.sunera.com> <1145015212.2035.19.camel@localhost.localdomain> <443F9332.6030004@mesias.co.uk> <1145283186.2435.6.camel@dhollis-lnx.sunera.com> Message-ID: David Hollis wrote: > Tracking on location can be a tougher nut than some folks might think > though. It would most likely be a somewhat manual effort IMHO. Well, manual effort does not need to be complicated. NetworkManager could popup a small box with radio buttons like: You changed location. You are now : - at home - at work - at some-other-configured-location - at a new place (checkbox to choose to configure it) Button OK - Button stop-bothering-me-with-profiles Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From fedora at soeterbroek.com Mon Apr 17 18:21:09 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Mon, 17 Apr 2006 20:21:09 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <4443DC95.9020809@soeterbroek.com> Patrick W. Barnes wrote: > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. idea: YUM Fedora internal update server ('reposerver') How about a project for tools/utilities to create, maintain fedora/custom yum repositories behind the corporate firewall. - local mirror for fedora repositories (core, extras etc.) - Custom repos - Ability to merge repos to create custom, tested 'releases' (read: http://www.linuxdevcenter.com/lpt/a/5625) Regards, Joost Soeterbroek From nman64 at n-man.com Mon Apr 17 18:49:22 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Mon, 17 Apr 2006 13:49:22 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604170139h69f7fa4fgd58800a4076f8bcd@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <200604170323.18200.nman64@n-man.com> <16de708d0604170139h69f7fa4fgd58800a4076f8bcd@mail.gmail.com> Message-ID: <200604171349.25429.nman64@n-man.com> On Monday 17 April 2006 03:39, "Arthur Pemberton" wrote: > On 4/17/06, Patrick W. Barnes wrote: > > On Monday 17 April 2006 03:09, "Arthur Pemberton" wrote: > > > What became of the Backup tool from last year's SOC? > > > > https://sucs.org/~davea/trac/ > > > > The developer disappeared. > > Does that mean I can apply to do this? I am a freshman (I found out > about SOC-2005 when it was too late) and I think Fedora is desperately > in need of a backup/restoration tool, esp. since fresh installs are > so..fresh. > > Also it is a lot harder for me to dissappear. www.pembo13.com > I don't see any reason why not. It does qualify according to the SoC rules, and it is something that we need. It might help to coordinate with the rest of our community a little better than the previous developer to get the support and feedback that this sort of project really needs. If you do apply for this project, please make sure you reference the previous work and give a solid summary of what you plan to accomplish and how. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From Lam at Lam.pl Mon Apr 17 19:07:28 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 17 Apr 2006 21:07:28 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4443DC95.9020809@soeterbroek.com> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> Message-ID: <1145300848.2832.54.camel@pensja.lam.pl> Dnia 17-04-2006, pon o godzinie 20:21 +0200, Joost Soeterbroek napisa?(a): > idea: YUM Fedora internal update server ('reposerver') So maybe let's make yum usable? :) How about: - ^C support! (Insert lots of curses here) Logging in as root on another console to killall -9 yum is boring. - showing download speed - not downloading older repo data than newer, but grabbed from another mirror earlier - incremental (differences (added/removed packages) only) repo data download - showing "real" ETA for all files, not the file being downloaded atm Or maybe simply fix apt if it still has problems with dual-arch setups? :) Oh, oh, and maybe someone can force pup to not freeze the UI for half an hour when it's downloading something (or not)? And, of course, showing some progress (yum isn't very good at it, but pup is just horrible) and good speed/ETA values won't hurt users ;) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From benny+usenet at amorsen.dk Mon Apr 17 19:33:01 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 17 Apr 2006 21:33:01 +0200 Subject: Fedora Bounties (seeking ideas) References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> Message-ID: >>>>> "LM" == Leszek Matok writes: LM> So maybe let's make yum usable? :) How about: - ^C support! LM> (Insert lots of curses here) Logging in as root on another console LM> to killall -9 yum is boring. C-z works, so logging in on a different console is not necessary. I agree that it is annoying though. /Benny From michael at knox.net.nz Mon Apr 17 19:35:58 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 18 Apr 2006 07:35:58 +1200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145300848.2832.54.camel@pensja.lam.pl> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> Message-ID: <4443EE1E.8090107@knox.net.nz> Leszek Matok wrote: > Dnia 17-04-2006, pon o godzinie 20:21 +0200, Joost Soeterbroek > napisa?(a): >> idea: YUM Fedora internal update server ('reposerver') > So maybe let's make yum usable? :) > How about: > - ^C support! (Insert lots of curses here) Logging in as root on another > console to killall -9 yum is boring. > - showing download speed > - not downloading older repo data than newer, but grabbed from another > mirror earlier > - incremental (differences (added/removed packages) only) repo data > download > - showing "real" ETA for all files, not the file being downloaded atm > > Or maybe simply fix apt if it still has problems with dual-arch > setups? :) > > Oh, oh, and maybe someone can force pup to not freeze the UI for half an > hour when it's downloading something (or not)? And, of course, showing > some progress (yum isn't very good at it, but pup is just horrible) and > good speed/ETA values won't hurt users ;) +1 ! Those would be some awesome additions. Michael From skvidal at linux.duke.edu Mon Apr 17 19:44:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 17 Apr 2006 15:44:47 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145300848.2832.54.camel@pensja.lam.pl> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> Message-ID: <1145303087.32015.11.camel@cutter> On Mon, 2006-04-17 at 21:07 +0200, Leszek Matok wrote: > Dnia 17-04-2006, pon o godzinie 20:21 +0200, Joost Soeterbroek > napisa?(a): > > idea: YUM Fedora internal update server ('reposerver') > So maybe let's make yum usable? :) > How about: > - ^C support! (Insert lots of curses here) Logging in as root on another > console to killall -9 yum is boring. rpm grabs ctrl-c when you open a transaction set. That is the trick. We could work around it - but something should probably give here. > - showing download speed *yawn* we went through this on the yum list - we have finite space - how is download speed useful to you? > - not downloading older repo data than newer, but grabbed from another > mirror earlier again - how do we determine this w/o downloading the information? > - incremental (differences (added/removed packages) only) repo data > download I'd love to hear how we're going to break it up so you can tell. > - showing "real" ETA for all files, not the file being downloaded atm this is probably more doable. > Or maybe simply fix apt if it still has problems with dual-arch > setups? :) this won't help us with pup, anaconda or pirut. If you have some suggestions on actual resolutions I'd encourage you to contact the appropriate list. If you're just bitching and moaning then stop. -sv From seg at haxxed.com Mon Apr 17 19:55:12 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 17 Apr 2006 14:55:12 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145300848.2832.54.camel@pensja.lam.pl> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> Message-ID: <1145303714.5173.11.camel@hamburger.booze> On Mon, 2006-04-17 at 21:07 +0200, Leszek Matok wrote: > - ^C support! (Insert lots of curses here) Logging in as root on another > console to killall -9 yum is boring. Yeah, I've noticed Python apps in general tend to be very leisurely about responding to a ^C. Yum in particular seems to take ^C to mean "Cancel download and retry on a different mirror" when it should mean "!@#$ing stop already". Though being able to move to a different mirror is handy. Put that on a *different* key please. > Or maybe simply fix apt if it still has problems with dual-arch > setups? :) That's being taken care of. Check out whats in extras-development. As an extra bonus, apt can now use yum metadata. No more special apt repo support needed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Apr 17 20:01:12 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Apr 2006 16:01:12 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145303087.32015.11.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> Message-ID: <20060417200112.GE32157@devserv.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > On Mon, 2006-04-17 at 21:07 +0200, Leszek Matok wrote: > > Dnia 17-04-2006, pon o godzinie 20:21 +0200, Joost Soeterbroek > > napisa?(a): > > > idea: YUM Fedora internal update server ('reposerver') > > So maybe let's make yum usable? :) > > How about: > > - ^C support! (Insert lots of curses here) Logging in as root on another > > console to killall -9 yum is boring. > > rpm grabs ctrl-c when you open a transaction set. That is the trick. We > could work around it - but something should probably give here. I do not know for sure, but he may be discussing the Ctrl-C -> fallback to next mirror behavior. > > - not downloading older repo data than newer, but grabbed from another > > mirror earlier > > again - how do we determine this w/o downloading the information? HEAD? (Yeah, yeah, only works for HTTP.) Bill From skvidal at linux.duke.edu Mon Apr 17 20:04:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 17 Apr 2006 16:04:14 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <20060417200112.GE32157@devserv.devel.redhat.com> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417200112.GE32157@devserv.devel.redhat.com> Message-ID: <1145304254.32015.16.camel@cutter> On Mon, 2006-04-17 at 16:01 -0400, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > On Mon, 2006-04-17 at 21:07 +0200, Leszek Matok wrote: > > > Dnia 17-04-2006, pon o godzinie 20:21 +0200, Joost Soeterbroek > > > napisa?(a): > > > > idea: YUM Fedora internal update server ('reposerver') > > > So maybe let's make yum usable? :) > > > How about: > > > - ^C support! (Insert lots of curses here) Logging in as root on another > > > console to killall -9 yum is boring. > > > > rpm grabs ctrl-c when you open a transaction set. That is the trick. We > > could work around it - but something should probably give here. > > I do not know for sure, but he may be discussing the Ctrl-C -> > fallback to next mirror behavior. > > > > - not downloading older repo data than newer, but grabbed from another > > > mirror earlier > > > > again - how do we determine this w/o downloading the information? > > HEAD? (Yeah, yeah, only works for HTTP.) > and only some http servers. -sv From pemboa at gmail.com Mon Apr 17 20:11:17 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 17 Apr 2006 15:11:17 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4443DC95.9020809@soeterbroek.com> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> Message-ID: <16de708d0604171311t1da8d19fod3e613abfc52a1cc@mail.gmail.com> On 4/17/06, Joost Soeterbroek wrote: > Patrick W. Barnes wrote: > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > > Project has not yet applied to participate this year, I suspect we are likely > > to do so. However, our Fedora Bounties list is now quite short. We need > > fresh ideas. If there are any projects that you would like to see, please > > add them to the FedoraBounties page. These can include ideas that you may > > have had but don't have time to work on, problems that you have encountered > > that need attention, or tools you really wish we had. > > idea: YUM Fedora internal update server ('reposerver') > > How about a project for tools/utilities to create, maintain > fedora/custom yum repositories behind the corporate firewall. > > - local mirror for fedora repositories (core, extras etc.) > - Custom repos > - Ability to merge repos to create custom, tested 'releases' (read: > http://www.linuxdevcenter.com/lpt/a/5625) > > Regards, > > Joost Soeterbroek Yam already (supposedly) does this. As a boy I jumped through Windows, as a man I play with Penguins. From fedora at camperquake.de Mon Apr 17 20:18:49 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 17 Apr 2006 22:18:49 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145303087.32015.11.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> Message-ID: <20060417221849.69d56171@nausicaa.camperquake.de> Hi. seth vidal wrote: > again - how do we determine this w/o downloading the information? How about downloading and then determining if the information is older than the information we already have? Sure, we have downloaded unneeded information. But it's better than going ahead and actually using information we know to be outdated. -- "Bought case from supplier . Bought power supply also from supplier , in the same order, in fact. Does the switch attached to the latter fit into the little hole in the former? Do fires burn underwater?" -- Alistair Young From Lam at Lam.pl Mon Apr 17 20:28:38 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 17 Apr 2006 22:28:38 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145303087.32015.11.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> Message-ID: <1145305718.2832.88.camel@pensja.lam.pl> Dnia 17-04-2006, pon o godzinie 15:44 -0400, seth vidal napisa?(a): > rpm grabs ctrl-c when you open a transaction set I was talking about ^C when downloading packages, not in RPM transaction. It thinks the download was broken and tries with another mirror, even if I keep ^C pressed with repeat set to 30/s! :) I checked ^\, too (doesn't work). > > - showing download speed > *yawn* we went through this on the yum list - we have finite space - how > is download speed useful to you? Since you asked - I want to see if it works (try to upgrade OOo on 32 Kbps link and tell me if it's doing something or not), I want to see if it's using fast mirror or not (so I can break the download and try again), I want to see if it's using whole my bw, and most important to me - knowing the speed I'm able to come up with real ETA if I start or stop downloading something else at the same time. > > - not downloading older repo data than newer, but grabbed from another > > mirror earlier > again - how do we determine this w/o downloading the information? repomd.xml is small and contains timestamps, but I get an impression it overrides previously downloaded info and makes yum download older primary.xml.gz. I see info like "400 new, 30 old" and "30 new, 400 old" few times a day, maybe it's just a coincidence and my wrong impression, not "downgrading". If that's the case, I'm really sorry for being a troll. > > - incremental (differences (added/removed packages) only) repo data > > download > I'd love to hear how we're going to break it up so you can tell. Make repository data a dir of files with serial numbers (00001.xml.gz, 00002.xml.gz or similar) containing changes. After adding/removing packages, new file is created with incremented serial numer, including info on changes. Repository metadata contains the current serial number. Updating package list means checking current serial number and downloading changes since last known change. Also, there's old-style everything-in-one-file file used by older yum versions and by newer if serial delta is more than the one provided by yum.conf. It would work with any FTP and HTTP server with no effort on their side (unlike CVS server). Keepalive HTTP connections and every FTP connection can download multiple files in a row, so it's no problem either. Again, I'm not trying to be smarter than anyone here, just writing it because you asked. I know it's not five minutes of work. > If you have some suggestions on actual resolutions I'd encourage you to > contact the appropriate list. This is the "seeking ideas" thread. I'm not writing this just to write, but I don't have knowledge to fix it myself and I see people wanting this changes every other day, really (from your yawning I guess you see it too). Another thing I'd like to see changed - I'm seeing: "primary.xml.gz xx%" - it would be nice showing let's say: "updates/primary xx%" - there is space for that. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From bojan at rexursive.com Mon Apr 17 22:22:15 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Apr 2006 08:22:15 +1000 Subject: FC5 kernel updates Message-ID: <1145312535.16371.51.camel@coyote.rexursive.com> Maybe slightly off topic here (not sure)... Are there plans to bump up FC5 kernels to 2.6.16.6, given that several stable kernel updates contained security fixes? Or is FC5 unaffected by the ones mentioned in kernel release notes (i.e. wrong arch, features that are not compiled, already patched by FC specific patches etc.)? -- Bojan From davej at redhat.com Mon Apr 17 22:33:10 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 17 Apr 2006 17:33:10 -0500 Subject: FC5 kernel updates In-Reply-To: <1145312535.16371.51.camel@coyote.rexursive.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> Message-ID: <20060417223310.GL16508@redhat.com> On Tue, Apr 18, 2006 at 08:22:15AM +1000, Bojan Smojver wrote: > Maybe slightly off topic here (not sure)... > > Are there plans to bump up FC5 kernels to 2.6.16.6, given that several > stable kernel updates contained security fixes? Or is FC5 unaffected by > the ones mentioned in kernel release notes (i.e. wrong arch, features > that are not compiled, already patched by FC specific patches etc.)? It's compiling right now. Should be out today/tomorrow. Dave -- http://www.codemonkey.org.uk From rodd at clarkson.id.au Tue Apr 18 00:28:37 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 18 Apr 2006 10:28:37 +1000 Subject: FC5 kernel updates In-Reply-To: <20060417223310.GL16508@redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> Message-ID: <1145320117.2840.1.camel@localhost.localdomain> On Mon, 2006-04-17 at 17:33 -0500, Dave Jones wrote: > On Tue, Apr 18, 2006 at 08:22:15AM +1000, Bojan Smojver wrote: > > Maybe slightly off topic here (not sure)... > > > > Are there plans to bump up FC5 kernels to 2.6.16.6, given that several > > stable kernel updates contained security fixes? Or is FC5 unaffected by > > the ones mentioned in kernel release notes (i.e. wrong arch, features > > that are not compiled, already patched by FC specific patches etc.)? > > It's compiling right now. Should be out today/tomorrow. > > Dave > > -- > http://www.codemonkey.org.uk While we're discussing kernel upgrades, any likely hood of seeing 2.17.x based kernels for FC5 at some time in the future? Or, how well should rawhide 2.17.x kernels work with FC5? I'm keen to get my SD card reader working and this is in the 2.17.x series. R. -- "It's a fine line between denial and faith. It's much better on my side" From mike at miketc.com Tue Apr 18 00:34:23 2006 From: mike at miketc.com (Mike Chambers) Date: Mon, 17 Apr 2006 19:34:23 -0500 Subject: FC5 kernel updates In-Reply-To: <1145320117.2840.1.camel@localhost.localdomain> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> Message-ID: <1145320463.4508.0.camel@scrappy.miketc.com> On Tue, 2006-04-18 at 10:28 +1000, Rodd Clarkson wrote: > While we're discussing kernel upgrades, any likely hood of seeing 2.17.x > based kernels for FC5 at some time in the future? > > Or, how well should rawhide 2.17.x kernels work with FC5? Unless I'm mistaken, still seeing/using 2.6.16 kernels in rawhide. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important until you aren't getting any!" From jwboyer at jdub.homelinux.org Tue Apr 18 00:46:17 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 17 Apr 2006 19:46:17 -0500 Subject: FC5 kernel updates In-Reply-To: <1145320463.4508.0.camel@scrappy.miketc.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> <1145320463.4508.0.camel@scrappy.miketc.com> Message-ID: <1145321178.9939.10.camel@yoda.jdub.homelinux.org> On Mon, 2006-04-17 at 19:34 -0500, Mike Chambers wrote: > On Tue, 2006-04-18 at 10:28 +1000, Rodd Clarkson wrote: > > > While we're discussing kernel upgrades, any likely hood of seeing 2.17.x > > based kernels for FC5 at some time in the future? > > > > Or, how well should rawhide 2.17.x kernels work with FC5? > > Unless I'm mistaken, still seeing/using 2.6.16 kernels in rawhide. 2.6.17 hasn't been released yet. It's still in release candidate mode. Rawhide kernels aren't really 2.6.16 though. They're 2.6.16 + patches from the 2.6.17 git tree. See today's rawhide report: kernel-2.6.16-1.2134_FC6 ------------------------ * Sun Apr 16 2006 Dave Jones - Big rebase to 2.6.17-rc1-git12 The reason the RPM version is still .16 is because you still want to be able to upgrade to 2.6.17 when it comes out. josh From skvidal at linux.duke.edu Tue Apr 18 01:45:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 17 Apr 2006 21:45:54 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <20060417221849.69d56171@nausicaa.camperquake.de> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> Message-ID: <1145324754.1568.8.camel@cutter> On Mon, 2006-04-17 at 22:18 +0200, Ralf Ertzinger wrote: > Hi. > > seth vidal wrote: > > > again - how do we determine this w/o downloading the information? > > How about downloading and then determining if the information is older > than the information we already have? > Sure, we have downloaded unneeded information. But it's better than > going ahead and actually using information we know to be outdated. It just means we have to make an additional temp file and compare it every time. It costs time for the generic case where the files have changed and are newer. That being the most common case. -sv From bojan at rexursive.com Tue Apr 18 01:56:21 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Apr 2006 11:56:21 +1000 Subject: pilot-link for FC5 updates Message-ID: <1145325382.16371.60.camel@coyote.rexursive.com> Could someone move that from testing to real updates for FC5? Evo and other stuff depends on it... -- Bojan From rodd at clarkson.id.au Tue Apr 18 02:02:50 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 18 Apr 2006 12:02:50 +1000 Subject: FC5 kernel updates In-Reply-To: <1145321178.9939.10.camel@yoda.jdub.homelinux.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> <1145320463.4508.0.camel@scrappy.miketc.com> <1145321178.9939.10.camel@yoda.jdub.homelinux.org> Message-ID: <1145325771.2840.3.camel@localhost.localdomain> On Mon, 2006-04-17 at 19:46 -0500, Josh Boyer wrote: > On Mon, 2006-04-17 at 19:34 -0500, Mike Chambers wrote: > > On Tue, 2006-04-18 at 10:28 +1000, Rodd Clarkson wrote: > > > > > While we're discussing kernel upgrades, any likely hood of seeing 2.17.x > > > based kernels for FC5 at some time in the future? > > > > > > Or, how well should rawhide 2.17.x kernels work with FC5? > > > > Unless I'm mistaken, still seeing/using 2.6.16 kernels in rawhide. > > 2.6.17 hasn't been released yet. It's still in release candidate mode. > > Rawhide kernels aren't really 2.6.16 though. They're 2.6.16 + patches > from the 2.6.17 git tree. See today's rawhide report: > > kernel-2.6.16-1.2134_FC6 > ------------------------ > * Sun Apr 16 2006 Dave Jones > - Big rebase to 2.6.17-rc1-git12 > > The reason the RPM version is still .16 is because you still want to be > able to upgrade to 2.6.17 when it comes out. All, good, but will/should FC5 work with the current rawhide kernels? R. -- "It's a fine line between denial and faith. It's much better on my side" From jkeating at redhat.com Tue Apr 18 02:12:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 17 Apr 2006 22:12:02 -0400 Subject: pilot-link for FC5 updates In-Reply-To: <1145325382.16371.60.camel@coyote.rexursive.com> References: <1145325382.16371.60.camel@coyote.rexursive.com> Message-ID: <1145326322.3071.40.camel@ender> On Tue, 2006-04-18 at 11:56 +1000, Bojan Smojver wrote: > Could someone move that from testing to real updates for FC5? Evo and > other stuff depends on it... There is something of a problem with that. If I do that, I have to move the pending large set of KDE updates. I didn't notice this dep chain when I pushed the evo update with the rest of the gnome updates. There was a bit of miscommunication here and now we're left w/ a bit of a problem. I'm waiting for the KDE maintainer to start his work day (lives in a different country) so that we can hopefully push the KDE updates, and pilot-link along with it. This will be resolved soon. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Apr 18 02:13:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 17 Apr 2006 22:13:10 -0400 Subject: FC5 kernel updates In-Reply-To: <1145325771.2840.3.camel@localhost.localdomain> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> <1145320463.4508.0.camel@scrappy.miketc.com> <1145321178.9939.10.camel@yoda.jdub.homelinux.org> <1145325771.2840.3.camel@localhost.localdomain> Message-ID: <604aa7910604171913u1bbbb4gd17d392dd30cd9a4@mail.gmail.com> On 4/17/06, Rodd Clarkson wrote: > All, good, but will/should FC5 work with the current rawhide kernels? c'mon... you know the drill... its rawhide. Rawhide eats babies. You are free to use rawhide is small chunks are in large pieces... either way noone is going to promise you that its suppose to work...especially outside of the coordinating test release phases. -jef"I'm a brok..brok...brok..brok... en record"spaleta From rodd at clarkson.id.au Tue Apr 18 02:31:03 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 18 Apr 2006 12:31:03 +1000 Subject: FC5 kernel updates In-Reply-To: <604aa7910604171913u1bbbb4gd17d392dd30cd9a4@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> <1145320463.4508.0.camel@scrappy.miketc.com> <1145321178.9939.10.camel@yoda.jdub.homelinux.org> <1145325771.2840.3.camel@localhost.localdomain> <604aa7910604171913u1bbbb4gd17d392dd30cd9a4@mail.gmail.com> Message-ID: <1145327463.2840.7.camel@localhost.localdomain> On Mon, 2006-04-17 at 22:13 -0400, Jeff Spaleta wrote: > On 4/17/06, Rodd Clarkson wrote: > > All, good, but will/should FC5 work with the current rawhide kernels? > > c'mon... you know the drill... its rawhide. Rawhide eats babies. You > are free to use rawhide is small chunks are in large pieces... either > way noone is going to promise you that its suppose to > work...especially outside of the coordinating test release phases. Yeah, yeah, I know this drill. I'm not asking will rawhide eat my babies. I'm asking has anything major changed in the rawhide kernel since FC5 that would mean that the kernel just won't work and isn't worth trying. I just thought a quick low band-width question on a mailing list might be better than a high bandwidth download, but maybe I should just put my babies on a plate, add a little sauce and see whether the rawhide kernel is hungry. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From bojan at rexursive.com Tue Apr 18 02:57:12 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Apr 2006 02:57:12 +0000 (UTC) Subject: pilot-link for FC5 updates References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> Message-ID: Jesse Keating redhat.com> writes: > There is something of a problem with that. If I do that, I have to move > the pending large set of KDE updates. I didn't notice this dep chain > when I pushed the evo update with the rest of the gnome updates. There > was a bit of miscommunication here and now we're left w/ a bit of a > problem. > > I'm waiting for the KDE maintainer to start his work day (lives in a > different country) so that we can hopefully push the KDE updates, and > pilot-link along with it. This will be resolved soon. No worries. I just pulled packages manually from testing and it all worked. -- Bojan From bojan at rexursive.com Tue Apr 18 03:00:40 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Apr 2006 03:00:40 +0000 (UTC) Subject: FC5 kernel updates References: <1145312535.16371.51.camel@coyote.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Are there plans to bump up FC5 kernels to 2.6.16.6, [..snip..] Scrap that! 2.6.16.7 is out! -- Bojan From bojan at rexursive.com Tue Apr 18 03:44:09 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 18 Apr 2006 03:44:09 +0000 (UTC) Subject: Init scritps timeout References: <20060415091436.80143.qmail@web35602.mail.mud.yahoo.com> Message-ID: Federico yahoo.com> writes: > Yesterday my server had a power failure and the ldap database got corrupted. > The weird thing is that the corruption caused the ldap init script to hang and > it stopped the server boot. Today I corrupted the database on purpose to > reproduce the problem but it's not happening anymore. > Beside all the precautions (ups, raid, journaled filesystems, etc...) and > beside the fact it probably was a really particoular database corruption, > shouldn't the init scripts have a timeout? If any of the scripts hangs the > whole boot process stops. Isn't this a really dangerous behaviour? Bumped into this one myself. Really annoying. You probably have BDB as you LDAP back end, just like me. And BDB is scary when it comes to uncommitted transactions or any other type of problem you may have present in your database. Although probably not entirely correct, in order to avoid this hang, I have this in /etc/sysconfig/ldap: su - -s /bin/bash ldap -c /usr/sbin/slapd_db_recover If the database is OK, nothing happens. If it is screwed, the recover process gets it to the state where slapd actually starts. Usually, it even works properly :-) Word of warning: I do dump my LDAP database regularly, so I know that even if db_recover stuffs up my database, I can go back. Unless you're doing something similar, I suggest you read more about what db_recover does before implementing this workaround. -- Bojan From davej at redhat.com Tue Apr 18 03:54:09 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 17 Apr 2006 22:54:09 -0500 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> Message-ID: <20060418035409.GP16508@redhat.com> On Tue, Apr 18, 2006 at 03:00:40AM +0000, Bojan Smojver wrote: > Bojan Smojver rexursive.com> writes: > > > Are there plans to bump up FC5 kernels to 2.6.16.6, [..snip..] > > Scrap that! 2.6.16.7 is out! *grumble*, just as .6 finished... builds restarting, they should be done by the morning hopefully. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Tue Apr 18 03:57:08 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 17 Apr 2006 22:57:08 -0500 Subject: FC5 kernel updates In-Reply-To: <1145320117.2840.1.camel@localhost.localdomain> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> Message-ID: <20060418035708.GQ16508@redhat.com> On Tue, Apr 18, 2006 at 10:28:37AM +1000, Rodd Clarkson wrote: > While we're discussing kernel upgrades, any likely hood of seeing 2.17.x > based kernels for FC5 at some time in the future? > > Or, how well should rawhide 2.17.x kernels work with FC5? > > I'm keen to get my SD card reader working and this is in the 2.17.x > series. I do intend on doing .17rc kernels for FC4/FC5 soon(ish), I've just been real busy with travelling (power management summit) and some real-life stuff lately. There are also some logistical hurdles that need overcoming, such as people.redhat.com not being the best place for me to distribute experimental kernels (Because there are so many of them) Hopefully stuff will settle down again soon, and I can make some progress on sorting this out. Dave -- http://www.codemonkey.org.uk From rodd at clarkson.id.au Tue Apr 18 04:14:54 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 18 Apr 2006 14:14:54 +1000 Subject: FC5 kernel updates In-Reply-To: <20060418035708.GQ16508@redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <1145320117.2840.1.camel@localhost.localdomain> <20060418035708.GQ16508@redhat.com> Message-ID: <1145333694.2840.11.camel@localhost.localdomain> On Mon, 2006-04-17 at 22:57 -0500, Dave Jones wrote: > On Tue, Apr 18, 2006 at 10:28:37AM +1000, Rodd Clarkson wrote: > > While we're discussing kernel upgrades, any likely hood of seeing 2.17.x > > based kernels for FC5 at some time in the future? > > > > Or, how well should rawhide 2.17.x kernels work with FC5? > > > > I'm keen to get my SD card reader working and this is in the 2.17.x > > series. > > I do intend on doing .17rc kernels for FC4/FC5 soon(ish), I've just been > real busy with travelling (power management summit) and some real-life stuff > lately. There are also some logistical hurdles that need overcoming, > such as people.redhat.com not being the best place for me to distribute > experimental kernels (Because there are so many of them) > > Hopefully stuff will settle down again soon, and I can make some progress > on sorting this out. Thanks Dave, If I can help with testing then ask. R. -- "It's a fine line between denial and faith. It's much better on my side" From tdiehl at rogueind.com Tue Apr 18 04:59:58 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 18 Apr 2006 00:59:58 -0400 (EDT) Subject: FC5 kernel updates In-Reply-To: <20060417223310.GL16508@redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> Message-ID: On Mon, 17 Apr 2006, Dave Jones wrote: > On Tue, Apr 18, 2006 at 08:22:15AM +1000, Bojan Smojver wrote: > > Maybe slightly off topic here (not sure)... > > > > Are there plans to bump up FC5 kernels to 2.6.16.6, given that several > > stable kernel updates contained security fixes? Or is FC5 unaffected by > > the ones mentioned in kernel release notes (i.e. wrong arch, features > > that are not compiled, already patched by FC specific patches etc.)? > > It's compiling right now. Should be out today/tomorrow. Will this have fixes for bug 186628 and if so is it going to be released for FC4 as well? I would really like to be able to mount CIFS partitions again. :-( Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From davej at redhat.com Tue Apr 18 05:03:31 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 18 Apr 2006 01:03:31 -0400 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> Message-ID: <20060418050331.GA26628@redhat.com> On Tue, Apr 18, 2006 at 12:59:58AM -0400, Tom Diehl wrote: > On Mon, 17 Apr 2006, Dave Jones wrote: > > > On Tue, Apr 18, 2006 at 08:22:15AM +1000, Bojan Smojver wrote: > > > Maybe slightly off topic here (not sure)... > > > > > > Are there plans to bump up FC5 kernels to 2.6.16.6, given that several > > > stable kernel updates contained security fixes? Or is FC5 unaffected by > > > the ones mentioned in kernel release notes (i.e. wrong arch, features > > > that are not compiled, already patched by FC specific patches etc.)? > > > > It's compiling right now. Should be out today/tomorrow. > > Will this have fixes for bug 186628 and if so is it going to be released for > FC4 as well? Right now the priority is getting something out to fix up all the security holes that became public in the last week. Once this is done, I'll be taking a pass through bugzilla, as things have really piled up over the last few weeks. Dave -- http://www.codemonkey.org.uk From tdiehl at rogueind.com Tue Apr 18 05:22:37 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 18 Apr 2006 01:22:37 -0400 (EDT) Subject: FC5 kernel updates In-Reply-To: <20060418050331.GA26628@redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060417223310.GL16508@redhat.com> <20060418050331.GA26628@redhat.com> Message-ID: On Tue, 18 Apr 2006, Dave Jones wrote: > On Tue, Apr 18, 2006 at 12:59:58AM -0400, Tom Diehl wrote: > > On Mon, 17 Apr 2006, Dave Jones wrote: > > > > > On Tue, Apr 18, 2006 at 08:22:15AM +1000, Bojan Smojver wrote: > > > > Maybe slightly off topic here (not sure)... > > > > > > > > Are there plans to bump up FC5 kernels to 2.6.16.6, given that several > > > > stable kernel updates contained security fixes? Or is FC5 unaffected by > > > > the ones mentioned in kernel release notes (i.e. wrong arch, features > > > > that are not compiled, already patched by FC specific patches etc.)? > > > > > > It's compiling right now. Should be out today/tomorrow. > > > > Will this have fixes for bug 186628 and if so is it going to be released for > > FC4 as well? > > Right now the priority is getting something out to fix up all the security > holes that became public in the last week. Once this is done, I'll be > taking a pass through bugzilla, as things have really piled up over the > last few weeks. Thanks for the info. Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From dragoran at feuerpokemon.de Tue Apr 18 05:46:11 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 18 Apr 2006 07:46:11 +0200 Subject: FC5 updates missing dep Message-ID: <44447D23.9070408@feuerpokemon.de> I tryed to update using pup today and got this: Missing Dependency: libpisock.so.8()(64bit) is needed by package evolution From dragoran at feuerpokemon.de Tue Apr 18 05:53:56 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 18 Apr 2006 07:53:56 +0200 Subject: FC5 updates missing dep In-Reply-To: <44447D23.9070408@feuerpokemon.de> References: <44447D23.9070408@feuerpokemon.de> Message-ID: <44447EF4.70300@feuerpokemon.de> dragoran wrote: > I tryed to update using pup today and got this: > Missing Dependency: libpisock.so.8()(64bit) is needed by package > evolution > sorry for posting this its already posted.. I just execluded evo for now and waiting for the kde updates... From dragoran at feuerpokemon.de Tue Apr 18 06:01:01 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 18 Apr 2006 08:01:01 +0200 Subject: FC5 updates missing dep In-Reply-To: <44447EF4.70300@feuerpokemon.de> References: <44447D23.9070408@feuerpokemon.de> <44447EF4.70300@feuerpokemon.de> Message-ID: <4444809D.40103@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> I tryed to update using pup today and got this: >> Missing Dependency: libpisock.so.8()(64bit) is needed by package >> evolution >> > sorry for posting this its already posted.. > I just execluded evo for now and waiting for the kde updates... > other error: Transaction Check Error: file /etc/gconf/schemas/desktop_gnome_accessibility_keyboard.schemas from install of libgnome-2.14.1-1.fc5.1 conflicts with file from package libgnome-2.14.0-1 From giallu at gmail.com Tue Apr 18 07:06:52 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 18 Apr 2006 09:06:52 +0200 Subject: FC5 updates missing dep In-Reply-To: <44447D23.9070408@feuerpokemon.de> References: <44447D23.9070408@feuerpokemon.de> Message-ID: On 4/18/06, dragoran wrote: > I tryed to update using pup today and got this: > Missing Dependency: libpisock.so.8()(64bit) is needed by package evolution Confirmed on x86 arch. Do we need a bugzilla for this? [giallu at hal9001 ~]$ sudo yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories livna [1/4] core [2/4] updates [3/4] extras [4/4] Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package evolution.i386 0:2.6.1-1.fc5.2 set to be updated --> Running transaction check --> Processing Dependency: libpisock.so.8 for package: evolution --> Finished Dependency Resolution Error: Missing Dependency: libpisock.so.8 is needed by package evolution From giallu at gmail.com Tue Apr 18 07:08:19 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 18 Apr 2006 09:08:19 +0200 Subject: FC5 updates missing dep In-Reply-To: <4444809D.40103@feuerpokemon.de> References: <44447D23.9070408@feuerpokemon.de> <44447EF4.70300@feuerpokemon.de> <4444809D.40103@feuerpokemon.de> Message-ID: On 4/18/06, dragoran wrote: > other error: > Transaction Check Error: file > /etc/gconf/schemas/desktop_gnome_accessibility_keyboard.schemas from > install of libgnome-2.14.1-1.fc5.1 conflicts with file from package > libgnome-2.14.0-1 > This one worked for me. [giallu at hal9001 ~]$ rpm -q libgnome libgnome-2.14.1-1.fc5.1 From dragoran at feuerpokemon.de Tue Apr 18 07:11:55 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 18 Apr 2006 09:11:55 +0200 Subject: FC5 updates missing dep In-Reply-To: References: <44447D23.9070408@feuerpokemon.de> <44447EF4.70300@feuerpokemon.de> <4444809D.40103@feuerpokemon.de> Message-ID: <4444913B.3060509@feuerpokemon.de> Gianluca Sforna wrote: > On 4/18/06, dragoran wrote: > >> other error: >> Transaction Check Error: file >> /etc/gconf/schemas/desktop_gnome_accessibility_keyboard.schemas from >> install of libgnome-2.14.1-1.fc5.1 conflicts with file from package >> libgnome-2.14.0-1 >> >> > > This one worked for me. > > [giallu at hal9001 ~]$ rpm -q libgnome > libgnome-2.14.1-1.fc5.1 > > the first one will be fixed when the kde updates are out. the libgnome issue seems to be related to a libgnome.i386 and a libgnome.x86_64 package installed. I removed both with --nodeps and reinstalled them and it should be fine now ;) From buildsys at redhat.com Tue Apr 18 07:15:03 2006 From: buildsys at redhat.com (Build System) Date: Tue, 18 Apr 2006 03:15:03 -0400 Subject: rawhide report: 20060418 changes Message-ID: <200604180715.k3I7F30n004703@porkchop.devel.redhat.com> Updated Packages: at-spi-1.7.7-6 -------------- * Mon Apr 17 2006 Matthias Clasen - 1.7.7-6 - Revert the previous change audiofile-1:0.2.6-4 ------------------- * Mon Apr 17 2006 John (J5) Palmieri - 1:0.2.6-4 - Remove Makefile* from docs so they are not installed bluez-utils-2.25-6 ------------------ * Mon Apr 17 2006 Peter Jones - 2.25-6 - Clean up initscripts. - Clean up specfile. control-center-1:2.14.1-3 ------------------------- * Mon Apr 17 2006 Matthias Clasen - 2.14.1-3 - Fix the thunderbird commandline createrepo-0.4.4-1 ------------------ * Mon Apr 17 2006 Paul Nasrat - 0.4.4-1 - Update to latest upstream dbus-0.61-4 ----------- * Mon Apr 17 2006 John (J5) Palmieri 0.61-4 - New audit patch * Fri Feb 24 2006 John (J5) Palmieri 0.61-3 - ABI hasn't changed so add patch that makes dbus-sharp think it is still 0.60 (mono uses hard version names so any change means apps need to recompile) gnome-menus-2.14.0-2 -------------------- * Thu Apr 13 2006 Matthias Clasen - 2.14.0-2 - Update to 2.14.0 - Drop upstreamed patch gnome-terminal-2.14.1-8 ----------------------- * Tue Apr 18 2006 Kristian H??gsberg 2.14.1-8 - Bump for rawhide build. * Tue Apr 18 2006 Kristian H??gsberg 2.14.1-7 - Only use ARGB visual if a compositing manager is running to avoid slow-down caused by automatic compositor. * Mon Apr 17 2006 Kristian H??gsberg 2.14.1-6 - Bumpd for rawhide build. gnome-utils-1:2.14.0-4 ---------------------- * Tue Apr 11 2006 Matthias Clasen 2.14.0-4 - Update to zenity 2.14.1 gnucash-1.9.5-1 --------------- * Mon Apr 17 2006 Bill Nottingham - 1.9.5-1 - update to 1.9.5 gtk2-engines-2.7.4-4 -------------------- * Mon Apr 17 2006 Soren Sandmann - 2.7.4-4 - Add missing clone method in the Clearlooks engine man-pages-ja-20060415-1 ----------------------- * Mon Apr 17 2006 Akira TAGOH - 20060415-1 - updates to 20060415. * Mon Mar 20 2006 Akira TAGOH - 20060315-1 - updates to 20060315. * Thu Mar 09 2006 Akira TAGOH - 20060215-1 - updates to 20060215. notify-daemon-0.3.1-10 ---------------------- * Mon Apr 17 2006 Kristian H??gsberg 0.3.1-10 - Update name of compositing manager selection to track recent metacity changes. pm-utils-0.17-1 --------------- * Mon Apr 17 2006 Peter Jones - 0.17-1 - add more helper functions - rework things that were forking an extra subshell - fix the suspend lock - work around bluetooth/usb suspend wackiness * Fri Mar 17 2006 Peter Jones - 0.16-1 - rework the difference between hibernate and suspend; get rid of PM_MODE - add 00clear script - move default_resume_kernel from "functions" to 01grub's hibernate section pykickstart-0.26-1 ------------------ * Mon Apr 17 2006 Chris Lumens 0.26-1 - Ignore spaces before group names (#188095). - Added some translations. - Add options for repo command. - Reorder %packages section output. - Output %packages header options. - Initialize RAID and volume group members to empty lists. rhythmbox-0.9.4-2 ----------------- * Mon Apr 17 2006 Matthias Clasen - 0.9.4-2 - Update to 0.9.4 - Drop upstreamed patches scim-1.4.4-15 ------------- * Tue Apr 18 2006 Jens Petersen - 1.4.4-15 - scim-bridge-0.1.6 * Mon Apr 10 2006 Jens Petersen - 1.4.4-14 - subpackage scim-bridge and add xinput.d file for scim-bridge - add scim_ver and scim_bridge_ver * Fri Apr 07 2006 Jens Petersen - 1.4.4-13 - update to scim-bridge-0.1.4 selinux-policy-2.2.32-2 ----------------------- * Fri Apr 14 2006 Dan Walsh 2.2.32-2 - Add unconfined_mount_t - Allow privoxy to connect to httpd_cache - fix cups labeleing on /var/cache/cups sound-juicer-2.14.3-2 --------------------- * Mon Apr 17 2006 Matthias Clasen - 2.14.3-2 - Update to 2.14.3 tog-pegasus-2:2.5.1-3.FC6 ------------------------- * Mon Apr 17 2006 Jason Vas Dias - 2:2.5.1-3 - Fix repupgrade (make it use correct paths) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From gilboad at gmail.com Tue Apr 18 07:26:17 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 18 Apr 2006 10:26:17 +0300 Subject: FC5 updates missing dep In-Reply-To: References: <44447D23.9070408@feuerpokemon.de> Message-ID: <1145345177.9905.6.camel@gilboa-home-dev.localhost> On Tue, 2006-04-18 at 09:06 +0200, Gianluca Sforna wrote: > On 4/18/06, dragoran wrote: > > I tryed to update using pup today and got this: > > Missing Dependency: libpisock.so.8()(64bit) is needed by package evolution > > Confirmed on x86 arch. Do we need a bugzilla for this? > > [giallu at hal9001 ~]$ sudo yum update > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > livna [1/4] > core [2/4] > updates [3/4] > extras [4/4] > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package evolution.i386 0:2.6.1-1.fc5.2 set to be updated > --> Running transaction check > --> Processing Dependency: libpisock.so.8 for package: evolution > --> Finished Dependency Resolution > Error: Missing Dependency: libpisock.so.8 is needed by package evolution > I solved the problem by manually removing libpisock (and deps: evolution, etc) applied the update and reinstall the removed packages (minus the libpisock) Gilboa From gilboad at gmail.com Tue Apr 18 07:28:25 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 18 Apr 2006 10:28:25 +0300 Subject: pilot-link for FC5 updates In-Reply-To: <1145326322.3071.40.camel@ender> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> Message-ID: <1145345305.9905.9.camel@gilboa-home-dev.localhost> On Mon, 2006-04-17 at 22:12 -0400, Jesse Keating wrote: > On Tue, 2006-04-18 at 11:56 +1000, Bojan Smojver wrote: > > Could someone move that from testing to real updates for FC5? Evo and > > other stuff depends on it... > > There is something of a problem with that. If I do that, I have to move > the pending large set of KDE updates. I didn't notice this dep chain > when I pushed the evo update with the rest of the gnome updates. There > was a bit of miscommunication here and now we're left w/ a bit of a > problem. > > I'm waiting for the KDE maintainer to start his work day (lives in a > different country) so that we can hopefully push the KDE updates, and > pilot-link along with it. This will be resolved soon. > I'd suggest you wait.... pilot-link still doesn't work right on 80% of all sync attempts. I'll send some info once I have something more informative beyond "gnome-pilot hangs on mutex"... Gilboa From ilpettegolo at yahoo.it Tue Apr 18 08:01:30 2006 From: ilpettegolo at yahoo.it (Mario Pascucci) Date: Tue, 18 Apr 2006 10:01:30 +0200 Subject: FC4 update: Missing dependency libpisock.8 Message-ID: <1145347290.3207.4.camel@defiant> Today, starting a manual update (yum update), I get this error: ... ... ---> Package evolution.i386 0:2.2.3-4.fc4 set to be updated ---> Package bind-libs.i386 24:9.3.1-20.FC4 set to be updated ---> Package selinux-policy-targeted.noarch 0:1.27.1-2.28 set to be updated --> Running transaction check --> Processing Dependency: libpisock.so.8 for package: evolution --> Finished Dependency Resolution Error: Missing Dependency: libpisock.so.8 is needed by package evolution [root at defiant ~]# slocate libpisock /usr/lib/libpisock.so.9.0.0 /usr/lib/libpisock.a /usr/lib/libpisock.so /usr/lib/libpisock.so.9 [root at defiant ~]# rpm -qf /usr/lib/libpisock.so.9.0.0 pilot-link-0.12.0-0.pre4.0.fc4.2 Ciao. -- Mario 'Reliant' Pascucci http://ilpettegolo.altervista.org/ ___________________________________ Bolletta salata? Passa a Yahoo! Messenger with Voice http://it.messenger.yahoo.com From simon3z at yahoo.com Tue Apr 18 08:09:29 2006 From: simon3z at yahoo.com (Federico) Date: Tue, 18 Apr 2006 01:09:29 -0700 (PDT) Subject: Init scritps timeout In-Reply-To: <1145244823.6382.340.camel@dimi> Message-ID: <20060418080929.90225.qmail@web35611.mail.mud.yahoo.com> --- Dimi Paun wrote: > On Sun, 2006-04-16 at 23:22 -0400, Harry Hoffman wrote: > > Why should httpd depend on networking? what is the network comes up > > later... do you not want httpd to already be running? > > You're reading to much in the exact example there :) Just use A and B. > > But I admit, I was a bit off-topic regarding the timeout problem. > I was commenting on the need to have greater control of these inter > service dependencies. > > As for the timeout, that would have to be handled by the services > manager that starts the services up. Ctrl-C is fine if you're in front > of the console, but the reboot may be unattended, we need to have a > system that is able to handle things by itself as well. > This is exactly what i was meaning. If an init script is taking too long (10 minutes?) it must be killed. Think if you have a remote server and the boot is stopped cos the ldap init script is blocked. You would need to get on the site to fix it or find someone expert enough to do it for you. -- Federico. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From simon3z at yahoo.com Tue Apr 18 08:18:36 2006 From: simon3z at yahoo.com (Federico) Date: Tue, 18 Apr 2006 01:18:36 -0700 (PDT) Subject: Init scritps timeout In-Reply-To: Message-ID: <20060418081836.92946.qmail@web35611.mail.mud.yahoo.com> --- Bojan Smojver wrote: > Bumped into this one myself. Really annoying. You probably have BDB as you > LDAP back end, just like me. And BDB is scary when it comes to uncommitted > transactions or any other type of problem you may have present in your > database. > Although probably not entirely correct, in order to avoid this hang, I have > this in /etc/sysconfig/ldap: > > su - -s /bin/bash ldap -c /usr/sbin/slapd_db_recover > > If the database is OK, nothing happens. If it is screwed, the recover process > gets it to the state where slapd actually starts. Usually, it even works > properly :-) It looks like a great solution to me. We might just need to get a notification (email to root?) if the database was corrupted. I hope it can be added in the future ldap releases. Anyway I still think that init scripts should have a timeout managed by the SysV system. -- Federico. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From redhat at olen.net Tue Apr 18 09:18:54 2006 From: redhat at olen.net (Ola Thoresen) Date: Tue, 18 Apr 2006 09:18:54 +0000 (UTC) Subject: Init scritps timeout References: <1145244823.6382.340.camel@dimi> <20060418080929.90225.qmail@web35611.mail.mud.yahoo.com> Message-ID: 2006-04-18 Federico wrote > > > --- Dimi Paun wrote: > >> On Sun, 2006-04-16 at 23:22 -0400, Harry Hoffman wrote: >> > Why should httpd depend on networking? what is the network comes up >> > later... do you not want httpd to already be running? >> >> You're reading to much in the exact example there :) Just use A and B. >> >> But I admit, I was a bit off-topic regarding the timeout problem. >> I was commenting on the need to have greater control of these inter >> service dependencies. >> >> As for the timeout, that would have to be handled by the services >> manager that starts the services up. Ctrl-C is fine if you're in front >> of the console, but the reboot may be unattended, we need to have a >> system that is able to handle things by itself as well. >> > > This is exactly what i was meaning. If an init script is taking too long (10 > minutes?) it must be killed. > Think if you have a remote server and the boot is stopped cos the ldap init > script is blocked. You would need to get on the site to fix it or find someone > expert enough to do it for you. This has bit me _many_ times (but it has been the shutdown process, not the boot process that hangs). Normally from a dead NFS-server, causing some other process to wait for some I/O, which again blocks the shutdown. It is still part of "init", but just thought I'd mention it so the same timeouts are considered for shutdowns as well. Rgds. Ola Thoresen From smorovic at fizika.org Tue Apr 18 09:38:54 2006 From: smorovic at fizika.org (Srecko Morovic) Date: Tue, 18 Apr 2006 09:38:54 +0000 (UTC) Subject: Elektra's technical suitablity References: <604aa7910603281434y3b15d1f5o4b2d6c700abe70a4@mail.gmail.com> <1144002377.2775.1.camel@rousalka.dyndns.org> <20060402210813.GB2827@plain.rackshack.net> <1cef3e950604021557vc31a023pe576ea52c8ab09fb@mail.gmail.com> <1cef3e950604021838m65baad1cg5a160f488ca7861f@mail.gmail.com> Message-ID: Shane Stixrud geeklords.org> writes: > > On Sun, 2 Apr 2006, Avi Alkalay wrote: > > > I understand the value and importance of that, but I'm afraid this is > > out of the Elektra scope. > > Such semantics and functionality should go in a GConf or KConfig XT layer. > > > > I can see value in a schema library that is optional and elektra aware for > non kde/gnome applications. Something that encourages good semantics, but > I agree that should be separate. > If it is separate, how SHOULD application define variable type (schema)? Wasn't the purpose of elektra to be able to easily "configure"? With data type information ("schema") written in the registry, it gets much easier (and more inituitive). Yes, you still have everything written as strings, but config programs know automatically how to interpret it. However it is also important to have available API to set that. I don't think people should use separate library only to have variable type set up, it's ridiculous. API should be extended to support type setting (and maybe variable constrains, etc.) with simplicity in mind, because otherwise most application writers will be likely to omit defining such information (another library just to do that is exactly what shouldn't exist). From Lam at Lam.pl Tue Apr 18 10:10:09 2006 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 18 Apr 2006 12:10:09 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145324754.1568.8.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> Message-ID: <1145355009.6824.28.camel@pensja.lam.pl> Dnia 17-04-2006, pon o godzinie 21:45 -0400, seth vidal napisa?(a): > It just means we have to make an additional temp file and compare it > every time. It costs time for the generic case where the files have > changed and are newer. That being the most common case. The most common case? Maybe if you use one server only. I use FC5 default config which uses a ton of mirrors. I am downloading "new" version of the same repo's "primary.xml.gz" every half an hour (with many versions spread among the mirrors) and other users are doing the same thing. Yes, I know I can use "yum -C", but I really want to have the newer data downloaded when I use yum list/yum install (which I do pretty often), why can't I? When I think about the cost I see one assembly jlt/jgt (how many CPU cycles? ;)) to check if a timestamp is less (file is older) and issuing a "move file" operation from (let's say) repomd.xml.tmp to repomd.xml, which 1. is handled by kernel and kept in cache for a while, so no slowup for yum and 2. "download xml.tmp;remove xml;move xml.tmp to xml" instead of "remove xml;download xml" doesn't cost much more instructions as I see it. Oh, and last night I updated updates' cache with the updates at 1:00, but wanted to download it when I sleep (86 MiB of updates after manually taking pilot-link from updates-testing - this took over 2,5 hours on my link), so (stupid me) instead of "yum -C" I did a "yum update" an hour later. Turned out there were three repo versions on the mirrors (with primary.xml.gz having 122, 130 and 161 "k"B). I ended up doing "yum clean all; yum update" (with only one repo enabled) for 10 straight minutes just to see the data I already had over an hour earlier. It also downloaded megabytes of useless data from the mirrors - to hell with my link, but it costs the mirrors' bandwidth. All this IS a cost, but simple "if timestamp2 > timestamp1" isn't. I'm really not moaning, I can live with that until I get my hands on the new apt, but I think about the others - why do they have to live with it? :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From rdieter at math.unl.edu Tue Apr 18 12:31:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 18 Apr 2006 07:31:39 -0500 Subject: pilot-link for FC5 updates In-Reply-To: <1145345305.9905.9.camel@gilboa-home-dev.localhost> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> <1145345305.9905.9.camel@gilboa-home-dev.localhost> Message-ID: <4444DC2B.7060102@math.unl.edu> Gilboa Davara wrote: > On Mon, 2006-04-17 at 22:12 -0400, Jesse Keating wrote: >>I'm waiting for the KDE maintainer to start his work day (lives in a >>different country) so that we can hopefully push the KDE updates, and >>pilot-link along with it. This will be resolved soon. >> > > > I'd suggest you wait.... pilot-link still doesn't work right on 80% of > all sync attempts. > I'll send some info once I have something more informative beyond > "gnome-pilot hangs on mutex"... Have you bugzilla'd it (yet)? ;-) -- rex From gilboad at gmail.com Tue Apr 18 13:13:54 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 18 Apr 2006 16:13:54 +0300 Subject: pilot-link for FC5 updates In-Reply-To: <4444DC2B.7060102@math.unl.edu> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> <1145345305.9905.9.camel@gilboa-home-dev.localhost> <4444DC2B.7060102@math.unl.edu> Message-ID: <1145366034.23413.0.camel@gilboa-home-dev.localhost> On Tue, 2006-04-18 at 07:31 -0500, Rex Dieter wrote: > Gilboa Davara wrote: > > On Mon, 2006-04-17 at 22:12 -0400, Jesse Keating wrote: > > >>I'm waiting for the KDE maintainer to start his work day (lives in a > >>different country) so that we can hopefully push the KDE updates, and > >>pilot-link along with it. This will be resolved soon. > >> > > > > > > I'd suggest you wait.... pilot-link still doesn't work right on 80% of > > all sync attempts. > > I'll send some info once I have something more informative beyond > > "gnome-pilot hangs on mutex"... > > Have you bugzilla'd it (yet)? ;-) > > -- rex Bugzilla is taking a long.... errr... nap ;) Gilboa From jspaleta at gmail.com Tue Apr 18 13:21:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 18 Apr 2006 09:21:23 -0400 Subject: pilot-link for FC5 updates In-Reply-To: <1145366034.23413.0.camel@gilboa-home-dev.localhost> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> <1145345305.9905.9.camel@gilboa-home-dev.localhost> <4444DC2B.7060102@math.unl.edu> <1145366034.23413.0.camel@gilboa-home-dev.localhost> Message-ID: <604aa7910604180621m30a390c8nbd3df911b1e115eb@mail.gmail.com> On 4/18/06, Gilboa Davara wrote: > Bugzilla is taking a long.... errr... nap ;) its working just fine for me right now. I can search and file new bugs and file comments on existing bugs. -jef From pjones at redhat.com Tue Apr 18 15:55:09 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 18 Apr 2006 11:55:09 -0400 Subject: Caring about users In-Reply-To: <20060412173633.GB2795@dspnet.fr.eu.org> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> <20060412172055.GA12112@yoda.jdub.homelinux.org> <20060412173633.GB2795@dspnet.fr.eu.org> Message-ID: <1145375710.27679.30.camel@localhost.localdomain> On Wed, 2006-04-12 at 19:36 +0200, Olivier Galibert wrote: > > If someone wants to sit there and bitch about things and expect someone else > > to go fix them all the time, they can kindly move the fuck on. Now, if they > > want to actually contribute, that is the attitude we want. And that is a great > > attitude for the future of Fedora. > > I'd be happy to patch anaconda to have "everything" again. I'm > probably going to in practice. I will submit the patch if you want, > but I know it will be rejected, so what's the point? So the question is: could you, instead of patching it for this, help devise a better way that we could use in the future? We need to handle multiple repositories, repositories with overlapping package names, etc., and "just install it all" doesn't make *any* sense. It's time for a new way to do it. Instead of rehashing the same thread over and over, we need to be looking for a way to better address the issue. -- Peter From jwboyer at jdub.homelinux.org Tue Apr 18 17:12:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 18 Apr 2006 12:12:56 -0500 Subject: pilot-link for FC5 updates In-Reply-To: <604aa7910604180621m30a390c8nbd3df911b1e115eb@mail.gmail.com> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> <1145345305.9905.9.camel@gilboa-home-dev.localhost> <4444DC2B.7060102@math.unl.edu> <1145366034.23413.0.camel@gilboa-home-dev.localhost> <604aa7910604180621m30a390c8nbd3df911b1e115eb@mail.gmail.com> Message-ID: <20060418171256.GA21935@yoda.jdub.homelinux.org> On Tue, Apr 18, 2006 at 09:21:23AM -0400, Jeff Spaleta wrote: > On 4/18/06, Gilboa Davara wrote: > > Bugzilla is taking a long.... errr... nap ;) > > its working just fine for me right now. I can search and file new bugs > and file comments on existing bugs. I had a problem with it yesterday. Then I logged out and logged back in and it magically worked again. Perhaps the DB change to switch to the -review list and cookies are causing a problem? josh "who has no friggin clue when it comes to web crap, so the above probably doesn't even make sense" From pemboa at gmail.com Tue Apr 18 17:17:17 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 18 Apr 2006 12:17:17 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145355009.6824.28.camel@pensja.lam.pl> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> Message-ID: <16de708d0604181017m748b97a5v8e3ead3cfccea633@mail.gmail.com> On 4/18/06, Leszek Matok wrote: > Dnia 17-04-2006, pon o godzinie 21:45 -0400, seth vidal napisa?(a): > > It just means we have to make an additional temp file and compare it > > every time. It costs time for the generic case where the files have > > changed and are newer. That being the most common case. > The most common case? Maybe if you use one server only. I use FC5 > default config which uses a ton of mirrors. I am downloading "new" > version of the same repo's "primary.xml.gz" every half an hour (with > many versions spread among the mirrors) and other users are doing the > same thing. Yes, I know I can use "yum -C", but I really want to have > the newer data downloaded when I use yum list/yum install (which I do > pretty often), why can't I? > > When I think about the cost I see one assembly jlt/jgt (how many CPU > cycles? ;)) to check if a timestamp is less (file is older) and issuing > a "move file" operation from (let's say) repomd.xml.tmp to repomd.xml, > which 1. is handled by kernel and kept in cache for a while, so no > slowup for yum and 2. "download xml.tmp;remove xml;move xml.tmp to xml" > instead of "remove xml;download xml" doesn't cost much more instructions > as I see it. > > Oh, and last night I updated updates' cache with the updates at 1:00, > but wanted to download it when I sleep (86 MiB of updates after manually > taking pilot-link from updates-testing - this took over 2,5 hours on my > link), so (stupid me) instead of "yum -C" I did a "yum update" an hour > later. > > Turned out there were three repo versions on the mirrors (with > primary.xml.gz having 122, 130 and 161 "k"B). I ended up doing "yum > clean all; yum update" (with only one repo enabled) for 10 straight > minutes just to see the data I already had over an hour earlier. It also > downloaded megabytes of useless data from the mirrors - to hell with my > link, but it costs the mirrors' bandwidth. All this IS a cost, but > simple "if timestamp2 > timestamp1" isn't. > > I'm really not moaning, I can live with that until I get my hands on the > new apt, but I think about the others - why do they have to live with > it? :) > > Lam > Seems like Squid could help you out a bit. -- As a boy I jumped through Windows, as a man I play with Penguins. From fedora at camperquake.de Tue Apr 18 18:41:02 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 18 Apr 2006 20:41:02 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604181017m748b97a5v8e3ead3cfccea633@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <16de708d0604181017m748b97a5v8e3ead3cfccea633@mail.gmail.com> Message-ID: <20060418204102.3c670093@nausicaa.camperquake.de> Hi. "Arthur Pemberton" wrote: > Seems like Squid could help you out a bit. It does not solve the problem presented here. And even if it would, that's entirely besides the point. -- Q. What's the difference between a seamstress and a violist? A. The seamstress tucks up the frills. From dlutter at redhat.com Tue Apr 18 19:55:46 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 12:55:46 -0700 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604171311t1da8d19fod3e613abfc52a1cc@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <16de708d0604171311t1da8d19fod3e613abfc52a1cc@mail.gmail.com> Message-ID: <1145390146.21268.3.camel@currant.watzmann.net> On Mon, 2006-04-17 at 15:11 -0500, Arthur Pemberton wrote: > On 4/17/06, Joost Soeterbroek wrote: > > Patrick W. Barnes wrote: > > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > > > Project has not yet applied to participate this year, I suspect we are likely > > > to do so. However, our Fedora Bounties list is now quite short. We need > > > fresh ideas. If there are any projects that you would like to see, please > > > add them to the FedoraBounties page. These can include ideas that you may > > > have had but don't have time to work on, problems that you have encountered > > > that need attention, or tools you really wish we had. > > > > idea: YUM Fedora internal update server ('reposerver') > > > > How about a project for tools/utilities to create, maintain > > fedora/custom yum repositories behind the corporate firewall. > > > > - local mirror for fedora repositories (core, extras etc.) > > - Custom repos > > - Ability to merge repos to create custom, tested 'releases' (read: > > http://www.linuxdevcenter.com/lpt/a/5625) > > > > Regards, > > > > Joost Soeterbroek > > Yam already (supposedly) does this. It does some of that, but not all; there's some functionality that would be useful around provisioning systems that's related to yam, such as maintaining local ks trees and better/easier maintenance of pxe boot infrastructure. David From gilboad at gmail.com Tue Apr 18 20:59:19 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 18 Apr 2006 23:59:19 +0300 Subject: pilot-link for FC5 updates In-Reply-To: <604aa7910604180621m30a390c8nbd3df911b1e115eb@mail.gmail.com> References: <1145325382.16371.60.camel@coyote.rexursive.com> <1145326322.3071.40.camel@ender> <1145345305.9905.9.camel@gilboa-home-dev.localhost> <4444DC2B.7060102@math.unl.edu> <1145366034.23413.0.camel@gilboa-home-dev.localhost> <604aa7910604180621m30a390c8nbd3df911b1e115eb@mail.gmail.com> Message-ID: <1145393959.32416.2.camel@gilboa-home-dev.localhost> On Tue, 2006-04-18 at 09:21 -0400, Jeff Spaleta wrote: > On 4/18/06, Gilboa Davara wrote: > > Bugzilla is taking a long.... errr... nap ;) > > its working just fine for me right now. I can search and file new bugs > and file comments on existing bugs. > > -jef Baah.... BZ seems to be working now.... dog slow, but working. Thanks. FYI: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189294 Gilboa From dlutter at redhat.com Tue Apr 18 21:29:35 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 14:29:35 -0700 Subject: Ruby on Rails and Fedora In-Reply-To: <200604132059.k3DKxJq26437@xos037.xos.nl> References: <200604132059.k3DKxJq26437@xos037.xos.nl> Message-ID: <1145395775.21268.9.camel@currant.watzmann.net> On Thu, 2006-04-13 at 22:59 +0200, Jos Vos wrote: > I was surprised to see that Ruby on Rails is not in Core or Extras. > But I found a nice set of RPMs: . > Is this the recommended set of packages to use/rebuilt for FC5? It's my intention to submit these packages to FE - I am waiting on getting sponsored and having two other packages that I submitted approved. > Isn't it a good idea to include them in FC6 (Core or Extras)? This > stuff becomes pretty popular (I also hope to see it back in RHEL5). Completely agree. If you find any problems with the packages as they are, please let me know. The one known issue right now is that I built them as noarch, but because of bz184199 I need to rebuild them as arch-specific packages. David From dlutter at redhat.com Tue Apr 18 22:23:44 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 15:23:44 -0700 Subject: Kickstart and roles In-Reply-To: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <1145399024.21268.42.camel@currant.watzmann.net> On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > So I've been kicking around this idea for a while and wanted to see > what others thought. Who knows maybe someone will be interested in > helping. More than interested. That's actually right down the road me and some others have been thinking lately. > This may already exist so if it does please let me know but I would > like to setup a bunch of kickstart scripts for server and workstation > roles using only official Fedora software. For example, lets say > someone wants a xen workstation. We could setup a kickstart script > with everything they need, only the minimals and at the end, yum > update, configure what we can and on reboot, that user has a working > xen machine. We are working on a tool to simplify the very basics of keeping track of provisioning setup, both for bare-metal and domU provisioing. Our focus so far has been on the mechanics of keeping kernel/initrd/ks.cfg on a central server and using PXE boot (for bare-metal) and a separate script (for domU) to start the provisioning. It's just a tad early to inflict this on the world, but we'll make a prototype available in the next week or two. For domU's, the idea is that it should be easy to publish special-purpose kickstart files and use them with the tool. > Perhaps a better example, lets say somene needs an email server that > supports SMTP, imaps and webmail. We could create a kickstart script > that installs and configures as much of it as possible in a way that > we deem secure. All the user would have to do is fill out a fiew > variables at the top of the ks script (like domain or something). > Anaconda would ask for things like partitions and network. When the > machine reboots, they have a working email server. I think kickstart is not the right tool for that purpose; for something like webmail, you also need to make sure that the machine stays in a specific state, update various aspects of the machine (not just packages, but also configs), make it easy to adapt the upstream version of the setup to local needs while still being able to consume upstream updates etc. As a separate project, I've been looking into using a config management tool (puppet [1]) to create 'system recipes', i.e. recommended configurations for a specific purpose like webmail or a mail server. The tutorial [2] describes how that would work for one example, and we've been working on a prototype for distributing these recipes based on a distributed source control system, mercurial in the prototype [3]. > I have a hunch > there's a market out there for it, and if every ks script came with > clear "What to do next" instructions we might be able to save some > chatter on the lists and open Fedora up to many more users out there > who want to do more with Fedora but just don't know how. Even better if the 'What to do next' instructions would describe the configuration of the machine in a way that can be used by the appropriate tools with minimal human intervention - that's kinda the idea behind system recipes. I would love to hear your thoughts on this; and if you have the time, a helping hand is always welcome, David [1] http://reductivelabs.com/projects/puppet [2] http://people.redhat.com/dlutter/puppet-app.html [3] http://people.redhat.com/alikins/prm/prm.README From skvidal at linux.duke.edu Tue Apr 18 22:29:56 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 18 Apr 2006 18:29:56 -0400 Subject: Kickstart and roles In-Reply-To: <1145399024.21268.42.camel@currant.watzmann.net> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> Message-ID: <1145399396.1568.101.camel@cutter> On Tue, 2006-04-18 at 15:23 -0700, David Lutterkort wrote: > On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > > So I've been kicking around this idea for a while and wanted to see > > what others thought. Who knows maybe someone will be interested in > > helping. > > More than interested. That's actually right down the road me and some > others have been thinking lately. > > > This may already exist so if it does please let me know but I would > > like to setup a bunch of kickstart scripts for server and workstation > > roles using only official Fedora software. For example, lets say > > someone wants a xen workstation. We could setup a kickstart script > > with everything they need, only the minimals and at the end, yum > > update, configure what we can and on reboot, that user has a working > > xen machine. > > We are working on a tool to simplify the very basics of keeping track of > provisioning setup, both for bare-metal and domU provisioing. Our focus > so far has been on the mechanics of keeping kernel/initrd/ks.cfg on a > central server and using PXE boot (for bare-metal) and a separate script > (for domU) to start the provisioning. It's just a tad early to inflict > this on the world, but we'll make a prototype available in the next week > or two. For domU's, the idea is that it should be easy to publish > special-purpose kickstart files and use them with the tool. > > > Perhaps a better example, lets say somene needs an email server that > > supports SMTP, imaps and webmail. We could create a kickstart script > > that installs and configures as much of it as possible in a way that > > we deem secure. All the user would have to do is fill out a fiew > > variables at the top of the ks script (like domain or something). > > Anaconda would ask for things like partitions and network. When the > > machine reboots, they have a working email server. > > I think kickstart is not the right tool for that purpose; for something > like webmail, you also need to make sure that the machine stays in a > specific state, update various aspects of the machine (not just > packages, but also configs), make it easy to adapt the upstream version > of the setup to local needs while still being able to consume upstream > updates etc. > > As a separate project, I've been looking into using a config management > tool (puppet [1]) to create 'system recipes', i.e. recommended > configurations for a specific purpose like webmail or a mail server. The > tutorial [2] describes how that would work for one example, and we've > been working on a prototype for distributing these recipes based on a > distributed source control system, mercurial in the prototype [3]. > What we did at duke was to take snippets of kickstarts and assemble them in whatever order per-profile using glump: http://linux.duke.edu/projects/mini/glump/ It sounds like puppet is taking that a step further by allowing the conversation to go both ways. It's kind a shame puppet isn't in python - it would make it easier to integrate some of the pkg handling mechanisms of yum with it if it were. -sv From dlutter at redhat.com Tue Apr 18 22:35:12 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 15:35:12 -0700 Subject: Kickstart and roles In-Reply-To: <1145007071.16571.3.camel@heretic.grobb.org> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145007071.16571.3.camel@heretic.grobb.org> Message-ID: <1145399712.21268.50.camel@currant.watzmann.net> On Fri, 2006-04-14 at 21:31 +1200, David Mohring wrote: > On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > > So I've been kicking around this idea for a while and wanted to see > > what others thought. > ... > > Thoughts, opinions, suggestions? > > Now and Xen:Complexities of Fedora,Grub,LVM and Xen > https://www.redhat.com/archives/fedora-devel-list/2005-April/msg00545.html > See the "Thirdly, so-so ideas" under run levels and roles. I am not sure what you mean by this: Allocate file system mount rights on a first come first served basis, with fall over of NFS mounting if the first serves the requested partition. As for grub and domU, I think there are many interesting things we could do if we moved away from booting domU's with grub, and used tools in dom0 or on a central server to manage the kernel/initrd/OS image/domU association. David From bojan at rexursive.com Tue Apr 18 22:53:05 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Apr 2006 08:53:05 +1000 Subject: KDE updates for FC5 Message-ID: <1145400786.2012.10.camel@coyote.rexursive.com> I see that KDE updates have been published. Was publishing of both 0.1 and 0.2 RPMS done on purpose? The appear to be a day apart in testing (i.e. one would think that 0.2 superseded 0.1) and yet both version are in real updates... Any reason to force the mirrors to sync double the amount of KDE stuff? Can the old version be removed? -- Bojan From dlutter at redhat.com Tue Apr 18 23:03:09 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 16:03:09 -0700 Subject: Kickstart and roles In-Reply-To: <1145399396.1568.101.camel@cutter> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <1145399396.1568.101.camel@cutter> Message-ID: <1145401389.21268.73.camel@currant.watzmann.net> On Tue, 2006-04-18 at 18:29 -0400, seth vidal wrote: > What we did at duke was to take snippets of kickstarts and assemble them > in whatever order per-profile using glump: > http://linux.duke.edu/projects/mini/glump/ Cool .. if I understand that page right, glump is a combination of a templating system and a config management system. > It sounds like puppet is taking that a step further by allowing the > conversation to go both ways. That, and very flexible mechanisms on how you associate specific configurations with hosts; in addition, puppet models various aspects of a system's configuration in its own declarative language, which nicely decouples the 'what' of the desired system state from the 'how' of achieving that state. One of puppet's goals is to make it possible to describe a system's configuration in a modular way oriented along logical lines. For example, it should be possible to describe the setup of a webserver and a DB server (needed packages, config files, users, mounts etc.) completely separately from each other and then combine these two descriptions on one machine to support webapp X. The modularity requires that configurations are not just pushed around as opaque files, but can be described as 'objects', i.e. allow the administrator to talk about users, packages, mounts etc. rather than /etc/passwd or /etc/fstab. > It's kind a shame puppet isn't in python - it would make it easier to > integrate some of the pkg handling mechanisms of yum with it if it were. When you say "package { httpd: version => '2.0.54' }" or "package { mysql-server: ensure => latest }" in your puppet manifest, puppet will use yum to install/update those packages to the appropriate versions; so far, that level of yum integration seems to be sufficient. I've also writen a 'yumrepo' type that lets you express the yum configuration within a puppet manifest - that should help in controlling what repos each machine uses for package installs/updates. David From dlutter at redhat.com Tue Apr 18 23:30:44 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 16:30:44 -0700 Subject: Kickstart and roles In-Reply-To: <20060414043809.40336.qmail@web38409.mail.mud.yahoo.com> References: <20060414043809.40336.qmail@web38409.mail.mud.yahoo.com> Message-ID: <1145403044.21268.90.camel@currant.watzmann.net> On Thu, 2006-04-13 at 21:38 -0700, Jane Dogalt wrote: > This is a great idea and something I was planning on doing myself. But for > simplicity, it seems like this could be implemented dirt-simply (from an > infrastructure impact point of view) via rpms. I.e. rpms that are heavy on > specifying dependencies and pre/post scripts, but probably very light on files > (if not in fact lacking any rpm owned files). While it's very tempting to do that, and I've seen quite a few places that try to manage their config this way, pre/post scripts are a very poor way to define the configuration of a machine: they leave no trace of what they did, scripts by their very nature are entirely operational (how would you display what the scripts do in a UI ?), they introduce very tight coupling between dependent packages, and they give you no help in figuring out if a machine's configuration deviates from what was initially installed (think about finding out that somebody has edited /etc/passwd and changed httpd's login shell to /bin/bash). In addition, building rpm's to roll out config changes is a fairly heavy-weight process - do you really want to rebuild an rpm just to fix a typo in a config file somewhere ? > Hopefully you write the rpm uninstall > scripts with enough intelligence to revert the system exactly back to the > preinstall state. That's another problem with pre/post install scripts: all that intelligence needs to be handcrafted for each script. And when things go wrong, it's very hard to figure out what went wrong and why. Config mgmt tools seem a much better solution for these kind of things than rpm's. David From skvidal at linux.duke.edu Tue Apr 18 23:39:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 18 Apr 2006 19:39:26 -0400 Subject: Kickstart and roles In-Reply-To: <1145401389.21268.73.camel@currant.watzmann.net> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <1145399396.1568.101.camel@cutter> <1145401389.21268.73.camel@currant.watzmann.net> Message-ID: <1145403567.1568.113.camel@cutter> On Tue, 2006-04-18 at 16:03 -0700, David Lutterkort wrote: > On Tue, 2006-04-18 at 18:29 -0400, seth vidal wrote: > > What we did at duke was to take snippets of kickstarts and assemble them > > in whatever order per-profile using glump: > > http://linux.duke.edu/projects/mini/glump/ > > Cool .. if I understand that page right, glump is a combination of a > templating system and a config management system. > Yes, that's correct. It is very simple in how it puts files together. You use the xml to specify the components(members) of a result and you just use wget or what-have-you to grab the resulting concatenations of the files. > > It sounds like puppet is taking that a step further by allowing the > > conversation to go both ways. > > That, and very flexible mechanisms on how you associate specific > configurations with hosts; in addition, puppet models various aspects of > a system's configuration in its own declarative language, which nicely > decouples the 'what' of the desired system state from the 'how' of > achieving that state. One of puppet's goals is to make it possible to > describe a system's configuration in a modular way oriented along > logical lines. For example, it should be possible to describe the setup > of a webserver and a DB server (needed packages, config files, users, > mounts etc.) completely separately from each other and then combine > these two descriptions on one machine to support webapp X. The > modularity requires that configurations are not just pushed around as > opaque files, but can be described as 'objects', i.e. allow the > administrator to talk about users, packages, mounts etc. rather > than /etc/passwd or /etc/fstab. > except that means that a lot of work has to go into the client side that ends up having to parse the result of the manifests/recipes from puppet. A LOT of work, in fact. That's one thing we escaped with glump. Glump just creates the files programs on the client use. What those clients are or what the format of the file is, glump doesn't care. > > It's kind a shame puppet isn't in python - it would make it easier to > > integrate some of the pkg handling mechanisms of yum with it if it were. > > When you say "package { httpd: version => '2.0.54' }" or "package > { mysql-server: ensure => latest }" in your puppet manifest, puppet will > use yum to install/update those packages to the appropriate versions; so > far, that level of yum integration seems to be sufficient. I've also > writen a 'yumrepo' type that lets you express the yum configuration > within a puppet manifest - that should help in controlling what repos > each machine uses for package installs/updates. > But performing conditionals like: if package { httpd: version >= '2.0.54'} then install package 'foo' is not all that simple and may not be all that possible, either. I was talking with the puppet lead on irc. It sounds like the flow is: puppet server takes manifests/recipes and compiles them into yaml yaml is sent to the client client reads yaml and does stuff with it What I couldn't figure out is why I'd write how to do it in the recipes to begin with. Why not just write it in yaml and store that in a db per-host/per-class/per-profile and be done with it. or better yet just have a web interface that dumps the selected items out to yaml (or, given the transforms, xml) then stores that into a db and dispenses with recipes altogether? -sv From dlutter at redhat.com Tue Apr 18 23:54:01 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 18 Apr 2006 16:54:01 -0700 Subject: Kickstart and roles In-Reply-To: <1145403567.1568.113.camel@cutter> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <1145399396.1568.101.camel@cutter> <1145401389.21268.73.camel@currant.watzmann.net> <1145403567.1568.113.camel@cutter> Message-ID: <1145404441.21268.103.camel@currant.watzmann.net> On Tue, 2006-04-18 at 19:39 -0400, seth vidal wrote: > > these two descriptions on one machine to support webapp X. The > > modularity requires that configurations are not just pushed around as > > opaque files, but can be described as 'objects', i.e. allow the > > administrator to talk about users, packages, mounts etc. rather > > than /etc/passwd or /etc/fstab. > > > > except that means that a lot of work has to go into the client side that > ends up having to parse the result of the manifests/recipes from puppet. > A LOT of work, in fact. Most of the work for a specific config object is actually in parsing/manipulating the appropriate config files on the client side, not in parsing the puppet manifest. > That's one thing we escaped with glump. Glump just creates the files > programs on the client use. What those clients are or what the format of > the file is, glump doesn't care. That's certainly preferrable over parsing config files, but it's not always feasible. For example, think of all the config files that are really databases of various objects like passwd or fstab - managing those on the file level is usually not granular enough, and you need to manage them on the 'record' level. > But performing conditionals like: > > if package { httpd: version >= '2.0.54'} then install package 'foo' is > not all that simple and may not be all that possible, either. Yeah .. does this come up in practice ? It seems that package 'foo' in that scenario is doing something very strange. > What I couldn't figure out is why I'd write how to do it in the recipes > to begin with. Why not just write it in yaml and store that in a db > per-host/per-class/per-profile and be done with it. yaml/xml isn't very human readable. The puppet language also lets you group things in a way that is easier to understand for humans (check out 'class' and 'define' in the language reference), both of which are resolved on the server. > or better yet just have a web interface that dumps the selected items > out to yaml (or, given the transforms, xml) Certainly something that would be desirable at some point in the future, but writing a good UI is hard; and as far as the language is concerned, the emphasis right now should be more on making it easy to model configurations of a large number of systems. There are plenty of things that could be added to the language to make that easier. And as a side-effect, the puppet language makes it easy to distribute parts of a system's configuration as a 'recipe', a canned HOWTO, while leaving users of the recipes some leeway in modifying them locally and later incorporating updates from upstream without clobbering local modifications. That would be much harder in a strictly DB-based system. David From pemboa at gmail.com Wed Apr 19 00:00:22 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 18 Apr 2006 19:00:22 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <16de708d0604181700v294fa1f2p85afa7f831174b17@mail.gmail.com> "The N-Man", Fedora best meet the deadline for submitting their application as a mentor, as I would really like to work on a Fedora project. Pembo From benjy.grogan at gmail.com Wed Apr 19 00:57:04 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Tue, 18 Apr 2006 20:57:04 -0400 Subject: Caring about users In-Reply-To: <1145375710.27679.30.camel@localhost.localdomain> References: <20060412152515.GA89988@dspnet.fr.eu.org> <1144855778.2294.300.camel@sundaram.pnq.redhat.com> <20060412153356.GB89988@dspnet.fr.eu.org> <20060412160327.GA22574@devserv.devel.redhat.com> <20060412161702.GA94772@dspnet.fr.eu.org> <20060412164255.GA19877@thyrsus.com> <20060412172055.GA12112@yoda.jdub.homelinux.org> <20060412173633.GB2795@dspnet.fr.eu.org> <1145375710.27679.30.camel@localhost.localdomain> Message-ID: On 4/18/06, Peter Jones wrote: > On Wed, 2006-04-12 at 19:36 +0200, Olivier Galibert wrote: > > > If someone wants to sit there and bitch about things and expect someone else > > > to go fix them all the time, they can kindly move the fuck on. Now, if they > > > want to actually contribute, that is the attitude we want. And that is a great > > > attitude for the future of Fedora. > > > > I'd be happy to patch anaconda to have "everything" again. I'm > > probably going to in practice. I will submit the patch if you want, > > but I know it will be rejected, so what's the point? > > So the question is: could you, instead of patching it for this, help > devise a better way that we could use in the future? We need to handle > multiple repositories, repositories with overlapping package names, > etc., and "just install it all" doesn't make *any* sense. Here are some issues I've had with the new update system that I'm sure others have had, and possibly are already being worked on. I just thought I'd mention them to help improve the system, which overall is a big improvement over the old one. 1) in Pirut.. the Add/Remove software function... shouldn't there be support for determining which repository the packages are coming from? at the moment the only way to figure out which repository holds the package that I've just searched for is to manually disable the yum repositories, and then go back into Pirut. Ex: When installing wine, I wanted to know which repository it was coming from but I couldn't. As well, [updates-testing] brings up duplicate results to [core] occasionally, or so I'm figuring since I see two identical packages here and there in my Pirut searches. 2) It would be great to be able to turn on and off repositories from within Pirut. 3) Pirut doesn't differentiate between Installing and Updating Software. It says "Updating Software" when in fact it's installing wine. 4) Once new software is installed, it would be great if there was a highlight of some sort so that you could find the software in the Gnome menus. Windows has such functionality. I often have to go through the menus searching for what I just installed, and it can get annoying, especially when it's the Deskbar applet and it's not there at all. :) Benjy > > It's time for a new way to do it. Instead of rehashing the same thread > over and over, we need to be looking for a way to better address the > issue. > > -- > Peter > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From perbj at sbcglobal.net Wed Apr 19 04:02:11 2006 From: perbj at sbcglobal.net (Per Bjornsson) Date: Tue, 18 Apr 2006 21:02:11 -0700 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145355009.6824.28.camel@pensja.lam.pl> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> Message-ID: <1145419331.10519.14.camel@minicooper> On Tue, 2006-04-18 at 12:10 +0200, Leszek Matok wrote: > Dnia 17-04-2006, pon o godzinie 21:45 -0400, seth vidal napisa?(a): > > It just means we have to make an additional temp file and compare it > > every time. It costs time for the generic case where the files have > > changed and are newer. That being the most common case. > The most common case? Maybe if you use one server only. I use FC5 > default config which uses a ton of mirrors. The "fastestmirror" yum plugin is your friend - I really think it should be part of the default install! yum install yum-fastestmirror /Per From bojan at rexursive.com Wed Apr 19 04:30:15 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 19 Apr 2006 04:30:15 +0000 (UTC) Subject: FC5 kernel updates References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> Message-ID: Dave Jones redhat.com> writes: > *grumble*, just as .6 finished... > builds restarting, they should be done by the morning hopefully. Would you believe it - .8 is out! Gee, they come out fast these days, don't they? ;-) -- Bojan From david at lovesunix.net Wed Apr 19 04:42:48 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 19 Apr 2006 06:42:48 +0200 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> Message-ID: <1145421768.8581.7.camel@localhost.localdomain> ons, 19 04 2006 kl. 04:30 +0000, skrev Bojan Smojver: > Dave Jones redhat.com> writes: > > > *grumble*, just as .6 finished... > > builds restarting, they should be done by the morning hopefully. > > Would you believe it - .8 is out! Gee, they come out fast these days, don't > they? ;-) Jebus.. I thought they were supposed to be weekly releases, not hourly. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From pmatilai at laiskiainen.org Wed Apr 19 06:10:30 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 18 Apr 2006 23:10:30 -0700 (PDT) Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145419331.10519.14.camel@minicooper> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> Message-ID: On Tue, 18 Apr 2006, Per Bjornsson wrote: > On Tue, 2006-04-18 at 12:10 +0200, Leszek Matok wrote: >> Dnia 17-04-2006, pon o godzinie 21:45 -0400, seth vidal napisa??(a): >>> It just means we have to make an additional temp file and compare it >>> every time. It costs time for the generic case where the files have >>> changed and are newer. That being the most common case. >> The most common case? Maybe if you use one server only. I use FC5 >> default config which uses a ton of mirrors. > > The "fastestmirror" yum plugin is your friend - I really think it should > be part of the default install! > yum install yum-fastestmirror I think the idea is to eventually enable it by default once the nasty little details like not working through proxies have been sorted out one way or another (there were some other bits as well on the todo IIRC, don't remember offhand). - Panu who hates proxies - From buildsys at redhat.com Wed Apr 19 07:29:37 2006 From: buildsys at redhat.com (Build System) Date: Wed, 19 Apr 2006 03:29:37 -0400 Subject: rawhide report: 20060419 changes Message-ID: <200604190729.k3J7TbEV026835@porkchop.devel.redhat.com> New package gcalctool A desktop calculator New package gucharmap Unicode character picker and font browser New package zenity Display dialog boxes from shell scripts Updated Packages: anaconda-11.1.0.4-1 ------------------- * Tue Apr 18 2006 Chris Lumens 11.1.0.4-1 - Pass version to mkstamp for discinfo files (jkeating). - Fix FTP method handling. - Don't download RPMs twice on FTP and HTTP methods (pnasrat, #183654). - Use libuser for setting root password. - Fix up rescue image script problems (dcantrel, #188011). bind-30:9.3.2-22.FC6 -------------------- * Tue Apr 18 2006 Jason Vas Dias - 30:9.3.2-22 - apply upstream patch for ncache_adderesult segfault bug 173961 addenda - fix bug 188382: rpm --verify permissions inconsistencies - fix bug 189186: use /sbin/service instead of initscript - rebuild for new gcc, glibc-kernheaders dvd+rw-tools-6.1-3 ------------------ * Tue Apr 18 2006 Harald Hoyer - 6.1-2 - compile with smaller buffer size - removed O_EXCL patch * Fri Mar 24 2006 Harald Hoyer - 6.1-1 - version 6.1 emacs-21.4-14.1 --------------- * Tue Apr 18 2006 Chip Coldwell - 21.4-14.1 - don't clobber site-lisp/default.el (Ritesh Khadgaray, 180153) * Tue Mar 07 2006 Jens Petersen - 21.4-14 - bring back setarch for i386 with -R option in spec file and drop emacs-21-personality-linux32-101818.patch since it no longer seems sufficient with recent kernels (Sam Peterson, #174736) - buildrequire giflib-devel instead of libungif-devel * Thu Mar 02 2006 Jens Petersen - avoid backup for fix-x-vs-no-x-diffs.dpatch (Ian Collier, #183503) - remove the old ccmode info manual (#182084) file-roller-2.14.2-2 -------------------- * Tue Apr 18 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 - Some .spec file cleanups firefox-1.5.0.2-3 ----------------- * Tue Apr 18 2006 Christopher Aillon - 1.5.0.2-3 - Drop some broken langpacks gimp-2:2.2.11-1 --------------- * Tue Apr 18 2006 Nils Philippsen - 2:2.2.11-1 - version 2.2.11 * Fri Mar 03 2006 Nils Philippsen - 2:2.2.10-4 - use htmlview as default web browser (#183730, patch by Ben Levenson) - require hicolor-icon-theme (#182784, #182785) * Fri Feb 10 2006 Jesse Keating - 2:2.2.10-2.2 - bump again for double-long bug on ppc(64) gnome-utils-1:2.14.0-8 ---------------------- * Tue Apr 18 2006 Matthias Clasen 2.14.0-8 - Re-add the epoch * Tue Apr 18 2006 Matthias Clasen 2.14.0-7 - Bump rev * Tue Apr 18 2006 Matthias Clasen 2.14.0-6 - Incorporate package review feedback - Split off a -devel subpackage hal-0.5.7-4 ----------- * Wed Apr 19 2006 Matthias Clasen - 0.5.7-4 - Add Requires on pm-utils >= 0.10-1 (#185134, Andrew Overholt) hplip-0.9.10-5 -------------- * Tue Apr 18 2006 Tim Waugh 0.9.10-5 - Patchlevel 1. - Fixed another case-sensitive match. - Require hpijs sub-package (bug #189140). - Don't package unneeded files (bug #189162). - Put fax PPD in the right place (bug #186213). jwhois-3.2.3-4 -------------- * Wed Apr 19 2006 Miloslav Trmac - 3.2.3-4 - Update to upstream config as of Apr 19 2006 (#188366) kernel-2.6.16-1.2136_FC6 ------------------------ * Tue Apr 18 2006 Dave Jones - 2.6.17rc1-git13 * Mon Apr 17 2006 Juan Quintela - enable xen again. krb5-1.4.3-5 ------------ * Fri Apr 14 2006 Stepan Kasal - 1.4.3-5 - Fix formatting typo in kinit.1 (krb5-kinit-man-typo.patch) libmusicbrainz-2.1.1-3 ---------------------- * Tue Apr 18 2006 Matthias Clasen - 2.1.1-3 - apply .spec file cleanups from Matthias Saou (#172926) man-pages-2.29-1 ---------------- * Tue Apr 18 2006 Ivana Varekova 2.29-1 - update to 2.29 - fix sigprocmask(2) man page (#189121) policycoreutils-1.30.6-2 ------------------------ * Tue Apr 18 2006 Dan Walsh 1.30.6-2 - Ship avc.py psmisc-22.1.03072006cvs-1.1 --------------------------- * Wed Mar 22 2006 Karel Zak 22.1.03072006cvs-1.1 - rebuild * Tue Mar 07 2006 Karel Zak 22.1.03072006cvs-1 - update to new upstream CVS version - enable new fuser version - fix fuser return code - fix #183897 - "pstree -a" call results in segmentation fault sqlite-3.3.5-1 -------------- * Mon Apr 17 2006 Paul Nasrat - 3.3.5-1 - Update to 3.3.5 tetex-3.0-21 ------------ * Tue Apr 18 2006 Jindrich Novy 3.0-21 - update caption style, the one we have is outdated (#188904) - envlab cleanup util-linux-2.13-0.20.1 ---------------------- * Thu Mar 30 2006 Karel Zak 2.13-0.20.1 - sync with upstream 2.13-pre7 release - fix #187014 - umount segfaults for normal user - fix #184410 - RHEL3 and RHEL4 mount supports 'noacl', FC5 mount command does not - fix #183446 - cal not UTF-8-aware - fix #186915 - mount does not translate SELIinux context options though libselinux - fix #185500 - need man page entry for -o context= mount option - fix #152579 - missing info about /etc/mtab and /proc/mounts mismatch - fix #183890 - missing info about possible ioctl() and fcntl() problems on NFS filesystem xen-3.0.1-5 ----------- * Tue Apr 18 2006 Daniel Veillard - 3.0.1-5 - augment the close on exec patch with the fix for #188361 yum-2.6.0-3 ----------- * Tue Apr 18 2006 Jeremy Katz - 2.6.0-3 - more proxy fixing for non CLI use case (#185309) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnome-utils-devel - 1:2.14.0-8.i386 requires gnome-utils = 0:2.14.0-8 Broken deps for ia64 ---------------------------------------------------------- gnome-utils-devel - 1:2.14.0-8.ia64 requires gnome-utils = 0:2.14.0-8 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gnome-utils-devel - 1:2.14.0-8.ppc requires gnome-utils = 0:2.14.0-8 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-utils-devel - 1:2.14.0-8.ppc64 requires gnome-utils = 0:2.14.0-8 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-utils-devel - 1:2.14.0-8.s390 requires gnome-utils = 0:2.14.0-8 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-utils-devel - 1:2.14.0-8.s390x requires gnome-utils = 0:2.14.0-8 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnome-utils-devel - 1:2.14.0-8.x86_64 requires gnome-utils = 0:2.14.0-8 From gianluca.cecchi at gmail.com Wed Apr 19 07:30:13 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 19 Apr 2006 09:30:13 +0200 Subject: FC5 kernel updates Message-ID: <561c252c0604190030vafd7361sd19607f0b16b0356@mail.gmail.com> On Wed, 19 Apr 2006 06:42:48 +0200 David Nielsen wrote: >> Dave Jones writes: >> Would you believe it - .8 is out! Gee, they come out fast these days, don't >> they? ;-) > >Jebus.. I thought they were supposed to be weekly releases, not hourly. faster and faster: now 2.6.16.9 is out too!!! Gianluca From david at lovesunix.net Wed Apr 19 07:44:44 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 19 Apr 2006 09:44:44 +0200 Subject: FC5 kernel updates In-Reply-To: <1145421768.8581.7.camel@localhost.localdomain> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <1145421768.8581.7.camel@localhost.localdomain> Message-ID: <1145432684.8581.15.camel@localhost.localdomain> ons, 19 04 2006 kl. 06:42 +0200, skrev David Nielsen: > ons, 19 04 2006 kl. 04:30 +0000, skrev Bojan Smojver: > > Dave Jones redhat.com> writes: > > > > > *grumble*, just as .6 finished... > > > builds restarting, they should be done by the morning hopefully. > > > > Would you believe it - .8 is out! Gee, they come out fast these days, don't > > they? ;-) > > Jebus.. I thought they were supposed to be weekly releases, not hourly. > > - David Dear lord.. .9 is out All these security updates, are they related to the Coverity scans or some other kind of review process? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From tmus at tmus.dk Wed Apr 19 11:17:23 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 19 Apr 2006 13:17:23 +0200 Subject: yum bails on update dependency problems... Message-ID: Hi guys... I think we've had this discussion during FC5 development but in the light of recent update problems, I thought I'd bring it up again... Shouldn't we make yum able to install all the good updates, if only one package out of 60 is causing problems? I.e. skip the individual packages that are causing problems and install everything else. My reason for suggesting this is that we may miss important security updates because of something like this. And say we have 10 serious security updates, and one is failing, i'd much rather see the 9 others get installed with my nightly update. I seem to recall that some were concerned that if would be harder to spot errors like these, if we let all the good stuf get through. Well, then lets figure out a good way to get the errors visible too. Whether this should be resolved within yum or through a plugin doesn't bother me, but last i looked at it, the yum plugin infrastructure wouldn't allow me to exclude packages an rerun dependency tests. Has this changed? Thanks /Thomas From makoto at hep-th.phys.s.u-tokyo.ac.jp Wed Apr 19 11:42:56 2006 From: makoto at hep-th.phys.s.u-tokyo.ac.jp (Makoto Sakurai) Date: Wed, 19 Apr 2006 20:42:56 +0900 Subject: Xen3.0.2 rpm for Fedora Core 5 on 64bit CPU Message-ID: <000f01c663a6$66aafa40$040ba8c0@makotovirtual> Dear all; I'm using Pentium D 950 / Fedora Core 5 64bit. Has anyone built the rpmfile for kernel-xen0 and xen of 3.0.2 (not 3.0.1-4)? I installed the new rpm file distributed at the Xensource for Fedora Core 4 32bit, which worked unsuccessfully. In addition, I tried the source code (see the mailing list of Xen) as well as the hybrid use of kernel-xen0 with openSUSE rpm for xen 3.0.2, but it all failed. I look forward to your reply, Best, Makoto Sakurai From erik.sjolund at sbc.su.se Wed Apr 19 11:45:49 2006 From: erik.sjolund at sbc.su.se (Erik =?ISO-8859-1?Q?Sj=F6lund?=) Date: Wed, 19 Apr 2006 13:45:49 +0200 Subject: Kickstart and roles In-Reply-To: <20060414043809.40336.qmail@web38409.mail.mud.yahoo.com> References: <20060414043809.40336.qmail@web38409.mail.mud.yahoo.com> Message-ID: <1145447149.22177.109.camel@otto> On Thu, 2006-04-13 at 21:38 -0700, Jane Dogalt wrote: > This is a great idea and something I was planning on doing myself. But for > simplicity, it seems like this could be implemented dirt-simply (from an > infrastructure impact point of view) via rpms. I.e. rpms that are heavy on > specifying dependencies and pre/post scripts, but probably very light on files > (if not in fact lacking any rpm owned files). > > Therefore each role gets packaged as an rpm and placed in your yum repo, so > that you just do a yum install of it. That picks up all the package > dependencies to install, and does all the system config in the (rather more > invasive than usual) pre/post script. Hopefully you write the rpm uninstall > scripts with enough intelligence to revert the system exactly back to the > preinstall state. > > -jdog Sounds a lot like: http://xml2hostconf.sourceforge.net/ >From the home page: xml2hostconf is a utility for central configuration and automatic installation of a network of Fedora Linux computers. Instead of inventing new installation/updating/syncing methods it uses the functionality already present in rpm, anaconda (kickstart), dhcpd, pxelinux and yum. xml2hostconf generates appropriate configuration files for the above mentioned programs and let them do the work. xml2hostconf is written in the scripting language XSLT and Python. xml2hostconf differs to other installation frameworks in the sense that it lets the client setup be defined as generated configuration RPMs, consisting of configuration files and dependencies to "normal" application RPMs and possibly some post-installation commands. This gives the benefit that both already installed machines and newly installed machines will be kept in sync with the central configuration. You don't have to reinstall a machine to get it to reflect the configuration at the central configuration server. The command "yum update" pulls the current configuration to the client. I am just about to release a new version that has been packaged with autotools. Hopefully within the next days ... cheers, Erik Sj?lund From mdehaan at redhat.com Wed Apr 19 13:35:38 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 19 Apr 2006 09:35:38 -0400 Subject: Kickstart and roles In-Reply-To: <1145399024.21268.42.camel@currant.watzmann.net> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> Message-ID: <44463CAA.9030201@redhat.com> David Lutterkort wrote: > On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote: > >> So I've been kicking around this idea for a while and wanted to see >> what others thought. Who knows maybe someone will be interested in >> helping. >> > > More than interested. That's actually right down the road me and some > others have been thinking lately. > > >> This may already exist so if it does please let me know but I would >> like to setup a bunch of kickstart scripts for server and workstation >> roles using only official Fedora software. For example, lets say >> someone wants a xen workstation. We could setup a kickstart script >> with everything they need, only the minimals and at the end, yum >> update, configure what we can and on reboot, that user has a working >> xen machine. >> > > We are working on a tool to simplify the very basics of keeping track of > provisioning setup, both for bare-metal and domU provisioing. Our focus > so far has been on the mechanics of keeping kernel/initrd/ks.cfg on a > central server and using PXE boot (for bare-metal) and a separate script > (for domU) to start the provisioning. It's just a tad early to inflict > this on the world, but we'll make a prototype available in the next week > or two. For domU's, the idea is that it should be easy to publish > special-purpose kickstart files and use them with the tool. > Seeing I'm the one writing this puppy, I'll chime in briefly. David is, of course, right on -- including the part about inflictions! The basics are that in the end PXE provisioning is ultimately very similar to Xen provisioning, and we're creating a tool to allow both to be simultaneously or independently managed from a central boot server. At first, this will likely be a command line tool (with an optionally hand-editable config file), though we may see GTK interfaces later. Ultimately, this should allow a new bare-metal machine to be easily PXE provisioned to be a Xen host, and then from the kickstart for that machine, any number of domU images can be automatically installed (and provisioned with their own kickstarts, in turn, if neccessary) in one pass. So things like "make this machine a Xen workstation with these 2 specific Xen guests" will be possible -- with a minimal amount of kickstart hacking. Advanced configuration of services though things like puppet is something I'm excited about, as it's a step beyond kickstarts. Ultimately I'd like to see kickstart creation and system setup demystified as much as possible. Handrolling of custom boot/provision solutions is always going to occur, but it needs to be easier. Minimal kickstarts followed up by "make it so, number 1" orders ultimately make it less work for SA's for automated deployments/rollouts. Some integration with or evolution of yam is also likely a good add. In general, I like the minimal install ideas Mike points out as well. Comments definitely welcome. --Michael DeHaan From wesley at bu.edu Wed Apr 19 13:41:10 2006 From: wesley at bu.edu (Wesley Harrell) Date: Wed, 19 Apr 2006 09:41:10 -0400 Subject: yum bails on update dependency problems... In-Reply-To: References: Message-ID: <20060419134110.GD26688@hogtown.bu.edu> On Wed, Apr 19, 2006 at 01:17:23PM +0200, Thomas M Steenholdt wrote: > I think we've had this discussion during FC5 development but in the > light of recent update problems, I thought I'd bring it up again... > > Whether this should be resolved within yum or through a plugin doesn't > bother me, but last i looked at it, the yum plugin infrastructure > wouldn't allow me to exclude packages an rerun dependency tests. Has > this changed? Its a good idea, but you should also post this to the yum-devel list. I am sure you will get an answer here as well, but you may get a better discussion on that list. From tbrinkman at sbcglobal.net Wed Apr 19 14:06:44 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Wed, 19 Apr 2006 09:06:44 -0500 Subject: yum bails on update dependency problems... In-Reply-To: References: Message-ID: <200604190906.44750.tbrinkman@sbcglobal.net> On Wednesday 19 April 2006 06:17, Thomas M Steenholdt wrote: > Hi guys... > > I think we've had this discussion during FC5 development but in the > light of recent update problems, I thought I'd bring it up again... > > Shouldn't we make yum able to install all the good updates, if only > one package out of 60 is causing problems? I.e. skip the individual > packages that are causing problems and install everything else. http://fedoraproject.org/wiki/Tools/yum .................... Tips and Tricks "Yum halts if there is any dependency problem within the repository to be safe and doesnt perform partial updates. Use this script if you want that. Kindly ensure that you report any dependency issues to the appropriate repository bug tracker or post to the relevant project list if it requires more discussions." #!/bin/sh for i in `yum list updates |cut -f 1 -d " " |grep -A 500 -e Updated |\ grep -v -e Updated` ; do echo "Updating $i" yum -y update $i done .................... I put the script in //bin and made it executable, but I run it as root. I've been using it for sometime to update rawhide daily since 'yum update' has become a problem. Often needin to run it several times to get all the updates. I've just now installed 'yum-fastestmirror', so I'll see tomorrow if that helps with the mirror situation. -- Tom Brinkman Corpus Christi, Texas From mcdavey at mrao.cam.ac.uk Wed Apr 19 14:48:37 2006 From: mcdavey at mrao.cam.ac.uk (Matt Davey) Date: Wed, 19 Apr 2006 15:48:37 +0100 Subject: fix for gnome-pilot crasher (fc5 updates 2.0.13-7.fc5.5) Message-ID: <1145458117.6158.127.camel@mistral.local.corvil.com> Hi, The recently released gnome-pilot package (2.0.13-7.fc5.5) crashes on every sync attempt, for me at least. I've updated the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189294 and have attached a patch (actually, a meta-patch) that fixes the bug. The problem was the inclusion of a patch that removes a memory leak in gnome-pilot, but inadvertently triggers a free(NULL) in the pilot-link library. It doesn't cause that behaviour when linked against pilot-link 0.12.0pre*, but with the welcome downgrade to 0.11.8, causes a crash every time for me. Regards, Matt Matt Davey Socrates said man is never free, but Socrates mcdavey at mrao.cam.ac.uk never windsurfed. From bruno at wolff.to Wed Apr 19 14:59:47 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 19 Apr 2006 09:59:47 -0500 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> Message-ID: <20060419145947.GA21899@wolff.to> On Wed, Apr 19, 2006 at 04:30:15 +0000, Bojan Smojver wrote: > Dave Jones redhat.com> writes: > > > *grumble*, just as .6 finished... > > builds restarting, they should be done by the morning hopefully. > > Would you believe it - .8 is out! Gee, they come out fast these days, don't > they? ;-) That's old news. .9 is out now. From arjan at fenrus.demon.nl Wed Apr 19 15:40:39 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 19 Apr 2006 17:40:39 +0200 Subject: FC5 kernel updates In-Reply-To: <20060419145947.GA21899@wolff.to> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> Message-ID: <1145461239.3085.56.camel@laptopd505.fenrus.org> On Wed, 2006-04-19 at 09:59 -0500, Bruno Wolff III wrote: > On Wed, Apr 19, 2006 at 04:30:15 +0000, > Bojan Smojver wrote: > > Dave Jones redhat.com> writes: > > > > > *grumble*, just as .6 finished... > > > builds restarting, they should be done by the morning hopefully. > > > > Would you believe it - .8 is out! Gee, they come out fast these days, don't > > they? ;-) > > That's old news. .9 is out now. > a kernel a day keeps the spam monster away :) From smooge at gmail.com Wed Apr 19 16:16:16 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 19 Apr 2006 10:16:16 -0600 Subject: Puppet Re: Kickstart and roles Message-ID: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> If I understood what Luke was working on with puppet, the program is meant to be a re-engineering of cfengine to be less of an academic testbed and more of stable product. [I might be part of the reason for the fact it is in Ruby.. I suggested it a long time ago when Luke was giving a training course.] What I was wanting from a product was something that could be added into a network management system: what is on the computer, what is connected to the computer (and when), what is the configuration of the computers services (stuff lower than RPMs so that all 2000 desktops have a useless banner, point to the correct email servers, and have the desktop menus with the correct applications set up.), and who is on the computer and when. Where the computer is would be even better :). -- Stephen J Smoogen. CSIRT/Linux System Administrator From notting at redhat.com Wed Apr 19 16:22:48 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 19 Apr 2006 12:22:48 -0400 Subject: FC5 kernel updates In-Reply-To: <1145461239.3085.56.camel@laptopd505.fenrus.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> Message-ID: <20060419162248.GB32734@devserv.devel.redhat.com> Arjan van de Ven (arjan at fenrus.demon.nl) said: > > That's old news. .9 is out now. > > a kernel a day keeps the spam monster away :) A day? I thought the idea was to release them faster than they can actually be built. Bill From davej at redhat.com Wed Apr 19 16:25:25 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 19 Apr 2006 12:25:25 -0400 Subject: FC5 kernel updates In-Reply-To: <20060419162248.GB32734@devserv.devel.redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> Message-ID: <20060419162525.GD16298@redhat.com> On Wed, Apr 19, 2006 at 12:22:48PM -0400, Bill Nottingham wrote: > Arjan van de Ven (arjan at fenrus.demon.nl) said: > > > That's old news. .9 is out now. > > > > a kernel a day keeps the spam monster away :) > > A day? I thought the idea was to release them faster than they can > actually be built. That's certainly been the case this week ;) I knew .9 was coming, which is why I sat on it a little longer. *fingers crossed*, this should be it (for now). I'll kick off the build soon. Dave -- http://www.codemonkey.org.uk From shane at geeklords.org Wed Apr 19 16:52:19 2006 From: shane at geeklords.org (Shane Stixrud) Date: Wed, 19 Apr 2006 09:52:19 -0700 (PDT) Subject: Kickstart and roles In-Reply-To: <44463CAA.9030201@redhat.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <44463CAA.9030201@redhat.com> Message-ID: On Wed, 19 Apr 2006, Michael DeHaan wrote: > > Seeing I'm the one writing this puppy, I'll chime in briefly. [snip] > Advanced configuration of services though things like puppet is something I'm > excited about, as it's a step beyond kickstarts. Ultimately I'd like to see > kickstart creation and system setup demystified as much as possible. > Handrolling of custom boot/provision solutions is always going to occur, but > it needs to be easier. Minimal kickstarts followed up by "make it so, > number 1" orders ultimately make it less work for SA's for automated > deployments/rollouts. Some integration with or evolution of yam is also > likely a good add. In general, I like the minimal install ideas Mike points > out as well. The main problem I see with configuration engines like cfengine (I assume puppet has this same issue?) is admins must either make all changes from the central server or be forced to remember to go back and write policies on the central server after the fact. Sadly doing the Right Thing (tm) isn't always an option due to real life circumstances (cough cough management) and performing a "quick fix" to the managed device without taking the time to write centralized policies is the result. Writing these policies after the fact is of course desirable but in many cases this would require another change control and testing cycle. In short these type of tools really need the ability to detect what has changed and let the admin easily integrate/pull these changes and sign off on them as part of the devices new recipe/state. Cheers, Shane From smooge at gmail.com Wed Apr 19 17:01:01 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 19 Apr 2006 11:01:01 -0600 Subject: Kickstart and roles In-Reply-To: References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <44463CAA.9030201@redhat.com> Message-ID: <80d7e4090604191001p35a4cdfbgef7243d41e0e7cf1@mail.gmail.com> On 4/19/06, Shane Stixrud wrote: > On Wed, 19 Apr 2006, Michael DeHaan wrote: > > > > > Seeing I'm the one writing this puppy, I'll chime in briefly. > [snip] > > Advanced configuration of services though things like puppet is something I'm > > excited about, as it's a step beyond kickstarts. Ultimately I'd like to see > > kickstart creation and system setup demystified as much as possible. > > Handrolling of custom boot/provision solutions is always going to occur, but > > it needs to be easier. Minimal kickstarts followed up by "make it so, > > number 1" orders ultimately make it less work for SA's for automated > > deployments/rollouts. Some integration with or evolution of yam is also > > likely a good add. In general, I like the minimal install ideas Mike points > > out as well. > > The main problem I see with configuration engines like cfengine (I assume > puppet has this same issue?) is admins must either make all changes from > the central server or be forced to remember to go back and write policies > on the central server after the fact. > > Sadly doing the Right Thing (tm) isn't always an option due to real life > circumstances (cough cough management) and performing a "quick fix" to the > managed device without taking the time to write centralized policies is There is no technical solution to a management issue. You can hack as much at it but the managers will come up with a completely new way to be stupid. I found that getting management to buy off on how change control works was a better cost solution. [Getting them to sign the timesheet for the extra work/pay got them to cut down on last minute changes.] > the result. Writing these policies after the fact is of course desirable > but in many cases this would require another change control and testing > cycle. In short these type of tools really need the ability to detect what > has changed and let the admin easily integrate/pull these changes and > sign off on them as part of the devices new recipe/state. This would be useful in a different manner.. when the hacker breaks in and fixes your broken server. > > Cheers, > Shane > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From shane at geeklords.org Wed Apr 19 17:20:48 2006 From: shane at geeklords.org (Shane Stixrud) Date: Wed, 19 Apr 2006 10:20:48 -0700 (PDT) Subject: Kickstart and roles In-Reply-To: <80d7e4090604191001p35a4cdfbgef7243d41e0e7cf1@mail.gmail.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <44463CAA.9030201@redhat.com> <80d7e4090604191001p35a4cdfbgef7243d41e0e7cf1@mail.gmail.com> Message-ID: On Wed, 19 Apr 2006, Stephen John Smoogen wrote: >> Sadly doing the Right Thing (tm) isn't always an option due to real life >> circumstances (cough cough management) and performing a "quick fix" to the >> managed device without taking the time to write centralized policies is > > There is no technical solution to a management issue. You can hack as > much at it but the managers will come up with a completely new way to > be stupid. I found that getting management to buy off on how change > control works was a better cost solution. [Getting them to sign the > timesheet for the extra work/pay got them to cut down on last minute > changes.] Sure and for the most part the change control where I work is sane. There are still issues that come up where taking the time to write the policies isn't available for various reasons. >> the result. Writing these policies after the fact is of course desirable >> but in many cases this would require another change control and testing >> cycle. In short these type of tools really need the ability to detect what >> has changed and let the admin easily integrate/pull these changes and >> sign off on them as part of the devices new recipe/state. > > This would be useful in a different manner.. when the hacker breaks in > and fixes your broken server. How do you mean? Such a feature would allow the admin to see what changes a cracker made, not sign off on them and instead revert them to the previous state. Cheers, Shane From dwmw2 at infradead.org Wed Apr 19 18:16:03 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 19 Apr 2006 19:16:03 +0100 Subject: FC5 kernel updates In-Reply-To: <20060419162525.GD16298@redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> Message-ID: <1145470563.11909.69.camel@pmac.infradead.org> On Wed, 2006-04-19 at 12:25 -0400, Dave Jones wrote: > That's certainly been the case this week ;) > I knew .9 was coming, which is why I sat on it a little longer. > *fingers crossed*, this should be it (for now). > > I'll kick off the build soon. I did the night shift -- .8 and .9 were both built while you were sleeping :) -- dwmw2 From mmcgrath at fedoraproject.org Wed Apr 19 18:54:33 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 19 Apr 2006 13:54:33 -0500 Subject: Kickstart and roles In-Reply-To: <44463CAA.9030201@redhat.com> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <44463CAA.9030201@redhat.com> Message-ID: <44468769.2090208@fedoraproject.org> > > Seeing I'm the one writing this puppy, I'll chime in briefly. David > is, of course, right on -- including the part about inflictions! > The basics are that in the end PXE provisioning is ultimately very > similar to Xen provisioning, and we're creating a tool to allow both > to be simultaneously or independently managed from a central boot > server. At first, this will likely be a command line tool (with an > optionally hand-editable config file), though we may see GTK > interfaces later. > Ultimately, this should allow a new bare-metal machine to be easily > PXE provisioned to be a Xen host, and then from the kickstart for that > machine, any number of domU images can be automatically installed (and > provisioned with their own kickstarts, in turn, if neccessary) in one > pass. So things like "make this machine a Xen workstation with these > 2 specific Xen guests" will be possible -- with a minimal amount of > kickstart hacking. > Advanced configuration of services though things like puppet is > something I'm excited about, as it's a step beyond kickstarts. > Ultimately I'd like to see kickstart creation and system setup > demystified as much as possible. Handrolling of custom boot/provision > solutions is always going to occur, but it needs to be easier. > Minimal kickstarts followed up by "make it so, number 1" orders > ultimately make it less work for SA's for automated > deployments/rollouts. Some integration with or evolution of yam is > also likely a good add. In general, I like the minimal install ideas > Mike points out as well. > > Comments definitely welcome. > > --Michael DeHaan > Is there a status page or any place I can follow the development? -Mike From davej at redhat.com Wed Apr 19 18:57:27 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 19 Apr 2006 14:57:27 -0400 Subject: FC5 kernel updates In-Reply-To: <1145470563.11909.69.camel@pmac.infradead.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> <1145470563.11909.69.camel@pmac.infradead.org> Message-ID: <20060419185727.GG16298@redhat.com> On Wed, Apr 19, 2006 at 07:16:03PM +0100, David Woodhouse wrote: > On Wed, 2006-04-19 at 12:25 -0400, Dave Jones wrote: > > That's certainly been the case this week ;) > > I knew .9 was coming, which is why I sat on it a little longer. > > *fingers crossed*, this should be it (for now). > > > > I'll kick off the build soon. > > I did the night shift -- .8 and .9 were both built while you were > sleeping :) Great :-) I've just submitted that as an errata, so that should go out soon. I've just kicked off the FC4 build of the same too. Dave -- http://www.codemonkey.org.uk From than at redhat.com Wed Apr 19 19:22:44 2006 From: than at redhat.com (Than Ngo) Date: Wed, 19 Apr 2006 21:22:44 +0200 Subject: fix for gnome-pilot crasher (fc5 updates 2.0.13-7.fc5.5) In-Reply-To: <1145458117.6158.127.camel@mistral.local.corvil.com> References: <1145458117.6158.127.camel@mistral.local.corvil.com> Message-ID: <44468E04.6010409@redhat.com> Matt Davey wrote: > Hi, > > The recently released gnome-pilot package (2.0.13-7.fc5.5) crashes on > every sync attempt, for me at least. > > I've updated the following bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189294 > > and have attached a patch (actually, a meta-patch) that fixes the bug. > > The problem was the inclusion of a patch that removes a memory leak in > gnome-pilot, but inadvertently triggers a free(NULL) in the pilot-link > library. It doesn't cause that behaviour when linked against pilot-link > 0.12.0pre*, but with the welcome downgrade to 0.11.8, causes a crash > every time for me. > > Regards, > > Matt > > Matt Davey Socrates said man is never free, but Socrates > mcdavey at mrao.cam.ac.uk never windsurfed. > > i'm preparing new gnome-pilot for fc4/fc5 updates and fc6-devel to fix #189294. Many thanks for the patch. Than From krh at redhat.com Wed Apr 19 20:00:48 2006 From: krh at redhat.com (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=) Date: Wed, 19 Apr 2006 16:00:48 -0400 Subject: AIGLX packages for FC5 (and rawhide) Message-ID: <444696F0.9080801@redhat.com> Hi, I've set up a yum repository with AIGLX packages for FC5. It's on download.fedora.redhat.com: http://download.fedora.redhat.com/pub/fedora/projects/aiglx and there's a aiglx.repo file there that can be dropped into /etc/yum.repos.d. With that, $ yum --enablerepo=aiglx update should pull down the AIGLX package set. The packages are just the rawhide RPMs rebuilt for FC5, so they're a little rough around the edges. That said, if the metacity compositor isn't enabled (see below), things should be pretty stable. Here's an overview of the features and tweakable settings in the current versions of the repository packages. Since rawhide has the same packages the instructions below can also be used with a recent rawhide system: - metacity with compositing manager functionality. Turn it on using gconf-editor by enabling /apps/metacity/general/compositing_manager or alternatively, use $ gconftool-2 -s /apps/metacity/general/compositing_manager --type bool true - the metacity build in the repo has wobbly windows as an optional feature. Set the environment variable USE_WOBBLY to 1 and restart metacity. For example: $ USE_WOBBLY=1 metacity --replace & - metacity also has an experimental screen magnifier built in. Like the wobbly windows this is enabled by setting an environment variable - USE_MAGNIFIER: $ USE_MAGNIFIER=1 metacity --replace & - real translucency in gnome-terminal. Enable this by clicking the "Transparent background" radio box in the "Effects" tab of the termnal profile editor dialog. gnome-terminal may have to be restarted for this to take effect - pkill gnome-terminal should do the trick. There are a number of known bugs with these packages, so go easy on bugzilla :). Specifically, - The damage events doesn't always kick in, so sometimes window contents doesn't update properly. A workaround for this is to switch desktop back and forth. - The drop shadows look weird on shaped/argb windows, for example xeyes, the notify bubbles and well, even the rounded metacity corners. The shadow code is due for an overhaul later, so we're not going to patch over this issue in the short term. - Perfomance for in-window updates isn't always great. We're currently doing too much work when updating textures from pixmaps. It's still possible to optimize this further with the current setup, and longer term the memory architecture in the X server and DRI stack will see some changes that will allow us to optimize this further. Have fun, Kristian From mdehaan at redhat.com Wed Apr 19 20:39:24 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 19 Apr 2006 16:39:24 -0400 Subject: Kickstart and roles In-Reply-To: <44468769.2090208@fedoraproject.org> References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> <1145399024.21268.42.camel@currant.watzmann.net> <44463CAA.9030201@redhat.com> <44468769.2090208@fedoraproject.org> Message-ID: <44469FFC.60507@redhat.com> Mike McGrath wrote: > >> >> Seeing I'm the one writing this puppy, I'll chime in briefly. David >> is, of course, right on -- including the part about inflictions! >> The basics are that in the end PXE provisioning is ultimately very >> similar to Xen provisioning, and we're creating a tool to allow both >> to be simultaneously or independently managed from a central boot >> server. At first, this will likely be a command line tool (with an >> optionally hand-editable config file), though we may see GTK >> interfaces later. Ultimately, this should allow a new bare-metal >> machine to be easily PXE provisioned to be a Xen host, and then from >> the kickstart for that machine, any number of domU images can be >> automatically installed (and provisioned with their own kickstarts, >> in turn, if neccessary) in one pass. So things like "make this >> machine a Xen workstation with these 2 specific Xen guests" will be >> possible -- with a minimal amount of kickstart hacking. Advanced >> configuration of services though things like puppet is something I'm >> excited about, as it's a step beyond kickstarts. Ultimately I'd >> like to see kickstart creation and system setup demystified as much >> as possible. Handrolling of custom boot/provision solutions is >> always going to occur, but it needs to be easier. Minimal >> kickstarts followed up by "make it so, number 1" orders ultimately >> make it less work for SA's for automated deployments/rollouts. Some >> integration with or evolution of yam is also likely a good add. In >> general, I like the minimal install ideas Mike points out as well. >> >> Comments definitely welcome. >> >> --Michael DeHaan >> > > Is there a status page or any place I can follow the development? > > -Mike > Not yet... as David L. said it's prob. a couple of weeks off, if only to add things like packaging and some more sensible documentation/examples and the like. I'll post to the list when I have something for people to play with. --Michael DeHaan From tmus at tmus.dk Wed Apr 19 20:45:44 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 19 Apr 2006 22:45:44 +0200 Subject: yum bails on update dependency problems... In-Reply-To: <200604190906.44750.tbrinkman@sbcglobal.net> References: <200604190906.44750.tbrinkman@sbcglobal.net> Message-ID: Tom Brinkman wrote: > "Yum halts if there is any dependency problem within the repository to > be safe and doesnt perform partial updates. Use this script if you > want that. Kindly ensure that you report any dependency issues to the > appropriate repository bug tracker or post to the relevant project > list if it requires more discussions." > > #!/bin/sh > for i in `yum list updates |cut -f 1 -d " " |grep -A 500 -e Updated |\ > grep -v -e Updated` ; do > echo "Updating $i" > yum -y update $i > done This is acceptable for rawhide machines, where its generally more accepteble to have slightly hack-ish things implemented... This is hack-ish and is not the way to do this kind of thing properly. (1) you loose updating of packages with long names(unless by coincidence that package is pulled in as dependency for package with shorter name) (2) yum will be run multiple times, whereof a large number is likely to do absolutely nothing, so wasting resources for no good reason. If we want this kind of thing, we need to implement it properly. /Thomas From redhat at olen.net Wed Apr 19 21:52:09 2006 From: redhat at olen.net (Ola Thoresen) Date: Wed, 19 Apr 2006 21:52:09 +0000 (UTC) Subject: Kickstart and roles References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: 2006-04-19 Shane Stixrud wrote > In short these type of tools really need the ability to detect what > has changed and let the admin easily integrate/pull these changes and > sign off on them as part of the devices new recipe/state. I have always wanted at linux-version of "write" in cisco. So many times have network-devices been changed, IP-addresses added and removed, routing tables altered, sysctl-settings been updated, services started or stopped.. you name it. The box is running perfectly, all customers are happy - and along comes a power surge. (Or a random HW-error or kernel panic or whatever), and then most of the next day will be used to recreate all the little bits and pieces that were changed on the fly and not written to the proper config-files. iptables at least has a simple "save" function. Something along those lines, that would generate the proper ipsec-config, ifcfg-files and update chkconfig with the currently running services would go a long way in many cases. Ofcourse, being able to "backup" the config, sign it off, and recreate it on a different machine later by remotely updating a central "config-server" would be perfect, but a great first step would be "service network save", "service ipsec save" ... Rgds. Ola Thoresen From pemboa at gmail.com Wed Apr 19 22:46:21 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 19 Apr 2006 17:46:21 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> On 4/16/06, Patrick W. Barnes wrote: > Last year, after Fedora applied to participate in Google's Summer of Code > 2005, we created the FedoraBounties page on the wiki: > > http://fedoraproject.org/wiki/FedoraBounties > > This page features specific ideas for new projects that the Fedora Project > would like to see completed. Several of these ideas were selected by > students for the Summer of Code event. > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. > > Assuming we do participate in this year's event, we can expect several of the > project ideas to be selected again, so this is an excellent opportunity to > suggest long-missed projects. Students will be able to apply for this year's > event after May 1st, so there isn't much time to get your ideas listed. > > http://fedoraproject.org/wiki/SummerOfCode > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > A GUI utility which helps newbies get information that may be useful in helping them get answers on irc, forums, mailing lists etc, might be helpful. Things like the output of: uname -a cat /proc/cpuinfo lsmod lspci lsusb tail /var/log/messages du -h free -h Or other info such: current desktop environment current login manager -- As a boy I jumped through Windows, as a man I play with Penguins. From alan at clueserver.org Wed Apr 19 23:03:04 2006 From: alan at clueserver.org (alan) Date: Wed, 19 Apr 2006 16:03:04 -0700 (PDT) Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: On Wed, 19 Apr 2006, Kristian H?gsberg wrote: > Hi, > > I've set up a yum repository with AIGLX packages for FC5. It's on > download.fedora.redhat.com: > > http://download.fedora.redhat.com/pub/fedora/projects/aiglx > > and there's a aiglx.repo file there that can be dropped into > /etc/yum.repos.d. With that, > > $ yum --enablerepo=aiglx update > > should pull down the AIGLX package set. The packages are just the rawhide > RPMs rebuilt for FC5, so they're a little rough around the edges. That said, > if the metacity compositor isn't enabled (see below), things should be pretty > stable. Yum chokes pretty hard on that repository. aiglx [4/6] //var/cache/yum/aiglx/repomd.xml:16: parser error : Opening and ending tag mismatch: link line 15 and head ^ //var/cache/yum/aiglx/repomd.xml:22: parser error : Opening and ending tag mismatch: img line 22 and a Fedora Project ^ //var/cache/yum/aiglx/repomd.xml:27: parser error : Opening and ending tag mismatch: img line 27 and a Download Projects FAQ ^ //var/cache/yum/aiglx/repomd.xml:29: parser error : Opening and ending tag mismatch: a line 29 and span a href="/About/FAQ.html"> FAQ ^ //var/cache/yum/aiglx/repomd.xml:31: parser error : Opening and ending tag mismatch: a line 27 and div ^ //var/cache/yum/aiglx/repomd.xml:52: parser error : Entity 'nbsp' not defined

 
^ //var/cache/yum/aiglx/repomd.xml:53: parser error : Entity 'nbsp' not defined
 
^ //var/cache/yum/aiglx/repomd.xml:60: parser error : Entity 'nbsp' not defined
 
^ //var/cache/yum/aiglx/repomd.xml:61: parser error : Entity 'nbsp' not defined
 
^ //var/cache/yum/aiglx/repomd.xml:93: parser error : Entity 'copy' not defined Copyright © 2003-2005 Red Hat, Inc. All rights reserved. ^ //var/cache/yum/aiglx/repomd.xml:96: parser error : Opening and ending tag mismatch: br line 96 and div
^ //var/cache/yum/aiglx/repomd.xml:111: parser error : Opening and ending tag mismatch: br line 95 and body ^ //var/cache/yum/aiglx/repomd.xml:112: parser error : Opening and ending tag mismatch: br line 94 and html ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag div line 92 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag span line 26 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag div line 25 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag div line 21 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag div line 20 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag body line 18 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag link line 14 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag meta line 13 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag link line 7 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag meta line 6 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag head line 4 ^ //var/cache/yum/aiglx/repomd.xml:113: parser error : Premature end of data in tag html line 3 ^ aiglx 100% |=========================| 4.1 kB 00:00 http://download.fedora.redhat.com/pub/fedora/projects/aiglx/x86_64/repodata/repomd.xml: [Errno -1] Error importing repomd.xml for aiglx: Error: could not parse file //var/cache/yum/aiglx/repomd.xml Trying other mirror. Cannot open/read repomd.xml file for repository: aiglx failure: repodata/repomd.xml from aiglx: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from aiglx: [Errno 256] No more mirrors to try. -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From alan at clueserver.org Wed Apr 19 23:04:27 2006 From: alan at clueserver.org (alan) Date: Wed, 19 Apr 2006 16:04:27 -0700 (PDT) Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: On Wed, 19 Apr 2006, Kristian H?gsberg wrote: > Hi, > > I've set up a yum repository with AIGLX packages for FC5. It's on > download.fedora.redhat.com: > > http://download.fedora.redhat.com/pub/fedora/projects/aiglx > > and there's a aiglx.repo file there that can be dropped into > /etc/yum.repos.d. With that, > > $ yum --enablerepo=aiglx update > > should pull down the AIGLX package set. The packages are just the rawhide > RPMs rebuilt for FC5, so they're a little rough around the edges. That said, > if the metacity compositor isn't enabled (see below), things should be pretty > stable. Oops. Failed to notice that there is not a version for x86_64. Doh! -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From camilo at mesias.co.uk Wed Apr 19 23:45:04 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 20 Apr 2006 00:45:04 +0100 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: <4446CB80.6020309@mesias.co.uk> Kristian I tried this just for fun on my ATI r300 and was surprised that it almost worked. I get what looks like an alpha channel (blue screen with shadows on it). True to the notes I can turn compositing off and everything is back to normal. Is there a focus for this work (mail list, wiki page, irc meeting)? Do you want feedback to bugzilla? -Cam -- <-- camilo at mesias.co.uk From mike at miketc.com Thu Apr 20 00:04:43 2006 From: mike at miketc.com (Mike Chambers) Date: Wed, 19 Apr 2006 19:04:43 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4446CB80.6020309@mesias.co.uk> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> Message-ID: <1145491483.3234.0.camel@scrappy.miketc.com> On Thu, 2006-04-20 at 00:45 +0100, Cam wrote: > I tried this just for fun on my ATI r300 and was surprised that it > almost worked. I get what looks like an alpha channel (blue screen with > shadows on it). True to the notes I can turn compositing off and > everything is back to normal. I set it up on a Radeon 9000 Pro system and it was really slow. Made X use CPU up to 60-70%. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important until you aren't getting any!" From skvidal at linux.duke.edu Thu Apr 20 00:11:23 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 19 Apr 2006 20:11:23 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: References: <444696F0.9080801@redhat.com> Message-ID: <1145491883.12794.0.camel@cutter> On Wed, 2006-04-19 at 16:03 -0700, alan wrote: > On Wed, 19 Apr 2006, Kristian H?gsberg wrote: > > > Hi, > > > > I've set up a yum repository with AIGLX packages for FC5. It's on > > download.fedora.redhat.com: > > > > http://download.fedora.redhat.com/pub/fedora/projects/aiglx > > > > and there's a aiglx.repo file there that can be dropped into > > /etc/yum.repos.d. With that, > > > > $ yum --enablerepo=aiglx update > > > > should pull down the AIGLX package set. The packages are just the rawhide > > RPMs rebuilt for FC5, so they're a little rough around the edges. That said, > > if the metacity compositor isn't enabled (see below), things should be pretty > > stable. > > Yum chokes pretty hard on that repository. > no, actually, yum doesn't choke at all: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189443 -sv From jwboyer at jdub.homelinux.org Thu Apr 20 00:30:51 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 19 Apr 2006 19:30:51 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4446CB80.6020309@mesias.co.uk> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> Message-ID: <1145493051.4749.1.camel@yoda.jdub.homelinux.org> On Thu, 2006-04-20 at 00:45 +0100, Cam wrote: > Kristian > > I tried this just for fun on my ATI r300 and was surprised that it > almost worked. I get what looks like an alpha channel (blue screen with > shadows on it). True to the notes I can turn compositing off and > everything is back to normal. I saw the same thing on my laptop with an ATI Radeon Mobility something or other. > > Is there a focus for this work (mail list, wiki page, irc meeting)? Do > you want feedback to bugzilla? > http://fedoraproject.org/wiki/RenderingProject/aiglx josh From joelonlinux at optonline.net Thu Apr 20 04:33:36 2006 From: joelonlinux at optonline.net (Joel Rittvo) Date: Thu, 20 Apr 2006 00:33:36 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145493051.4749.1.camel@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> Message-ID: <44470F20.2000602@optonline.net> Is it possible (as in: would it work) to use metacity with a KDE desktop, or is this fun only for a gnome desktop at this point? Joel Rittvo From ivazquez at ivazquez.net Thu Apr 20 04:44:45 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 20 Apr 2006 00:44:45 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <44470F20.2000602@optonline.net> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <44470F20.2000602@optonline.net> Message-ID: <1145508285.3228.18.camel@ignacio.lan> On Thu, 2006-04-20 at 00:33 -0400, Joel Rittvo wrote: > Is it possible (as in: would it work) to use metacity with a KDE > desktop, or is this fun only for a gnome desktop at this point? metacity is just a window manager. There's almost no reason you can't use it in place of kwin. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Thu Apr 20 07:26:26 2006 From: buildsys at redhat.com (Build System) Date: Thu, 20 Apr 2006 03:26:26 -0400 Subject: rawhide report: 20060420 changes Message-ID: <200604200726.k3K7QP7g004533@porkchop.devel.redhat.com> Updated Packages: Pyrex-0:0.9.4-1 --------------- * Wed Apr 19 2006 John (J5) Palmieri - 0.9.4-1 - Upgrade to upstream 0.9.4 device-mapper-1.02.05-1.0 ------------------------- * Wed Apr 19 2006 Alasdair Kergon - 1.02.05-1.0 - New upstream release (incorporates patches). - Exclude dmeventd (no kernel support yet). firefox-1.5.0.2-4 ----------------- * Wed Apr 19 2006 Christopher Aillon - 1.5.0.2-4 - Really drop the broken langpacks this time. gcalctool-5.7.32-4 ------------------ gimp-2:2.2.11-2 --------------- * Wed Apr 19 2006 Nils Philippsen - 2:2.2.11-2 - require pkgconfig (#189314) * Tue Apr 18 2006 Nils Philippsen - 2:2.2.11-1 - version 2.2.11 * Fri Mar 03 2006 Nils Philippsen - 2:2.2.10-4 - use htmlview as default web browser (#183730, patch by Ben Levenson) - require hicolor-icon-theme (#182784, #182785) gnome-pilot-2.0.13-9 -------------------- * Wed Apr 19 2006 Than Ngo 2.0.13-9 - apply patch to fix crash with pilot-link 0.11.8 #189294 thanks to Matt Dave gnome-terminal-2.14.1-9 ----------------------- * Wed Apr 19 2006 Ray Strode 2.14.1-9 - Require newer vte (bug 189341) gnome-utils-1:2.14.0-10 ----------------------- * Wed Apr 19 2006 Jeremy Katz - 1:2.14.0-10 - fix -devel requires on main package * Wed Apr 19 2006 Matthias Clasen 2.14.0-9 - Fix some crashes in gdict (#189090) gtk2-engines-2.7.4-6 -------------------- * Wed Apr 19 2006 Soren Sandmann - 2.7.4-6 - It was in fact a missing copy method. See gnome bug 338826. * Tue Apr 18 2006 Kristian H??gsberg 2.7.4-5 - Bump for fc5-blig repo build. isdn4k-utils-3.2-43 ------------------- * Wed Apr 19 2006 Than Ngo 3.2-43 - update to CVS-2006-02-13 - add support capi #169902 kernel-2.6.16-1.2141_FC6 ------------------------ * Wed Apr 19 2006 Dave Jones - 2.6.17rc2-git1 - Use unicode VTs by default. lvm2-2.02.04-1.0 ---------------- * Wed Apr 19 2006 Alasdair Kergon - 2.02.04-1.0 - New release upstream, including better handling of duplicated VG names. m2crypto-0.15-4 --------------- * Wed Apr 19 2006 Miloslav Trmac - 0.15-4 - Fix SSL.Connection.accept (#188742) selinux-policy-2.2.33-1 ----------------------- * Tue Apr 18 2006 Dan Walsh 2.2.33-1 - Update to latest from upstream - Add James Antill patch for xen - Many fixes for pegasus swig-1.3.29-0.1 --------------- * Wed Apr 19 2006 Jitka Kudrnacova - 1.3.29.0.1 - folder /usr/share/swig should be owned by swig package (bug #189145) system-config-netboot-0.1.40-1.FC6 ---------------------------------- * Wed Apr 19 2006 Jason Vas Dias - 0.1.40-1 - fix further issues reported by brian at chpc.utah.edu: o should be a way of configuring remote logging from the GUI o provide a means of disabling default snapshot directory generation udev-090-1 ---------- * Wed Apr 19 2006 Harald Hoyer - 090-1 - version 090 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From chitlesh at fedoraproject.org Thu Apr 20 09:53:34 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 20 Apr 2006 11:53:34 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145508285.3228.18.camel@ignacio.lan> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <44470F20.2000602@optonline.net> <1145508285.3228.18.camel@ignacio.lan> Message-ID: <13dbfe4f0604200253p4d218182w78d4952c0635f1b6@mail.gmail.com> Does it work with the latest nvidia driver ? I think it was not mentioned the old aiglx repo should be removed from our /etc/yum.repos.d. On 4/20/06, Ignacio Vazquez-Abrams wrote: > On Thu, 2006-04-20 at 00:33 -0400, Joel Rittvo wrote: > > Is it possible (as in: would it work) to use metacity with a KDE > > desktop, or is this fun only for a gnome desktop at this point? > > metacity is just a window manager. There's almost no reason you can't > use it in place of kwin. > > -- > Ignacio Vazquez-Abrams > http://fedora.ivazquez.net/ > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQBERxG9oK1Hsnseh8QRAgIMAJ4uuvWERoY87ewDOR9NfPN/rdLbZQCeL87y > QiU95cT8j0Vu5pprhQR7wfc= > =WchA > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Thu Apr 20 12:09:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Apr 2006 17:39:08 +0530 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> Message-ID: <1145534949.18551.82.camel@sundaram.pnq.redhat.com> On Wed, 2006-04-19 at 17:46 -0500, Arthur Pemberton wrote: > > > > A GUI utility which helps newbies get information that may be useful > in helping them get answers on irc, forums, mailing lists etc, might > be helpful. > > Things like the output of: > uname -a > cat /proc/cpuinfo > lsmod > lspci > lsusb > tail /var/log/messages > du -h > free -h > > Or other info such: > current desktop environment > current login manager Sounds like a wrapper for sysreport which is available in Fedora too. Would be quite useful for the less technically inclined users. http://kbase.redhat.com/faq/FAQ_80_456.shtm Rahul From camilo at mesias.co.uk Thu Apr 20 12:23:46 2006 From: camilo at mesias.co.uk (Cam) Date: Thu, 20 Apr 2006 13:23:46 +0100 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145534949.18551.82.camel@sundaram.pnq.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> Message-ID: <44477D52.4060704@mesias.co.uk> Rahul I remember a lot of fun was to be had with commercial OSs and tools like SiSoft Sandra. That would be a good source of ideas. http://www.sisoftware.co.uk/index.html?dir=&location=pinformation&langx=en&a= Many of the underlying tools are available already (eg. hdparm -t, iostat, smartd, lspci, xdpyinfo, /proc, lshal) but wrapping them in a GUI would be useful for beginners. -Cam -- camilo at mesias.co.uk <-- From sundaram at fedoraproject.org Thu Apr 20 12:32:18 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 20 Apr 2006 18:02:18 +0530 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44477D52.4060704@mesias.co.uk> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <44477D52.4060704@mesias.co.uk> Message-ID: <1145536338.18551.90.camel@sundaram.pnq.redhat.com> On Thu, 2006-04-20 at 13:23 +0100, Cam wrote: > Rahul > > I remember a lot of fun was to be had with commercial OSs and tools like > SiSoft Sandra. That would be a good source of ideas. > > http://www.sisoftware.co.uk/index.html?dir=&location=pinformation&langx=en&a= > > Many of the underlying tools are available already (eg. hdparm -t, > iostat, smartd, lspci, xdpyinfo, /proc, lshal) but wrapping them in a > GUI would be useful for beginners. Yes a wrapper around all this tools would be quite useful indeed using something like PyGTK. Red Hat support relies on sysreport extensively which is why I pointed it out to give an idea on what information would be useful to collect. Rahul From shiva at sewingwitch.com Thu Apr 20 13:08:22 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 20 Apr 2006 06:08:22 -0700 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <1145193778.2594.5.camel@localhost.localdomain> References: <1145193778.2594.5.camel@localhost.localdomain> Message-ID: <072B2A39CE3B74E33099F3FB@[169.254.160.111]> I'd love to see a GUI version of the iptables command line tool. This should display the current chains in some kind of tree layout and allow one to insert/edit/delete the live rules and save them to /etc/sysconfig/iptables. It should accept module-specific plugins just like the command line tool. From che666 at gmail.com Thu Apr 20 13:11:13 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:11:13 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <13dbfe4f0604200253p4d218182w78d4952c0635f1b6@mail.gmail.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <44470F20.2000602@optonline.net> <1145508285.3228.18.camel@ignacio.lan> <13dbfe4f0604200253p4d218182w78d4952c0635f1b6@mail.gmail.com> Message-ID: the latest nvidia driver doesent work its missing the required extension... the latest nvidia driver doesent work with xorg head at all btw. has to be fixed with nvidia... the driver got the work with the system not the system with the driver ;) regards, Rudolf Kastl 2006/4/20, Chitlesh GOORAH : > Does it work with the latest nvidia driver ? > > I think it was not mentioned the old aiglx repo should be removed from > our /etc/yum.repos.d. > > > On 4/20/06, Ignacio Vazquez-Abrams wrote: > > On Thu, 2006-04-20 at 00:33 -0400, Joel Rittvo wrote: > > > Is it possible (as in: would it work) to use metacity with a KDE > > > desktop, or is this fun only for a gnome desktop at this point? > > > > metacity is just a window manager. There's almost no reason you can't > > use it in place of kwin. > > > > -- > > Ignacio Vazquez-Abrams > > http://fedora.ivazquez.net/ > > > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.2.2 (GNU/Linux) > > > > iD8DBQBERxG9oK1Hsnseh8QRAgIMAJ4uuvWERoY87ewDOR9NfPN/rdLbZQCeL87y > > QiU95cT8j0Vu5pprhQR7wfc= > > =WchA > > -----END PGP SIGNATURE----- > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > -- > http://clunixchit.blogspot.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From che666 at gmail.com Thu Apr 20 13:12:00 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:12:00 +0200 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <072B2A39CE3B74E33099F3FB@169.254.160.111> References: <1145193778.2594.5.camel@localhost.localdomain> <072B2A39CE3B74E33099F3FB@169.254.160.111> Message-ID: tried firestarter yet? regards, rudolf kastl 2006/4/20, Kenneth Porter : > I'd love to see a GUI version of the iptables command line tool. This > should display the current chains in some kind of tree layout and allow one > to insert/edit/delete the live rules and save them to > /etc/sysconfig/iptables. It should accept module-specific plugins just like > the command line tool. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From che666 at gmail.com Thu Apr 20 13:13:14 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:13:14 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44427E44.7080304@fedora.pl> References: <200604160349.25854.nman64@n-man.com> <44427E44.7080304@fedora.pl> Message-ID: its about time to start an atleast basic 3d accelerated driver for nvidia cards/linux regards, Rudolf Kastl p.s. just my opinion 2006/4/16, Dawid Gajownik : > Dnia 04/16/2006 10:49 AM, U?ytkownik Patrick W. Barnes napisa?: > > Although the Fedora Project has not yet applied to participate this > > year, I suspect we are likely to do so. However, our Fedora Bounties > > list is now quite short. We need fresh ideas. > > What do you think about porting nVidia driver from BeOS? > https://bugs.freedesktop.org/show_bug.cgi?id=5190#c6 > This is just a proposition because, unfortunately, I don't have such a > skills (I can only help testing) :/ > > Regards, > Dawid > -- > > ^_* > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From James_Martin at ao.uscourts.gov Thu Apr 20 13:14:11 2006 From: James_Martin at ao.uscourts.gov (James_Martin at ao.uscourts.gov) Date: Thu, 20 Apr 2006 09:14:11 -0400 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <072B2A39CE3B74E33099F3FB@[169.254.160.111]> Message-ID: fedora-devel-list-bounces at redhat.com wrote on 04/20/2006 09:08:22 AM: > I'd love to see a GUI version of the iptables command line tool. This > should display the current chains in some kind of tree layout and allow one > to insert/edit/delete the live rules and save them to > /etc/sysconfig/iptables. It should accept module-specific plugins just like > the command line tool. Let's not re-invent the wheel (again)! Firewall builder does this already. http://www.fwbuilder.org/images/screenshot1.png James S. Martin, RHCE Contractor Administrative Office of the United States Courts Washington, DC (202) 502-2394 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From tbrinkman at sbcglobal.net Thu Apr 20 13:15:16 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Thu, 20 Apr 2006 08:15:16 -0500 Subject: yum bails on update dependency problems... In-Reply-To: References: <200604190906.44750.tbrinkman@sbcglobal.net> Message-ID: <200604200815.16123.tbrinkman@sbcglobal.net> On Wednesday 19 April 2006 15:45, Thomas M Steenholdt wrote: > Tom Brinkman wrote: > > "Yum halts if there is any dependency problem within the > > repository to be safe and doesnt perform partial updates. Use > > this script if you want that. Kindly ensure that you report any > > dependency issues to the appropriate repository bug tracker or > > post to the relevant project list if it requires more > > discussions." > > > > #!/bin/sh > > for i in `yum list updates |cut -f 1 -d " " |grep -A 500 -e > > Updated |\ grep -v -e Updated` ; do > > echo "Updating $i" > > yum -y update $i > > done > > This is acceptable for rawhide machines, where its generally more > accepteble to have slightly hack-ish things implemented... This is > hack-ish and is not the way to do this kind of thing properly. > (1) you loose updating of packages with long names(unless by > coincidence that package is pulled in as dependency for package > with shorter name) (2) yum will be run multiple times, whereof a > large number is likely to do absolutely nothing, so wasting > resources for no good reason. > > If we want this kind of thing, we need to implement it properly. > > /Thomas I suppose I agree with you. I really can't say. I'm new to FC havin come from Mandriva cooker. But I've not had problems with 'long names. The script is slower, an acts a lot like Mdv's 'urpmi --auto-select --keep' usin wget. It is offered on the Fedora Project wiki tho, http://fedoraproject.org/wiki/Tools/yum It seems to be my only work around for the mirror situation which began a few weeks ago, an was blamed on apache config changes after several people on this, or the -test list, complained that suddenly yum was quittin on "no more mirrors to try". A fix (revert to old behavior) was promised, but doesn't appear to ever have been made. -- Tom Brinkman Corpus Christi, Texas From che666 at gmail.com Thu Apr 20 13:20:57 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:20:57 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: How about bluetooth support for ppp connections in NetworkManager? actually bluetooth dongles cost like nothing (3 euros?) and enables everyone to use "cheap wireless". while wireless support has become better i still think that this would be a nice fallback for people with e.g. yet unsupported adapters or for people just trying to get wireless inet with least money to invest to have it working. regards, Rudolf Kastl 2006/4/16, Patrick W. Barnes : > Last year, after Fedora applied to participate in Google's Summer of Code > 2005, we created the FedoraBounties page on the wiki: > > http://fedoraproject.org/wiki/FedoraBounties > > This page features specific ideas for new projects that the Fedora Project > would like to see completed. Several of these ideas were selected by > students for the Summer of Code event. > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. > > Assuming we do participate in this year's event, we can expect several of the > project ideas to be selected again, so this is an excellent opportunity to > suggest long-missed projects. Students will be able to apply for this year's > event after May 1st, so there isn't much time to get your ideas listed. > > http://fedoraproject.org/wiki/SummerOfCode > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > > http://www.n-man.com/ > > Have I been helpful? Rate my assistance! > http://rate.affero.net/nman64/ > -- > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From cmadams at hiwaay.net Thu Apr 20 13:22:35 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 20 Apr 2006 08:22:35 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> Message-ID: <20060420132234.GA1404954@hiwaay.net> Once upon a time, Rudolf Kastl said: > How about bluetooth support for ppp connections in NetworkManager? How about Bluetooth security? When I turn on a mouse, Windows prompts me about accepting the connection; Linux just starts using it (and I can't even see a way to block a random mouse). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwboyer at jdub.homelinux.org Thu Apr 20 13:26:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 20 Apr 2006 08:26:56 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145493051.4749.1.camel@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> Message-ID: <20060420132656.GA9733@yoda.jdub.homelinux.org> On Wed, Apr 19, 2006 at 07:30:51PM -0500, Josh Boyer wrote: > On Thu, 2006-04-20 at 00:45 +0100, Cam wrote: > > Kristian > > > > I tried this just for fun on my ATI r300 and was surprised that it > > almost worked. I get what looks like an alpha channel (blue screen with > > shadows on it). True to the notes I can turn compositing off and > > everything is back to normal. > > I saw the same thing on my laptop with an ATI Radeon Mobility something > or other. Are there any differences between the FC5 and rawhide packages? I was working with Bill Nottingham last night, who has an identical graphics card, and his setup was working with AIGLX whereas mine wasn't. The only difference that we could see was that Bill was running rawhide, and I was running FC5. The chipset in question is an ATI r250. josh From bdwheele at indiana.edu Thu Apr 20 13:18:37 2006 From: bdwheele at indiana.edu (Brian Wheeler) Date: Thu, 20 Apr 2006 09:18:37 -0400 Subject: Google Summer of Code 2006: SMIT clone In-Reply-To: <072B2A39CE3B74E33099F3FB@[169.254.160.111]> References: <1145193778.2594.5.camel@localhost.localdomain> <072B2A39CE3B74E33099F3FB@[169.254.160.111]> Message-ID: <1145539117.17787.9.camel@wombat.dlib.indiana.edu> I'd like to see an AIX SMIT clone (or at least something in spirit). For those who haven't used it, its a text & motif based system administration tool which basically guides you through a pile of options and then runs the commands required to do the task. It has made my life tons easier when dealing with AIX, and it'd probably be a great help for newbies and it would tie all of the administrative tasks together. Here's a couple of 'screen shots' for the text-based version. Brian --------------------------------------------------------------------------- System Management Move cursor to desired item and press Enter. Software Installation and Maintenance Software License Management Devices System Storage Management (Physical & Logical Storage) Security & Users Communications Applications and Services Print Spooling Problem Determination Performance & Resource Scheduling System Environments Processes & Subsystems Applications Installation Assistant Cluster Systems Management Using SMIT (information only) F1=Help F2=Refresh F3=Cancel F8=Image F9=Shell F10=Exit Enter=Do ----------------------------------------------------------------------------- Add a Journaled File System Move cursor to desired item and press Enter. Add a Standard Journaled File System Add a Compressed Journaled File System Add a Large File Enabled Journaled File System ???????????????????????????????????????????????????????????????????????????? ? Volume Group Name ? ? ? ? Move cursor to desired item and press Enter. ? ? ? ? rootvg ? ? datavg1 ? ? datavg2 ? ? ? ? F1=Help F2=Refresh F3=Cancel ? ? F8=Image F10=Exit Enter=Do ? F1? /=Find n=Find Next ? F9???????????????????????????????????????????????????????????????????????????? -------------------------------------------------------------------------------- Add a Standard Journaled File System Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] Volume group name rootvg SIZE of file system Unit Size Megabytes + * Number of units [] # * MOUNT POINT [] Mount AUTOMATICALLY at system restart? no + PERMISSIONS read/write + Mount OPTIONS [] + Start Disk Accounting? no + Fragment Size (bytes) 4096 + Number of bytes per inode 4096 + Allocation Group Size (MBytes) 8 + F1=Help F2=Refresh F3=Cancel F4=List F5=Reset F6=Command F7=Edit F8=Image F9=Shell F10=Exit Enter=Do From che666 at gmail.com Thu Apr 20 13:36:04 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:36:04 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420132656.GA9733@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <20060420132656.GA9733@yoda.jdub.homelinux.org> Message-ID: 2006/4/20, Josh Boyer : > On Wed, Apr 19, 2006 at 07:30:51PM -0500, Josh Boyer wrote: > > On Thu, 2006-04-20 at 00:45 +0100, Cam wrote: > > > Kristian > > > > > > I tried this just for fun on my ATI r300 and was surprised that it > > > almost worked. I get what looks like an alpha channel (blue screen with > > > shadows on it). True to the notes I can turn compositing off and > > > everything is back to normal. > > > > I saw the same thing on my laptop with an ATI Radeon Mobility something > > or other. > > Are there any differences between the FC5 and rawhide packages? I was > working with Bill Nottingham last night, who has an identical graphics > card, and his setup was working with AIGLX whereas mine wasn't. The > only difference that we could see was that Bill was running rawhide, and > I was running FC5. > > The chipset in question is an ATI r250. > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > i am not surprised as aiglx also doesent work on my r250 with fc5 state. it might be working with current rawhide though. id have to test that. check the version that is shipped in fc5 and check what rawhide has (kinda xorg head) regards, Rudolf Kastl From j.w.r.degoede at hhs.nl Thu Apr 20 13:54:33 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Apr 2006 15:54:33 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: <44479299.3010907@hhs.nl> Hi all, What I would like to see is a tool which automaticly generates /etc/sensors.conf based on motherboard information from dmidecode. The idea is to identify a motherboard with dmidecode output and then look it up in a database to find the correct config. So besides the tool doing the autoconfig, we also need a tool (webbased?) to build such a databse. This system would be best not be Fedora specific, I know upstream wants a web based database with known to work sensors.conf for different motherboards. Now if this webbbased system could generate a database file for use by a autoconfig tool that would be great. I've been thinking about a system like this for a while now but unfortunatly I don't have the time to implement. I'm however willing and able to coach someone doing the work during the summer. Regards, Hans From che666 at gmail.com Thu Apr 20 13:59:38 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 15:59:38 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44479299.3010907@hhs.nl> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> Message-ID: 2006/4/20, Hans de Goede : > Hi all, > > What I would like to see is a tool which automaticly generates > /etc/sensors.conf based on motherboard information from dmidecode. > > The idea is to identify a motherboard with dmidecode output and then > look it up in a database to find the correct config. > > So besides the tool doing the autoconfig, we also need a tool > (webbased?) to build such a databse. This system would be best not be > Fedora specific, I know upstream wants a web based database with known > to work sensors.conf for different motherboards. Now if this webbbased > system could generate a database file for use by a autoconfig tool that > would be great. > > I've been thinking about a system like this for a while now but > unfortunatly I don't have the time to implement. I'm however willing and > able to coach someone doing the work during the summer. > > Regards, > > Hans Do you have something like a "design document"? atleast as raw as specifying what each component has to do? from what i understand you want a db with a webfrontend accessible to users to add their info? wouldnt the info have to be verified somehow? regards, Rudolf Kastl > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From che666 at gmail.com Thu Apr 20 14:04:56 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 16:04:56 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604160349.25854.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> Message-ID: 2006/4/16, Patrick W. Barnes : > Last year, after Fedora applied to participate in Google's Summer of Code > 2005, we created the FedoraBounties page on the wiki: > > http://fedoraproject.org/wiki/FedoraBounties > > This page features specific ideas for new projects that the Fedora Project > would like to see completed. Several of these ideas were selected by > students for the Summer of Code event. > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > Project has not yet applied to participate this year, I suspect we are likely > to do so. However, our Fedora Bounties list is now quite short. We need > fresh ideas. If there are any projects that you would like to see, please > add them to the FedoraBounties page. These can include ideas that you may > have had but don't have time to work on, problems that you have encountered > that need attention, or tools you really wish we had. > > Assuming we do participate in this year's event, we can expect several of the > project ideas to be selected again, so this is an excellent opportunity to > suggest long-missed projects. Students will be able to apply for this year's > event after May 1st, so there isn't much time to get your ideas listed. > > http://fedoraproject.org/wiki/SummerOfCode > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > > http://www.n-man.com/ > > Have I been helpful? Rate my assistance! > http://rate.affero.net/nman64/ > -- > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > Another idea would be to get webgcj plugin ready or rather the security bits in the free java implementation. this would minimize the amount of users installing the binary java packages, which dont work on x86_64 anyways (browser plugin wise) regards, Rudolf Kastl From shiva at sewingwitch.com Thu Apr 20 14:15:20 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 20 Apr 2006 07:15:20 -0700 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: References: Message-ID: <4ACD125F91AB802EF3B3EC9F@[169.254.160.111]> On Thursday, April 20, 2006 9:14 AM -0400 James_Martin at ao.uscourts.gov wrote: > Let's not re-invent the wheel (again)! > > Firewall builder does this already. I tried fwbuilder for awhile and its level of abstraction made it difficult to see what was going on at the iptables layer. From the fwbuilder FAQ: > 3.1. Is there any way to import iptables (or ipfilter, pf, ipfw or PIX) > rules to Firewall Builder? > > No, currently there is no way to import existing firewall configuration > into Firewall Builder Does fwbuilder even know how to use any of the more interesting and exotic iptables modules? Or does it only handle stuff that it can also use for the other OS's that it supports? BTW, as long as I'm in brainstorm mode, a GUI front end for the traffic shaper system (http://lartc.org/) would also be nice. Or at least initscripts to manage it. From gilboad at gmail.com Thu Apr 20 14:20:38 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 20 Apr 2006 17:20:38 +0300 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> Message-ID: <1145542838.22736.22.camel@gilboa-work-dev> On Thu, 2006-04-20 at 16:04 +0200, Rudolf Kastl wrote: > 2006/4/16, Patrick W. Barnes : > > Last year, after Fedora applied to participate in Google's Summer of Code > > 2005, we created the FedoraBounties page on the wiki: > > > > http://fedoraproject.org/wiki/FedoraBounties > > > > This page features specific ideas for new projects that the Fedora Project > > would like to see completed. Several of these ideas were selected by > > students for the Summer of Code event. > > > > Now, Google has just announced the Summer of Code 2006. Although the Fedora > > Project has not yet applied to participate this year, I suspect we are likely > > to do so. However, our Fedora Bounties list is now quite short. We need > > fresh ideas. If there are any projects that you would like to see, please > > add them to the FedoraBounties page. These can include ideas that you may > > have had but don't have time to work on, problems that you have encountered > > that need attention, or tools you really wish we had. > > > > Assuming we do participate in this year's event, we can expect several of the > > project ideas to be selected again, so this is an excellent opportunity to > > suggest long-missed projects. Students will be able to apply for this year's > > event after May 1st, so there isn't much time to get your ideas listed. > > > > http://fedoraproject.org/wiki/SummerOfCode > > > > -- > > Patrick "The N-Man" Barnes > > nman64 at n-man.com > > > > http://www.n-man.com/ > > > > Have I been helpful? Rate my assistance! > > http://rate.affero.net/nman64/ > > -- > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > Another idea would be to get webgcj plugin ready or rather the > security bits in the free java implementation. > > this would minimize the amount of users installing the binary java > packages, which dont work on x86_64 anyways (browser plugin wise) > > regards, > Rudolf Kastl > I second the above. More-ever, I'd consider putting people behind gnash (or any other open flash implementation.) Gilboa From ajackson at redhat.com Thu Apr 20 14:05:09 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 10:05:09 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420132656.GA9733@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <20060420132656.GA9733@yoda.jdub.homelinux.org> Message-ID: <44479515.4000700@redhat.com> Josh Boyer wrote: > Are there any differences between the FC5 and rawhide packages? I was > working with Bill Nottingham last night, who has an identical graphics > card, and his setup was working with AIGLX whereas mine wasn't. The > only difference that we could see was that Bill was running rawhide, and > I was running FC5. There shouldn't be, should just be a backport to FC5. I'll verify this today. - ajax From ajackson at redhat.com Thu Apr 20 14:10:58 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 10:10:58 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4446CB80.6020309@mesias.co.uk> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> Message-ID: <44479672.1040408@redhat.com> Cam wrote: > Kristian > > I tried this just for fun on my ATI r300 and was surprised that it > almost worked. I get what looks like an alpha channel (blue screen with > shadows on it). True to the notes I can turn compositing off and > everything is back to normal. I see this too on an X800, but I think it was only on amd64 kit. I'm looking into it. The weird thing is pretty much everything else about accelerated indirect works (q3 over the network, etc), just not the texture_from_pixmap extension, so it should be pretty straightforward to track down. > Is there a focus for this work (mail list, wiki page, irc meeting)? Do > you want feedback to bugzilla? This list is fine, and we're usually findable on freenode. And yes, bugzilla is always good. - ajax From notting at redhat.com Thu Apr 20 15:11:41 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 20 Apr 2006 11:11:41 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44479299.3010907@hhs.nl> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> Message-ID: <20060420151141.GA30403@devserv.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > What I would like to see is a tool which automaticly generates > /etc/sensors.conf based on motherboard information from dmidecode. > > The idea is to identify a motherboard with dmidecode output and then > look it up in a database to find the correct config. Ugh. Why not fix the sensors infrastructure so the kernel exports IDs in a sane framework so they can be autoloaded like any other system? Bill From sfolkwil at redhat.com Thu Apr 20 15:17:16 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Thu, 20 Apr 2006 11:17:16 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: <20060420151715.GR11508@xander.rdu.redhat.com> On Wed, Apr 19, 2006 at 04:00:48PM -0400, Kristian H?gsberg wrote: > feature. Set the environment variable USE_WOBBLY to 1 and restart > metacity. For example: > > $ USE_WOBBLY=1 metacity --replace & > > - metacity also has an experimental screen magnifier built in. Like > the wobbly windows this is enabled by setting an environment variable - > USE_MAGNIFIER: > > $ USE_MAGNIFIER=1 metacity --replace & Hi, this is what I get when I execute either of the above commands. This is on a t42 with a ATI mobility 7500, with the livna kmod package installed. Any hints or tips much appreciated: [root at localhost ~]# /usr/share/themes/Clearlooks-gOrangeous/gtk-2.0/gtkrc:3: Unable to find include file: "icons/iconrc" depth: 24 type: _NET_WM_WINDOW_TYPE_DESKTOP type: _NET_WM_WINDOW_TYPE_DESKTOP type: _NET_WM_WINDOW_TYPE_DOCK type: _NET_WM_WINDOW_TYPE_DOCK type: _NET_WM_WINDOW_TYPE_DOCK type: _NET_WM_WINDOW_TYPE_DOCK metacity: symbol lookup error: metacity: undefined symbol: glXBindTexImageEXT [1]+ Exit 127 USE_WOBBLY=1 metacity --replace > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 20 15:20:33 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 20 Apr 2006 17:20:33 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <44479672.1040408@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> Message-ID: <20060420172033.1c1eb2c4@python2> Adam Jackson wrote : > > I tried this just for fun on my ATI r300 and was surprised that it > > almost worked. I get what looks like an alpha channel (blue screen with > > shadows on it). True to the notes I can turn compositing off and > > everything is back to normal. > > I see this too on an X800, but I think it was only on amd64 kit. I'm > looking into it. The weird thing is pretty much everything else about > accelerated indirect works (q3 over the network, etc), just not the > texture_from_pixmap extension, so it should be pretty straightforward to > track down. I'd love to test this too, but it would be with an RV350 (Mobility Radeon 9600 M10)... what are my chances to have accelerated 3D working if I switch to rawhide? Just curious to know if it's even worth thinking about trying or not. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2080_FC5 Load : 0.87 1.02 0.73 From ajackson at redhat.com Thu Apr 20 14:32:36 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 10:32:36 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420172033.1c1eb2c4@python2> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> Message-ID: <44479B84.5050900@redhat.com> Matthias Saou wrote: > Adam Jackson wrote : > >>> I tried this just for fun on my ATI r300 and was surprised that it >>> almost worked. I get what looks like an alpha channel (blue screen with >>> shadows on it). True to the notes I can turn compositing off and >>> everything is back to normal. >> I see this too on an X800, but I think it was only on amd64 kit. I'm >> looking into it. The weird thing is pretty much everything else about >> accelerated indirect works (q3 over the network, etc), just not the >> texture_from_pixmap extension, so it should be pretty straightforward to >> track down. > > I'd love to test this too, but it would be with an RV350 (Mobility Radeon > 9600 M10)... what are my chances to have accelerated 3D working if I switch to rawhide? Just curious to know if it's even worth thinking about trying or not. Rawhide should have DRI enabled for all R300 and R400 series cards, with the caveat that PCIE cards are busted until hopefully the end of the day (need to backport some stuff from Mesa head). Of course, that's just whether it's enabled, not whether it works. But the M10 stands a pretty good chance. - ajax From pemboa at gmail.com Thu Apr 20 15:34:27 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 10:34:27 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145534949.18551.82.camel@sundaram.pnq.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> Message-ID: <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> On 4/20/06, Rahul Sundaram wrote: > On Wed, 2006-04-19 at 17:46 -0500, Arthur Pemberton wrote: > > > > > > > A GUI utility which helps newbies get information that may be useful > > in helping them get answers on irc, forums, mailing lists etc, might > > be helpful. > > > > Things like the output of: > > uname -a > > cat /proc/cpuinfo > > lsmod > > lspci > > lsusb > > tail /var/log/messages > > du -h > > free -h > > > > Or other info such: > > current desktop environment > > current login manager > > Sounds like a wrapper for sysreport which is available in Fedora too. > Would be quite useful for the less technically inclined users. > > http://kbase.redhat.com/faq/FAQ_80_456.shtm > > Rahul > Sweet, didn't even know about that tool. Seems like something which should be a lot more visible. -- As a boy I jumped through Windows, as a man I play with Penguins. From andre.nogueira.fedora at gmail.com Thu Apr 20 15:41:26 2006 From: andre.nogueira.fedora at gmail.com (Andre Nogueira) Date: Thu, 20 Apr 2006 16:41:26 +0100 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> Message-ID: <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> Hi, How about improvements to Anaconda? Here are a few things... 1) If you install from FTP or HTTP, you can only download from one mirror. Why not ask the user if (s)he wants to add more mirrors, so several packages can be downloaded at the same time, from different mirrors (thus increasing download speed). It would also be useful if, for some reason, one mirror has a corrupted package. 2) When Anaconda is installing a package, it is not downloading the next package. Why not continue downloading packages while installing downloaded packages? 3) When Anaconda starts, ask the user if (s)he has a kickstart configuration file on a pen drive or remote FTP/HTTP location (s)he'd like to use. This would make kickstart files much more user friendly. I tried browsing through Bugzilla to see if any of these had already been suggested, and didn't find anything. However, I'm new to helping Fedora, so forgive me if I simply didn't search correctly... Thanks, Andre On 4/20/06, Arthur Pemberton wrote: > > On 4/20/06, Rahul Sundaram wrote: > > On Wed, 2006-04-19 at 17:46 -0500, Arthur Pemberton wrote: > > > > > > > > > > A GUI utility which helps newbies get information that may be useful > > > in helping them get answers on irc, forums, mailing lists etc, might > > > be helpful. > > > > > > Things like the output of: > > > uname -a > > > cat /proc/cpuinfo > > > lsmod > > > lspci > > > lsusb > > > tail /var/log/messages > > > du -h > > > free -h > > > > > > Or other info such: > > > current desktop environment > > > current login manager > > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > Would be quite useful for the less technically inclined users. > > > > http://kbase.redhat.com/faq/FAQ_80_456.shtm > > > > Rahul > > > > Sweet, didn't even know about that tool. Seems like something which > should be a lot more visible. > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > > -- > 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 pemboa at gmail.com Thu Apr 20 15:49:59 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 10:49:59 -0500 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <072B2A39CE3B74E33099F3FB@169.254.160.111> References: <1145193778.2594.5.camel@localhost.localdomain> <072B2A39CE3B74E33099F3FB@169.254.160.111> Message-ID: <16de708d0604200849x3a96b61bh3134a811ad112e6@mail.gmail.com> On 4/20/06, Kenneth Porter wrote: > I'd love to see a GUI version of the iptables command line tool. This > should display the current chains in some kind of tree layout and allow one > to insert/edit/delete the live rules and save them to > /etc/sysconfig/iptables. It should accept module-specific plugins just like > the command line tool. As has been already said, there are dozens of firewal GUI's around, mayber extending, and making one standard in FC would be better. I hear firestarter is good. -- As a boy I jumped through Windows, as a man I play with Penguins. From pemboa at gmail.com Thu Apr 20 15:52:30 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 10:52:30 -0500 Subject: /usr/sbin/sys-unconfig --help Message-ID: <16de708d0604200852i73267b51x98bce08631e34e67@mail.gmail.com> I really don't think `/usr/sbin/sys-unconfig --help` should halt and deconfigure a machine without warning. I guessing doing `man sys-unconfig` would have been helpful, but still. This behavior seems to happen as early as RH8 and as late as FC5. -- As a boy I jumped through Windows, as a man I play with Penguins. From mitr at volny.cz Thu Apr 20 16:05:18 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 20 Apr 2006 18:05:18 +0200 Subject: /usr/sbin/sys-unconfig --help In-Reply-To: <16de708d0604200852i73267b51x98bce08631e34e67@mail.gmail.com> References: <16de708d0604200852i73267b51x98bce08631e34e67@mail.gmail.com> Message-ID: <4447B13E.2020400@volny.cz> Arthur Pemberton napsal(a): > I really don't think `/usr/sbin/sys-unconfig --help` should halt and > deconfigure a machine without warning. I guessing doing `man > sys-unconfig` would have been helpful, but still. This behavior seems > to happen as early as RH8 and as late as FC5. Please file a bug at bugzilla.redhat.com against initscripts. Mirek From jwboyer at jdub.homelinux.org Thu Apr 20 16:06:12 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 20 Apr 2006 11:06:12 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <44479515.4000700@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <20060420132656.GA9733@yoda.jdub.homelinux.org> <44479515.4000700@redhat.com> Message-ID: <20060420160612.GA10005@yoda.jdub.homelinux.org> On Thu, Apr 20, 2006 at 10:05:09AM -0400, Adam Jackson wrote: > Josh Boyer wrote: > > >Are there any differences between the FC5 and rawhide packages? I was > >working with Bill Nottingham last night, who has an identical graphics > >card, and his setup was working with AIGLX whereas mine wasn't. The > >only difference that we could see was that Bill was running rawhide, and > >I was running FC5. > > There shouldn't be, should just be a backport to FC5. I'll verify this > today. That would be great. If there's no major differences in the aiglx packages, could the difference in kernel versions between FC5 and rawhide have something to do with it? That was asked on IRC, and graphics stuff is a black box to me so I have no idea. josh From pemboa at gmail.com Thu Apr 20 16:07:54 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 11:07:54 -0500 Subject: /usr/sbin/sys-unconfig --help In-Reply-To: <4447B13E.2020400@volny.cz> References: <16de708d0604200852i73267b51x98bce08631e34e67@mail.gmail.com> <4447B13E.2020400@volny.cz> Message-ID: <16de708d0604200907j28f95e1ci84e86224c8eb0899@mail.gmail.com> On 4/20/06, Miloslav Trmac wrote: > Arthur Pemberton napsal(a): > > I really don't think `/usr/sbin/sys-unconfig --help` should halt and > > deconfigure a machine without warning. I guessing doing `man > > sys-unconfig` would have been helpful, but still. This behavior seems > > to happen as early as RH8 and as late as FC5. > Please file a bug at bugzilla.redhat.com against initscripts. > Mirek > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Will do now. -- As a boy I jumped through Windows, as a man I play with Penguins. From pemboa at gmail.com Thu Apr 20 16:16:32 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 11:16:32 -0500 Subject: /usr/sbin/sys-unconfig --help In-Reply-To: <4447B13E.2020400@volny.cz> References: <16de708d0604200852i73267b51x98bce08631e34e67@mail.gmail.com> <4447B13E.2020400@volny.cz> Message-ID: <16de708d0604200916q648acca2ib386a97b3bcdee3d@mail.gmail.com> On 4/20/06, Miloslav Trmac wrote: > Arthur Pemberton napsal(a): > > I really don't think `/usr/sbin/sys-unconfig --help` should halt and > > deconfigure a machine without warning. I guessing doing `man > > sys-unconfig` would have been helpful, but still. This behavior seems > > to happen as early as RH8 and as late as FC5. > Please file a bug at bugzilla.redhat.com against initscripts. > Mirek > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189501 -- As a boy I jumped through Windows, as a man I play with Penguins. From avibrazil at gmail.com Thu Apr 20 16:26:53 2006 From: avibrazil at gmail.com (Avi Alkalay) Date: Thu, 20 Apr 2006 13:26:53 -0300 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> Message-ID: >From the Bounties page: ----------------------- System G-Conf (or other configuration) backend Currently, NetworkManager relies on talking to the session GConf daemon for configuration. With some of these other interface types, a configuration store is needed that would be available even when no user session is initialized. ----------------------- I'd like to propose Elektra as this other system-wide configuration backend. GConf, in its essence, was not designed to be system wide. It actually has too much dependencies for that. More info here: http://www.libelektra.org/ http://www.libelektra.org/GConf Regards, Avi From j.w.r.degoede at hhs.nl Thu Apr 20 16:42:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Apr 2006 18:42:57 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <20060420151141.GA30403@devserv.devel.redhat.com> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> <20060420151141.GA30403@devserv.devel.redhat.com> Message-ID: <4447BA11.7010903@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> What I would like to see is a tool which automaticly generates >> /etc/sensors.conf based on motherboard information from dmidecode. >> >> The idea is to identify a motherboard with dmidecode output and then >> look it up in a database to find the correct config. > > Ugh. Why not fix the sensors infrastructure so the kernel exports > IDs in a sane framework so they can be autoloaded like any other > system? > Because sensors are not plug and play, unfortunatly they are not plug and play at all. They are either on an i2c bus which doesn't do plug and play or on the isa bus without isapnp support, so there is no way to automagicly find which sensor chips there are, even if you manage to find out which sensor chips there are, there is no way to find out whioch voltage / temp / fan is connected to which input, and if they are divided (using resistors) before being connected. Luckily they are however usually soldered onto the motherboard, so which chips there are and how they are hooked up is fixed for a given motherboard. Hence the idea to use a database with this info per (known) motherboard and a tool which uses this database to generate the correct configuration. In essence this is like the foomagic / ppd database for printers, but then very different :) What I'm trying to say is here is we've done this (the database solution) for printers so why not for sensors? I think it would be a cool feature if we could autoconfig sensors on the most used motherboards (if only because MS doesn't :). Regards, Hans From j.w.r.degoede at hhs.nl Thu Apr 20 16:44:29 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Apr 2006 18:44:29 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> Message-ID: <4447BA6D.8050405@hhs.nl> Rudolf Kastl wrote: > 2006/4/20, Hans de Goede : >> Hi all, >> >> What I would like to see is a tool which automaticly generates >> /etc/sensors.conf based on motherboard information from dmidecode. >> >> The idea is to identify a motherboard with dmidecode output and then >> look it up in a database to find the correct config. >> >> So besides the tool doing the autoconfig, we also need a tool >> (webbased?) to build such a databse. This system would be best not be >> Fedora specific, I know upstream wants a web based database with known >> to work sensors.conf for different motherboards. Now if this webbbased >> system could generate a database file for use by a autoconfig tool that >> would be great. >> >> I've been thinking about a system like this for a while now but >> unfortunatly I don't have the time to implement. I'm however willing and >> able to coach someone doing the work during the summer. >> >> Regards, >> >> Hans > > Do you have something like a "design document"? atleast as raw as > specifying what each component has to do? > In my head, yes on paper, no. But if there is serious interest in this I'm more then willing to produce such a document. > from what i understand you want a db with a webfrontend accessible to > users to add their info? wouldnt the info have to be verified somehow? > Preferably yes, maybe with a voting system or something, anyone know how linuxprinting does this? Regards, Hans From notting at redhat.com Thu Apr 20 16:51:59 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 20 Apr 2006 12:51:59 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4447BA11.7010903@hhs.nl> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> <20060420151141.GA30403@devserv.devel.redhat.com> <4447BA11.7010903@hhs.nl> Message-ID: <20060420165159.GB14128@devserv.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Because sensors are not plug and play, unfortunatly they are not plug > and play at all. They are either on an i2c bus which doesn't do plug and > play or on the isa bus without isapnp support, so there is no way to > automagicly find which sensor chips there are, even if you manage to > find out which sensor chips there are, there is no way to find out > whioch voltage / temp / fan is connected to which input, and if they are > divided (using resistors) before being connected. > > Luckily they are however usually soldered onto the motherboard, so which > chips there are and how they are hooked up is fixed for a given > motherboard. Hence the idea to use a database with this info per (known) > motherboard and a tool which uses this database to generate the correct > configuration. I'm somewhat talking out of my ass here, but: Then, have platform devices that export DMI info, and add the proper DMI aliases mbASUSPXV (or whatever) so the modules can be autoloaded. Bill From ajackson at redhat.com Thu Apr 20 15:55:14 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 11:55:14 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420160612.GA10005@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <20060420132656.GA9733@yoda.jdub.homelinux.org> <44479515.4000700@redhat.com> <20060420160612.GA10005@yoda.jdub.homelinux.org> Message-ID: <4447AEE2.2050505@redhat.com> Josh Boyer wrote: > If there's no major differences in the aiglx packages, could the difference > in kernel versions between FC5 and rawhide have something to do with it? > That was asked on IRC, and graphics stuff is a black box to me so I have > no idea. Possible. The major components that would matter would be fbdev, drm, and agpgart, and I don't think any of those have had significant changes since FC5. - ajax From j.w.r.degoede at hhs.nl Thu Apr 20 17:02:39 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Apr 2006 19:02:39 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <20060420165159.GB14128@devserv.devel.redhat.com> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> <20060420151141.GA30403@devserv.devel.redhat.com> <4447BA11.7010903@hhs.nl> <20060420165159.GB14128@devserv.devel.redhat.com> Message-ID: <4447BEAF.2000707@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> Because sensors are not plug and play, unfortunatly they are not plug >> and play at all. They are either on an i2c bus which doesn't do plug and >> play or on the isa bus without isapnp support, so there is no way to >> automagicly find which sensor chips there are, even if you manage to >> find out which sensor chips there are, there is no way to find out >> whioch voltage / temp / fan is connected to which input, and if they are >> divided (using resistors) before being connected. >> >> Luckily they are however usually soldered onto the motherboard, so which >> chips there are and how they are hooked up is fixed for a given >> motherboard. Hence the idea to use a database with this info per (known) >> motherboard and a tool which uses this database to generate the correct >> configuration. > > I'm somewhat talking out of my ass here, but: > Then, have platform devices that export DMI info, and add the proper > DMI aliases mbASUSPXV (or whatever) so the modules can be autoloaded. > I don't know enough about the current udev module autoloading stuff to really comment on this, but yes a platform driver could be written which would generate some kinda fake plug and play message sending a unique mb identification to udev, and then udev could look this up in a database and load the proper drivers. We would then however still need a (udev helper?) script that generates a correct /etc/sensors.conf, which contains the input pins -> measured items and their scales. But the biggest problem is building the still needed database, the exact implementation of the tool is IMHO a lesser problem, I'm sure we can work this out. If your above idea is doable it might actually be a nice clean way for the autoconfig tool part. Regards, Hans From dragoran at feuerpokemon.de Thu Apr 20 17:12:24 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 20 Apr 2006 19:12:24 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: <4447C0F8.6060305@feuerpokemon.de> Kristian H?gsberg wrote: > Hi, > > I've set up a yum repository with AIGLX packages for FC5. It's on > download.fedora.redhat.com: > > http://download.fedora.redhat.com/pub/fedora/projects/aiglx > > and there's a aiglx.repo file there that can be dropped into > /etc/yum.repos.d. With that, > > $ yum --enablerepo=aiglx update > > should pull down the AIGLX package set. The packages are just the > rawhide RPMs rebuilt for FC5, so they're a little rough around the > edges. That said, if the metacity compositor isn't enabled (see > below), things should be pretty stable. > > Here's an overview of the features and tweakable settings in the > current versions of the repository packages. Since rawhide has the > same packages the instructions below can also be used with a recent > rawhide system: > > - metacity with compositing manager functionality. Turn it on using > gconf-editor by enabling /apps/metacity/general/compositing_manager or > alternatively, use > > $ gconftool-2 -s /apps/metacity/general/compositing_manager --type > bool true > > - the metacity build in the repo has wobbly windows as an optional > feature. Set the environment variable USE_WOBBLY to 1 and restart > metacity. For example: > > $ USE_WOBBLY=1 metacity --replace & > > - metacity also has an experimental screen magnifier built in. Like > the wobbly windows this is enabled by setting an environment variable > - USE_MAGNIFIER: > > $ USE_MAGNIFIER=1 metacity --replace & > > - real translucency in gnome-terminal. Enable this by clicking the > "Transparent background" radio box in the "Effects" tab of the termnal > profile editor dialog. gnome-terminal may have to be restarted for > this to take effect - pkill gnome-terminal should do the trick. > > There are a number of known bugs with these packages, so go easy on > bugzilla :). Specifically, > > - The damage events doesn't always kick in, so sometimes window > contents doesn't update properly. A workaround for this is to switch > desktop back and forth. > > - The drop shadows look weird on shaped/argb windows, for example > xeyes, the notify bubbles and well, even the rounded metacity corners. > The shadow code is due for an overhaul later, so we're not going to > patch over this issue in the short term. > > - Perfomance for in-window updates isn't always great. We're > currently doing too much work when updating textures from pixmaps. > It's still possible to optimize this further with the current setup, > and longer term the memory architecture in the X server and DRI stack > will see some changes that will allow us to optimize this further. > > Have fun, > Kristian > where are the x86_64 packages? I thought the bug was fixed. From sfolkwil at redhat.com Thu Apr 20 17:30:35 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Thu, 20 Apr 2006 13:30:35 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420151715.GR11508@xander.rdu.redhat.com> References: <444696F0.9080801@redhat.com> <20060420151715.GR11508@xander.rdu.redhat.com> Message-ID: <20060420173035.GV11508@xander.rdu.redhat.com> On Thu, Apr 20, 2006 at 11:17:16AM -0400, Sam Folk-Williams wrote: > Hi, this is what I get when I execute either of the above commands. This is on > a t42 with a ATI mobility 7500, with the livna kmod package installed. Any > hints or tips much appreciated: > > [root at localhost ~]# /usr/share/themes/Clearlooks-gOrangeous/gtk-2.0/gtkrc:3: Unable > to find include file: "icons/iconrc" > > depth: 24 > > type: _NET_WM_WINDOW_TYPE_DESKTOP > > type: _NET_WM_WINDOW_TYPE_DESKTOP > > type: _NET_WM_WINDOW_TYPE_DOCK > > type: _NET_WM_WINDOW_TYPE_DOCK > > type: _NET_WM_WINDOW_TYPE_DOCK > > type: _NET_WM_WINDOW_TYPE_DOCK > > metacity: symbol lookup error: metacity: undefined symbol: glXBindTexImageEXT > > > > [1]+ Exit 127 USE_WOBBLY=1 metacity --replace Turns out this was due to the kmod-fgrlx package -- thanks Jeremy. Now I am getting the blue screen others have mentioned. Sam > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- ? Sam Folk-Williams, RHCE ? Red Hat Global Support Services ? Phone: 919/754-4558 ? Cell: 919/943-9623 ? Fax: 919/754-3708 ? GPG ID: 1B0D46BA From jeff at ocjtech.us Thu Apr 20 17:35:25 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 20 Apr 2006 12:35:25 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420172033.1c1eb2c4@python2> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> Message-ID: <1145554525.2630.8.camel@lt16585.campus.dmacc.edu> On Thu, 2006-04-20 at 17:20 +0200, Matthias Saou wrote: > Adam Jackson wrote : > > > > I tried this just for fun on my ATI r300 and was surprised that it > > > almost worked. I get what looks like an alpha channel (blue screen with > > > shadows on it). True to the notes I can turn compositing off and > > > everything is back to normal. > > > > I see this too on an X800, but I think it was only on amd64 kit. I'm > > looking into it. The weird thing is pretty much everything else about > > accelerated indirect works (q3 over the network, etc), just not the > > texture_from_pixmap extension, so it should be pretty straightforward to > > track down. > > I'd love to test this too, but it would be with an RV350 (Mobility Radeon > 9600 M10)... what are my chances to have accelerated 3D working if I switch to rawhide? Just curious to know if it's even worth thinking about trying or not. I have the same graphics chip in my laptop (Compaq nc8000) and an up-to-date rawhide install and I get the same problem described above. 3D acceleration seems to be working otherwise (I get OK performance out of ppracer). Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 20 17:36:42 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 20 Apr 2006 19:36:42 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <44479B84.5050900@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> Message-ID: <20060420193642.7a8a7637@python2> Adam Jackson wrote : > Rawhide should have DRI enabled for all R300 and R400 series cards, with > the caveat that PCIE cards are busted until hopefully the end of the day > (need to backport some stuff from Mesa head). > > Of course, that's just whether it's enabled, not whether it works. But > the M10 stands a pretty good chance. I've updated to Rawhide + AIGLX specific packages... which might have not been needed if they're just backports from Rawhide. Too late now, though. After a reboot, X works fine and the logs indicate that I have DRI/DRM enabled, wow! glxgears gives me 1200 fps... but I have no idea what results I should expect, and forgot to run it before the upgrade to be able to compare. I've tried enabling compositing_manager in metacity and restarting it, but then got : Window manager warning: Log level 16: Disabling compositor since the server is missing at least one of the COMPOSITE, DAMAGE, FIXES or TEST extensions Which is strange since my X log seems to indicate that all those extensions are present (although FIXES and TEST are called XFIXES and XTEST)... I'm missing something, but I'm not sure what :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.06 0.38 0.28 From krh at redhat.com Thu Apr 20 17:36:23 2006 From: krh at redhat.com (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=) Date: Thu, 20 Apr 2006 13:36:23 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4447C0F8.6060305@feuerpokemon.de> References: <444696F0.9080801@redhat.com> <4447C0F8.6060305@feuerpokemon.de> Message-ID: <4447C697.4060703@redhat.com> dragoran wrote: > Kristian H?gsberg wrote: >> Hi, >> >> I've set up a yum repository with AIGLX packages for FC5. It's on >> download.fedora.redhat.com: ... > where are the x86_64 packages? I thought the bug was fixed. They should be up soon, but the X server was crashing consistently for me on x86_64 when I tested it, so I didn't want to push that just yet. Kristian From ajackson at redhat.com Thu Apr 20 16:41:52 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 12:41:52 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420193642.7a8a7637@python2> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> Message-ID: <4447B9D0.4020108@redhat.com> Matthias Saou wrote: > I've tried enabling compositing_manager in metacity and restarting it, but > then got : > > Window manager warning: Log level 16: Disabling compositor since the > server is missing at least one of the COMPOSITE, DAMAGE, FIXES or TEST > extensions > > Which is strange since my X log seems to indicate that all those > extensions are present (although FIXES and TEST are called XFIXES and > XTEST)... The log _always_ claims to "initialize" the Composite extension, which is broken. If you just see the message: (II) Initializing built-in extension COMPOSITE then that just means your server was built with Composite support. If you also see the message: (**) Extension "Composite" is enabled then you really do have Composite enabled. If you don't, you need to turn it on in your xorg.conf: Section "Extensions" Option "Composite" EndSection - ajax From hughsient at gmail.com Thu Apr 20 17:43:41 2006 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 20 Apr 2006 18:43:41 +0100 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420173035.GV11508@xander.rdu.redhat.com> References: <444696F0.9080801@redhat.com> <20060420151715.GR11508@xander.rdu.redhat.com> <20060420173035.GV11508@xander.rdu.redhat.com> Message-ID: <1145555021.2604.22.camel@localhost.localdomain> On Thu, 2006-04-20 at 13:30 -0400, Sam Folk-Williams wrote: > Turns out this was due to the kmod-fgrlx package -- thanks Jeremy. Now > I am getting the blue screen others have mentioned. BSOD: Blue screen of death on Linux... that's made my day :-) Richard. From katzj at redhat.com Thu Apr 20 17:47:56 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Apr 2006 13:47:56 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4447B9D0.4020108@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> Message-ID: <1145555276.26605.66.camel@orodruin.boston.redhat.com> On Thu, 2006-04-20 at 12:41 -0400, Adam Jackson wrote: > Matthias Saou wrote: > then you really do have Composite enabled. If you don't, you need to > turn it on in your xorg.conf: Wouldn't it make sense to start enabling this by default at this point? What's the downside of doing so? Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 20 17:48:37 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 20 Apr 2006 19:48:37 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4447B9D0.4020108@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> Message-ID: <20060420194837.1bb8e834@python2> Adam Jackson wrote : > The log _always_ claims to "initialize" the Composite extension, which > is broken. If you just see the message: > > (II) Initializing built-in extension COMPOSITE > > then that just means your server was built with Composite support. If > you also see the message: > > (**) Extension "Composite" is enabled > > then you really do have Composite enabled. If you don't, you need to > turn it on in your xorg.conf: > > Section "Extensions" > Option "Composite" > EndSection This is what I was missing! Now I get a nice blue background, a blue panel, a blue gkrellm... and some blue shades to go with them. Seems like I got to the same point as all the others now :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2141_FC6 Load : 0.31 0.43 0.36 From dragoran at feuerpokemon.de Thu Apr 20 17:48:56 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 20 Apr 2006 19:48:56 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145555021.2604.22.camel@localhost.localdomain> References: <444696F0.9080801@redhat.com> <20060420151715.GR11508@xander.rdu.redhat.com> <20060420173035.GV11508@xander.rdu.redhat.com> <1145555021.2604.22.camel@localhost.localdomain> Message-ID: <4447C988.5020909@feuerpokemon.de> Richard Hughes wrote: > On Thu, 2006-04-20 at 13:30 -0400, Sam Folk-Williams wrote: > >> Turns out this was due to the kmod-fgrlx package -- thanks Jeremy. Now >> I am getting the blue screen others have mentioned. >> > > BSOD: Blue screen of death on Linux... that's made my day :-) > > Richard. > > was one of the features that many people missed when they changed from windows ;) From dragoran at feuerpokemon.de Thu Apr 20 17:50:59 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 20 Apr 2006 19:50:59 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145555276.26605.66.camel@orodruin.boston.redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> Message-ID: <4447CA03.8010007@feuerpokemon.de> Jeremy Katz wrote: > On Thu, 2006-04-20 at 12:41 -0400, Adam Jackson wrote: > >> Matthias Saou wrote: >> then you really do have Composite enabled. If you don't, you need to >> turn it on in your xorg.conf: >> > > Wouldn't it make sense to start enabling this by default at this point? > What's the downside of doing so? > > Jeremy > > as long as the composite manager is disabled it should'nt make any differnce... From ajackson at redhat.com Thu Apr 20 16:52:23 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 12:52:23 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145555276.26605.66.camel@orodruin.boston.redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> Message-ID: <4447BC47.7090806@redhat.com> Jeremy Katz wrote: > Wouldn't it make sense to start enabling this by default at this point? No. Otherwise I'd have just done it upstream. > What's the downside of doing so? You break Xinerama. And GLX and Xv redirection still don't work yet, which is sort of a bad thing. - ajax From che666 at gmail.com Thu Apr 20 17:56:17 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 19:56:17 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> Message-ID: 2006/4/20, Andre Nogueira : > > Hi, > > How about improvements to Anaconda? > > Here are a few things... > > 1) If you install from FTP or HTTP, you can only download from one mirror. > Why not ask the user if (s)he wants to add more mirrors, so several packages > can be downloaded at the same time, from different mirrors (thus increasing > download speed). It would also be useful if, for some reason, one mirror has > a corrupted package. why not just use the yum mirrorlist feature instead? 0 configuration then. especially if used in conjunction with the fastestmirror plugin it would be nice. > > 2) When Anaconda is installing a package, it is not downloading the next > package. Why not continue downloading packages while installing downloaded > packages? > > 3) When Anaconda starts, ask the user if (s)he has a kickstart configuration > file on a pen drive or remote FTP/HTTP location (s)he'd like to use. This > would make kickstart files much more user friendly. > > I tried browsing through Bugzilla to see if any of these had already been > suggested, and didn't find anything. However, I'm new to helping Fedora, so > forgive me if I simply didn't search correctly... > > Thanks, > > Andre > > > On 4/20/06, Arthur Pemberton wrote: > > On 4/20/06, Rahul Sundaram wrote: > > > On Wed, 2006-04-19 at 17:46 -0500, Arthur Pemberton wrote: > > > > > > > > > > > > > A GUI utility which helps newbies get information that may be useful > > > > in helping them get answers on irc, forums, mailing lists etc, might > > > > be helpful. > > > > > > > > Things like the output of: > > > > uname -a > > > > cat /proc/cpuinfo > > > > lsmod > > > > lspci > > > > lsusb > > > > tail /var/log/messages > > > > du -h > > > > free -h > > > > > > > > Or other info such: > > > > current desktop environment > > > > current login manager > > > > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > > Would be quite useful for the less technically inclined users. > > > > > > http://kbase.redhat.com/faq/FAQ_80_456.shtm > > > > > > Rahul > > > > > > > Sweet, didn't even know about that tool. Seems like something which > > should be a lot more visible. > > > > -- > > As a boy I jumped through Windows, as a man I play with Penguins. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From notting at redhat.com Thu Apr 20 17:58:48 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 20 Apr 2006 13:58:48 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <4447BC47.7090806@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> <4447BC47.7090806@redhat.com> Message-ID: <20060420175848.GF14128@devserv.devel.redhat.com> Adam Jackson (ajackson at redhat.com) said: > Jeremy Katz wrote: > > >Wouldn't it make sense to start enabling this by default at this point? > > No. Otherwise I'd have just done it upstream. > > >What's the downside of doing so? > > You break Xinerama. And GLX and Xv redirection still don't work yet, > which is sort of a bad thing. So it's the compositing extension that breaks Xinerama/GLX/Xv, not the presence of a CM? Bill From alan at clueserver.org Thu Apr 20 18:01:31 2006 From: alan at clueserver.org (alan) Date: Thu, 20 Apr 2006 11:01:31 -0700 (PDT) Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420160612.GA10005@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <20060420132656.GA9733@yoda.jdub.homelinux.org> <44479515.4000700@redhat.com> <20060420160612.GA10005@yoda.jdub.homelinux.org> Message-ID: On Thu, 20 Apr 2006, Josh Boyer wrote: > On Thu, Apr 20, 2006 at 10:05:09AM -0400, Adam Jackson wrote: >> Josh Boyer wrote: >> >>> Are there any differences between the FC5 and rawhide packages? I was >>> working with Bill Nottingham last night, who has an identical graphics >>> card, and his setup was working with AIGLX whereas mine wasn't. The >>> only difference that we could see was that Bill was running rawhide, and >>> I was running FC5. >> >> There shouldn't be, should just be a backport to FC5. I'll verify this >> today. > > That would be great. > > If there's no major differences in the aiglx packages, could the difference > in kernel versions between FC5 and rawhide have something to do with it? > That was asked on IRC, and graphics stuff is a black box to me so I have > no idea. Would it be also possible (assuming that it works) of getting x86_64 packages for AIGLX? I don't want to have to move everything on my laptop to rawhide quite yet. -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From che666 at gmail.com Thu Apr 20 18:16:17 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 20 Apr 2006 20:16:17 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4447BA6D.8050405@hhs.nl> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> <4447BA6D.8050405@hhs.nl> Message-ID: 2006/4/20, Hans de Goede : > Rudolf Kastl wrote: > > 2006/4/20, Hans de Goede : > >> Hi all, > >> > >> What I would like to see is a tool which automaticly generates > >> /etc/sensors.conf based on motherboard information from dmidecode. > >> > >> The idea is to identify a motherboard with dmidecode output and then > >> look it up in a database to find the correct config. > >> > >> So besides the tool doing the autoconfig, we also need a tool > >> (webbased?) to build such a databse. This system would be best not be > >> Fedora specific, I know upstream wants a web based database with known > >> to work sensors.conf for different motherboards. Now if this webbbased > >> system could generate a database file for use by a autoconfig tool that > >> would be great. > >> > >> I've been thinking about a system like this for a while now but > >> unfortunatly I don't have the time to implement. I'm however willing and > >> able to coach someone doing the work during the summer. > >> > >> Regards, > >> > >> Hans > > > > Do you have something like a "design document"? atleast as raw as > > specifying what each component has to do? > > > > In my head, yes on paper, no. But if there is serious interest in this > I'm more then willing to produce such a document. or maybe starting wiki pages for the "good" ideas would help to get the general design discussed and get brainwork into "how to do it". i think this should be a first step today especially if its about collaborative development. even if no one would be implementing it at this point... collecting concepts and having a number of concepts for the ideas to pick from and then decide what to do next makes alot sense to me. If it doesent happen for fc6 it might maybe happen for fc7 unless more important or plain better ideas come up then. just my point of view. > > > from what i understand you want a db with a webfrontend accessible to > > users to add their info? wouldnt the info have to be verified somehow? > > > > Preferably yes, maybe with a voting system or something, anyone know how > linuxprinting does this? > > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From ajackson at redhat.com Thu Apr 20 18:40:13 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 20 Apr 2006 14:40:13 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060420175848.GF14128@devserv.devel.redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> <4447BC47.7090806@redhat.com> <20060420175848.GF14128@devserv.devel.redhat.com> Message-ID: <4447D58D.8060404@redhat.com> Bill Nottingham wrote: > Adam Jackson (ajackson at redhat.com) said: >> You break Xinerama. And GLX and Xv redirection still don't work yet, >> which is sort of a bad thing. > > So it's the compositing extension that breaks Xinerama/GLX/Xv, not the > presence of a CM? Xinerama + Composite does nasty things even with the compmgr off, last I checked. The other two can do weird things in some semi-corner cases (creating a window on the ARGB visual is _always_ automatically redirected even without a compmgr, which triggers some cliprect fighting when an ARGB window and a DRI window overlap) but for the most part works okay when there's no compmgr. - ajax From kevin.kofler at chello.at Thu Apr 20 19:42:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 20 Apr 2006 19:42:51 +0000 (UTC) Subject: rawhide report: 20060415 changes References: <200604150717.k3F7HokQ025766@porkchop.devel.redhat.com> Message-ID: > gdb-6.3.0.0-1.128.FC6 Why is GDB still at 6.3 even though 6.4 has been released a few months ago? I assume there to be a good reason, because I can't imagine the release has not been noticed, so it would be nice to know what that reason is. Kevin Kofler From kevinverma at gmail.com Thu Apr 20 19:45:59 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 21 Apr 2006 01:15:59 +0530 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <16de708d0604200849x3a96b61bh3134a811ad112e6@mail.gmail.com> References: <1145193778.2594.5.camel@localhost.localdomain> <072B2A39CE3B74E33099F3FB@169.254.160.111> <16de708d0604200849x3a96b61bh3134a811ad112e6@mail.gmail.com> Message-ID: I had been jotting down few of my thoughts about similar ideas. Some of the highlights were like: 1. Firewall control per interface 2. Override main system firewall 3. Connection sharing {to one or more interfaces} 4. Control for systcl parameters specific to interface 5. QoS and ToS 6. Bluetooth interface support 7. Dial-in support :-) 8. Extended dial-out controls to compare with kppp to some extent Also a new protocol support and mime extension for network connections. I have also filled a bug (enhancement) request. But my ideas are prone to flaws, and I'll welcome any of the feedback. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185839 http://linuxbite.blogspot.com/2006/03/network-plumbing-on-linux.html Cheers, Kevin On 4/20/06, Arthur Pemberton wrote: > On 4/20/06, Kenneth Porter wrote: > > I'd love to see a GUI version of the iptables command line tool. This > > should display the current chains in some kind of tree layout and allow one > > to insert/edit/delete the live rules and save them to > > /etc/sysconfig/iptables. It should accept module-specific plugins just like > > the command line tool. > > As has been already said, there are dozens of firewal GUI's around, > mayber extending, and making one standard in FC would be better. > > I hear firestarter is good. > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From kevinverma at gmail.com Thu Apr 20 19:48:29 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 21 Apr 2006 01:18:29 +0530 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: References: <1145193778.2594.5.camel@localhost.localdomain> <072B2A39CE3B74E33099F3FB@169.254.160.111> <16de708d0604200849x3a96b61bh3134a811ad112e6@mail.gmail.com> Message-ID: Note:- "protocol" as for nautilus file browser e.g: computer:/// On 4/21/06, Kevin Verma wrote: > I had been jotting down few of my thoughts about similar ideas. Some > of the highlights were like: > > 1. Firewall control per interface > 2. Override main system firewall > 3. Connection sharing {to one or more interfaces} > 4. Control for systcl parameters specific to interface > 5. QoS and ToS > 6. Bluetooth interface support > 7. Dial-in support :-) > 8. Extended dial-out controls to compare with kppp to some extent > > Also a new protocol support and mime extension for network > connections. I have also filled a bug (enhancement) request. But my > ideas are prone to flaws, and I'll welcome any of the feedback. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185839 > http://linuxbite.blogspot.com/2006/03/network-plumbing-on-linux.html > > Cheers, > Kevin > > On 4/20/06, Arthur Pemberton wrote: > > On 4/20/06, Kenneth Porter wrote: > > > I'd love to see a GUI version of the iptables command line tool. This > > > should display the current chains in some kind of tree layout and allow one > > > to insert/edit/delete the live rules and save them to > > > /etc/sysconfig/iptables. It should accept module-specific plugins just like > > > the command line tool. > > > > As has been already said, there are dozens of firewal GUI's around, > > mayber extending, and making one standard in FC would be better. > > > > I hear firestarter is good. > > > > -- > > As a boy I jumped through Windows, as a man I play with Penguins. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From notting at redhat.com Thu Apr 20 20:28:39 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 20 Apr 2006 16:28:39 -0400 Subject: [stateless] readonly-root support Message-ID: <20060420202839.GA20143@devserv.devel.redhat.com> Initial readonly root support will be in tomorrow's initscripts-8.33-1. How to use: - Edit /etc/sysconfig/readonly-root. Set 'READONLY' to 'yes'. - Add any exceptions that need to be writable that aren't in the stock /etc/rwtab to an /etc/rwtab.d file. (See below) ** NOTE: This does not currently work with SELinux. We're working on it. ** How it works: - On boot, we mount a tmpfs (by default, at /var/lib/stateless/writable), and then parse /etc/rwtab and /etc/rwtab.d/* for things to put there. These files have the format: Types are as follows: empty: An empty path. Example: 'empty /tmp' dirs: A directory tree that is copied, empty. Example: 'dirs /var/run' files: A file or directory tree that is copied intact. Example: 'files /etc/resolv.conf' A stock rwtab is shipped with common things that need mounted. We're currently investigating other things. If you come up with new ones, please file a bug. Problems should be filed in bugzilla at https://bugzilla.redhat.com/, product Fedora Core, release devel, component initscripts. Things we know need work: - a simple 'prepare' script for a filesystem that is intended to be mounted read-only - it will update various caches (beagle, locate), clean out extraneous temporary files, and build the SELinux policy module. - using local storage automatically for swap, etc. - the rest of http://fedoraproject.org/wiki/StatelessLinux :) Bill From ich at frank-schmitt.net Thu Apr 20 12:25:38 2006 From: ich at frank-schmitt.net (Frank Schmitt) Date: Thu, 20 Apr 2006 14:25:38 +0200 Subject: Fedora Bounties (seeking ideas) References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> Message-ID: Rahul Sundaram writes: > Sounds like a wrapper for sysreport which is available in Fedora too. > Would be quite useful for the less technically inclined users. Have a look at KDE's kinfocenter. -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From mark.a.allyn at intel.com Thu Apr 20 20:38:30 2006 From: mark.a.allyn at intel.com (Allyn, Mark A) Date: Thu, 20 Apr 2006 13:38:30 -0700 Subject: Alsa 1.0.11 final Message-ID: <75EC4D5486CAC247B84AAAA6F96AA55807320A39@orsmsx402.amr.corp.intel.com> Hello: What are the plans for updating the Alsa drivers in FC5 to 1.0.11rc5 or 1.0.11 final (which was released the week of April 17th)? I have a bug (189245) for the FC5 audio, which is having record problems on an Intel D945 Chipset based system. Thank you Mark Allyn From orion at cora.nwra.com Thu Apr 20 21:17:47 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 20 Apr 2006 15:17:47 -0600 Subject: Puppet Re: Kickstart and roles In-Reply-To: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> References: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > If I understood what Luke was working on with puppet, the program is > meant to be a re-engineering of cfengine to be less of an academic > testbed and more of stable product. [I might be part of the reason for > the fact it is in Ruby.. I suggested it a long time ago when Luke was > giving a training course.] > Since the puppet and facter spec files at http://reductivelabs.com/downloads/rpm/ have changelog entries like: * Tue Jan 17 2006 David Lutterkort - 0.11.0-1 - Rebuild perhaps we'll see it in Extras soon? I'd like to try it out. - Orion From florin at andrei.myip.org Thu Apr 20 21:19:55 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 20 Apr 2006 14:19:55 -0700 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: <1145567995.1199.45.camel@stantz.corp.sgi.com> Is it working with XVideo yet? If not, any workaround for Xine and MythTV? -- Florin Andrei http://florin.myip.org/ From jon.nettleton at gmail.com Thu Apr 20 21:26:08 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 20 Apr 2006 17:26:08 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145567995.1199.45.camel@stantz.corp.sgi.com> References: <444696F0.9080801@redhat.com> <1145567995.1199.45.camel@stantz.corp.sgi.com> Message-ID: <1145568368.2002.5.camel@averatec.charles.net> On Thu, 2006-04-20 at 14:19 -0700, Florin Andrei wrote: > Is it working with XVideo yet? > > If not, any workaround for Xine and MythTV? > > -- > Florin Andrei > > http://florin.myip.org/ > Why would you want to watch movies when you have all this bling? You should just sit back and be mesmerized by the wobbly windows. :-) As far as I know the problem with XVideo is based in the Composite extension. I am using OpenGL for video acceleration right now. Jon From seg at haxxed.com Thu Apr 20 21:32:23 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 20 Apr 2006 16:32:23 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145419331.10519.14.camel@minicooper> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> Message-ID: <1145568745.17779.8.camel@hamburger.booze> On Tue, 2006-04-18 at 21:02 -0700, Per Bjornsson wrote: > The "fastestmirror" yum plugin is your friend - I really think it should > be part of the default install! > yum install yum-fastestmirror It's not my friend. It seems to always pick the worst mirrors possible. It shouldn't take 5 minutes to download 100k. In particular, mirror.clarkson.edu always seems to top the list, and I can only seem to get about 300bps sustained from them... Mirrors need to be ranked by actual download rate, not whatever it is yum-fastestmirror is doing. (It appears to be simply timing how long it takes to connect()...) From vikasx.aggarwal at intel.com Thu Apr 20 22:52:55 2006 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Thu, 20 Apr 2006 15:52:55 -0700 Subject: corrupt package message during FC5 install from NFS. Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A0853B410@orsmsx408> Hi, I am trying to do install from NFS of a custom distribution which is based on FC5test3. After formatting the local drive the anaconda-installer shows message - "The package traceroute-1.0.4-1.2.i386 cannot be opened. This is due to missing file or perhaps the corrupt package. If you are installing from CD media this usually means the CD is corrupt, or the CD drive is unable to read media". I tried to check the internal checksum of each package with the -K option to rpm, based on an article from http://www.linuxjournal.com/article/6473 cd /Fedora5test3/ONE_CD/RedHat/RPMS rpm --import /usr/share/rhn/RPM-GPG-KEY rpm -K *.rpm | grep "NOT *OK" For all the packages I get " (GPG) NOT OK MISSING KEYS ". My build system is FC5. What could be wrong with my install tree? Please provide ideas about troubleshooting the above anaconda error message or otherwise why "rpm -K" will say MISSING KEYS. Thanks for help -vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Thu Apr 20 23:06:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 20 Apr 2006 19:06:47 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145568745.17779.8.camel@hamburger.booze> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> Message-ID: <1145574407.7813.1.camel@cutter> On Thu, 2006-04-20 at 16:32 -0500, Callum Lerwick wrote: > On Tue, 2006-04-18 at 21:02 -0700, Per Bjornsson wrote: > > The "fastestmirror" yum plugin is your friend - I really think it should > > be part of the default install! > > yum install yum-fastestmirror > > It's not my friend. It seems to always pick the worst mirrors possible. > It shouldn't take 5 minutes to download 100k. In particular, > mirror.clarkson.edu always seems to top the list, and I can only seem to > get about 300bps sustained from them... > > Mirrors need to be ranked by actual download rate, not whatever it is > yum-fastestmirror is doing. (It appears to be simply timing how long it > takes to connect()...) Then do so! :) You can make your own mirrorlist for your own use if you want. just put the baseurl of the sites you like in a file somewhere on your system then refer to the file in the repo section in the .repo file like this: [myrepo] name=some repo mirrorlist=file:///path/to/my/mirrorlist that's it! -sv From stickster at gmail.com Thu Apr 20 23:12:40 2006 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Apr 2006 19:12:40 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145568745.17779.8.camel@hamburger.booze> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> Message-ID: <1145574760.2559.2.camel@localhost.localdomain> On Thu, 2006-04-20 at 16:32 -0500, Callum Lerwick wrote: > On Tue, 2006-04-18 at 21:02 -0700, Per Bjornsson wrote: > > The "fastestmirror" yum plugin is your friend - I really think it should > > be part of the default install! > > yum install yum-fastestmirror > > It's not my friend. It seems to always pick the worst mirrors possible. > It shouldn't take 5 minutes to download 100k. In particular, > mirror.clarkson.edu always seems to top the list, and I can only seem to > get about 300bps sustained from them... > > Mirrors need to be ranked by actual download rate, not whatever it is > yum-fastestmirror is doing. (It appears to be simply timing how long it > takes to connect()...) This has been my experience as well, although I can't say if any one slow mirror has consistently outranked another. Often the mirror I get is in Europe and not the U.S. While that's not a problem per se, my habit is to keep traffic on the same continent when I have a choice. :-) After removing or disabling yum-fastestmirror my yum/pup/pirut experience is much more satisfactory. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From joelonlinux at optonline.net Thu Apr 20 23:15:30 2006 From: joelonlinux at optonline.net (Joel Rittvo) Date: Thu, 20 Apr 2006 19:15:30 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145508285.3228.18.camel@ignacio.lan> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <44470F20.2000602@optonline.net> <1145508285.3228.18.camel@ignacio.lan> Message-ID: <44481612.1000202@optonline.net> Ignacio Vazquez-Abrams wrote: > On Thu, 2006-04-20 at 00:33 -0400, Joel Rittvo wrote: >> Is it possible (as in: would it work) to use metacity with a KDE >> desktop, or is this fun only for a gnome desktop at this point? > > metacity is just a window manager. There's almost no reason you can't > use it in place of kwin. I renamed /usr/bin/kwin to /usr/bin/kwin-real, and then made a symlink between metacity and kwin. Everything seems to be running fine calling metacity in this roundabout way. Could someone tell me the correct way to tell KDE to use metacity instead of kwin so I can undo this kludge method, though. Thanks! Joel Rittvo From katzj at redhat.com Thu Apr 20 23:36:45 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 20 Apr 2006 19:36:45 -0400 Subject: Puppet Re: Kickstart and roles In-Reply-To: References: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> Message-ID: <1145576205.2869.4.camel@aglarond.local> On Thu, 2006-04-20 at 15:17 -0600, Orion Poplawski wrote: > Stephen John Smoogen wrote: > > If I understood what Luke was working on with puppet, the program is > > meant to be a re-engineering of cfengine to be less of an academic > > testbed and more of stable product. [I might be part of the reason for > > the fact it is in Ruby.. I suggested it a long time ago when Luke was > > giving a training course.] > > Since the puppet and facter spec files at > http://reductivelabs.com/downloads/rpm/ have changelog entries like: > > > * Tue Jan 17 2006 David Lutterkort - 0.11.0-1 > - Rebuild > > perhaps we'll see it in Extras soon? I'd like to try it out. The packages have been submitted for review[1] and are awaiting an entrepreneurial soul who's willing to review something written in ruby :-) Jeremy [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182064 From stickster at gmail.com Fri Apr 21 00:09:35 2006 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 20 Apr 2006 20:09:35 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145574407.7813.1.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> <1145574407.7813.1.camel@cutter> Message-ID: <1145578175.2559.42.camel@localhost.localdomain> On Thu, 2006-04-20 at 19:06 -0400, seth vidal wrote: > On Thu, 2006-04-20 at 16:32 -0500, Callum Lerwick wrote: > > On Tue, 2006-04-18 at 21:02 -0700, Per Bjornsson wrote: > > > The "fastestmirror" yum plugin is your friend - I really think it should > > > be part of the default install! > > > yum install yum-fastestmirror > > > > It's not my friend. It seems to always pick the worst mirrors possible. > > It shouldn't take 5 minutes to download 100k. In particular, > > mirror.clarkson.edu always seems to top the list, and I can only seem to > > get about 300bps sustained from them... > > > > Mirrors need to be ranked by actual download rate, not whatever it is > > yum-fastestmirror is doing. (It appears to be simply timing how long it > > takes to connect()...) > > Then do so! :) > > You can make your own mirrorlist for your own use if you want. > > just put the baseurl of the sites you like in a file somewhere on your > system > > then refer to the file in the repo section in the .repo file like this: > > [myrepo] > name=some repo > mirrorlist=file:///path/to/my/mirrorlist > > that's it! > -sv I did this by taking the old FC4 ".us.east" lists and (after confirmation of the repos) including them on my system. I wasn't sure that was the accepted usage, but now it seems so. I know there are probably myriad ways to accomplish this with a more user-friendly bent, but would it make sense for there to be a tool that asked the user to select a geographic region, and populated a local mirror list appropriately, using a remotely gathered list that included lat/long data? Does such a thing exist already and I'm just clueless? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nman64 at n-man.com Fri Apr 21 00:57:01 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 20 Apr 2006 19:57:01 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145578175.2559.42.camel@localhost.localdomain> References: <200604160349.25854.nman64@n-man.com> <1145574407.7813.1.camel@cutter> <1145578175.2559.42.camel@localhost.localdomain> Message-ID: <200604201957.03980.nman64@n-man.com> On Thursday 20 April 2006 19:09, "Paul W. Frields" wrote: > > I did this by taking the old FC4 ".us.east" lists and (after > confirmation of the repos) including them on my system. I wasn't sure > that was the accepted usage, but now it seems so. I know there are > probably myriad ways to accomplish this with a more user-friendly bent, > but would it make sense for there to be a tool that asked the user to > select a geographic region, and populated a local mirror list > appropriately, using a remotely gathered list that included lat/long > data? Does such a thing exist already and I'm just clueless? We've always said that the best way for someone to get the best mirrors is for them to gather a list of their preferred mirrors and set up that list in their yum configuration. This was true even before the mirrorlist option was enabled. Unfortunately, there isn't a single reliable way to automatically generate the best list for any given person at any given location. Physical proximity is rarely a good indicator of the best mirrors. As we work towards better mirror management, we'll be able to produce more reliable lists. We're hoping to enable smart redirection to disperse requests to mirrors. At the moment, download.fedoraproject.org does do redirects, but we don't yet have the ability to make those redirections at all intelligent. That would be one potential project. Bouncer is the tool we've been looking at, but it needs work before we can hope to use it. Really, just about any working solution would be welcome. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From cmadams at hiwaay.net Fri Apr 21 01:13:48 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 20 Apr 2006 20:13:48 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604201957.03980.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> <1145574407.7813.1.camel@cutter> <1145578175.2559.42.camel@localhost.localdomain> <200604201957.03980.nman64@n-man.com> Message-ID: <20060421011348.GA1314081@hiwaay.net> Once upon a time, Patrick W. Barnes said: > We've always said that the best way for someone to get the best mirrors is for > them to gather a list of their preferred mirrors and set up that list in > their yum configuration. This was true even before the mirrorlist option was > enabled. Another thing that would be nice is a way to configure this outside of the RPM-managed config files. Right now, you get .rpmsave and/or .rpmnew files on upgrades (and if you get .rpmnew files, your edited files may also now point at bogus locations). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tibbs at math.uh.edu Fri Apr 21 01:26:59 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 20 Apr 2006 20:26:59 -0500 Subject: Puppet Re: Kickstart and roles In-Reply-To: <1145576205.2869.4.camel@aglarond.local> (Jeremy Katz's message of "Thu, 20 Apr 2006 19:36:45 -0400") References: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> <1145576205.2869.4.camel@aglarond.local> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> The packages have been submitted for review[1] and are awaiting an JK> entrepreneurial soul who's willing to review something written in JK> ruby :-) The first module in the dependency chain is under review. I would have done a review, but the submitter needs a sponsor so I can't. Tagoh-san has shown willingness to fix some of the issues complicating Ruby packaging, so hopefully the process will become much simpler in the future. - J< From pemboa at gmail.com Fri Apr 21 01:29:43 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 20:29:43 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> Message-ID: <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> On 4/20/06, Frank Schmitt wrote: > Rahul Sundaram writes: > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > Would be quite useful for the less technically inclined users. > > Have a look at KDE's kinfocenter. > Unfortuantely, not many people use KDE on Fedora apperently. -- As a boy I jumped through Windows, as a man I play with Penguins. From nman64 at n-man.com Fri Apr 21 01:53:58 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 20 Apr 2006 20:53:58 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> Message-ID: <200604202054.00563.nman64@n-man.com> On Thursday 20 April 2006 20:29, "Arthur Pemberton" wrote: > On 4/20/06, Frank Schmitt wrote: > > Rahul Sundaram writes: > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > > Would be quite useful for the less technically inclined users. > > > > Have a look at KDE's kinfocenter. > > Unfortuantely, not many people use KDE on Fedora apperently. Actually, a lot of people do, including myself. The majority use GNOME either by preference or because it is the default. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From nman64 at n-man.com Fri Apr 21 01:56:29 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 20 Apr 2006 20:56:29 -0500 Subject: Google's Summer of Code (Seeking mentors) Message-ID: <200604202056.31699.nman64@n-man.com> We have officially agreed to participate in Google's Summer of Code again this year. http://fedoraproject.org/wiki/SummerOfCode If anyone on this list would like to volunteer to be a mentor, please contact the Fedora Mentors team. http://fedoraproject.org/wiki/Mentors When Google begins accepting student applications, the Fedora Project will be among the available options. http://code.google.com/soc/ -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From michael at knox.net.nz Fri Apr 21 02:02:02 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 21 Apr 2006 14:02:02 +1200 Subject: Google's Summer of Code (Seeking mentors) In-Reply-To: <200604202056.31699.nman64@n-man.com> References: <200604202056.31699.nman64@n-man.com> Message-ID: <44483D1A.1060706@knox.net.nz> Patrick W. Barnes wrote: > We have officially agreed to participate in Google's Summer of Code again this > year. > > http://fedoraproject.org/wiki/SummerOfCode > > If anyone on this list would like to volunteer to be a mentor, please contact > the Fedora Mentors team. > > http://fedoraproject.org/wiki/Mentors > > When Google begins accepting student applications, the Fedora Project will be > among the available options. > > http://code.google.com/soc/ > > What areas do you need mentors in? Michael From nman64 at n-man.com Fri Apr 21 02:10:26 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 20 Apr 2006 21:10:26 -0500 Subject: Google's Summer of Code (Seeking mentors) In-Reply-To: <44483D1A.1060706@knox.net.nz> References: <200604202056.31699.nman64@n-man.com> <44483D1A.1060706@knox.net.nz> Message-ID: <200604202110.28553.nman64@n-man.com> On Thursday 20 April 2006 21:02, "Michael J. Knox" wrote: > Patrick W. Barnes wrote: > > We have officially agreed to participate in Google's Summer of Code again > > this year. > > > > http://fedoraproject.org/wiki/SummerOfCode > > > > If anyone on this list would like to volunteer to be a mentor, please > > contact the Fedora Mentors team. > > > > http://fedoraproject.org/wiki/Mentors > > > > When Google begins accepting student applications, the Fedora Project > > will be among the available options. > > > > http://code.google.com/soc/ > > What areas do you need mentors in? > We won't know what exact projects we'll be mentoring until student applications start coming in after May 1st, but the volunteers we have will have an impact on what projects we accept. Volunteer your expertise and we'll see if a suitable project comes in for you. You'll have the opportunity to claim whatever student project ideas interest you the most. We'll be working to gather ideas on our Fedora Bounties page, so if there is a particular project you'd like to mentor for, make sure it is added to that page. http://fedoraproject.org/wiki/FedoraBounties -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From pemboa at gmail.com Fri Apr 21 02:32:14 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 20 Apr 2006 21:32:14 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604202054.00563.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> Message-ID: <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> On 4/20/06, Patrick W. Barnes wrote: > On Thursday 20 April 2006 20:29, "Arthur Pemberton" wrote: > > On 4/20/06, Frank Schmitt wrote: > > > Rahul Sundaram writes: > > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > > > Would be quite useful for the less technically inclined users. > > > > > > Have a look at KDE's kinfocenter. > > > > Unfortuantely, not many people use KDE on Fedora apperently. > > Actually, a lot of people do, including myself. The majority use GNOME either > by preference or because it is the default. > > -- Well I can take your word on that. However, it is handly encouraging when one selects all KDE apps in Anaconda-Pirut and then I boot and find gdm. And the only way to fix tha tis to manually uninstall gdm or edit /etc/X11/predm -- As a boy I jumped through Windows, as a man I play with Penguins. From mitr at volny.cz Fri Apr 21 02:42:14 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 21 Apr 2006 04:42:14 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> Message-ID: <44484686.6020301@volny.cz> Arthur Pemberton napsal(a): > Well I can take your word on that. However, it is handly encouraging > when one selects all KDE apps in Anaconda-Pirut and then I boot and > find gdm. And the only way to fix tha tis to manually uninstall gdm or > edit /etc/X11/predm It is hardly encouraging to see posts implying that KDE is intentionally crippled" on fedora-devel ;) (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) Mirek From jon.nettleton at gmail.com Fri Apr 21 02:49:47 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 20 Apr 2006 22:49:47 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44484686.6020301@volny.cz> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> <44484686.6020301@volny.cz> Message-ID: <1145587787.2002.35.camel@averatec.charles.net> On Fri, 2006-04-21 at 04:42 +0200, Miloslav Trmac wrote: > Arthur Pemberton napsal(a): > > Well I can take your word on that. However, it is handly encouraging > > when one selects all KDE apps in Anaconda-Pirut and then I boot and > > find gdm. And the only way to fix tha tis to manually uninstall gdm or > > edit /etc/X11/predm > It is hardly encouraging to see posts implying that KDE is intentionally > crippled" on fedora-devel ;) > > (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) > Mirek > I hardly think that KDE is intentionally crippled at all. If anything my guess is that it just isn't as thoroughly tested. I think this reflects more on the participation of KDE users in the testing process of the Fedora development process. I guess the only proof to that statement would be some fancy bugzilla reporting. If a bug exists for one community or the other, it isn't going to be fixed unless it is reported. Jon From nman64 at n-man.com Fri Apr 21 02:55:37 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 20 Apr 2006 21:55:37 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> Message-ID: <200604202155.39301.nman64@n-man.com> On Thursday 20 April 2006 21:32, "Arthur Pemberton" wrote: > On 4/20/06, Patrick W. Barnes wrote: > > On Thursday 20 April 2006 20:29, "Arthur Pemberton" wrote: > > > On 4/20/06, Frank Schmitt wrote: > > > > Rahul Sundaram writes: > > > > > Sounds like a wrapper for sysreport which is available in Fedora > > > > > too. Would be quite useful for the less technically inclined users. > > > > > > > > Have a look at KDE's kinfocenter. > > > > > > Unfortuantely, not many people use KDE on Fedora apperently. > > > > Actually, a lot of people do, including myself. The majority use GNOME > > either by preference or because it is the default. > > > > -- > > Well I can take your word on that. However, it is handly encouraging > when one selects all KDE apps in Anaconda-Pirut and then I boot and > find gdm. And the only way to fix tha tis to manually uninstall gdm or > edit /etc/X11/predm > You can set the preferred display manager globally in a much cleaner manner: su -c echo 'DISPLAYMANAGER="KDE"' >> /etc/sysconfig/desktop It might not be unreasonable to seek an option in firstboot to select the display manager at install time when multiple desktop environments are installed. (I suspect that's too small of a project for the SoC, though. ;-) ) -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From rodd at clarkson.id.au Fri Apr 21 03:23:12 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 21 Apr 2006 13:23:12 +1000 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145587787.2002.35.camel@averatec.charles.net> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> <44484686.6020301@volny.cz> <1145587787.2002.35.camel@averatec.charles.net> Message-ID: <1145589792.2799.4.camel@localhost.localdomain> On Thu, 2006-04-20 at 22:49 -0400, Jon Nettleton wrote: > On Fri, 2006-04-21 at 04:42 +0200, Miloslav Trmac wrote: > > Arthur Pemberton napsal(a): > > > Well I can take your word on that. However, it is handly encouraging > > > when one selects all KDE apps in Anaconda-Pirut and then I boot and > > > find gdm. And the only way to fix tha tis to manually uninstall gdm or > > > edit /etc/X11/predm > > It is hardly encouraging to see posts implying that KDE is intentionally > > crippled" on fedora-devel ;) > > > > (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) > > Mirek > > > I hardly think that KDE is intentionally crippled at all. If anything > my guess is that it just isn't as thoroughly tested. I think this > reflects more on the participation of KDE users in the testing process > of the Fedora development process. I guess the only proof to that > statement would be some fancy bugzilla reporting. If a bug exists for > one community or the other, it isn't going to be fixed unless it is > reported. One factor to consider is those that have a preference for either KDE or Gnome are likely to choose a distro that defaults to their preferred desktop. So, since Fedora defaults to Gnome, it's more likely that Gnome users will use it (which makes it a sort of self-fulfilling prophecy). I wouldn't be surprised to find that distros that default to KDE get less testing with Gnome. R. -- "It's a fine line between denial and faith. It's much better on my side" From mmcgrath at fedoraproject.org Fri Apr 21 03:25:27 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 20 Apr 2006 22:25:27 -0500 Subject: Kickstart and roles In-Reply-To: References: <3237e4410604132047r57589db2va9ed4e3307363f1c@mail.gmail.com> Message-ID: <3237e4410604202025t1881f6e8h6a75ef97994d0353@mail.gmail.com> I guess I'm less concerned with the distribution system and more concerned with providing usable secure 'configs' for end-users. Regardless of the distribution system we should really go in and show what a stable / secure system consists of whether it be a php/apache server or an SMTP virus scanning server. From jon.nettleton at gmail.com Fri Apr 21 03:38:19 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 20 Apr 2006 23:38:19 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145589792.2799.4.camel@localhost.localdomain> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> <44484686.6020301@volny.cz> <1145587787.2002.35.camel@averatec.charles.net> <1145589792.2799.4.camel@localhost.localdomain> Message-ID: <1145590700.2002.51.camel@averatec.charles.net> On Fri, 2006-04-21 at 13:23 +1000, Rodd Clarkson wrote: > On Thu, 2006-04-20 at 22:49 -0400, Jon Nettleton wrote: > > On Fri, 2006-04-21 at 04:42 +0200, Miloslav Trmac wrote: > > > Arthur Pemberton napsal(a): > > > > Well I can take your word on that. However, it is handly encouraging > > > > when one selects all KDE apps in Anaconda-Pirut and then I boot and > > > > find gdm. And the only way to fix tha tis to manually uninstall gdm or > > > > edit /etc/X11/predm > > > It is hardly encouraging to see posts implying that KDE is intentionally > > > crippled" on fedora-devel ;) > > > > > > (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) > > > Mirek > > > > > I hardly think that KDE is intentionally crippled at all. If anything > > my guess is that it just isn't as thoroughly tested. I think this > > reflects more on the participation of KDE users in the testing process > > of the Fedora development process. I guess the only proof to that > > statement would be some fancy bugzilla reporting. If a bug exists for > > one community or the other, it isn't going to be fixed unless it is > > reported. > > > One factor to consider is those that have a preference for either KDE or > Gnome are likely to choose a distro that defaults to their preferred > desktop. So, since Fedora defaults to Gnome, it's more likely that > Gnome users will use it (which makes it a sort of self-fulfilling > prophecy). > > I wouldn't be surprised to find that distros that default to KDE get > less testing with Gnome. > I completely agree that can be the case. Looking back at my statement I can see how it can be mis-construed. I didn't mean that the KDE users weren't pulling their weight in debugging. In participation I clearly meant numbers of user and bugs filed, which also might be wrong. That is why I suggested looking at bugzilla. Obviously the proper solution to this isn't to discuss the holy trinity, but for the original poster to file a bugzilla and get the issued resolved. Jon From perbj at sbcglobal.net Fri Apr 21 04:27:46 2006 From: perbj at sbcglobal.net (Per Bjornsson) Date: Thu, 20 Apr 2006 21:27:46 -0700 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145574760.2559.2.camel@localhost.localdomain> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> <1145574760.2559.2.camel@localhost.localdomain> Message-ID: <1145593667.10519.16.camel@minicooper> On Thu, 2006-04-20 at 19:12 -0400, Paul W. Frields wrote: > On Thu, 2006-04-20 at 16:32 -0500, Callum Lerwick wrote: > > Mirrors need to be ranked by actual download rate, not whatever it is > > yum-fastestmirror is doing. (It appears to be simply timing how long it > > takes to connect()...) > > This has been my experience as well, although I can't say if any one > slow mirror has consistently outranked another. Often the mirror I get > is in Europe and not the U.S. While that's not a problem per se, my > habit is to keep traffic on the same continent when I have a choice. :-) > After removing or disabling yum-fastestmirror my yum/pup/pirut > experience is much more satisfactory. Hmm, that's strange, last time I checked it seemed to ocnsistently connect me to mirrors.kernel.org which is basically around the corner for me. Maybe I've just been lucky... /Per From pemboa at gmail.com Fri Apr 21 05:55:29 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Apr 2006 00:55:29 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <44484686.6020301@volny.cz> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> <44484686.6020301@volny.cz> Message-ID: <16de708d0604202255u2e099af0nb1535e7b1c44847d@mail.gmail.com> On 4/20/06, Miloslav Trmac wrote: > Arthur Pemberton napsal(a): > > Well I can take your word on that. However, it is handly encouraging > > when one selects all KDE apps in Anaconda-Pirut and then I boot and > > find gdm. And the only way to fix tha tis to manually uninstall gdm or > > edit /etc/X11/predm > It is hardly encouraging to see posts implying that KDE is intentionally > crippled" on fedora-devel ;) > > (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) > Mirek > Oops, I meant /etc/sysconfig/desktop Should I file a bug report on this? Or is there a reason that gdm gets installed regardless of choice in desktop environtment? -- As a boy I jumped through Windows, as a man I play with Penguins. From pemboa at gmail.com Fri Apr 21 05:56:27 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Apr 2006 00:56:27 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145590700.2002.51.camel@averatec.charles.net> References: <200604160349.25854.nman64@n-man.com> <16de708d0604201829h7ce3f950xa88e14c54155d917@mail.gmail.com> <200604202054.00563.nman64@n-man.com> <16de708d0604201932r6029c05fp5f02841abace3672@mail.gmail.com> <44484686.6020301@volny.cz> <1145587787.2002.35.camel@averatec.charles.net> <1145589792.2799.4.camel@localhost.localdomain> <1145590700.2002.51.camel@averatec.charles.net> Message-ID: <16de708d0604202256y4aea70abvbe6f84b0f13b2598@mail.gmail.com> On 4/20/06, Jon Nettleton wrote: > On Fri, 2006-04-21 at 13:23 +1000, Rodd Clarkson wrote: > > On Thu, 2006-04-20 at 22:49 -0400, Jon Nettleton wrote: > > > On Fri, 2006-04-21 at 04:42 +0200, Miloslav Trmac wrote: > > > > Arthur Pemberton napsal(a): > > > > > Well I can take your word on that. However, it is handly encouraging > > > > > when one selects all KDE apps in Anaconda-Pirut and then I boot and > > > > > find gdm. And the only way to fix tha tis to manually uninstall gdm or > > > > > edit /etc/X11/predm > > > > It is hardly encouraging to see posts implying that KDE is intentionally > > > > crippled" on fedora-devel ;) > > > > > > > > (echo DISPLAYMANAGER=KDE >> /etc/sysconfig/desktop) > > > > Mirek > > > > > > > I hardly think that KDE is intentionally crippled at all. If anything > > > my guess is that it just isn't as thoroughly tested. I think this > > > reflects more on the participation of KDE users in the testing process > > > of the Fedora development process. I guess the only proof to that > > > statement would be some fancy bugzilla reporting. If a bug exists for > > > one community or the other, it isn't going to be fixed unless it is > > > reported. > > > > > > One factor to consider is those that have a preference for either KDE or > > Gnome are likely to choose a distro that defaults to their preferred > > desktop. So, since Fedora defaults to Gnome, it's more likely that > > Gnome users will use it (which makes it a sort of self-fulfilling > > prophecy). > > > > I wouldn't be surprised to find that distros that default to KDE get > > less testing with Gnome. > > > I completely agree that can be the case. Looking back at my statement I > can see how it can be mis-construed. I didn't mean that the KDE users > weren't pulling their weight in debugging. In participation I clearly > meant numbers of user and bugs filed, which also might be wrong. That > is why I suggested looking at bugzilla. Obviously the proper solution > to this isn't to discuss the holy trinity, but for the original poster > to file a bugzilla and get the issued resolved. > > Jon > Will do . . . any suggestion on what to file the bug against? Anaconda? First boot? -- As a boy I jumped through Windows, as a man I play with Penguins. From nman64 at n-man.com Fri Apr 21 06:30:14 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 21 Apr 2006 01:30:14 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604202255u2e099af0nb1535e7b1c44847d@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <44484686.6020301@volny.cz> <16de708d0604202255u2e099af0nb1535e7b1c44847d@mail.gmail.com> Message-ID: <200604210130.24149.nman64@n-man.com> On Friday 21 April 2006 00:55, "Arthur Pemberton" wrote: > > Should I file a bug report on this? Or is there a reason that gdm gets > installed regardless of choice in desktop environtment? > GDM is used by default only because GNOME is the default desktop. An option to use KDM when KDE packages are installed could theoretically be added to firstboot. The best way to handle this would be a unified way to tell when different display managers are installed. This method could be used to determine what options to offer and could include desktop environments which are only available in Extras or third-party repositories. You can file a bug against firstboot and see what happens. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From seg at haxxed.com Fri Apr 21 06:57:33 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 21 Apr 2006 01:57:33 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145578175.2559.42.camel@localhost.localdomain> References: <200604160349.25854.nman64@n-man.com> <4443DC95.9020809@soeterbroek.com> <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> <1145574407.7813.1.camel@cutter> <1145578175.2559.42.camel@localhost.localdomain> Message-ID: <1145602655.17779.14.camel@hamburger.booze> On Thu, 2006-04-20 at 20:09 -0400, Paul W. Frields wrote: > I did this by taking the old FC4 ".us.east" lists and (after > confirmation of the repos) including them on my system. I wasn't sure > that was the accepted usage, but now it seems so. I know there are > probably myriad ways to accomplish this with a more user-friendly bent, > but would it make sense for there to be a tool that asked the user to > select a geographic region, and populated a local mirror list > appropriately, using a remotely gathered list that included lat/long > data? Does such a thing exist already and I'm just clueless? I'm thinking of hacking yum-fastestmirror to rank based on number of hops to the mirror, this would get you the closest mirrors "as the packet flies", which is probably better than geographical proximity. Though it would still be nice to track actual transfer rates from each mirror. I don't know if that can be hacked on in a plugin. I really need to learn some python... From gianluca.cecchi at gmail.com Fri Apr 21 07:15:38 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 21 Apr 2006 09:15:38 +0200 Subject: Alsa 1.0.11 final Message-ID: <561c252c0604210015x6eb94eacmd4af2378e2d0eab4@mail.gmail.com> On Thu, 20 Apr 2006 13:38:30 -0700 "Allyn, Mark A" wrote: >What are the plans for updating the Alsa drivers in FC5 to 1.0.11rc5 or >1.0.11 final (which was released the week of April 17th)? I've not seen in the recent past patching the kernel by fc for alsa matters. So probably it will be included after inclusion by final vanilla 2.6.17and inclusion of the new vanilla as a base for fc (as it recently happened from kernel-2.6.15-1.2054 to kernel-2.6.16-1.2080 for fc5) The current states in standard kernel http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.17-rc1 is: commit a3c44854a59f7e983c867060aa906bbf5befb1ef Author: Jaroslav Kysela Date: Wed Mar 22 14:37:15 2006 +0100 [ALSA] version 1.0.11rc4 You might ask linux kernel list or mantainer what are in the mean time the plans for standard inclusion, hoping further inclusion in fc... HIH, Gianluca From stransky at redhat.com Fri Apr 21 07:29:25 2006 From: stransky at redhat.com (Martin Stransky) Date: Fri, 21 Apr 2006 09:29:25 +0200 Subject: Alsa 1.0.11 final In-Reply-To: <75EC4D5486CAC247B84AAAA6F96AA55807320A39@orsmsx402.amr.corp.intel.com> References: <75EC4D5486CAC247B84AAAA6F96AA55807320A39@orsmsx402.amr.corp.intel.com> Message-ID: <444889D5.9020802@redhat.com> Just install new 1.0.11 ALSA drivers to your current kernel.... Allyn, Mark A wrote: > Hello: > > What are the plans for updating the Alsa drivers in FC5 to 1.0.11rc5 or > 1.0.11 final (which was released the week of April 17th)? > > I have a bug (189245) for the FC5 audio, which is having record problems > on an Intel D945 Chipset based system. > > Thank you > > Mark Allyn > From redhat at olen.net Fri Apr 21 07:34:41 2006 From: redhat at olen.net (Ola Thoresen) Date: Fri, 21 Apr 2006 07:34:41 +0000 (UTC) Subject: Fedora Bounties (seeking ideas) References: <200604160349.25854.nman64@n-man.com> <1145602655.17779.14.camel@hamburger.booze> Message-ID: 2006-04-21 Callum Lerwick wrote > On Thu, 2006-04-20 at 20:09 -0400, Paul W. Frields wrote: >> I did this by taking the old FC4 ".us.east" lists and (after >> confirmation of the repos) including them on my system. I wasn't sure >> that was the accepted usage, but now it seems so. I know there are >> probably myriad ways to accomplish this with a more user-friendly bent, >> but would it make sense for there to be a tool that asked the user to >> select a geographic region, and populated a local mirror list >> appropriately, using a remotely gathered list that included lat/long >> data? Does such a thing exist already and I'm just clueless? > > I'm thinking of hacking yum-fastestmirror to rank based on number of > hops to the mirror, this would get you the closest mirrors "as the > packet flies", which is probably better than geographical proximity. > > Though it would still be nice to track actual transfer rates from each > mirror. I don't know if that can be hacked on in a plugin. I really need > to learn some python... > As far as I rememeber, the fastesmirror-plugin downloads a small file(?) the first time it sees a mirror and determines the time this takes, and then sorts the list according to this timing. The main problem with it as I see it is that it does not seem to ever update the timing of a mirror after it is first added. I think the easiest would probably be to make a small addition to the plugin, so it will either a) Update the timings of one or more "random" mirrors every time it is run, so you are sure to pick it up if a mirror had temporarily problems the first time it was timed, or if a mirror is upgraded with better connectivity and so on. or b) Use the acutal transfers from a mirror to update its timings. - So if a mirror is considered the "fastest" by the first timing, yum will us this mirror on the next run. But this run will also be a new timing of said mirror, so that if it was just "lucky" being the fastest the first time, and it turns out it is really slow for actual use, it will be moved down the list for next run. This requires a change in "timedhost.txts" so it no longer logs the number of seconds the download used, but rather use some kind of "speed" (IE. kbps) that is calculated from the transfers. Any of these solutions will probably make fastestmirror a lot better when it comes to actually determining the fastest mirror. Rgds. Ola Thoresen From buildsys at redhat.com Fri Apr 21 07:43:18 2006 From: buildsys at redhat.com (Build System) Date: Fri, 21 Apr 2006 03:43:18 -0400 Subject: rawhide report: 20060421 changes Message-ID: <200604210743.k3L7hIoj005239@porkchop.devel.redhat.com> Updated Packages: coreutils-5.94-3 ---------------- * Thu Apr 20 2006 Tim Waugh 5.94-3 - Make 'ls -Z' output more consistent with other output formats. device-mapper-1.02.02-3.2 ------------------------- * Fri Feb 10 2006 Jesse Keating - 1.02.02-3.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.02.02-3.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 11 2006 Karel Zak - 1.02.02-3 - cleanup selinux patch - add pkg-config support dhcdbd-1.14-1.FC6 ----------------- * Thu Apr 20 2006 Jason Vas Dias - 1.14-1.FC5 - fix bug 189529: prevent potential memory corruption on hex string options with single-byte non-ascii values - modify dhcp option types to be in line with latest ISC dhcp ethereal-0.99.0-0.svn.1 ----------------------- * Thu Apr 20 2006 Radek Vok??l 0.99.0-0.svn.1 - 0.99.0 prerelease gcc-4.1.0-9 ----------- * Thu Apr 20 2006 Jakub Jelinek 4.1.0-9 - update from gcc-4_1-branch (-r112951:113110) - PRs c++/10385, c++/26036, c++/26365, c++/26558, classpath/27163, fortran/26769, libgcj/27171, libgfortran/26766, libstdc++/27162, middle-end/27095, middle-end/27134, target/27182, tree-optimization/26643, tree-optimization/26821, tree-optimization/26854, tree-optimization/27087 - fix ppc32 va_arg bug (Alan Modra) - assorted gomp fixes (PRs c++/25874, middle-end/25989, c/25996, c/26171, middle-end/26913) - fix pretty printing C array types (#188944) - fix ICE on unprototyped alloca (PR tree-optimization/26865) - fix truncation optimization overflow handling (PR middle-end/26729) - uuencode dejagnu testsuite log files in rpmbuild output gimp-2:2.2.11-3 --------------- * Thu Apr 20 2006 Nils Philippsen - 2:2.2.11-3 - only use pkgconfig if needed in gimptool, require pkgconfig in devel subpackage (#189314, #189371) * Wed Apr 19 2006 Nils Philippsen - 2:2.2.11-2 - require pkgconfig (#189314) * Tue Apr 18 2006 Nils Philippsen - 2:2.2.11-1 - version 2.2.11 gnome-user-share-0.10-2 ----------------------- * Thu Apr 20 2006 Matthias Clasen 0.10-2 - Update to 0.10 gthumb-2.7.6-2 -------------- * Thu Apr 20 2006 Matthias Clasen - 2.7.6-2 - Update to 2.7.6 initscripts-8.33-1 ------------------ * Thu Apr 20 2006 Bill Nottingham 8.33-1 - support for readonly root - rc.sysinit: remove call to zfcpconf.sh - that should be udev rules - ifup*: add NETWORKDELAY and LINKDELAY (#176851, ) - rc.sysinit: remove obsolete initrd code () ipsec-tools-0.6.5-1 ------------------- * Tue Apr 18 2006 Dan Walsh - 0.6.5-1 - Update to latest upstream version - Add MLS Patch to allow use of labeled networks - Patch provided by Joy Latten kernel-2.6.16-1.2147_FC6 ------------------------ * Thu Apr 20 2006 Dave Jones - 2.6.17rc2-git3 - Make AHCI suspend/resume work. lvm2-2.02.01-1.2.1 ------------------ * Fri Feb 10 2006 Jesse Keating - 2.02.01-1.2.1 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.02.01-1.2 - rebuilt for new gcc4.1 snapshot and glibc changes * Fri Dec 09 2005 Jesse Keating - rebuilt policycoreutils-1.30.6-3 ------------------------ * Thu Apr 20 2006 Dan Walsh 1.30.6-3 - Fix check for "msg" * Mon Apr 17 2006 Dan Walsh 1.30.6-2 - Ship avc.py * Fri Apr 14 2006 Dan Walsh 1.30.6-1 - Add /etc/samba/secrets.tdb to restorecond.conf - Update from upstream * Merged semanage prefix support from Russell Coker. * Added a test to setfiles to check that the spec file is a regular file. procinfo-18-18.3 ---------------- * Fri Apr 21 2006 Karel Zak - 18-18.2.3 - fix #185300 - cpu steal time support pygtk2-2.8.6-1 -------------- * Thu Apr 20 2006 John (J5) Palmieri - 2.8.6-1 - Update to upstream 2.8.6 selinux-policy-2.2.34-2 ----------------------- * Thu Apr 20 2006 Dan Walsh 2.2.34-2 - Allow procmail to sendmail - Allow nfs to share dosfs * Thu Apr 20 2006 Dan Walsh 2.2.34-1 - Update to latest from upstream - Allow selinux-policy to be removed and kernel not to crash system-config-printer-0.7.5-1 ----------------------------- * Thu Apr 20 2006 Tim Waugh 0.7.5-1 - Updated to pycups-1.9.8. No longer need threads patch. - Updated to system-config-printer-0.7.5. * Sat Apr 15 2006 Tim Waugh - Updated to pycups-1.9.7. tcl-8.4.13-1 ------------ * Wed Apr 19 2006 David Cantrell - 8.4.13-1 - Upgraded to Tcl 8.4.13 * Fri Feb 17 2006 David Cantrell - 8.4.12-4 - Enable threads (#181871) * Fri Feb 10 2006 Jesse Keating - 8.4.12-3.2 - bump again for double-long bug on ppc(64) thunderbird-0:1.5.0.2-2 ----------------------- * Wed Apr 19 2006 Christopher Aillon - 1.5.0.2-2 - Update to 1.5.0.2 * Thu Mar 16 2006 Christopher Aillon - 1.5-7 - Bring the other arches back * Mon Mar 13 2006 Christopher Aillon - 1.5.6 - Temporarily disable other arches that we don't ship FC5 with, for time tix-1:8.4.0-8 ------------- * Thu Apr 20 2006 David Cantrell - 1:8.4.0-8 - Rebuild against Tcl/Tk 8.4.13 tk-8.4.13-1 ----------- * Thu Apr 20 2006 David Cantrell - 8.4.13-1 - Upgraded to Tk 8.4.13 tzdata-2006d-1 -------------- * Thu Apr 20 2006 Petr Machata - 2006d-1 - Upstream 2006d - Haiti observes DST - Sri Lanka change actually took effect Apr/15 - All Canada is now scheduled for 2007 US DST rules - Some historical fixes vim-1:7.0.e001-1 ---------------- * Thu Apr 20 2006 Karsten Hopp 7.0.e001-1 - vim-7.0e BETA Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From seg at haxxed.com Fri Apr 21 07:56:47 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 21 Apr 2006 02:56:47 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <44427E44.7080304@fedora.pl> Message-ID: <1145606209.17779.17.camel@hamburger.booze> On Thu, 2006-04-20 at 15:13 +0200, Rudolf Kastl wrote: > its about time to start an atleast basic 3d accelerated driver for > nvidia cards/linux http://nouveau.sourceforge.net/ From nphilipp at redhat.com Fri Apr 21 08:06:41 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 21 Apr 2006 10:06:41 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> Message-ID: <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-04-20 at 16:41 +0100, Andre Nogueira wrote: > 2) When Anaconda is installing a package, it is not downloading the > next package. Why not continue downloading packages while installing > downloaded packages? Before starting an RPM transaction you want to be sure that everything is available. Think about a transaction that consists of packages a, b, c (each with version-release) which are to be installed in that order. You propose s.th. along that: 1) a gets downloaded 2) a gets installed while b gets downloaded 3) b gets installed while c gets downloaded 4) c gets installed Unfortunately, somewhere during step 2, the mirror gets updated with a new version of c which actually would be required to be installed _before_ b. Now you've got a broken transaction --> this is why yum etc. download first, then install afterwards. > 3) When Anaconda starts, ask the user if (s)he has a kickstart > configuration file on a pen drive or remote FTP/HTTP location (s)he'd > like to use. This would make kickstart files much more user friendly. Writing/modifying kickstart files actually is tougher than writing "ks=..." on the installer kernel command line. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri Apr 21 08:08:49 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 21 Apr 2006 10:08:49 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> Message-ID: <1145606930.2945.15.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-04-20 at 13:26 -0300, Avi Alkalay wrote: > >From the Bounties page: > > ----------------------- > System G-Conf (or other configuration) backend > > Currently, NetworkManager relies on talking to the session GConf > daemon for configuration. With some of these other interface types, a > configuration store is needed that would be available even when no > user session is initialized. > ----------------------- > > I'd like to propose Elektra as this other system-wide configuration backend. > GConf, in its essence, was not designed to be system wide. It actually > has too much dependencies for that. > > More info here: > http://www.libelektra.org/ > http://www.libelektra.org/GConf Oh please ... let's ... not ... start ... that ... discussion ... again! Every argument for and against either GConf or Elektra has been brought forth already, nothing to see here, move along. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nman64 at n-man.com Fri Apr 21 08:25:13 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 21 Apr 2006 03:25:13 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> References: <200604160349.25854.nman64@n-man.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200604210325.16636.nman64@n-man.com> On Friday 21 April 2006 03:06, Nils Philippsen wrote: > On Thu, 2006-04-20 at 16:41 +0100, Andre Nogueira wrote: > > 3) When Anaconda starts, ask the user if (s)he has a kickstart > > configuration file on a pen drive or remote FTP/HTTP location (s)he'd > > like to use. This would make kickstart files much more user friendly. > > Writing/modifying kickstart files actually is tougher than writing > "ks=..." on the installer kernel command line. > If nothing else, having a prompt would increase awareness of kickstart. It would be nice if we could improve upon system-config-kickstart and get nice interfaces for both creating and using kickstart files. Having a prompt where a user could select the source of a kickstart file, and just basic information provided with that prompt, would allow even a novice user to save the kickstart file that was created by one installation and use it to repeat that installation. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lmacken at redhat.com Fri Apr 21 08:55:12 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 21 Apr 2006 04:55:12 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145602655.17779.14.camel@hamburger.booze> References: <1145300848.2832.54.camel@pensja.lam.pl> <1145303087.32015.11.camel@cutter> <20060417221849.69d56171@nausicaa.camperquake.de> <1145324754.1568.8.camel@cutter> <1145355009.6824.28.camel@pensja.lam.pl> <1145419331.10519.14.camel@minicooper> <1145568745.17779.8.camel@hamburger.booze> <1145574407.7813.1.camel@cutter> <1145578175.2559.42.camel@localhost.localdomain> <1145602655.17779.14.camel@hamburger.booze> Message-ID: <20060421085512.GA6792@tomservo.boston.redhat.com> On Fri, Apr 21, 2006 at 01:57:33AM -0500, Callum Lerwick wrote: > On Thu, 2006-04-20 at 20:09 -0400, Paul W. Frields wrote: > > I did this by taking the old FC4 ".us.east" lists and (after > > confirmation of the repos) including them on my system. I wasn't sure > > that was the accepted usage, but now it seems so. I know there are > > probably myriad ways to accomplish this with a more user-friendly bent, > > but would it make sense for there to be a tool that asked the user to > > select a geographic region, and populated a local mirror list > > appropriately, using a remotely gathered list that included lat/long > > data? Does such a thing exist already and I'm just clueless? > > I'm thinking of hacking yum-fastestmirror to rank based on number of > hops to the mirror, this would get you the closest mirrors "as the > packet flies", which is probably better than geographical proximity. I would be interested in seeing how this works out. I wrote the connect() based mirror-selection algorithm to be fast, and semi-accurate. It might be nice to have multiple mirror-selection algorithms built into fastestmirror, and selectable via a configure option. This would allow us to test the various techniques and see which yields the most reliable results. > Though it would still be nice to track actual transfer rates from each > mirror. I don't know if that can be hacked on in a plugin. I really need > to learn some python... You could do this by pulling down a file from each mirror, and using the average_rate() function in urlgrabbers RateEstimator[0] class. luke [0]: http://linux.duke.edu/projects/urlgrabber/help/urlgrabber.progress.html#RateEstimator From lmacken at redhat.com Fri Apr 21 09:01:50 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 21 Apr 2006 05:01:50 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <1145602655.17779.14.camel@hamburger.booze> Message-ID: <20060421090150.GB6792@tomservo.boston.redhat.com> On Fri, Apr 21, 2006 at 07:34:41AM +0000, Ola Thoresen wrote: > 2006-04-21 Callum Lerwick wrote > > On Thu, 2006-04-20 at 20:09 -0400, Paul W. Frields wrote: > >> I did this by taking the old FC4 ".us.east" lists and (after > >> confirmation of the repos) including them on my system. I wasn't sure > >> that was the accepted usage, but now it seems so. I know there are > >> probably myriad ways to accomplish this with a more user-friendly bent, > >> but would it make sense for there to be a tool that asked the user to > >> select a geographic region, and populated a local mirror list > >> appropriately, using a remotely gathered list that included lat/long > >> data? Does such a thing exist already and I'm just clueless? > > > > I'm thinking of hacking yum-fastestmirror to rank based on number of > > hops to the mirror, this would get you the closest mirrors "as the > > packet flies", which is probably better than geographical proximity. > > > > Though it would still be nice to track actual transfer rates from each > > mirror. I don't know if that can be hacked on in a plugin. I really need > > to learn some python... > > > > As far as I rememeber, the fastesmirror-plugin downloads a small file(?) > the first time it sees a mirror and determines the time this takes, and > then sorts the list according to this timing. Nope, it only times how long it takes to open a socket with the mirror. > The main problem with it as I see it is that it does not seem to ever > update the timing of a mirror after it is first added. I think the > easiest would probably be to make a small addition to the plugin, so it > will either > a) Update the timings of one or more "random" mirrors every time it is > run, so you are sure to pick it up if a mirror had temporarily problems > the first time it was timed, or if a mirror is upgraded with better > connectivity and so on. > or There is a 'maxhostfileage' option which will refresh your mirrorlist after n days. > b) Use the acutal transfers from a mirror to update its timings. > - So if a mirror is considered the "fastest" by the first timing, yum > will us this mirror on the next run. But this run will also be a > new timing of said mirror, so that if it was just "lucky" > being the fastest the first time, and it turns out it is really slow > for actual use, it will be moved down the list for next run. > This requires a change in "timedhost.txts" so it no longer logs the > number of seconds the download used, but rather use some kind of "speed" > (IE. kbps) that is calculated from the transfers. > > Any of these solutions will probably make fastestmirror a lot better > when it comes to actually determining the fastest mirror. Definitely sounds feasable. Send patches ;) luke From hendrik.wiese at siemens.com Fri Apr 21 09:01:54 2006 From: hendrik.wiese at siemens.com (Wiese, Hendrik) Date: Fri, 21 Apr 2006 11:01:54 +0200 Subject: Need much more than 350 established network connections Message-ID: Hello, We develop a load simulator which simulates subscribers by establishing a high number of connections to different VLAN IPs. Now we got a problem here with Fedora 4, where we can only establish 350 connections from one IP to another one. But we need to establish much more connections between two specific IP addresses. SELinux is disabled, so this can't be the reason. We are rather sure that this is a security limitation, which isn't required in our systems. Any help breaking this limitation would be greatly appreciated. Ragards, H. Wiese From mailinglists at erwinrol.com Fri Apr 21 10:23:11 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 21 Apr 2006 12:23:11 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145493051.4749.1.camel@yoda.jdub.homelinux.org> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> Message-ID: <1145614991.2760.18.camel@xpc.home.erwinrol.com> On Wed, 2006-04-19 at 19:30 -0500, Josh Boyer wrote: > On Thu, 2006-04-20 at 00:45 +0100, Cam wrote: > > Kristian > > > > I tried this just for fun on my ATI r300 and was surprised that it > > almost worked. I get what looks like an alpha channel (blue screen with > > shadows on it). True to the notes I can turn compositing off and > > everything is back to normal. > > I saw the same thing on my laptop with an ATI Radeon Mobility something > or other. I also see the blue background with shadows only, when using aiglx, with a radeon laptop. What might be interesting is that it works a lot better when i switch from 24bit to 16bit mode (I can't test 32bit since that doesn't seem to be supported with the radeon driver). For OpenGL applications i get the following warning: libGL warning: 3D driver claims to not support visual 0x4b But they seem to work kind of, glxgears for example works, but the OpenGL part of the window is always ontop. Blender does weird things also, it looks OK but parts of the windows are black when you move the cursor over them (blender does things like highlighting, and the whole GUI is in OpenGL). What also is interesting (but probably unrelated to aiglx itself) is that my mouse stopped working, i can only use my touchpad now. But it looks promising :-) - Erwin From tarjei.knapstad at gmail.com Fri Apr 21 10:24:15 2006 From: tarjei.knapstad at gmail.com (Tarjei Knapstad) Date: Fri, 21 Apr 2006 12:24:15 +0200 Subject: Need much more than 350 established network connections In-Reply-To: References: Message-ID: On 4/21/06, Wiese, Hendrik wrote: > Hello, > Hi Hendrik, This question is better asked at the main users list (fedora-list at redhat.com) as it's not related to development of Fedora. Regards, -- Tarjei From mailinglists at erwinrol.com Fri Apr 21 10:44:50 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 21 Apr 2006 12:44:50 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145614991.2760.18.camel@xpc.home.erwinrol.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> Message-ID: <1145616290.2760.22.camel@xpc.home.erwinrol.com> On Fri, 2006-04-21 at 12:23 +0200, Erwin Rol wrote: > I also see the blue background with shadows only, when using aiglx, with > a radeon laptop. What might be interesting is that it works a lot better > when i switch from 24bit to 16bit mode (I can't test 32bit since that > doesn't seem to be supported with the radeon driver). I found the following warning, which might suggest a difference between FC5 and Rawhide. (WW) RADEON(0): [dri] limiting video memory to one aperture of 65536K (WW) RADEON(0): [dri] detected radeon kernel module version 1.22 but 1.23 or newer is required for full memory mapping. (II) RADEON(0): Detected total video RAM=32768K, accessible=65536K (PCI BAR=131072K) > But they seem to work kind of, glxgears for example works, but the > OpenGL part of the window is always ontop. Blender does weird things > also, it looks OK but parts of the windows are black when you move the > cursor over them (blender does things like highlighting, and the whole > GUI is in OpenGL). Interesting is that in 24bit mode the output of blender is OK. It looks like in 24 bit mode only the OpenGL parts are shown. - Erwin From mailinglists at erwinrol.com Fri Apr 21 11:00:08 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 21 Apr 2006 13:00:08 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145616290.2760.22.camel@xpc.home.erwinrol.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> <1145616290.2760.22.camel@xpc.home.erwinrol.com> Message-ID: <1145617208.2760.26.camel@xpc.home.erwinrol.com> The Gnome terminal transparency effect doesn't work, when i set it to minimum the window gets black, when i set it to maximum the window gets white, everything in between are shades of gray. - Erwin From sundaram at fedoraproject.org Fri Apr 21 12:20:22 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 21 Apr 2006 17:50:22 +0530 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> Message-ID: <1145622023.18551.139.camel@sundaram.pnq.redhat.com> On Thu, 2006-04-20 at 14:25 +0200, Frank Schmitt wrote: > Rahul Sundaram writes: > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > Would be quite useful for the less technically inclined users. > > Have a look at KDE's kinfocenter. We need a desktop environment neutral interface. Rahul From jspaleta at gmail.com Fri Apr 21 12:39:06 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 08:39:06 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <1145602655.17779.14.camel@hamburger.booze> Message-ID: <604aa7910604210539r6917da0fm3cb3ba68454c95ef@mail.gmail.com> On 4/21/06, Ola Thoresen wrote: > The main problem with it as I see it is that it does not seem to ever > update the timing of a mirror after it is first added. wrong... there is a timeout variable which sets the length of time that the timedhost file is cached. maxhostfileage -jef From nphilipp at redhat.com Fri Apr 21 12:45:41 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 21 Apr 2006 14:45:41 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> On Fri, 2006-04-21 at 10:06 +0200, Nils Philippsen wrote: > On Thu, 2006-04-20 at 16:41 +0100, Andre Nogueira wrote: > > > 2) When Anaconda is installing a package, it is not downloading the > > next package. Why not continue downloading packages while installing > > downloaded packages? > > Before starting an RPM transaction you want to be sure that everything > is available. Think about a transaction that consists of packages a, b, > c (each with version-release) which are to be installed in that order. > You propose s.th. along that: > > 1) a gets downloaded > 2) a gets installed while b gets downloaded > 3) b gets installed while c gets downloaded > 4) c gets installed > > Unfortunately, somewhere during step 2, the mirror gets updated with a > new version of c which actually would be required to be installed > _before_ b. Now you've got a broken transaction --> this is why yum etc. > download first, then install afterwards. Hmm, thl just made me aware of that anaconda already first downloads a package, then installs it. While I won't change anything w.r.t. NFS installations (I consider them "quasi local"), parallel download and install might even make sense for FTP and HTTP (as long as the code doesn't get too ugly ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From pnasrat at redhat.com Fri Apr 21 13:19:50 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 21 Apr 2006 09:19:50 -0400 Subject: corrupt package message during FC5 install from NFS. In-Reply-To: <69F69FD5FD4A9843ACBF7CE9B7830B4A0853B410@orsmsx408> References: <69F69FD5FD4A9843ACBF7CE9B7830B4A0853B410@orsmsx408> Message-ID: <1145625590.2720.11.camel@enki.eridu> On Thu, 2006-04-20 at 15:52 -0700, Aggarwal, VikasX wrote: > Hi, > > I am trying to do install from NFS of a custom distribution which is > based on FC5test3. > > > > After formatting the local drive the anaconda-installer shows message ? ?The package traceroute-1.0.4-1.2.i386 cannot be opened. This is due to missing file or perhaps the corrupt package. If you are installing from CD media this usually means the CD is corrupt, or the CD drive is unable to read media?. You probably want to rebase to FC5 GOLD before doing any customisation. Some of these error paths were caught. Ensure you have run createrepo on your tree correctly and there are no I/O errors on tty4. Paul From gazzerh at gmail.com Fri Apr 21 13:24:29 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Fri, 21 Apr 2006 14:24:29 +0100 Subject: Installation Wizard in Yumex In-Reply-To: <443A5A2E.2070007@rasmil.dk> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> Message-ID: <1fcc9e320604210624y35c94e31h8889b0da0b899b77@mail.gmail.com> On 10/04/06, Tim Lauridsen wrote: > Ignacio Vazquez-Abrams wrote: > On Mon, 2006-04-10 at 14:35 +0200, Tim Lauridsen wrote: > > > Hi. > > I just stumbled over easyUbuntu [1] and got a idea to add some kind of > installation Wizard in yumex, to make it easy to add all the > extra stuff need to get your fedora running. > > * Nvidia drivers. > * ATI Drivers > * NTFS support. > * MP3 support. > * Movie player with codecs. (Mplayer, gstreamer etc). > * Java > * Flash > > I want to make some kind of XML format to creating the Wizard entries > and the actions behind. The different people can make there own wizards > and people can just drag and drop an URL to a wizard XML into yumex to > add the wizard entries to the installation wizard. This could be a way > to close the gap between a FOSS distribution and the non free or patent > related stuff, there never can be included in Fedora. > Let me now what you think, is it a totally lame idea or is it a way to go. > > It's a nice idea, but... > > http://en.wikipedia.org/wiki/Patent_infringement#Active_inducement_of_infringement > > > I just want to code a easy way to install things, not try to break any > patent, i will not include anything illegal into yumex, but people located i > place where software patents don't exist, can make a wizard plugin to > install the stuff hosted in places like livna or freshrpms. > I same way as yum and rpm can be used to installed patent releated stuff, > but it is not the purpose of the application. > > Tim > This is good idea. Give the option in yumex to install and run a install wizard rpm/textfile located on dries for example (display a list of popular repos). This will then display the wizard allowing the installation of whatever packages are listed this rpm/texfile located on dries. Neither redhat, fedora or yourself are in direct control of the contents of this wizard file located on dries. Also give option to install rpm wizard packages from other sources. I don't see any infringement here? Please correct me if I am wrong, Garry From jspaleta at gmail.com Fri Apr 21 13:34:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 09:34:58 -0400 Subject: Installation Wizard in Yumex In-Reply-To: <1fcc9e320604210624y35c94e31h8889b0da0b899b77@mail.gmail.com> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> <1fcc9e320604210624y35c94e31h8889b0da0b899b77@mail.gmail.com> Message-ID: <604aa7910604210634r1f623a8ds6b2c2906c896e107@mail.gmail.com> On 4/21/06, Garry Harthill wrote: > This is good idea. Its a horrible idea., because it makes it that much easier for random inexperienced users to create mind-numbingly simple ways to create scripts that breaks other inexperienced users systems. For ever one of these scripts which will be provided by a reputable maintainer there will be a vast array of such scripts sitting in random-joe-user's personal blog or "help site" which hasn't seen a shred of testing by anyone else and willy-nilly enabled a array of repositories with conflicting update paths causing updating problems for any user who happens to find that random script on the web. What happens when stanton writes his yumex installer script which makes slightly different but conflicting choices than the dries script? What happens with atrpms adds yet another script which again makes slightly different but conflicting choices? And the poor user attempts to use all 3 because they each cover unique functionality? -jef"Can wait to add pathelogical yumex install scripts to his repository webpage of pathelogical packages of doom repository"spaleta From alotsum at gmail.com Fri Apr 21 14:42:17 2006 From: alotsum at gmail.com (Alo Tsum) Date: Fri, 21 Apr 2006 10:42:17 -0400 Subject: Fedora core suggestions Message-ID: Fedora Core 5 is a truly amazing OS and one I think has the potential to really do great things. Looking forward to what the Fedora Project has the potential to do, especially with its new focus I decided to give some suggestions as to what could possibly be done starting with Fedora 6 and onward. Some of my suggestions are definitely based on the OS itself but others are also concerning the general focus and outlook of the Fedora Project itself. I hope my suggestion are not regarded as offensive in anyway and they are only meant to highlight the greatness of Fedora as well as to reflect my strong desire to see this project take off and propel the Linux OS to new heights. First suggestions has to do with the software side of things. We users need a competent software installer which is graphical based. One that functions much the same way that the windows installer works. This installer should track dependencies naturally and place icons on the desktop or give the option to have icons for the software just installed to be placed on the desktop of the user as well as in the applications menu. Also when watching the Boston Linux conference the suggestion was made to offer a hard disc manager much like windows offers for formating and receiving hard drivers etc after installation. My second set of suggestions will deal with the over all focus and structure of the fedora project. I was listening to a pod cast interview with the head of the fedora project where in, the topic came up of some how generating revenue to put back into the project and make it more self sufficient. So I have a few suggestions which I think the Redhat company itself should take note of. Firstly Redhat while promoting Linux among enthusiast is also in the business of making money. On that front I believe that they should not only attempt to evangelize Linux in the government, education, and corporate sectors; they should also attempt to get Linux in each and every home. The reason being is if people are starting to use Linux in their homes and they are comfortable with it, employers will be more likely and willing to deploy a operating system which is different in many ways to windows on the interactive level. Reason being is when people have to stop to learn new technology this cuts down on productivity and as a person who works for a IT department in a major university I can also vouch for the fact a IT team will not be willing to suggest an infrastructure restructuring when they know, supporting users on something foreign to them is going to increase their workload 10 fold. So bottom line, more users both advanced, intermediate and beginners need to be converted to the Linux faithful but now the question becomes how? The Fedora project is the perfect tool for this and here is how. The fedora team should focus SOLELY on making the operating system run as smoothly and as fast as possible, interacting with a HUGE number of hardware configurations. Installation needs to be as smooth as silk and upgrading needs to be fail proof from version to version. Previously installed drives with personal user data needs to be able to be retained without fail from upgrade to upgrade if the user isn't doing a clean install. Now I would like to move on to "partnerships" Fedora project should look into making "partners" or some other creative term to define other Linux projects and organizations. In this partnership Fedora will tightly enforce standards which will ensure that any software created to run on fedora is following say the OIN and the GPL standards to the letter to ensure an user friendly and secure/stable operating system that runs smoothly. Many people in the Linux community may grumble about this suggestion however life is about progression and when things do not change and evolve and progress to new levels then they are doomed to become extinct (think dinosaurs here) or at the very least remain niche applications. If Fedora project implements such a model, they do not have to worry about making certain software for the OS which would take far to much time and man power to create. Prime example would be the hard disk manager or even the software installer. This sort of work could be left to groups who's soul purpose is to make such software and by following strict guidelines they would become Fedora project "partners" and in turn they would be promised that their software will be included in the fedora core release. Also by following strict guidelines this software could be implemented in other Linux distributions which are also following said guidelines. This would take the pressure off of Fedora and they can then focus on whats important which is making their OS run like silk. Again let me stress this approach is keeping in mind that projects such as Fedora and other Linux distributions desire to penetrate more into the home desktop market, which then also means more users will or could eventually equate to greater adoption of the platform in other industries as a result of user awareness and user comfort with the Linux platform. I should also mention that those software development groups that do not comply could be offered as Fedora extras so the community still has choices which is really part of the appeal of Linux. Okay so with all that said how could this generate income? Well lets say Fedora project comes up with one of the first 100% standard enforced distributions which is as user friendly or even more so than MS windows. Now say a "ambassador" from Fedora can start making the rounds to Dell and other companies and attempt to get them to start offering this FREE Linux distribution on some of their PC models, which would also allow for lower prices on the retail side for them (ie Dell, Gateway etc.) as the OS is FREE and that cuts down on cost which the end user ends up incurring. But we still have not addressed revenue for the Fedora project, and this can be done by following the Redhat model of offering technical support. Fedora project could basically offer technical support certification and training to Dell staff as an example so they (the PC manufacturer) can then take over supporting the platform for their end users, which also equates to revenue for these companies in the long run because they can offer extended tech support to end users at a premium. Fedora core could charge a VERY minimal fee for this training, so say charge enough that it would generate revenue that can then be pumped back into the project and at the same time would still make it cheaper for Dell and other companies to go with Linux on some desktop offerings as opposed to having a windows only offering. The future of Linux if to be taken seriously should not be relegated to just the business, government, and education world as far as standards, reliability, and software / hardware vendor support is concerned. The brand will grow far more rapidly if consumers are adopting the standard at home and at work so basically this is a bottom up approach. This of this, more desktop users in the home also means more software sales for major companies because you will have more people buying video games and other such things which will also mean more companies willing to adopt the platform because software offering become greater. There needs to be a consorted effort on the parts of all parties involved to take Linux to that next phase of existence other wise Linux as a brand, while it may grow some what will not see its full potential. With the software being a open and free model we still have to realize with a flurry of hodge podge coding and no standards insight the end user ends up losing at least as far as the home front is concerned. Most people are forced to run duel boot Windows and Linux systems because software makers and hardware manufactures have not fully bought into the Linux model and we as a community only have ourselves to blame for that. This approach will also take some evangelizing to the software makers of such things as yum and KDE however I believe that those who do not see the need and importants of doing such things will render themselves obsolete in the long run. Just look at the Unix model, and we can see what the disasters of not doing this can incur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at erwinrol.com Fri Apr 21 15:03:36 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 21 Apr 2006 17:03:36 +0200 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <1145631816.2760.30.camel@xpc.home.erwinrol.com> On Fri, 2006-04-21 at 10:42 -0400, Alo Tsum wrote: > Most people are forced to run duel boot Windows and Linux systems > because software makers and hardware manufactures have not fully > bought into the Linux model and we as a community only have ourselves > to blame for that. Yeah I blame myself everyday that ATI and nVidea don't understand they sell hardware instead of software and that making that software open source will not change anything to the fact I still have to buy their hardware. I think you should not blame the community for things that it should not be blamed for. - Erwin From ajackson at redhat.com Fri Apr 21 14:10:04 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 21 Apr 2006 10:10:04 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <44481612.1000202@optonline.net> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <44470F20.2000602@optonline.net> <1145508285.3228.18.camel@ignacio.lan> <44481612.1000202@optonline.net> Message-ID: <4448E7BC.5090402@redhat.com> Joel Rittvo wrote: > I renamed /usr/bin/kwin to /usr/bin/kwin-real, and then made a symlink > between metacity and kwin. Everything seems to be running fine calling > metacity in this roundabout way. > > Could someone tell me the correct way to tell KDE to use metacity > instead of kwin so I can undo this kludge method, though. Thanks! startkde will honor the $KDEWM environment variable. - ajax From ajackson at redhat.com Fri Apr 21 14:12:45 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 21 Apr 2006 10:12:45 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145614991.2760.18.camel@xpc.home.erwinrol.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> Message-ID: <4448E85D.7050004@redhat.com> Erwin Rol wrote: > But they seem to work kind of, glxgears for example works, but the > OpenGL part of the window is always ontop. Blender does weird things > also, it looks OK but parts of the windows are black when you move the > cursor over them (blender does things like highlighting, and the whole > GUI is in OpenGL). As mentioned earlier in the thread, redirected GLX does not work yet. This is an infrastructure problem with the DRI, not a metacity limitation. - ajax From jdesbonnet at gmail.com Fri Apr 21 15:14:56 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Fri, 21 Apr 2006 16:14:56 +0100 Subject: Fedora core suggestions In-Reply-To: <1145631816.2760.30.camel@xpc.home.erwinrol.com> References: <1145631816.2760.30.camel@xpc.home.erwinrol.com> Message-ID: <1cef3e950604210814u751a363cxec562d3f3a390191@mail.gmail.com> Someone made the excellent point (I think it was during the recent proprietary media flame war) that thanks to the current state of the patent system, almost every sizable computer product (hardware or software) is infringing on patents. Publishing technical documentation or driver source code only helps competitors identify "stolen IP". I think it's a good point. Joe. On 4/21/06, Erwin Rol wrote: > Yeah I blame myself everyday that ATI and nVidea don't understand they > sell hardware instead of software and that making that software open > source will not change anything to the fact I still have to buy their > hardware. From jdesbonnet at gmail.com Fri Apr 21 15:42:54 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Fri, 21 Apr 2006 16:42:54 +0100 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> I sent this suggestion to the original poster of the thread and it may have become lost: Project proposal: integrate Suse DeltaRPM software with yum to improve bandwidth efficiency when updating a distribution. I've experimented with this and I've got good results (see http://www.wombat.ie/software/rpmdc/manual.html ). However my implementation is heavy, requiring Java, Tomcat etc. Joe. From nman64 at n-man.com Fri Apr 21 15:45:23 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 21 Apr 2006 10:45:23 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145622023.18551.139.camel@sundaram.pnq.redhat.com> References: <200604160349.25854.nman64@n-man.com> <1145622023.18551.139.camel@sundaram.pnq.redhat.com> Message-ID: <200604211045.26234.nman64@n-man.com> On Friday 21 April 2006 07:20, Rahul Sundaram wrote: > On Thu, 2006-04-20 at 14:25 +0200, Frank Schmitt wrote: > > Rahul Sundaram writes: > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > > Would be quite useful for the less technically inclined users. > > > > Have a look at KDE's kinfocenter. > > We need a desktop environment neutral interface. > There is, at this time, no such thing as "desktop-environment-neutral". All of the "neutral" stuff in Fedora is GTK2/GNOME-based. The only significant distinction here is that we want software that only requires the default Fedora Core system, which happens to use GNOME, in order to function. Tools which provide GTK2 and CLI interfaces are best. This is in contrast to distributions which use KDE by default. They might prefer QT and CLI tools. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From alan at clueserver.org Fri Apr 21 16:48:31 2006 From: alan at clueserver.org (alan) Date: Fri, 21 Apr 2006 09:48:31 -0700 (PDT) Subject: AIGLX questions -- the x86_64 bit question Message-ID: Have the x86_64 problems been resolved? The AIGLX wiki has not been updated since FC5t3. Also, what is the status of the NVIDIA drivers? (I find it weird that XGL has NVIDIA working but not ATI and AIGLX has ATI working, but not NVIDIA.) -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From sfolkwil at redhat.com Fri Apr 21 16:51:09 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Fri, 21 Apr 2006 12:51:09 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: <20060421165109.GA22901@xander.rdu.redhat.com> On Wed, Apr 19, 2006 at 04:00:48PM -0400, Kristian H?gsberg wrote: > > $ USE_WOBBLY=1 metacity --replace & > > - metacity also has an experimental screen magnifier built in. Like > the wobbly windows this is enabled by setting an environment variable - > USE_MAGNIFIER: > > $ USE_MAGNIFIER=1 metacity --replace & > As a lot of people are having trouble with these awesome effects - are there other effects to play with? Like, how does one enable drop shadows or transparency -- or is it just these two for now? Also, where are these variables set permanently? Thanks, Sam > - real translucency in gnome-terminal. Enable this by clicking the > "Transparent background" radio box in the "Effects" tab of the termnal > profile editor dialog. gnome-terminal may have to be restarted for this > to take effect - pkill gnome-terminal should do the trick. > > There are a number of known bugs with these packages, so go easy on > bugzilla :). Specifically, > > - The damage events doesn't always kick in, so sometimes window > contents doesn't update properly. A workaround for this is to switch > desktop back and forth. > > - The drop shadows look weird on shaped/argb windows, for example > xeyes, the notify bubbles and well, even the rounded metacity corners. > The shadow code is due for an overhaul later, so we're not going to > patch over this issue in the short term. > > - Perfomance for in-window updates isn't always great. We're > currently doing too much work when updating textures from pixmaps. It's > still possible to optimize this further with the current setup, and > longer term the memory architecture in the X server and DRI stack will > see some changes that will allow us to optimize this further. > > Have fun, > Kristian > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- ? Sam Folk-Williams, RHCE ? Red Hat Global Support Services ? Phone: 919/754-4558 ? Cell: 919/943-9623 ? Fax: 919/754-3708 ? GPG ID: 1B0D46BA From andy at warmcat.com Fri Apr 21 17:54:16 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 21 Apr 2006 18:54:16 +0100 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <44491C48.4010101@warmcat.com> Alo Tsum wrote: > how generating revenue to put back into the project and make it more > self sufficient. So I have a few suggestions which I think the Redhat > company itself should take note of. Firstly Redhat while promoting Linux > among enthusiast is also in the business of making money. On that front > I believe that they should not only attempt to evangelize Linux in the Hum let me send out an alternate view: Free Software is outside the Sell and Evangelize paradigm. It exists, it can be offered, but its meaning in the world is that it honestly is there for people to use if they have a use for it. This is something different than commercial OSes that are there despite you asked to NOT have it, that are shoved down your throat, sold to you, lock you in and so on. > The Fedora project is the perfect tool for this and here is how. The > fedora team should focus SOLELY on making the operating system run as > smoothly and as fast as possible, interacting with a HUGE number of > hardware configurations. Installation needs to be as smooth as silk and Wll no argument there since that is useful for everyone. > upgrading needs to be fail proof from version to version. Previously > installed drives with personal user data needs to be able to be retained > without fail from upgrade to upgrade if the user isn't doing a clean Fedora is very decent at this already. > install. Now I would like to move on to "partnerships" Fedora project > should look into making "partners" or some other creative term to define > other Linux projects and organizations. In this partnership Fedora will > tightly enforce standards which will ensure that any software created to > run on fedora is following say the OIN and the GPL standards to the RHAT can confidently claim to have written the book on following "GPL standards". > by following strict guidelines they would become Fedora project > "partners" and in turn they would be promised that their software will > be included in the fedora core release. Also by following strict ... > approach is keeping in mind that projects such as Fedora and other Linux > distributions desire to penetrate more into the home desktop market, Hum again with the 'market', Free software doesn't compete in that sense, it is offered in the hope that it is useful, you can imagine it as demand-led. > which then also means more users will or could eventually equate to > greater adoption of the platform in other industries as a result of user No insult intended, but you or I don't get paid on the basis of adoption. I'm sure we're both pleased if there is increased adoption and maybe you or I will spend some time if we think it will increase takeup. But nonetheless offering a Free OS like Fedora is a different game than selling Commercial OSes. > Now say a "ambassador" from Fedora can start making the rounds to Dell Hum this is the thing, Fedora just is and Dell can take it up if they like. "Selling" a Free OS seems like a bit of an impedance mismatch. Why should people already pouring effort into the OS with no direct hope of return act to improve Dell's worldview as a charitable act if Michael is too locked into Bill's gravy train to do it himself? > at a premium. Fedora core could charge a VERY minimal fee for this > training, so say charge enough that it would generate revenue that can ... > The future of Linux if to be taken seriously should not be relegated to If a Free OS is taken seriously is up to the potential users. I take it real serious already. > There needs to be a con[ce]rted effort on the parts of all parties > involved to take Linux to that next phase of existence other wise Linux > as a brand, while it may grow some what will not see its full potential. > With the software being a open and free model we still have to realize No. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From mark.a.allyn at intel.com Fri Apr 21 17:57:27 2006 From: mark.a.allyn at intel.com (Allyn, Mark A) Date: Fri, 21 Apr 2006 10:57:27 -0700 Subject: Alsa 1.0.11 final Message-ID: <75EC4D5486CAC247B84AAAA6F96AA558073211D9@orsmsx402.amr.corp.intel.com> Thank you. I will be watching the upstream kernel. Mark -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Gianluca Cecchi Sent: Friday, April 21, 2006 12:16 AM To: Development discussions related to Fedora Core Subject: re: Alsa 1.0.11 final On Thu, 20 Apr 2006 13:38:30 -0700 "Allyn, Mark A" wrote: >What are the plans for updating the Alsa drivers in FC5 to 1.0.11rc5 or >1.0.11 final (which was released the week of April 17th)? I've not seen in the recent past patching the kernel by fc for alsa matters. So probably it will be included after inclusion by final vanilla 2.6.17and inclusion of the new vanilla as a base for fc (as it recently happened from kernel-2.6.15-1.2054 to kernel-2.6.16-1.2080 for fc5) The current states in standard kernel http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.17-rc1 is: commit a3c44854a59f7e983c867060aa906bbf5befb1ef Author: Jaroslav Kysela Date: Wed Mar 22 14:37:15 2006 +0100 [ALSA] version 1.0.11rc4 You might ask linux kernel list or mantainer what are in the mean time the plans for standard inclusion, hoping further inclusion in fc... HIH, Gianluca -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From sfolkwil at redhat.com Fri Apr 21 18:26:11 2006 From: sfolkwil at redhat.com (Sam Folk-Williams) Date: Fri, 21 Apr 2006 14:26:11 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060421165109.GA22901@xander.rdu.redhat.com> References: <444696F0.9080801@redhat.com> <20060421165109.GA22901@xander.rdu.redhat.com> Message-ID: <20060421182611.GA23491@xander.rdu.redhat.com> Sorry -- I figured this out. The drop shadows should just be there if it's working... I'm at the point where with wobbly it's the blue screen, without wobbly the composite works but X eats up a lot of cpu, everything drags, and the colors get sort of weird.... this is the radeon 7000 in a thinkpad t42 Sam On Fri, Apr 21, 2006 at 12:51:09PM -0400, Sam Folk-Williams wrote: > On Wed, Apr 19, 2006 at 04:00:48PM -0400, Kristian H?gsberg wrote: > > > > $ USE_WOBBLY=1 metacity --replace & > > > > - metacity also has an experimental screen magnifier built in. Like > > the wobbly windows this is enabled by setting an environment variable - > > USE_MAGNIFIER: > > > > $ USE_MAGNIFIER=1 metacity --replace & > > > > As a lot of people are having trouble with these awesome effects - are there > other effects to play with? Like, how does one enable drop shadows or > transparency -- or is it just these two for now? Also, where are these > variables set permanently? > > Thanks, > Sam > > > - real translucency in gnome-terminal. Enable this by clicking the > > "Transparent background" radio box in the "Effects" tab of the termnal > > profile editor dialog. gnome-terminal may have to be restarted for this > > to take effect - pkill gnome-terminal should do the trick. > > > > There are a number of known bugs with these packages, so go easy on > > bugzilla :). Specifically, > > > > - The damage events doesn't always kick in, so sometimes window > > contents doesn't update properly. A workaround for this is to switch > > desktop back and forth. > > > > - The drop shadows look weird on shaped/argb windows, for example > > xeyes, the notify bubbles and well, even the rounded metacity corners. > > The shadow code is due for an overhaul later, so we're not going to > > patch over this issue in the short term. > > > > - Perfomance for in-window updates isn't always great. We're > > currently doing too much work when updating textures from pixmaps. It's > > still possible to optimize this further with the current setup, and > > longer term the memory architecture in the X server and DRI stack will > > see some changes that will allow us to optimize this further. > > > > Have fun, > > Kristian > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > ? Sam Folk-Williams, RHCE ? Red Hat Global Support Services > ? Phone: 919/754-4558 ? Cell: 919/943-9623 > ? Fax: 919/754-3708 ? GPG ID: 1B0D46BA > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- ? Sam Folk-Williams, RHCE ? Red Hat Global Support Services ? Phone: 919/754-4558 ? Cell: 919/943-9623 ? Fax: 919/754-3708 ? GPG ID: 1B0D46BA From dpniner at dpniner.name Fri Apr 21 18:39:03 2006 From: dpniner at dpniner.name (David-Paul Niner) Date: Fri, 21 Apr 2006 14:39:03 -0400 Subject: Fedora core suggestions In-Reply-To: <44491C48.4010101@warmcat.com> References: <44491C48.4010101@warmcat.com> Message-ID: <1145644743.6606.27.camel@fortinbras.dpniner.net> Those are some truly great suggestions; No one reasoning logically should have any reason whatsoever to be offended. It would be nice if the newly-revamped Fedora governing body could include representation from the non-technical community. I realize this is probably a "pie-in-the-sky" expectation, and I can't imagine how one would go about selecting a person (or persons) for this role, but if this could somehow be accomplished then the distribution itself would be more universally appealing. This is not to imply that the current state of the distro is not excellent. Successfully preparing for release something as complex and feature-complete as Fedora Core is a daunting task well undertaken to date. Here are a few quick suggestions off the top of MY head. I realize some of these have been mentioned before: 1. Pre-release non-technical user testing. Integrate this process early in the testing phase. Document the findings and make them easily accessible to everyone, not just the core developers. Host local "touch and feel" sessions to attract users who might want to have a say in the future of the project but don't have the technical background to contribute code. 2. Marketing. Get with the Mozilla people if necessary and figure out what they're doing "right." Just about everyone's heard of Firefox by now. 3. Ego-containment. Leave the egos at the door. 4. Be more open-minded. >From the parent post: "Upgrading needs to be fail proof from version to version. Previously installed drives with personal user data needs to be able to be retained without fail from upgrade to upgrade if the user isn't doing a clean install." Response: "Fedora is very decent at this already." This sort of response shows no willingness to re-examine current practices and is very off-putting to people looking to become involved in the project. Before you bother flaming, I realize these are very general statements. The point is to foster discussion. DP On Fri, 2006-04-21 at 18:54 +0100, Andy Green wrote: > Alo Tsum wrote: > > > how generating revenue to put back into the project and make it more > > self sufficient. So I have a few suggestions which I think the Redhat > > company itself should take note of. Firstly Redhat while promoting Linux > > among enthusiast is also in the business of making money. On that front > > I believe that they should not only attempt to evangelize Linux in the > > Hum let me send out an alternate view: Free Software is outside the Sell > and Evangelize paradigm. It exists, it can be offered, but its meaning > in the world is that it honestly is there for people to use if they have > a use for it. This is something different than commercial OSes that are > there despite you asked to NOT have it, that are shoved down your > throat, sold to you, lock you in and so on. > > > The Fedora project is the perfect tool for this and here is how. The > > fedora team should focus SOLELY on making the operating system run as > > smoothly and as fast as possible, interacting with a HUGE number of > > hardware configurations. Installation needs to be as smooth as silk and > > Wll no argument there since that is useful for everyone. > > > upgrading needs to be fail proof from version to version. Previously > > installed drives with personal user data needs to be able to be retained > > without fail from upgrade to upgrade if the user isn't doing a clean > > Fedora is very decent at this already. > > > install. Now I would like to move on to "partnerships" Fedora project > > should look into making "partners" or some other creative term to define > > other Linux projects and organizations. In this partnership Fedora will > > tightly enforce standards which will ensure that any software created to > > run on fedora is following say the OIN and the GPL standards to the > > RHAT can confidently claim to have written the book on following "GPL > standards". > > > by following strict guidelines they would become Fedora project > > "partners" and in turn they would be promised that their software will > > be included in the fedora core release. Also by following strict > ... > > approach is keeping in mind that projects such as Fedora and other Linux > > distributions desire to penetrate more into the home desktop market, > > Hum again with the 'market', Free software doesn't compete in that > sense, it is offered in the hope that it is useful, you can imagine it > as demand-led. > > > which then also means more users will or could eventually equate to > > greater adoption of the platform in other industries as a result of user > > No insult intended, but you or I don't get paid on the basis of > adoption. I'm sure we're both pleased if there is increased adoption > and maybe you or I will spend some time if we think it will increase > takeup. But nonetheless offering a Free OS like Fedora is a different > game than selling Commercial OSes. > > > Now say a "ambassador" from Fedora can start making the rounds to Dell > > Hum this is the thing, Fedora just is and Dell can take it up if they > like. "Selling" a Free OS seems like a bit of an impedance mismatch. > Why should people already pouring effort into the OS with no direct hope > of return act to improve Dell's worldview as a charitable act if Michael > is too locked into Bill's gravy train to do it himself? > > > at a premium. Fedora core could charge a VERY minimal fee for this > > training, so say charge enough that it would generate revenue that can > ... > > The future of Linux if to be taken seriously should not be relegated to > > If a Free OS is taken seriously is up to the potential users. I take it > real serious already. > > > There needs to be a con[ce]rted effort on the parts of all parties > > involved to take Linux to that next phase of existence other wise Linux > > as a brand, while it may grow some what will not see its full potential. > > With the software being a open and free model we still have to realize > > No. > > -Andy > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- ======================================= David-Paul Niner, RHCE dpniner at dpniner.name Florida, United States of America Public Key for GPG key 1FCE01A2 available from http://www.dpniner.name GPG Fingerprint for key 1FCE01A2: 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 ======================================= -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dragoran at feuerpokemon.de Fri Apr 21 18:44:35 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 21 Apr 2006 20:44:35 +0200 Subject: AIGLX questions -- the x86_64 bit question In-Reply-To: References: Message-ID: <44492813.7060300@feuerpokemon.de> alan wrote: > > Have the x86_64 problems been resolved? The AIGLX wiki has not been > updated since FC5t3. > > Also, what is the status of the NVIDIA drivers? (I find it weird that > XGL has NVIDIA working but not ATI and AIGLX has ATI working, but not > NVIDIA.) > http://www.nvnews.net/vbulletin/showpost.php?p=866581&postcount=5 From andy at warmcat.com Fri Apr 21 19:29:16 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 21 Apr 2006 20:29:16 +0100 Subject: Fedora core suggestions In-Reply-To: <1145644743.6606.27.camel@fortinbras.dpniner.net> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> Message-ID: <4449328C.2040606@warmcat.com> David-Paul Niner wrote: > Those are some truly great suggestions; No one reasoning logically > should have any reason whatsoever to be offended. I am fairly hard to offend - what you read was disagreement. > It would be nice if the newly-revamped Fedora governing body could > include representation from the non-technical community. I realize this > is probably a "pie-in-the-sky" expectation, and I can't imagine how one > would go about selecting a person (or persons) for this role, but if > this could somehow be accomplished then the distribution itself would be > more universally appealing. Could you explain a little deeper about how inclusion of "representation from the non-technical community" at the beginning of your paragraph gets Fedora to be "more universally appealing" by the end? > 1. Pre-release non-technical user testing. The test releases merely need to be given to non-technical users -- by, eg, you -- for this to happen. > 2. Marketing. Why? I know why a commercial product is marketed, the goal is to maximize profit. But I'm not sure of the application to Free software. If you have some philosophical basis for it I am interested to hear it, but you just assume marketing Free software is a righteous goal. >>From the parent post: > > "Upgrading needs to be fail proof from version to version. Previously > installed drives with personal user data needs to be able to be retained > without fail from upgrade to upgrade if the user isn't doing a clean > install." > > Response: > > "Fedora is very decent at this already." > > This sort of response shows no willingness to re-examine current > practices and is very off-putting to people looking to become involved > in the project. That "sort of response" in fact shows my excellent experience with an rpm-based upgrade system, eg, upgrading boxes from FC1 through FC4 using yum. As I said Fedora IS very decent at this already thanks to the solid basis of RPM. If you believe otherwise please elaborate. > Before you bother flaming, I realize these are very general statements. > The point is to foster discussion. If you want to foster discussion, please issue considered argumentation, not unreasoned bulletpoints. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From davea at sucs.org Fri Apr 21 18:32:54 2006 From: davea at sucs.org (Dave Arter) Date: Fri, 21 Apr 2006 20:32:54 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604170323.18200.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604170109t3d311d0ewe09170c4948435bc@mail.gmail.com> <200604170323.18200.nman64@n-man.com> Message-ID: Patrick W. Barnes wrote: > On Monday 17 April 2006 03:09, "Arthur Pemberton" wrote: > >>What became of the Backup tool from last year's SOC? >> > > > https://sucs.org/~davea/trac/ > > The developer disappeared. > > I tried not to entirely disappear, however time has been at a premium because I'm a final year student. I intend to apply to continue with pyBackPack this summer, but don't let that put anyone else off of doing the same :) From steve at silug.org Fri Apr 21 19:57:59 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 21 Apr 2006 14:57:59 -0500 Subject: Google Summer of Code 2006: iptables GUI In-Reply-To: <4ACD125F91AB802EF3B3EC9F@[169.254.160.111]> References: <4ACD125F91AB802EF3B3EC9F@[169.254.160.111]> Message-ID: <20060421195759.GA26987@osiris.silug.org> On Thu, Apr 20, 2006 at 07:15:20AM -0700, Kenneth Porter wrote: > BTW, as long as I'm in brainstorm mode, a GUI front end for the traffic > shaper system (http://lartc.org/) would also be nice. Or at least > initscripts to manage it. Someone picking up maintenance of htb-util in Extras would be nice... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From vikasx.aggarwal at intel.com Fri Apr 21 20:05:09 2006 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Fri, 21 Apr 2006 13:05:09 -0700 Subject: corrupt package message during FC5 install from NFS. Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A0857215F@orsmsx408> Thanks !! Now I have this error for my custom distro. " Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated. failure: repodata/repomd.xml from anaconda: [Errno 256] No more mirros to try." I am doing anaconda --test -m nfs:/fedora Please help me in troubleshoot this. What can be wrong with my steps. I am doing createrepo+ buildinstall+ splittree.py. -vikas -----Original Message----- From: Paul Nasrat [mailto:pnasrat at redhat.com] Sent: Friday, April 21, 2006 6:20 AM To: Aggarwal, VikasX Cc: Anaconda-devel-list at redhat.com; fedora-devel-list at redhat.com Subject: Re: corrupt package message during FC5 install from NFS. On Thu, 2006-04-20 at 15:52 -0700, Aggarwal, VikasX wrote: > Hi, > > I am trying to do install from NFS of a custom distribution which is > based on FC5test3. > > > > After formatting the local drive the anaconda-installer shows message - "The package traceroute-1.0.4-1.2.i386 cannot be opened. This is due to missing file or perhaps the corrupt package. If you are installing from CD media this usually means the CD is corrupt, or the CD drive is unable to read media". You probably want to rebase to FC5 GOLD before doing any customisation. Some of these error paths were caught. Ensure you have run createrepo on your tree correctly and there are no I/O errors on tty4. Paul From pnasrat at redhat.com Fri Apr 21 20:15:22 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 21 Apr 2006 16:15:22 -0400 Subject: corrupt package message during FC5 install from NFS. In-Reply-To: <69F69FD5FD4A9843ACBF7CE9B7830B4A0857215F@orsmsx408> References: <69F69FD5FD4A9843ACBF7CE9B7830B4A0857215F@orsmsx408> Message-ID: <1145650523.7185.9.camel@enki.eridu> On Fri, 2006-04-21 at 13:05 -0700, Aggarwal, VikasX wrote: > Thanks !! > Now I have this error for my custom distro. > " Unable to read package metadata. This may be due to a missing > repodata directory. Please ensure that your install tree has been > correctly generated. failure: repodata/repomd.xml from anaconda: [Errno > 256] No more mirros to try." > > I am doing anaconda --test -m nfs:/fedora ls /fedora ls /fedora/repodata I'd expect /fedora/base /fedora/RPMS /fedora/repodata Then repomd.xml primary.xml.gz and some other files in repodata: comps.xml filelists.xml.gz other.xml.gz primary.xml.gz repomd.xml Paul From vikasx.aggarwal at intel.com Fri Apr 21 21:19:06 2006 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Fri, 21 Apr 2006 14:19:06 -0700 Subject: corrupt package message during FC5 install from NFS. Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A08572345@orsmsx408> comps.xml is in different folder(listed below). -----Original Message----- From: Paul Nasrat [mailto:pnasrat at redhat.com] Sent: Friday, April 21, 2006 1:15 PM To: Aggarwal, VikasX Cc: Anaconda-devel-list at redhat.com; fedora-devel-list at redhat.com Subject: RE: corrupt package message during FC5 install from NFS. On Fri, 2006-04-21 at 13:05 -0700, Aggarwal, VikasX wrote: > Thanks !! > Now I have this error for my custom distro. > " Unable to read package metadata. This may be due to a missing > repodata directory. Please ensure that your install tree has been > correctly generated. failure: repodata/repomd.xml from anaconda: [Errno > 256] No more mirros to try." > > I am doing anaconda --test -m nfs:/fedora ls /fedora ls /fedora/repodata I'd expect /fedora/base /fedora/RPMS /fedora/repodata Then repomd.xml primary.xml.gz and some other files in repodata: comps.xml filelists.xml.gz other.xml.gz primary.xml.gz repomd.xml comps.xml is in different folder(listed below). [root at puru i386]# ls autorun Fedora images README RELEASE-NOTES RPM-GPG-KEY RPM-GPG-KEY-fedora RPM-GPG-KEY-fedora-test eula.txt GPL isolinux README-Accessibility repodata RPM-GPG-KEY-beta RPM-GPG-KEY-fedora-rawhide RPM-GPG-KEY-rawhide [root at puru i386]# pwd /Fedora5/fc3/i386 [root at puru i386]# ls autorun Fedora images README RELEASE-NOTES RPM-GPG-KEY RPM-GPG-KEY-fedora RPM-GPG-KEY-fedora-test eula.txt GPL isolinux README-Accessibility repodata RPM-GPG-KEY-beta RPM-GPG-KEY-fedora-rawhide RPM-GPG-KEY-rawhide [root at puru i386]# ls -l repodata total 7836 -rw-r--r-- 1 root root 2238587 Apr 20 17:58 filelists.xml.gz -rw-r--r-- 1 root root 4993169 Apr 20 17:58 other.xml.gz -rw-r--r-- 1 root root 761837 Apr 20 17:58 primary.xml.gz -rw-r--r-- 1 root root 951 Apr 20 17:58 repomd.xml [root at puru i386]# uname -a Linux puru 2.6.15-1.1955_FC5hypervisor #1 SMP Wed Feb 15 16:21:02 EST 2006 i686 i686 i386 GNU/Linux [root at puru i386]# which anaconda /usr/sbin/anaconda [root at puru i386]# la -a bash: la: command not found [root at puru i386]# ls -a . autorun eula.txt GPL isolinux README RELEASE-NOTES RPM-GPG-KEY RPM-GPG-KEY-fedora RPM-GPG-KEY-fedora-test .. .discinfo Fedora images .olddata README-Accessibility repodata RPM-GPG-KEY-beta RPM-GPG-KEY-fedora-rawhide RPM-GPG-KEY-rawhide [root at puru i386]# find . | grep comps.xml ./.olddata/comps.xml ./Fedora/base/comps.xml [root at puru i386]# ls -l ./.olddata/comps.xml ./Fedora/base/comps.xml -rw-r--r-- 2 root root 698401 Apr 5 09:22 ./Fedora/base/comps.xml -rw-r--r-- 2 root root 698401 Apr 20 17:44 ./.olddata/comps.xml [root at puru i386]# Paul From alotsum at gmail.com Fri Apr 21 21:33:18 2006 From: alotsum at gmail.com (Alo Tsum) Date: Fri, 21 Apr 2006 17:33:18 -0400 Subject: fedora core suggestions Message-ID: I see some individuals got what I was saying concerning my original "Fedora core suggestions" post while others don't; so let me clear up some misconceptions. My point in bringing up marketing in relation to the Fedora project and proselytizing the OS, comes from a business background, I have my degree in International economics. I know for a lot of my suggestions to happen there has to be "buy in". Simply put all parties involved have to want to be a part of the model I suggested; which they will once they see whats in it for them. I brought up certain aspects ie the "bottom up" approach to show how this benefits Redhat in the long run. If they see a over all benefit besides just releasing the Fedora Cores as testing grounds for for the enterprise OS then they would be willing to venture outside of their present paradigm. As for the Dell situation I brought up, as I said before it would not be Dell reselling FREE software, but instead bundling the free software with their hardware offerings which would allow them to offer their hardware at lower cost but again that goes back to the concept of "buy in". As for the suggestion about allowing non technical persons to test the software and do installs that is a great idea. The reason for it would be so those involved in the project can truly see how easy and user friendly their software is or isn't. All companies small, big, not for profit or for profit have to do testing on a larger enough sample pool for the testing to truly be meaningful so this again is a great idea. I hope I didn't offend anyone, as I saw some of the responses seemed to be on the defensive side. Last but not least someone brought up the marketing idea I presented, and to them I say what exactly do you think the "Ambassador" roles that Fedora Project has on their site is supposed to do? That my friend is classic grass roots marketing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpniner at dpniner.name Fri Apr 21 21:34:01 2006 From: dpniner at dpniner.name (David-Paul Niner) Date: Fri, 21 Apr 2006 17:34:01 -0400 Subject: Fedora core suggestions In-Reply-To: <4449328C.2040606@warmcat.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> Message-ID: <1145655241.7517.29.camel@fortinbras.dpniner.net> >"If you want to foster discussion, please issue considered >argumentation, not unreasoned bulletpoints." Life Lesson #0: This is just the sort of response that causes people to assume defensive postures. Your assumption that your personal experiences in regards to rpm-based upgrades are reflective of the collective experiences of all users is incorrect. Overall, the process may be "excellent," but there is clearly room for some improvement, or someone wouldn't have bothered posting about it to a mailing list, would they? In regards to the involvement of non-technical individuals earlier in the testing process, I believe I was quite clear in my original message that I did not know exactly how the project should go about implementing that. Please, calm down and read my message again. Maybe 100 people will believe that to be a ridiculous idea, but if a handful of people start talking about it, who knows where it would lead? Also, you're awarding yourself an unrealistic amount of self-importance in a group discussion. ;-) DP -- ======================================= David-Paul Niner, RHCE dpniner at dpniner.name Florida, United States of America Public Key for GPG key 1FCE01A2 available from http://www.dpniner.name GPG Fingerprint for key 1FCE01A2: 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 ======================================= On Fri, 2006-04-21 at 20:29 +0100, Andy Green wrote: > David-Paul Niner wrote: > > > Those are some truly great suggestions; No one reasoning logically > > should have any reason whatsoever to be offended. > > I am fairly hard to offend - what you read was disagreement. > > > It would be nice if the newly-revamped Fedora governing body could > > include representation from the non-technical community. I realize this > > is probably a "pie-in-the-sky" expectation, and I can't imagine how one > > would go about selecting a person (or persons) for this role, but if > > this could somehow be accomplished then the distribution itself would be > > more universally appealing. > > Could you explain a little deeper about how inclusion of "representation > from the non-technical community" at the beginning of your paragraph > gets Fedora to be "more universally appealing" by the end? > > > 1. Pre-release non-technical user testing. > > The test releases merely need to be given to non-technical users -- by, > eg, you -- for this to happen. > > > 2. Marketing. > > Why? I know why a commercial product is marketed, the goal is to > maximize profit. But I'm not sure of the application to Free software. > If you have some philosophical basis for it I am interested to hear > it, but you just assume marketing Free software is a righteous goal. > > >>From the parent post: > > > > "Upgrading needs to be fail proof from version to version. Previously > > installed drives with personal user data needs to be able to be retained > > without fail from upgrade to upgrade if the user isn't doing a clean > > install." > > > > Response: > > > > "Fedora is very decent at this already." > > > > This sort of response shows no willingness to re-examine current > > practices and is very off-putting to people looking to become involved > > in the project. > > That "sort of response" in fact shows my excellent experience with an > rpm-based upgrade system, eg, upgrading boxes from FC1 through FC4 using > yum. As I said Fedora IS very decent at this already thanks to the > solid basis of RPM. If you believe otherwise please elaborate. > > > Before you bother flaming, I realize these are very general statements. > > The point is to foster discussion. > > If you want to foster discussion, please issue considered argumentation, > not unreasoned bulletpoints. > > -Andy > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sdl.web at gmail.com Fri Apr 21 21:39:24 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 21 Apr 2006 22:39:24 +0100 Subject: [NEW IDEA] Automatic removal of dependencies Message-ID: Dear all, This is something new and missing for linux. I think it's a great idea. The following wiki page explains clearly. https://wiki.ubuntu.com/PackageDependencyManagement -- Leon From seanlkml at sympatico.ca Fri Apr 21 21:34:16 2006 From: seanlkml at sympatico.ca (sean) Date: Fri, 21 Apr 2006 17:34:16 -0400 Subject: fedora core suggestions In-Reply-To: References: Message-ID: On Fri, 21 Apr 2006 17:33:18 -0400 "Alo Tsum" wrote: > Last but not least someone brought up the marketing idea I presented, and to > them I say what exactly do you think the "Ambassador" roles that Fedora > Project has on their site is supposed to do? That my friend is classic grass > roots marketing. You might want to checkout the fedora-marketing-list Cheers, Sean From mike at miketc.com Fri Apr 21 21:51:35 2006 From: mike at miketc.com (Mike Chambers) Date: Fri, 21 Apr 2006 16:51:35 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <20060421182611.GA23491@xander.rdu.redhat.com> References: <444696F0.9080801@redhat.com> <20060421165109.GA22901@xander.rdu.redhat.com> <20060421182611.GA23491@xander.rdu.redhat.com> Message-ID: <1145656295.2479.0.camel@scrappy.miketc.com> On Fri, 2006-04-21 at 14:26 -0400, Sam Folk-Williams wrote: > Sorry -- I figured this out. The drop shadows should just be there if it's > working... I'm at the point where with wobbly it's the blue screen, without > wobbly the composite works but X eats up a lot of cpu, everything drags, and > the colors get sort of weird.... this is the radeon 7000 in a thinkpad t42 Experienced the same thing without wobbly and X eating up lots of CPU. This is a Radeon 9000 Pro. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important until you aren't getting any!" From dpniner at dpniner.name Fri Apr 21 22:04:12 2006 From: dpniner at dpniner.name (David-Paul Niner) Date: Fri, 21 Apr 2006 18:04:12 -0400 Subject: fedora core suggestions In-Reply-To: References: Message-ID: <1145657052.7852.8.camel@fortinbras.dpniner.net> On Fri, 2006-04-21 at 17:33 -0400, Alo Tsum wrote: > > As for the suggestion about allowing non technical persons to test the > software and do installs that is a great idea. The reason for it would > be so those involved in the project can truly see how easy and user > friendly their software is or isn't. All companies small, big, not for > profit or for profit have to do testing on a larger enough sample pool > for the testing to truly be meaningful so this again is a great idea. That was my original thought for their involvement--to get direct feedback in regards to application design: What to leave in, What to leave out. Another latent effect is that the process may produce a bit of indirect "buy in." Wouldn't you think an organization would be more likely to give the product a test drive if they felt as though they had made some contribution to it's design? DP ======================================= David-Paul Niner, RHCE dpniner at dpniner.name Florida, United States of America Public Key for GPG key 1FCE01A2 available from http://www.dpniner.name GPG Fingerprint for key 1FCE01A2: 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 ======================================= -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From stickster at gmail.com Fri Apr 21 22:15:39 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 21 Apr 2006 18:15:39 -0400 Subject: Fedora core suggestions In-Reply-To: <4449328C.2040606@warmcat.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> Message-ID: <1145657739.27565.19.camel@localhost.localdomain> On Fri, 2006-04-21 at 20:29 +0100, Andy Green wrote: > > 1. Pre-release non-technical user testing. > > The test releases merely need to be given to non-technical users -- by, > eg, you -- for this to happen. Or: s/given to/downloaded and run by/ One alternative for non-technical users which Jef Spaleta mentioned a little while ago in IRC was testing of high-level functionality and interfaces using VMWare Player and an image provided by Fedora. This would potentially lower barriers not only to non-technical users but to willing folks who only have a single system available, or have a low risk threshold for some other reason. VMWare has opened its VMDK (virtual disk) format for use by anyone[1] so there's nothing preventing an intrepid Fedora hacker from designing a converter program. The community could then make some decisions about one or more "test platform" images that could be converted to VMDK and distributed via the existing BitTorrent tracker. People using either Windows or Linux could then download the free VMWare Player to run the Fedora VMDK image. = = = = = [1] I don't recall the exact license terms, but they are extremely liberal and would allow, for instance, a GPL-licensed converter program AIUI. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andy at warmcat.com Fri Apr 21 22:22:56 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 21 Apr 2006 23:22:56 +0100 Subject: Fedora core suggestions In-Reply-To: <1145655241.7517.29.camel@fortinbras.dpniner.net> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> Message-ID: <44495B40.8020800@warmcat.com> David-Paul Niner wrote: >> "If you want to foster discussion, please issue considered >> argumentation, not unreasoned bulletpoints." > > Life Lesson #0: This is just the sort of response that causes people to > assume defensive postures. I don't mind if you feel the need to form a defensive posture on being told you posted a load of handwaving junk. Have at it. > Your assumption that your personal experiences in regards to rpm-based > upgrades are reflective of the collective experiences of all users is > incorrect. Overall, the process may be "excellent," but there is > clearly room for some improvement, or someone wouldn't have bothered > posting about it to a mailing list, would they? I have bad news: many posts on the Internet are made if there is a valid point to them or not. If, as the original poster, you feel that upgrade installs are broken, please talk about that. My experience is I have done yum dist-upgrades, CD upgrades and CD reinstalls and the only way I blew user data away was if I reformatted the filesystem. If you have anything to add that doesn't fit with that experience, please talk about it. > In regards to the involvement of non-technical individuals earlier in > the testing process, I believe I was quite clear in my original message > that I did not know exactly how the project should go about implementing > that. Please, calm down and read my message again. It seems I correctly apprehended the missing middle in your message the first time, thanks. > Also, you're awarding yourself an unrealistic amount of self-importance > in a group discussion. > > ;-) Good job you were standing by with a "life lesson". Have a nice evening. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From pemboa at gmail.com Fri Apr 21 23:02:41 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Apr 2006 18:02:41 -0500 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> On 4/21/06, Alo Tsum wrote: > > Fedora Core 5 is a truly amazing OS and one I think has the potential to > really do great things. Tell that to the guys at /. [ snip ] > > First suggestions has to do with the software side of things. We users need > a competent software installer which is graphical based. The problem here is that there are several options, and Fedora has chosen to stick with Pirut. I am personally not a fan of the GUI style used by Pirut, but it is quite possible that I am in the minority in this regard. > One that functions > much the same way that the windows installer works. > This installer should track dependencies naturally and place icons on the desktop or give the > option to have icons for the software just installed to be placed on the > desktop of the user as well as in the applications menu. Also when watching This is somewhat impossible, the software is installed very much different than on Windows. The last thing i think we in general want is for packagers to take it upon themselves to get packages to put icons on the desktop. In all fairness though there there are multiplatform GUI based software installers available: InstallShield has one, this company also has one: http://www.installjammer.com/ > the Boston Linux conference the suggestion was made to offer a hard disc > manager much like windows offers for formating and receiving hard drivers > etc after installation. I agree here, however, it would have to be much better, Windows (natively) only supports a few file systems. > > My second set of suggestions will deal with the over all focus and structure > of the fedora project. I was listening to a pod cast interview with the head > of the fedora project where in, the topic came up of some how generating > revenue to put back into the project and make it more self sufficient. So I > have a few suggestions which I think the Redhat company itself should take > note of. Firstly Redhat while promoting Linux among enthusiast is also in > the business of making money. On that front I believe that they should not > only attempt to evangelize Linux in the government, education, and corporate > sectors; they should also attempt to get Linux in each and every home. I wish Redhat would approach my home government and make them an offer they can't refuse. But people hate change. > The > reason being is if people are starting to use Linux in their homes and they > are comfortable with it, employers will be more likely and willing to deploy > a operating system which is different in many ways to windows on the > interactive level. Reason being is when people have to stop to learn new > technology this cuts down on productivity and as a person who works for a IT > department in a major university I can also vouch for the fact a IT team > will not be willing to suggest an infrastructure restructuring when they > know, supporting users on something foreign to them is going to increase > their workload 10 fold. I do not totally agree here. A properly setup Linux distro used for simple end user tasks should be easier to admin that a similair Windows system. > So bottom line, more users both advanced, > intermediate and beginners need to be converted to the Linux faithful but > now the question becomes how? > I disagree with you fully here. I hate Windows (except for playing Age of Empires) and I love Linux (esp. KDE and associated apps) but I do _not_ think anyone people in general _need_ to be converted to Linux, that seems very much a pipe dream. To each their own, I used to spend hours fixign peoples Window's machines, I have simply decided to never do that again unless I get paid. So everyone should use what they feel does the job for them. I used Windows since 3.1, and I can't imagine going back from Fedora/KDE fulltime right now. > The Fedora project is the perfect tool for this and here is how. The fedora > team should focus SOLELY on making the operating system run as smoothly and > as fast as possible, interacting with a HUGE number of hardware > configurations. See now, here you have a problem. This is not the M.O of the Fedora Project. Fedora was not intended to be a "pretty" desktop/home user operating system. > Installation needs to be as smooth as silk and upgrading > needs to be fail proof from version to version. That is a very tall order IMHO. > Previously installed drives > with personal user data needs to be able to be retained without fail from > upgrade to upgrade if the user isn't doing a clean install. Another tall order, but I think this is very important myself however. [ snip ] -- As a boy I jumped through Windows, as a man I play with Penguins. From jspaleta at gmail.com Fri Apr 21 23:08:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 19:08:23 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: Message-ID: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> On 4/21/06, Leon wrote: > Dear all, > > This is something new and missing for linux. I think it's a great > idea. The following wiki page explains clearly. > > https://wiki.ubuntu.com/PackageDependencyManagement automatic removal of dependancies.. will only work if all applications and scripts on the system are managed by the package management system. That means that nothing on the system can be installed via source which makes it outside the scope of the package management system which may be using an "indirect" dependancy. Nothing can be install from an alternative catelog like CPAN.. which may be using an "indirect" dependancy. Nothing can be written locally as a script, shell or perl or python or php or otherwise... that may use an "indirect" dependancy. This only robustly works if every library and every executable and every intepretable script which could be calling other executables on the system is strictly managed by the package management system. Snowball's chance in that happening on a anything close to 90% of deployed systems. Whether its multiuser moderate to large network deployments, or someone's home workstation the chance that a system is rpm pure for every executable and script on the system is slim. -jef From philipp_subx at redfish-solutions.com Fri Apr 21 23:16:11 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 21 Apr 2006 17:16:11 -0600 Subject: Madwifi/wpa_supplicant packaging Message-ID: <444967BB.7010504@redfish-solutions.com> I was looking at the way wpa_supplicant was packaged, and wondered why not make it dependent instead on madwifi-devel or madwifi-headers instead (and tweak that src.rpm accordingly as well). Or it could optionally detect the presence of the madwifi headers, and enable CONFIG_DRIVER_MADWIFI=y automatically... I like the functionality of the FC5 wpa_supplicant, but it doesn't play well with the madwifi rpm's from ATrpms. That way if you grab madwifi from ATrpms, and rebuild wpa_supplicant from source it will do the right thing... Seem reasonable? -Philip From dlutter at redhat.com Fri Apr 21 23:17:16 2006 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 21 Apr 2006 16:17:16 -0700 Subject: Puppet Re: Kickstart and roles In-Reply-To: References: <80d7e4090604190916sa532fe5h9d7754967c287257@mail.gmail.com> Message-ID: <1145661437.6880.75.camel@currant.watzmann.net> On Thu, 2006-04-20 at 15:17 -0600, Orion Poplawski wrote: > Stephen John Smoogen wrote: > > If I understood what Luke was working on with puppet, the program is > > meant to be a re-engineering of cfengine to be less of an academic > > testbed and more of stable product. [I might be part of the reason for > > the fact it is in Ruby.. I suggested it a long time ago when Luke was > > giving a training course.] > > > > Since the puppet and facter spec files at > http://reductivelabs.com/downloads/rpm/ have changelog entries like: As Jeremy pointed out, I've been working on packaging puppet (and its dependency facter) for FE; I keep the latest RPM's at http://people.redhat.com/dlutter/yum/ John Mahowald is doing the review for facter - I am sure he won't object to anybody grabbing the puppet review request (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180571) David From dpniner at dpniner.name Fri Apr 21 23:23:17 2006 From: dpniner at dpniner.name (David-Paul Niner) Date: Fri, 21 Apr 2006 19:23:17 -0400 Subject: Fedora core suggestions In-Reply-To: <44495B40.8020800@warmcat.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> <44495B40.8020800@warmcat.com> Message-ID: <1145661797.8777.8.camel@fortinbras.dpniner.net> This "life lesson" was meant to be just that -- something for you take away and digest. I do sincerely apologize if I embarrassed you; it was a bad call for me to write what I did. I now realize, however, it seems quite likely that you could benefit from some talking with someone about things, as you seem quite angry: "I don't mind if you feel the need to form a defensive posture on being told you posted a load of handwaving junk." My original intention was not to put down you or the project, it was merely to generate some discussion. It's just not worth it. Seriously, best of luck; I have nothing against you and wish you well. ======================================= David-Paul Niner, RHCE dpniner at dpniner.name Florida, United States of America Public Key for GPG key 1FCE01A2 available from http://www.dpniner.name GPG Fingerprint for key 1FCE01A2: 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 ======================================= > >> "If you want to foster discussion, please issue considered > >> argumentation, not unreasoned bulletpoints." > > > > Life Lesson #0: This is just the sort of response that causes people to > > assume defensive postures. > > I don't mind if you feel the need to form a defensive posture on being > told you posted a load of handwaving junk. Have at it. > > > Your assumption that your personal experiences in regards to rpm-based > > upgrades are reflective of the collective experiences of all users is > > incorrect. Overall, the process may be "excellent," but there is > > clearly room for some improvement, or someone wouldn't have bothered > > posting about it to a mailing list, would they? > > I have bad news: many posts on the Internet are made if there is a valid > point to them or not. If, as the original poster, you feel that upgrade > installs are broken, please talk about that. My experience is I have > done yum dist-upgrades, CD upgrades and CD reinstalls and the only way I > blew user data away was if I reformatted the filesystem. If you have > anything to add that doesn't fit with that experience, please talk about it. > > > In regards to the involvement of non-technical individuals earlier in > > the testing process, I believe I was quite clear in my original message > > that I did not know exactly how the project should go about implementing > > that. Please, calm down and read my message again. > > It seems I correctly apprehended the missing middle in your message the > first time, thanks. > > > Also, you're awarding yourself an unrealistic amount of self-importance > > in a group discussion. > > > > ;-) > > Good job you were standing by with a "life lesson". > > Have a nice evening. > > -Andy > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jspaleta at gmail.com Fri Apr 21 23:27:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 19:27:18 -0400 Subject: Fedora core suggestions In-Reply-To: <1145655241.7517.29.camel@fortinbras.dpniner.net> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> Message-ID: <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> On 4/21/06, David-Paul Niner wrote: > Maybe 100 people will believe that to be a ridiculous idea, but if a > handful of people start talking about it, who knows where it would lead? I know where it will lead... to a 120 post long thread with 12 participants. 6 of which think their ideas are great but don't have the resources to implement any of them. The other 6 thinks the ideas are bad and have decided that convincing the other 6 through sheer superhuman retorical prowess is a constructive way to earn brownie points with the 5 people in the thread that agree with them. No wait 13 particpants. The 13th participant who hates everyone on general principle and only gets involved in the discussion because the themes being badly expressed by the other 12 people are too important to not have something worthwhile come out of the discussion. -jef"Generally good ideas are generally very bad discussions. Boring, mind-numbing detailed specific implementation issues are far more constructive discussions"spaleta From jspaleta at gmail.com Fri Apr 21 23:34:32 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 19:34:32 -0400 Subject: Fedora core suggestions In-Reply-To: <1145657739.27565.19.camel@localhost.localdomain> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> Message-ID: <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> On 4/21/06, Paul W. Frields wrote: > One alternative for non-technical users which Jef Spaleta mentioned a > little while ago in IRC was testing of high-level functionality and > interfaces using VMWare Player and an image provided by Fedora. This > would potentially lower barriers not only to non-technical users but to > willing folks who only have a single system available, or have a low > risk threshold for some other reason. > > VMWare has opened its VMDK (virtual disk) format for use by anyone[1] so > there's nothing preventing an intrepid Fedora hacker from designing a > converter program. The community could then make some decisions about > one or more "test platform" images that could be converted to VMDK and > distributed via the existing BitTorrent tracker. People using either > Windows or Linux could then download the free VMWare Player to run the > Fedora VMDK image. Someone has to check on the licensing is for the VMDK crap. My IRC musing was a whatif.. based on the assumption that the VMDK crap made it possible to engineer a player image with a yet-to-be-created open tool. Its possible right now to have player images, we saw the community create them in the fc5 testing phase. But i strongly feel the Fedora project shouldn't be offering official vmware player images until its possible to create those images with an open tool. I'm desperately hopeful that the VMDK licensing change is enough to make such an open tool possible. But as other pointed out in the same irc discussion special purposed images that I was thinking of have a very high bandwidth consumption. There might be another way to do a similar thing with a centralize vnc or FreeNX terminal server, which we give out "tester" accounts to and pre-configure some logins and log how people do specific tasks on that terminal server. Basically a central terminal server Fedora sets up designed to delibrately watch how people interact with the system. -jef From dpniner at dpniner.name Fri Apr 21 23:41:11 2006 From: dpniner at dpniner.name (David-Paul Niner) Date: Fri, 21 Apr 2006 19:41:11 -0400 Subject: Fedora core suggestions In-Reply-To: <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> Message-ID: <1145662871.8879.2.camel@fortinbras.dpniner.net> On Fri, 2006-04-21 at 19:27 -0400, Jeff Spaleta wrote: > On 4/21/06, David-Paul Niner wrote: > > Maybe 100 people will believe that to be a ridiculous idea, but if a > > handful of people start talking about it, who knows where it would lead? > > I know where it will lead... to a 120 post long thread with 12 > participants. 6 of which think their ideas are great but don't have > the resources to implement any of them. The other 6 thinks the ideas > are bad and have decided that convincing the other 6 through sheer > superhuman retorical prowess is a constructive way to earn brownie > points with the 5 people in the thread that agree with them. No wait > 13 particpants. The 13th participant who hates everyone on general > principle and only gets involved in the discussion because the themes > being badly expressed by the other 12 people are too important to not > have something worthwhile come out of the discussion. > > -jef"Generally good ideas are generally very bad discussions. Boring, > mind-numbing detailed specific implementation issues are far more > constructive discussions"spaleta I've learned my own life lesson! ;-) DP ======================================= David-Paul Niner, RHCE dpniner at dpniner.name Florida, United States of America Public Key for GPG key 1FCE01A2 available from http://www.dpniner.name GPG Fingerprint for key 1FCE01A2: 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 ======================================= -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sdl.web at gmail.com Fri Apr 21 23:50:14 2006 From: sdl.web at gmail.com (Leon) Date: Sat, 22 Apr 2006 00:50:14 +0100 Subject: [NEW IDEA] Automatic removal of dependencies References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: "Jeff Spaleta" writes: > On 4/21/06, Leon wrote: >> Dear all, >> >> This is something new and missing for linux. I think it's a great >> idea. The following wiki page explains clearly. >> >> https://wiki.ubuntu.com/PackageDependencyManagement > > automatic removal of dependancies.. will only work if all applications > and scripts on the system are managed by the package management > system. That means that nothing on the system can be installed via > source which makes it outside the scope of the package management > system which may be using an "indirect" dependancy. > Nothing can be install from an alternative catelog like CPAN.. which > may be using an "indirect" dependancy. Nothing can be written locally > as a script, shell or perl or python or php or otherwise... that may > use an "indirect" dependancy. > > This only robustly works if every library and every executable and > every intepretable script which could be calling other executables on > the system is strictly managed by the package management system. > Snowball's chance in that happening on a anything close to 90% of > deployed systems. Whether its multiuser moderate to large network > deployments, or someone's home workstation the chance that a system is > rpm pure for every executable and script on the system is slim. > > -jef I think you didn't get the idea right. Basically they want to divide packages (of course installed by package manager; those installed using source, the user has to track themselves) into two groups: one is installed by the user (explicitly 'yum install') and the other is those required to satisfy the dependence. Ubuntu put this *high* priority for the next release after dapper. After reading its wiki page, it make sense to me. And I believe it will be useful. -- Leon From pemboa at gmail.com Fri Apr 21 23:49:58 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 21 Apr 2006 18:49:58 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: <16de708d0604211649y269e0d91la2fbba0dcc621cff@mail.gmail.com> > Basically they want to divide packages (of course installed by package > manager; those installed using source, the user has to track > themselves) into two groups: one is installed by the user (explicitly > 'yum install') and the other is those required to satisfy the > dependence. I don't get it. Why? What's the point of this? -- As a boy I jumped through Windows, as a man I play with Penguins. From thacker at math.cornell.edu Sat Apr 22 00:12:42 2006 From: thacker at math.cornell.edu (John Thacker) Date: Fri, 21 Apr 2006 20:12:42 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <16de708d0604211649y269e0d91la2fbba0dcc621cff@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <16de708d0604211649y269e0d91la2fbba0dcc621cff@mail.gmail.com> Message-ID: <20060422001242.GA17052@thacker.dyndns.org> On Fri, Apr 21, 2006 at 06:49:58PM -0500, Arthur Pemberton wrote: > > Basically they want to divide packages (of course installed by package > > manager; those installed using source, the user has to track > > themselves) into two groups: one is installed by the user (explicitly > > 'yum install') and the other is those required to satisfy the > > dependence. > > I don't get it. Why? What's the point of this? The point, I imagine is something like: "With gnucash finally moved to GTK2, all the actual programs I had installed that used various GTK1 and GNOME1 libraries installed no longer use them. These libraries, which aren't real applications but only for support of end-user applications, take up extra space. I'd like them to be automatically removed." or "I told yum to install application X, and it had to install 10 other packages for dependencies. I now want to remove application X, and it sure would be nice if those dependencies all got removed at the same time automatically, since nothing else uses them. After all, it's easier for me to just remember end-user application X, which I actually use directly, than to remember it and the list of support libraries that got installed with it." Whether it's worth the effort involved to save the disk space and all, I don't know. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Sat Apr 22 00:18:50 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Apr 2006 20:18:50 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> On 4/21/06, Leon wrote: > Basically they want to divide packages (of course installed by package > manager; those installed using source, the user has to track > themselves) into two groups: one is installed by the user (explicitly > 'yum install') and the other is those required to satisfy the > dependence. Oh i get it.. and what I'm saying is I think you under-estimate how difficult it will be to robustly use automatical removal of dependancies marked for autoremoval without causing problems with crap that is not tracked by the package management system. I think you underestimate how often people install tools that were part of an automatically included dependancy which end up being used in scripts that were written locally that are not tracked in the rpm system. Little perl scripts, little shell scripts, little python scripts, little php scripts. Hell anyone running any sort of website with php enabled is most likely running some sort of not rpm managed php junk that is in fact configured to exec other binaries, binaries which may be marked as an indirect dependancy of some other package which would be removed via the automatic dependance removal feature. > > Ubuntu put this *high* priority for the next release after > dapper. After reading its wiki page, it make sense to me. And I > believe it will be useful. Sure it will be useful to some segment of the userbase I don't dispute that. What I think that it will also be a huge problem when people start turning that feature on and they see tools their homebrew scripts needed start disappearing on a large scale. I guess time will tell. I hope for the sake of Ubuntu users the people who implement this provide a cookie-cutter way for a local admin to exclude certain packages from the autoremove pool to prevent random script breakage. Or even better they provide a tool which can audit perl,python,ruby,php,shell scripts that are not being managed by the package management system before autoremovals of deps happen. -jef"Oh look I dont really need the sysstat package installed.. I'll just remove it from my system. Oh look sysstat is the only think which explictly needs the vixie-cron package. Hey look vixie-cron is marked as something that package manager can automatically remove because it was not an explicit application that I ask to install, it was pulled in by sysstat at install time. Oh crap my cron system was removed.. now none of my per-user cron jobs run. Yippie for ease-of-use software innovation!!!!!"spaleta From jdogalt at yahoo.com Sat Apr 22 01:03:17 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 21 Apr 2006 18:03:17 -0700 (PDT) Subject: any reason why system-config-kickstart requires root? Message-ID: <20060422010317.43857.qmail@web38415.mail.mud.yahoo.com> I can't think of one, and running /usr/share/system-config-kickstart/system-config-kickstart.py manually seems to work just fine (I saved my kickstart file without incident). Should I file a bug? -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From benjy.grogan at gmail.com Sat Apr 22 01:03:29 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 21 Apr 2006 21:03:29 -0400 Subject: Fedora core suggestions In-Reply-To: <1145662871.8879.2.camel@fortinbras.dpniner.net> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> <1145662871.8879.2.camel@fortinbras.dpniner.net> Message-ID: On 4/21/06, David-Paul Niner wrote: > On Fri, 2006-04-21 at 19:27 -0400, Jeff Spaleta wrote: > > On 4/21/06, David-Paul Niner wrote: > > > Maybe 100 people will believe that to be a ridiculous idea, but if a > > > handful of people start talking about it, who knows where it would lead? > > > > I know where it will lead... to a 120 post long thread with 12 > > participants. 6 of which think their ideas are great but don't have > > the resources to implement any of them. The other 6 thinks the ideas > > are bad and have decided that convincing the other 6 through sheer > > superhuman retorical prowess is a constructive way to earn brownie > > points with the 5 people in the thread that agree with them. No wait > > 13 particpants. The 13th participant who hates everyone on general > > principle and only gets involved in the discussion because the themes > > being badly expressed by the other 12 people are too important to not > > have something worthwhile come out of the discussion. > > > > -jef"Generally good ideas are generally very bad discussions. Boring, > > mind-numbing detailed specific implementation issues are far more > > constructive discussions"spaleta > > I've learned my own life lesson! ;-) I agree. I like specific implementation issues too. I would like to see some improvements to the already much improved update/add software system. I would start with 1) highlighting where new software has been installed in the Gnome menu (or KDE) on my Fedora box 2) being able to determine which repository a software package to be added is located 3) be able to add/remove repositories from Pirut and 4) a pipe dream (whatever that is), of having small deltarpms/smartrpms or something new to minimize bandwidth. I have a feeling these issues are already being tackled in some form except for the project of having a modern update system that creates the smallest possible update tailored specifically to every user's machine. That would be an amazing technical achievement. Benjy > > DP > > ======================================= > David-Paul Niner, RHCE > dpniner at dpniner.name > Florida, United States of America > > Public Key for GPG key 1FCE01A2 > available from http://www.dpniner.name > > GPG Fingerprint for key 1FCE01A2: > 9147 2826 BF20 962D C53E 6B1C 97FD 77A6 1FCE 01A2 > ======================================= > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From gazzerh at gmail.com Sat Apr 22 03:19:20 2006 From: gazzerh at gmail.com (Garry Harthill) Date: Sat, 22 Apr 2006 04:19:20 +0100 Subject: Installation Wizard in Yumex In-Reply-To: <604aa7910604210634r1f623a8ds6b2c2906c896e107@mail.gmail.com> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> <1fcc9e320604210624y35c94e31h8889b0da0b899b77@mail.gmail.com> <604aa7910604210634r1f623a8ds6b2c2906c896e107@mail.gmail.com> Message-ID: <1fcc9e320604212019q26f9064s83a67f835d8e13c4@mail.gmail.com> On 21/04/06, Jeff Spaleta wrote: > On 4/21/06, Garry Harthill wrote: > > This is good idea. > > Its a horrible idea., because it makes it that much easier for random > inexperienced users to create mind-numbingly simple ways to create > scripts that breaks other inexperienced users systems. For ever one > of these scripts which will be provided by a reputable maintainer > there will be a vast array of such scripts sitting in > random-joe-user's personal blog or "help site" which hasn't seen a > shred of testing by anyone else and willy-nilly enabled a array of > repositories with conflicting update paths causing updating problems > for any user who happens to find that random script on the web. > > What happens when stanton writes his yumex installer script which > makes slightly different but conflicting choices than the dries > script? What happens with atrpms adds yet another script which again > makes slightly different but conflicting choices? And the poor user > attempts to use all 3 because they each cover unique functionality? > > -jef"Can wait to add pathelogical yumex install scripts to his > repository webpage of pathelogical packages of doom repository"spaleta > I can see that it could be a problem for a lot of harmful scripts to be introduced. However, it is *very* easy for users to install an RPM for a destructive repo with enable=1 without them really knowing what damage they do when they yum install or update. If the "default" yumex repo wizard choices are carefully chosen then where is the problem? In fact because they are carefully chosen this could reduce destroyed systems due to yum repo misuse. Garry From buildsys at redhat.com Sat Apr 22 07:11:02 2006 From: buildsys at redhat.com (Build System) Date: Sat, 22 Apr 2006 03:11:02 -0400 Subject: rawhide report: 20060422 changes Message-ID: <200604220711.k3M7B2Li010755@porkchop.devel.redhat.com> Updated Packages: bluez-utils-2.25-7 ------------------ * Fri Apr 21 2006 David Woodhouse - 2.25-7 - Fix invalid timeval in reconnect_timer_start() cscope-15.5-13.3 ---------------- * Fri Apr 21 2006 Neil Horman - 15.5-13.3 - Added inverted overflow fix file-4.17-3 ----------- * Fri Apr 21 2006 Radek Vok??l 4.17-3 - add support for OCFS or ASM (#189017) * Tue Mar 14 2006 Radek Vok??l 4.17-2 - fix segfault when compiling magic - add check for wctype.h - fix for flac and mp3 files * Mon Mar 13 2006 Radek Vok??l 4.17-1 - upgrade to file-4.17, patch clean-up hplip-0.9.10-6 -------------- * Fri Apr 21 2006 Tim Waugh 0.9.10-6 - Patchlevel 2. * Wed Apr 19 2006 Tim Waugh - Don't package COPYING twice (bug #189162). pilot-link-2:0.11.8-15 ---------------------- * Fri Apr 21 2006 Than Ngo 2:0.11.8-15 - fix pilot-xfer crash on missing device node #186779, #175334 - don't include unnecessary man page #185147 procps-3.2.6-3.3 ---------------- * Wed Apr 19 2006 Karel Zak - 3.2.6-3.3 - fix #186017 - top "Cpu0" line never updates on single processor machine (bugfix added to the 'remcpu' patch) - fix #168444 - memory usage conflicts with /proc/meminfo - fix #174619 - top reports wrong values for CPU(s) in batch mode - fix #185299 ??? cpu steal time support selinux-policy-2.2.34-3 ----------------------- * Fri Apr 21 2006 Dan Walsh 2.2.34-3 - Allow mono to chat with unconfined system-config-kickstart-2.6.9-1 ------------------------------- * Fri Apr 21 2006 Chris Lumens 2.6.9-1 - Add support for more device names. - Display a progress bar while yum is working (#187435). vnc-4.1.1-37 ------------ * Fri Apr 21 2006 Jitka Kudrnacova 4.1.1-37 - removed liblbxutil-devel from BuildRequires Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From n0dalus+redhat at gmail.com Sat Apr 22 07:28:20 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 22 Apr 2006 16:58:20 +0930 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> Message-ID: <6280325c0604220028t34f7cffdx49465f1bbc2d0264@mail.gmail.com> On 4/21/06, Nils Philippsen wrote: > On Thu, 2006-04-20 at 16:41 +0100, Andre Nogueira wrote: > > > 2) When Anaconda is installing a package, it is not downloading the > > next package. Why not continue downloading packages while installing > > downloaded packages? > > Before starting an RPM transaction you want to be sure that everything > is available. Think about a transaction that consists of packages a, b, > c (each with version-release) which are to be installed in that order. > You propose s.th. along that: > > 1) a gets downloaded > 2) a gets installed while b gets downloaded > 3) b gets installed while c gets downloaded > 4) c gets installed > > Unfortunately, somewhere during step 2, the mirror gets updated with a > new version of c which actually would be required to be installed > _before_ b. Now you've got a broken transaction --> this is why yum etc. > download first, then install afterwards. > Since when do packages state what needs to be installed after them? I was under the impression that packages state instead what needs to be installed before them. In which case, the scenario you mention couldn't happen. Package 'b' either needs 'c' installed first or it doesn't. If it doesn't need 'c' installed first, then it doesn't matter that the 'c' package ended up being different to what was expected. In any case, I thought yum simply failed if it couldn't find the package corresponding to the header data it was using. n0dalus. From n0dalus+redhat at gmail.com Sat Apr 22 07:35:52 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 22 Apr 2006 17:05:52 +0930 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145614991.2760.18.camel@xpc.home.erwinrol.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> Message-ID: <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> On 4/21/06, Erwin Rol wrote: > when i switch from 24bit to 16bit mode (I can't test 32bit since that > doesn't seem to be supported with the radeon driver). Isn't 32 bit colour depth just the same as 24 bit with an unused 8 bits? n0dalus. From paul at all-the-johnsons.co.uk Sat Apr 22 08:06:23 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 22 Apr 2006 09:06:23 +0100 Subject: Madwifi/wpa_supplicant packaging In-Reply-To: <444967BB.7010504@redfish-solutions.com> References: <444967BB.7010504@redfish-solutions.com> Message-ID: <1145693184.3602.15.camel@T7.Linux> Hi, > That way if you grab madwifi from ATrpms, and rebuild wpa_supplicant > from source it will do the right thing... Why can't we just have madwifi-ng as a FE package? TTFN Paul -- Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei denn man ?ffnet die Fenster -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Sat Apr 22 08:18:01 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 22 Apr 2006 10:18:01 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> Message-ID: <20060422101801.32b587c0@nausicaa.camperquake.de> Hi. n0dalus wrote: > Isn't 32 bit colour depth just the same as 24 bit with an unused 8 bits? If you disregard a possible alpha channel, yes. It then comes down to access patterns in the video memory (accessing 32 bit values on 32 bit boundaries may be faster, depending on your system) -- "To be is to do" -- Plato "To do is to be" -- Aristotle "Do be do be do" -- Sinatra From Axel.Thimm at ATrpms.net Sat Apr 22 08:40:14 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 22 Apr 2006 10:40:14 +0200 Subject: Installation Wizard in Yumex In-Reply-To: <604aa7910604210634r1f623a8ds6b2c2906c896e107@mail.gmail.com> References: <443A5119.6020105@rasmil.dk> <1144673604.14119.15.camel@ignacio.lan> <443A5A2E.2070007@rasmil.dk> <1fcc9e320604210624y35c94e31h8889b0da0b899b77@mail.gmail.com> <604aa7910604210634r1f623a8ds6b2c2906c896e107@mail.gmail.com> Message-ID: <20060422084014.GC3545@neu.nirvana> On Fri, Apr 21, 2006 at 09:34:58AM -0400, Jeff Spaleta wrote: > On 4/21/06, Garry Harthill wrote: > > This is good idea. > > Its a horrible idea., because it makes it that much easier for random > inexperienced users to create mind-numbingly simple ways to create > scripts that breaks other inexperienced users systems. For ever one > of these scripts which will be provided by a reputable maintainer > there will be a vast array of such scripts sitting in > random-joe-user's personal blog or "help site" which hasn't seen a > shred of testing by anyone else and willy-nilly enabled a array of > repositories with conflicting update paths causing updating problems > for any user who happens to find that random script on the web. > > What happens when stanton writes his yumex installer script which > makes slightly different but conflicting choices than the dries > script? What happens with atrpms adds yet another script which again > makes slightly different but conflicting choices? What kind of script from atrpms are you thinking of? I may be off base (or topic), since I don't really know what yumex scripts can/should do, but ATrpms' policy is to let the users mess themselves with their configs (and therefore be responsible themselves for the bullet hole in their foot ;). All ATrpms does is offer an optional medley-package-config script that adds a lot of untampered with repos (no weighing, priorities etc), which the user needs to shape (turn off etc). It also offers (again an optional) package to use ATrpms' mirrors of fedora core contents. There is a polite request to either use ATrpms properly (and not partially enabled) or not at all, as there have been just too many bugs resulting from that. But this policy is not enforced by scripts. > And the poor user attempts to use all 3 because they each cover > unique functionality? > > -jef"Can wait to add pathelogical yumex install scripts to his > repository webpage of pathelogical packages of doom repository"spaleta > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mailinglists at erwinrol.com Sat Apr 22 08:52:59 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 22 Apr 2006 10:52:59 +0200 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> Message-ID: <1145695979.2760.47.camel@xpc.home.erwinrol.com> On Sat, 2006-04-22 at 17:05 +0930, n0dalus wrote: > On 4/21/06, Erwin Rol wrote: > > when i switch from 24bit to 16bit mode (I can't test 32bit since that > > doesn't seem to be supported with the radeon driver). > > Isn't 32 bit colour depth just the same as 24 bit with an unused 8 bits? Well the driver must think there is some difference because it bails out with a "not supported" when i select 32bit color depth :-) I dunno if the radeon actually does a 24bit packed (3 byte) or a 24bit unpacked (4byte) store in the frame buffer. Also the Matrox cards support this 10bit per color thing, so they need 30bit per pixel, there 24bit and 32bit really would be different. - Erwin From andy at warmcat.com Sat Apr 22 09:26:08 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 22 Apr 2006 10:26:08 +0100 Subject: Fedora core suggestions In-Reply-To: <1145661797.8777.8.camel@fortinbras.dpniner.net> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> <44495B40.8020800@warmcat.com> <1145661797.8777.8.camel@fortinbras.dpniner.net> Message-ID: <4449F6B0.40406@warmcat.com> David-Paul Niner wrote: > This "life lesson" was meant to be just that -- something for you take > away and digest. I do sincerely apologize if I embarrassed you; it was > a bad call for me to write what I did. > > I now realize, however, it seems quite likely that you could benefit > from some talking with someone about things, as you seem quite angry: Hm, I could have benefited from discussing what the meaning of 'marketing' actually is for Free software, especially now I read there is a fedora-marketing list. How does this fit in with the current project goals, is it a mild, budgetless advocacy concept or a gung-ho tattooed-on-the-forehead self flagellating squad of jihadis that raid corporate offices for re-education of the inhabitants, how that crosses over with RHEL / Redhat Desktop traditional marketing, what the metric is for 'success' on Fedora marketing, how it can even be measured given the inherent redistribution, etc. >>>>> 1. Pre-release non-technical user testing. >>>>> 2. Marketing. >>>>> 3. Ego-containment. >>>>> 4. Be more open-minded. >>>> If you want to foster discussion, please issue considered >>>> argumentation, not unreasoned bulletpoints >>> Life Lesson #0: This is just the sort of response that causes people >>> to assume defensive postures. ... >>> Also, you're awarding yourself an unrealistic amount of >>> self-importance in a group discussion. >> I don't mind if you feel the need to form a defensive posture on being >> told you posted a load of handwaving junk. > My original intention was not to put down you or the project, it was > merely to generate some discussion. > > Seriously, best of luck; I have nothing against you and wish you well. Yeah same to you. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From d.jacobfeuerborn at conversis.de Sat Apr 22 11:52:27 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 22 Apr 2006 13:52:27 +0200 Subject: Xorg signal 11's spontaneously In-Reply-To: <4449077C.1050705@conversis.de> References: <4449077C.1050705@conversis.de> Message-ID: <444A18FB.7070107@conversis.de> Dennis Jacobfeuerborn wrote: > In the last 10 days Xorg crashed three times with a signal 11 > spontaneously. This is the backtrace I found in the logfile: > > Backtrace: > 0: /usr/bin/Xorg(xf86SigHandler+0x87) [0x80b6d07] > 1: [0x49a420] > 2: /usr/lib/xorg/modules/libfb.so [0x134b81] > 3: /usr/lib/xorg/modules/libfb.so [0x13c80c] > 4: /usr/lib/xorg/modules/libfb.so(fbCompositeGeneral+0x855) [0x13a4e5] > 5: /usr/lib/xorg/modules/libfb.so(fbComposite+0x1cd) [0x1433ad] > 6: /usr/lib/xorg/modules/libxaa.so(XAAComposite+0x261) [0x81f001] > 7: /usr/bin/Xorg [0x8156d06] > 8: /usr/bin/Xorg [0x8153915] > 9: /usr/bin/Xorg(CompositePicture+0x153) [0x8140a13] > 10: /usr/bin/Xorg [0x814687c] > 11: /usr/bin/Xorg [0x8143bd5] > 12: /usr/bin/Xorg(Dispatch+0x19a) [0x80869ba] > 13: /usr/bin/Xorg(main+0x485) [0x806e3e5] > 14: /lib/libc.so.6(__libc_start_main+0xdc) [0x4cd7e4] > 15: /usr/bin/Xorg(FontFileCompleteXLFD+0xbd) [0x806d721] > > Fatal server error: > Caught signal 11. Server aborting > > All three crashes happened when I was loading a page in Firefox and > after the nightly Firefox builds got switched to Cairo as their > rendering backend so I wonder if Cairo could somehow trigger this. > > I'm running Fedora Core Rawhide with the following Xorg packages: > xorg-x11-server-Xorg-1.0.99.901-5 > xorg-x11-drv-nv-1.1.1-2 > > I'm using the open source nv driver with the AccelMethod set to EXA and > the 'load "dri"' and 'load "glx"' lines commented out. Just happened again and the backtrace looks similar to the one above. If I can do something to provide better information to debug this please tell me. Regards, Dennis From k.georgiou at imperial.ac.uk Sat Apr 22 12:18:01 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Sat, 22 Apr 2006 13:18:01 +0100 Subject: Fedora core suggestions In-Reply-To: <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> Message-ID: <20060422121801.GA909@imperial.ac.uk> On Fri, Apr 21, 2006 at 07:34:32PM -0400, Jeff Spaleta wrote: > On 4/21/06, Paul W. Frields wrote: > > One alternative for non-technical users which Jef Spaleta mentioned a > > little while ago in IRC was testing of high-level functionality and > > interfaces using VMWare Player and an image provided by Fedora. This > > would potentially lower barriers not only to non-technical users but to > > willing folks who only have a single system available, or have a low > > risk threshold for some other reason. > > > > VMWare has opened its VMDK (virtual disk) format for use by anyone[1] so > > there's nothing preventing an intrepid Fedora hacker from designing a > > converter program. The community could then make some decisions about > > one or more "test platform" images that could be converted to VMDK and > > distributed via the existing BitTorrent tracker. People using either > > Windows or Linux could then download the free VMWare Player to run the > > Fedora VMDK image. > > > Someone has to check on the licensing is for the VMDK crap. My IRC > musing was a whatif.. based on the assumption that the VMDK crap made > it possible to engineer a player image with a yet-to-be-created open > tool. Its possible right now to have player images, we saw the > community create them in the fc5 testing phase. But i strongly feel > the Fedora project shouldn't be offering official vmware player images > until its possible to create those images with an open tool. I'm > desperately hopeful that the VMDK licensing change is enough to make > such an open tool possible. qemu can use VMDK images so the tool is already available in extras. Most likely you'll only need minor (if any) configuration changes before you can use the image with vmplayer. Kostas Georgiou From mark at borkware.net Sat Apr 22 12:20:28 2006 From: mark at borkware.net (Mark Rosenstand) Date: Sat, 22 Apr 2006 14:20:28 +0200 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> Message-ID: <1145708428.19696.63.camel@hammer> On Fri, 2006-04-21 at 20:18 -0400, Jeff Spaleta wrote: > On 4/21/06, Leon wrote: > > Basically they want to divide packages (of course installed by package > > manager; those installed using source, the user has to track > > themselves) into two groups: one is installed by the user (explicitly > > 'yum install') and the other is those required to satisfy the > > dependence. > > Oh i get it.. and what I'm saying is I think you under-estimate how > difficult it will be to robustly use automatical removal of > dependancies marked for autoremoval without causing problems with crap > that is not tracked by the package management system. I think you > underestimate how often people install tools that were part of an > automatically included dependancy which end up being used in scripts > that were written locally that are not tracked in the rpm system. > Little perl scripts, little shell scripts, little python scripts, > little php scripts. Hell anyone running any sort of website with php > enabled is most likely running some sort of not rpm managed php junk > that is in fact configured to exec other binaries, binaries which may > be marked as an indirect dependancy of some other package which would > be removed via the automatic dependance removal feature. It really isn't needed to do it automatically. Debian have a package called debfoster (at least they had in 2002), which checks the interdependencies of all your packages and for then asks whether you want to remove each package that aren't needed by any others, e.g.: Package A keeps these packages installed: G, K, O, R Do you wish to keep package A? [Y/n] This has the obvious advantage that you don't have to add yet a piece of info to the ever-bloated rpm database. Gentoo also do it. IIRC it has a command which lists all packages that were not installed explicitly and which no other package depends upon (which is a nice, logical list), but then they have to ruin an otherwise nice feature by automatically removing all said packages after 10 seconds if not interrupted. From mark at borkware.net Sat Apr 22 12:39:16 2006 From: mark at borkware.net (Mark Rosenstand) Date: Sat, 22 Apr 2006 14:39:16 +0200 Subject: Fedora core suggestions In-Reply-To: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> References: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> Message-ID: <1145709556.19696.65.camel@hammer> On Fri, 2006-04-21 at 18:02 -0500, Arthur Pemberton wrote: > On 4/21/06, Alo Tsum wrote: > > > First suggestions has to do with the software side of things. We users need > > a competent software installer which is graphical based. > > The problem here is that there are several options, and Fedora has > chosen to stick with Pirut. I am personally not a fan of the GUI style > used by Pirut, but it is quite possible that I am in the minority in > this regard. Perhaps a minority, but definately not alone. It's hard to believe that it comes from the same vendor that proposed the HIG. From pmatilai at laiskiainen.org Sat Apr 22 13:30:34 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 22 Apr 2006 06:30:34 -0700 (PDT) Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145708428.19696.63.camel@hammer> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> Message-ID: On Sat, 22 Apr 2006, Mark Rosenstand wrote: > It really isn't needed to do it automatically. Debian have a package > called debfoster (at least they had in 2002), which checks the > interdependencies of all your packages and for then asks whether you > want to remove each package that aren't needed by any others, e.g.: > > Package A keeps these packages installed: G, K, O, R > Do you wish to keep package A? [Y/n] > > This has the obvious advantage that you don't have to add yet a piece of > info to the ever-bloated rpm database. > > Gentoo also do it. IIRC it has a command which lists all packages that > were not installed explicitly and which no other package depends upon > (which is a nice, logical list), but then they have to ruin an otherwise > nice feature by automatically removing all said packages after 10 > seconds if not interrupted. Checking the dependencies is the easy part. What gets less trivial is things like this: [pmatilai at cs181072240 ~]$ rpm -e --test grub [pmatilai at cs181072240 ~]$ Oops, nothing needs grub, so it can be removed safely, right? - Panu - From jspaleta at gmail.com Sat Apr 22 13:30:01 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Apr 2006 09:30:01 -0400 Subject: Fedora core suggestions In-Reply-To: <20060422121801.GA909@imperial.ac.uk> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> Message-ID: <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> On 4/22/06, Kostas Georgiou wrote: > qemu can use VMDK images so the tool is already available in extras. > Most likely you'll only need minor (if any) configuration changes > before you can use the image with vmplayer. qemu can use them... can qemu create them? We need an open tool that can be included in FC/FE that can create the content not just use it. -jef From mark at borkware.net Sat Apr 22 14:07:23 2006 From: mark at borkware.net (Mark Rosenstand) Date: Sat, 22 Apr 2006 16:07:23 +0200 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> Message-ID: <1145714843.19696.80.camel@hammer> On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote: > Checking the dependencies is the easy part. What gets less trivial is > things like this: > > [pmatilai at cs181072240 ~]$ rpm -e --test grub > [pmatilai at cs181072240 ~]$ > > Oops, nothing needs grub, so it can be removed safely, right? The Debian tool assumes that its users are capable of brain activity. I don't know if this is a problem in the Fedora case. Anyway, it does have a couple of more options than Y/n, one of them being 'i' which prints the description of the package, so it's easy to get a pretty good clue if you're uncertain whether you need the package. Of course this is where the "explicitly installed" attribute is useful. I assume glibc, grub, udev etc. are all explicitly installed by anaconda. From jspaleta at gmail.com Sat Apr 22 14:29:20 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Apr 2006 10:29:20 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145714843.19696.80.camel@hammer> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> <1145714843.19696.80.camel@hammer> Message-ID: <604aa7910604220729t1764d725xbe3434cdd2a52dd2@mail.gmail.com> On 4/22/06, Mark Rosenstand wrote: > Of course this is where the "explicitly installed" attribute is useful. > I assume glibc, grub, udev etc. are all explicitly installed by > anaconda. The smallest group of packages which you can be sure were explicitly installed are the mandatory members of the "Core" group in the comps.xml file for Fedora Core. Since Fedora's installer has the ability to use kickstart for highly customized installs, you can not be reasonable sure that any other specific package will be "explicitly" installed. My vixie-cron example illustrates that problem. vixie-cron is a mamber of the "Base" group which kickstart installs may or may not use so some installs may not "explicitly" ask vixie-cron to be installed and it may be pulled in by sysstat. Or it maybe explicitly removed at some later day and then pulled in by a sysstat install. "explicit" dependancy marking is an unreliable measure of how actively that dependacy is being used on the system and can not be the basis of a robust automatic dependancy removal process. I have no problem with a set of tools that help admins review leaf nodes in their packageset. But I have concern for any tool that offers to automatically remove leaf nodes...based solely on information which can be tracked by the package management system.. I firmly belief that leaf node removal requires active human review and the process should not be condensed into a set of simplified y/n/cancel dialogs. Things like how frequently/recently the files associated with the package have been accessed by un-dependant executables and libraries (excluding prelink) are important factors to consider.. factors which live outside the available package management information. -jef From stickster at gmail.com Sat Apr 22 14:33:26 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 22 Apr 2006 10:33:26 -0400 Subject: Fedora core suggestions In-Reply-To: <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> Message-ID: <1145716407.3046.39.camel@localhost.localdomain> On Sat, 2006-04-22 at 09:30 -0400, Jeff Spaleta wrote: > On 4/22/06, Kostas Georgiou wrote: > > qemu can use VMDK images so the tool is already available in extras. > > Most likely you'll only need minor (if any) configuration changes > > before you can use the image with vmplayer. > > qemu can use them... can qemu create them? We need an open tool that > can be included in FC/FE that can create the content not just use it. The press release on the website claims the licensing terms are GPL-compatible. There doesn't seem to be anywhere to download the actual terms, though. I have sent email to VMWare asking for a copy of the terms for review. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From k.georgiou at imperial.ac.uk Sat Apr 22 14:46:10 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Sat, 22 Apr 2006 15:46:10 +0100 Subject: Fedora core suggestions In-Reply-To: <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> Message-ID: <20060422144610.GB5746@imperial.ac.uk> On Sat, Apr 22, 2006 at 09:30:01AM -0400, Jeff Spaleta wrote: > On 4/22/06, Kostas Georgiou wrote: > > qemu can use VMDK images so the tool is already available in extras. > > Most likely you'll only need minor (if any) configuration changes > > before you can use the image with vmplayer. > > qemu can use them... can qemu create them? We need an open tool that > can be included in FC/FE that can create the content not just use it. qemu-img create -f vmdk fc5.vmdk 5G You can install fedora with either qemu (or vmplayer) afterwards. Have a look at http://www.easyvmx.com/ for examples on how to create a vmplayer config file so you can boot the image. You can probably copy an existing disk with something like qemu-img convert -f raw /dev/hda -O vmdk fc5.vmdk but I never tried it. From redhat at olen.net Sat Apr 22 15:01:51 2006 From: redhat at olen.net (Ola Thoresen) Date: Sat, 22 Apr 2006 15:01:51 +0000 (UTC) Subject: [NEW IDEA] Automatic removal of dependencies References: <604aa7910604220729t1764d725xbe3434cdd2a52dd2@mail.gmail.com> Message-ID: I have this little snippet as ~/bin/rpm-listunused #!/bin/sh rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg done It will simply list all packages where no files have been accessed the last 6 months. I believe it has been posted here before (or I might have picked it up somewhere else), but anyway something like this would probably more helpful than only looking at the dependencies if one is trying to determine what packages can safely be removed. Rgds. Ola Thoresen From jspaleta at gmail.com Sat Apr 22 15:09:47 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Apr 2006 11:09:47 -0400 Subject: Fedora core suggestions In-Reply-To: <20060422144610.GB5746@imperial.ac.uk> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> <20060422144610.GB5746@imperial.ac.uk> Message-ID: <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> On 4/22/06, Kostas Georgiou wrote: > qemu-img create -f vmdk fc5.vmdk 5G > You can install fedora with either qemu (or vmplayer) afterwards. > Have a look at http://www.easyvmx.com/ for examples on how to create > a vmplayer config file so you can boot the image. > > You can probably copy an existing disk with something like > qemu-img convert -f raw /dev/hda -O vmdk fc5.vmdk > but I never tried it. sweeeeeeeeeeeeeeeeeeeet If we can use qemu to create compatible vmplayer images we can have 'official' images on the fedoraproject website or possibly in the release trees if the release team see it as worthwhile. Now its just a question of whether or not having a sequence of pre-configured images for doing targetted issue testing is worth the effort... which was my original idea. But I'm not so sure its the best mechanism to do targetted usability testing. A dedicated vnc/freenx server which can be re-configured on a per-account basis using sabayon-like configuration might provide the more flexible option with much less bandwidth overhead. We can record the whole terminal session as individuals work through a set of tasks, starting from a pre-configured desktop environment. Obviously a remote session cant test certain tasks that I'd like to see some standardized usability sessions on.. things like burning a cd or dealing with digital cameras wouldn't be possible to record a session for via a remote vnc or freenx session without doing something extremely clever. -jef From jspaleta at gmail.com Sat Apr 22 15:12:05 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Apr 2006 11:12:05 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604220729t1764d725xbe3434cdd2a52dd2@mail.gmail.com> Message-ID: <604aa7910604220812r2710955do814baa2c84cdf856@mail.gmail.com> On 4/22/06, Ola Thoresen wrote: > It will simply list all packages where no files have been accessed the > last 6 months. I believe it has been posted here before (or I might > have picked it up somewhere else), but anyway something like this would > probably more helpful than only looking at the dependencies if one is > trying to determine what packages can safely be removed. doesn't prelink operation on libraries nullify much of the value of such a script? If prelink operation changes the access time, you'll basically get false positives for every library prelink touches. -jef From sdl.web at gmail.com Sat Apr 22 16:39:20 2006 From: sdl.web at gmail.com (Leon) Date: Sat, 22 Apr 2006 17:39:20 +0100 Subject: [NEW IDEA] Automatic removal of dependencies References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> <1145714843.19696.80.camel@hammer> <604aa7910604220729t1764d725xbe3434cdd2a52dd2@mail.gmail.com> Message-ID: "Jeff Spaleta" writes: > On 4/22/06, Mark Rosenstand wrote: >> Of course this is where the "explicitly installed" attribute is useful. >> I assume glibc, grub, udev etc. are all explicitly installed by >> anaconda. > > The smallest group of packages which you can be sure were explicitly > installed are the mandatory members of the "Core" group in the > comps.xml file for Fedora Core. Since Fedora's installer has the > ability to use kickstart for highly customized installs, you can not > be reasonable sure that any other specific package will be > "explicitly" installed. My vixie-cron example illustrates that > problem. vixie-cron is a mamber of the "Base" group which kickstart > installs may or may not use so some installs may not "explicitly" ask > vixie-cron to be installed and it may be pulled in by sysstat. Or it > maybe explicitly removed at some later day and then pulled in by a > sysstat install. "explicit" dependancy marking is an unreliable > measure of how actively that dependacy is being used on the system and > can not be the basis of a robust automatic dependancy removal process. > > I have no problem with a set of tools that help admins review leaf > nodes in their packageset. But I have concern for any tool that offers > to automatically remove leaf nodes...based solely on information which > can be tracked by the package management system.. I firmly belief > that leaf node removal requires active human review and the process > should not be condensed into a set of simplified y/n/cancel dialogs. > Things like how frequently/recently the files associated with the > package have been accessed by un-dependant executables and libraries > (excluding prelink) are important factors to consider.. factors which > live outside the available package management information. > > -jef Completely agree with your concern. I post this only from the perspective of end users. It's likely to have many obsolete libraries installed when upgrading system from release to release without fresh install. Anyway this is not a critical feature. -- Leon From sdl.web at gmail.com Sat Apr 22 16:48:11 2006 From: sdl.web at gmail.com (Leon) Date: Sat, 22 Apr 2006 17:48:11 +0100 Subject: firefox miniicon has extra black pixels Message-ID: Dear all, I attach two screenshots of firefox in SuSE 9.3 and FC5. It seems the mini icon of firefox in FC5 has an ugly black line along the bottom and right-hand side of the icon. I think this might be a very small bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: SuSE.png Type: image/png Size: 1154 bytes Desc: Firefox MiniIcon in SuSE 9.3 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fedora.png Type: image/png Size: 1124 bytes Desc: Firefox MiniIcon in Fedora Core 5 URL: -------------- next part -------------- Regards, -- Leon From pemboa at gmail.com Sat Apr 22 16:57:38 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 22 Apr 2006 11:57:38 -0500 Subject: Fedora core suggestions In-Reply-To: <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> <20060422144610.GB5746@imperial.ac.uk> <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> Message-ID: <16de708d0604220957ne713fd3g744ff9e8aec0d701@mail.gmail.com> On 4/22/06, Jeff Spaleta wrote: > On 4/22/06, Kostas Georgiou wrote: > > qemu-img create -f vmdk fc5.vmdk 5G > > You can install fedora with either qemu (or vmplayer) afterwards. > > Have a look at http://www.easyvmx.com/ for examples on how to create > > a vmplayer config file so you can boot the image. > > > > You can probably copy an existing disk with something like > > qemu-img convert -f raw /dev/hda -O vmdk fc5.vmdk > > but I never tried it. > > sweeeeeeeeeeeeeeeeeeeet > > If we can use qemu to create compatible vmplayer images we can have > 'official' images on the fedoraproject website or possibly in the > release trees if the release team see it as worthwhile. > > Now its just a question of whether or not having a sequence of > pre-configured images for doing targetted issue testing is worth the > effort... which was my original idea. But I'm not so sure its the best > mechanism to do targetted usability testing. A dedicated vnc/freenx > server which can be re-configured on a per-account basis using > sabayon-like configuration might provide the more flexible option with > much less bandwidth overhead. We can record the whole terminal session > as individuals work through a set of tasks, starting from a > pre-configured desktop environment. Obviously a remote session cant > test certain tasks that I'd like to see some standardized usability > sessions on.. things like burning a cd or dealing with digital cameras > wouldn't be possible to record a session for via a remote vnc or > freenx session without doing something extremely clever. > > -jef Can nx/freenx even be a part of Fedora legally? -- As a boy I jumped through Windows, as a man I play with Penguins. From seg at haxxed.com Sat Apr 22 17:02:42 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 12:02:42 -0500 Subject: Madwifi/wpa_supplicant packaging In-Reply-To: <1145693184.3602.15.camel@T7.Linux> References: <444967BB.7010504@redfish-solutions.com> <1145693184.3602.15.camel@T7.Linux> Message-ID: <1145725363.22802.1.camel@localhost.localdomain> On Sat, 2006-04-22 at 09:06 +0100, Paul wrote: > Hi, > > > That way if you grab madwifi from ATrpms, and rebuild wpa_supplicant > > from source it will do the right thing... > > Why can't we just have madwifi-ng as a FE package? No source for the HAL module? There's some reverse engineering attempts out there, but I haven't been able to get them to work. I use madwifi from Livna. Is it supposed to work with NetworkManager? Because it doesn't. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Apr 22 17:15:21 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 12:15:21 -0500 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145695979.2760.47.camel@xpc.home.erwinrol.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> <1145695979.2760.47.camel@xpc.home.erwinrol.com> Message-ID: <1145726122.22802.7.camel@localhost.localdomain> On Sat, 2006-04-22 at 10:52 +0200, Erwin Rol wrote: > On Sat, 2006-04-22 at 17:05 +0930, n0dalus wrote: > > On 4/21/06, Erwin Rol wrote: > > > when i switch from 24bit to 16bit mode (I can't test 32bit since that > > > doesn't seem to be supported with the radeon driver). > > > > Isn't 32 bit colour depth just the same as 24 bit with an unused 8 bits? > > Well the driver must think there is some difference because it bails out > with a "not supported" when i select 32bit color depth :-) I dunno if > the radeon actually does a 24bit packed (3 byte) or a 24bit unpacked > (4byte) store in the frame buffer. Also the Matrox cards support this > 10bit per color thing, so they need 30bit per pixel, there 24bit and > 32bit really would be different. For a while now, in XFree86/Xorg, setting depth 24 refers to the actual color depth, not padding. The driver is to set the actual framebuffer depth to 24 or 32 bits as is appropriate for the hardware. AFAIK on most hardware, padding 24bit out to 32 bit performs faster. No idea how Xorg plans to handle this new fangled HDR thing... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Apr 22 17:24:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 12:24:02 -0500 Subject: Fedora core suggestions In-Reply-To: <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145655241.7517.29.camel@fortinbras.dpniner.net> <604aa7910604211627m32ecc381o4d6acc76b7c8e630@mail.gmail.com> Message-ID: <1145726644.22802.10.camel@localhost.localdomain> On Fri, 2006-04-21 at 19:27 -0400, Jeff Spaleta wrote: > -jef"Generally good ideas are generally very bad discussions. Boring, > mind-numbing detailed specific implementation issues are far more > constructive discussions"spaleta +1 Discussions of grand unified plans for whatever belong on fedora-user or fedora-marketing or anywhere but here. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Apr 22 17:26:46 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 12:26:46 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: <1145726806.22802.14.camel@localhost.localdomain> On Fri, 2006-04-21 at 19:08 -0400, Jeff Spaleta wrote: > automatic upgrading of dependancies.. will only work if all applications ^^^^^^^^^ > and scripts on the system are managed by the package management > system. That means that nothing on the system can be installed via > source which makes it outside the scope of the package management > system which may be using an "indirect" dependancy. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ggw at wolves.durham.nc.us Sat Apr 22 17:45:56 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Sat, 22 Apr 2006 13:45:56 -0400 Subject: New Ideas - how about a GUI for /etc/fstab Message-ID: <20060422174556.GA23589@wolves.durham.nc.us> There are some automatic tools that manipulate parts of the fstab, but there isn't a GUI that understands all of the various pieces and options that go into the fstab of a Fedora Core system. It would be nice if there were a GUI editor that would allow the addition of NFS, CIFS and other network filesystems to the fstab with some handling of the options that they require. Submitted for discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From redhat at olen.net Sat Apr 22 17:47:25 2006 From: redhat at olen.net (Ola Thoresen) Date: Sat, 22 Apr 2006 17:47:25 +0000 (UTC) Subject: [NEW IDEA] Automatic removal of dependencies References: <604aa7910604220812r2710955do814baa2c84cdf856@mail.gmail.com> Message-ID: 2006-04-22 "Jeff Spaleta" wrote > On 4/22/06, Ola Thoresen wrote: >> It will simply list all packages where no files have been accessed the >> last 6 months. I believe it has been posted here before (or I might >> have picked it up somewhere else), but anyway something like this would >> probably more helpful than only looking at the dependencies if one is >> trying to determine what packages can safely be removed. > > doesn't prelink operation on libraries nullify much of the value of > such a script? If prelink operation changes the access time, you'll > basically get false positives for every library prelink touches. > After a stat of the files in /lib it seems like you are right, so with prelink running every night you will never catch unsed libs in /[usr/]lib{,64} and other paths where prelink runs. But on the other hand, it will also catch it if your php-script is using something that would otherwise get removed (becuase it was auto-installed). I don't claim this to be the one true solution, it is just a simple way to list at least some installed but unused packages. Maybe a simple prelink-patch wich restores the A-time of the files it prelinks would be a possible path.. hmm.... Rgds. Ola Thoresen From philipp_subx at redfish-solutions.com Sat Apr 22 18:03:02 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 22 Apr 2006 12:03:02 -0600 Subject: Madwifi/wpa_supplicant packaging In-Reply-To: <1145693184.3602.15.camel@T7.Linux> References: <444967BB.7010504@redfish-solutions.com> <1145693184.3602.15.camel@T7.Linux> Message-ID: <444A6FD6.60204@redfish-solutions.com> Paul wrote: >Hi, > > > >>That way if you grab madwifi from ATrpms, and rebuild wpa_supplicant >>from source it will do the right thing... >> >> > >Why can't we just have madwifi-ng as a FE package? > >TTFN > >Paul > > It's not clear that the NG version is stable enough, from what I can tell. It would be nice to get the .spec, etc. upstream into the Madwifi tree... Maybe the sysconfig and init.d parts as well... -Philip From sundaram at fedoraproject.org Sat Apr 22 18:34:37 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 23 Apr 2006 00:04:37 +0530 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <200604211045.26234.nman64@n-man.com> References: <200604160349.25854.nman64@n-man.com> <1145622023.18551.139.camel@sundaram.pnq.redhat.com> <200604211045.26234.nman64@n-man.com> Message-ID: <1145730877.18551.165.camel@sundaram.pnq.redhat.com> On Fri, 2006-04-21 at 10:45 -0500, Patrick W. Barnes wrote: > On Friday 21 April 2006 07:20, Rahul Sundaram > wrote: > > On Thu, 2006-04-20 at 14:25 +0200, Frank Schmitt wrote: > > > Rahul Sundaram writes: > > > > Sounds like a wrapper for sysreport which is available in Fedora too. > > > > Would be quite useful for the less technically inclined users. > > > > > > Have a look at KDE's kinfocenter. > > > > We need a desktop environment neutral interface. > > > > There is, at this time, no such thing as "desktop-environment-neutral". All > of the "neutral" stuff in Fedora is GTK2/GNOME-based. Written in PyGTK but not GNOME based in any way. Rahul From sundaram at fedoraproject.org Sat Apr 22 18:38:16 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 23 Apr 2006 00:08:16 +0530 Subject: Fedora core suggestions In-Reply-To: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> References: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> Message-ID: <1145731096.18551.167.camel@sundaram.pnq.redhat.com> Hi On Fri, 2006-04-21 at 18:02 -0500, Arthur Pemberton wrote: > > The Fedora project is the perfect tool for this and here is how. The fedora > > team should focus SOLELY on making the operating system run as smoothly and > > as fast as possible, interacting with a HUGE number of hardware > > configurations. > > See now, here you have a problem. This is not the M.O of the Fedora > Project. Fedora was not intended to be a "pretty" desktop/home user > operating system. Fairly popular myth. Fedora has a stated goal of being a general purpose platform. Rahul From esm at logic.net Sat Apr 22 19:32:48 2006 From: esm at logic.net (Edward S. Marshall) Date: Sat, 22 Apr 2006 14:32:48 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: <1145734368.11471.19.camel@performics.wireless> On Sat, 2006-04-22 at 00:50 +0100, Leon wrote: > Basically they want to divide packages (of course installed by package > manager; those installed using source, the user has to track > themselves) into two groups: one is installed by the user (explicitly > 'yum install') and the other is those required to satisfy the > dependence. See Gentoo's "emerge depclean"; portage flags whether the package was installed explicitly or via a dependancy, and depclean allows you to remove any packages not explicitly installed which aren't depended on by anything. Howeve,r also see how many problems they've had with it; it can be a very easy way to make a system unbootable. It does, however, have a nugget of a good idea embedded in it (which Jef touched on): making it easier for administrators to manage "leaf node" packages. Some use cases I've bumped into: - Administrator removes a package, and wants to know what other packages depended on it (and only it), so they can see good candidates for removal. - Administrator wants to browse through packages which nothing depends upon, for auditing for removal. I'm sure there's a few more. "rpm -q --leafnodes" perhaps, plus a little more verbosity from "yum uninstall" detailing packages this was the sole dependancy for? -- Edward S. Marshall http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. From ihok at hotmail.com Sat Apr 22 19:44:04 2006 From: ihok at hotmail.com (Jack Tanner) Date: Sat, 22 Apr 2006 15:44:04 -0400 Subject: Fedora core suggestions In-Reply-To: <16de708d0604220957ne713fd3g744ff9e8aec0d701@mail.gmail.com> References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> <20060422144610.GB5746@imperial.ac.uk> <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> <16de708d0604220957ne713fd3g744ff9e8aec0d701@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > Can nx/freenx even be a part of Fedora legally? Why not? From nomachine.com/developers.php: "NoMachine develops the NX technology as Open Source, under the GNU Public License, including modifications to X-Window libraries, agents and proxies implementing compression and deployment of X, RDP and VNC desktops, and tunneling of CIFS/SMB and multimedia channels." FreeNX is under GPL as well. I *love* NX/FreeNX. It makes it trivial to use my FC desktop over stupid-slow coffeeshop wireless. At the same time, there are a few things that would make the NX/FC integration nicer. - Selinux needs to let NX do its thing (under FC5). - GNOME and NX need to play nice together, a la vino. - NX is unhappy on 86_64, which keeps it from Extras. I dig Jef's idea for an NX server for remote QA testing. Smart. Have the community pitch in writing test cases, have others pitch in doing the testing, and the entire thing gets logged and recorded and analyzed in-house. From smooge at gmail.com Sat Apr 22 23:21:13 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 22 Apr 2006 17:21:13 -0600 Subject: Compiling alsa 1.0.11rc4 on FC5 and kernel wierdness In-Reply-To: <442B8735.808@redhat.com> References: <75EC4D5486CAC247B84AAAA6F96AA5580705A1FF@orsmsx402.amr.corp.intel.com> <442B8735.808@redhat.com> Message-ID: <80d7e4090604221621n3b4c352es1834073daaee4fff@mail.gmail.com> On 3/30/06, Martin Stransky wrote: > check my page - http://people.redhat.com/stransky/alsa > > Martin.. now that 1.0.11 is out.. will there be updates on people.redhat.com? -- Stephen J Smoogen. CSIRT/Linux System Administrator From skvidal at linux.duke.edu Sat Apr 22 23:29:50 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 22 Apr 2006 19:29:50 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145734368.11471.19.camel@performics.wireless> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145734368.11471.19.camel@performics.wireless> Message-ID: <1145748590.13271.23.camel@cutter> > - Administrator wants to browse through packages which nothing depends > upon, for auditing for removal. > > I'm sure there's a few more. "rpm -q --leafnodes" perhaps, plus a little > more verbosity from "yum uninstall" detailing packages this was the sole > dependancy for? > 1. let's not add more items to rpm's interface. 2. yum doesn't have an 'uninstall' option - it is remove or erase 3. yum-utils contains package-cleanup. 'package-cleanup --leaves --all' lists all programs that nothing depend on 'package-cleanup --leaves' lists all libraries (or as close as it can guess) that nothing depends on. -sv From pemboa at gmail.com Sat Apr 22 23:37:04 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 22 Apr 2006 18:37:04 -0500 Subject: Fedora core suggestions In-Reply-To: References: <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> <20060422144610.GB5746@imperial.ac.uk> <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> <16de708d0604220957ne713fd3g744ff9e8aec0d701@mail.gmail.com> Message-ID: <16de708d0604221637g2833b2bdg4a3ed14c5c077a92@mail.gmail.com> On 4/22/06, Jack Tanner wrote: > Arthur Pemberton wrote: > > Can nx/freenx even be a part of Fedora legally? > > Why not? From nomachine.com/developers.php: "NoMachine develops the NX > technology as Open Source, under the GNU Public License, including > modifications to X-Window libraries, agents and proxies implementing > compression and deployment of X, RDP and VNC desktops, and tunneling of > CIFS/SMB and multimedia channels." FreeNX is under GPL as well. Okay, I asked since the packages seemed not to be in extras. -- As a boy I jumped through Windows, as a man I play with Penguins. From seg at haxxed.com Sun Apr 23 00:17:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 19:17:06 -0500 Subject: [OLD IDEA] Automatic removal of dependencies (Use aptitude!) In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> Message-ID: <1145751427.22802.34.camel@localhost.localdomain> On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote: > Checking the dependencies is the easy part. What gets less trivial is > things like this: > > [pmatilai at cs181072240 ~]$ rpm -e --test grub > [pmatilai at cs181072240 ~]$ > > Oops, nothing needs grub, so it can be removed safely, right? > > - Panu - $ cat /etc/fedora-release Fedora Core release 5 (Bordeaux) $ rpm -q apt --queryformat '%{NAME}-%{VERSION}.%{ARCH}\n' apt-0.5.15lorg3.x86_64 $ head /etc/apt/rpmpriorities Essential: grub termcap ed kbd iproute libtermcap libgcc setserial file $ sudo apt-get remove grub Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: grub (0.97-5) WARNING: The following essential packages will be removed This should NOT be done unless you know exactly what you are doing! grub 0 upgraded, 0 newly installed, 1 removed and 6 not upgraded. Need to get 0B of archives. After unpacking 1767kB disk space will be freed. You are about to do something potentially harmful To continue type in the phrase 'Yes, do as I say!' ?] No thanks. Abort. BTW, kickass work on apt, Panu. You have first dibs on my firstborn child. If anyone wants to play with aptitude on Fedora, which already supports the exact feature this thread is about, I've made up a package: http://www.haxxed.com/rpms/aptitude-0.3.3-1.src.rpm http://www.haxxed.com/rpms/FC5/aptitude-0.3.3-1.x86_64.rpm http://www.haxxed.com/rpms/FC5/aptitude-0.3.3-1.i386.rpm On FC5 you will need/want apt from the extras-development repo, which supports multilib and yum style metadata. And a bonus screenshot: http://www.haxxed.com/rpms/Screenshot-aptitude.png -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Sun Apr 23 01:10:01 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 23 Apr 2006 01:10:01 +0000 (UTC) Subject: [OLD IDEA] Automatic removal of dependencies (Use aptitude!) References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> <1145751427.22802.34.camel@localhost.localdomain> Message-ID: Callum Lerwick haxxed.com> writes: > And a bonus screenshot: > http://www.haxxed.com/rpms/Screenshot-aptitude.png Err, removing system-config-display as "unused" doesn't look like that great an idea to me... Kevin Kofler From seg at haxxed.com Sun Apr 23 01:17:57 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 20:17:57 -0500 Subject: [OLD IDEA] Automatic removal of dependencies (Use aptitude!) In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <604aa7910604211718g54268489s1ee6d68767140e99@mail.gmail.com> <1145708428.19696.63.camel@hammer> <1145751427.22802.34.camel@localhost.localdomain> Message-ID: <1145755077.22802.38.camel@localhost.localdomain> On Sun, 2006-04-23 at 01:10 +0000, Kevin Kofler wrote: > Callum Lerwick haxxed.com> writes: > > And a bonus screenshot: > > http://www.haxxed.com/rpms/Screenshot-aptitude.png > > Err, removing system-config-display as "unused" doesn't look like that great an > idea to me... Err, well that's because I marked it as auto installed because I don't really need or want it. Toggling the flag is as simple as hitting M or m. It nicely doubles as an easy way to ask "Hey, do I really need this?". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sun Apr 23 01:28:21 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 22 Apr 2006 20:28:21 -0500 Subject: Fedora core suggestions In-Reply-To: <1145731096.18551.167.camel@sundaram.pnq.redhat.com> References: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> <1145731096.18551.167.camel@sundaram.pnq.redhat.com> Message-ID: <1145755703.22802.43.camel@localhost.localdomain> On Sun, 2006-04-23 at 00:08 +0530, Rahul Sundaram wrote: > On Fri, 2006-04-21 at 18:02 -0500, Arthur Pemberton wrote: > > See now, here you have a problem. This is not the M.O of the Fedora > > Project. Fedora was not intended to be a "pretty" desktop/home user > > operating system. > > Fairly popular myth. Fedora has a stated goal of being a general purpose > platform. Perhaps, but the #1 reason I use Fedora is because it is the most solid, reliable, well thought out distribution for desktop use there is IMHO, and has been since RH 7.0. Lets not forget this. In fact, my server runs debian. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sun Apr 23 07:27:10 2006 From: buildsys at redhat.com (Build System) Date: Sun, 23 Apr 2006 03:27:10 -0400 Subject: rawhide report: 20060423 changes Message-ID: <200604230727.k3N7RACP017927@porkchop.devel.redhat.com> Updated Packages: device-mapper-1.02.05-1.2 ------------------------- * Sat Apr 22 2006 Alasdair Kergon - 1.02.05-1.2 - Exclude s390/s390x in order to rebuild. * Fri Apr 21 2006 Alasdair Kergon - 1.02.05-1.1 - Rebuild. * Wed Apr 19 2006 Alasdair Kergon - 1.02.05-1.0 - New upstream release (incorporates patches). - Exclude dmeventd (no kernel support yet). lvm2-2.02.05-1.1 ---------------- * Sat Apr 22 2006 Alasdair Kergon - 2.02.05-1.1 - Exclude archs that aren't building. * Fri Apr 21 2006 Alasdair Kergon - 2.02.05-1.0 - Fix VG uuid comparisons. * Wed Apr 19 2006 Alasdair Kergon - 2.02.04-1.0 - New release upstream, including better handling of duplicated VG names. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From gilboad at gmail.com Sun Apr 23 08:03:06 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 23 Apr 2006 11:03:06 +0300 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <1145779386.13391.32.camel@gilboa-work-dev> On Fri, 2006-04-21 at 10:42 -0400, Alo Tsum wrote: > Fedora Core 5 is a truly amazing OS and one I think has the potential > to really do great things. Looking forward to what the Fedora Project > has the potential to do, especially with its new focus I decided to > give some suggestions as to what could possibly be done starting with > Fedora 6 and onward. Some of my suggestions are definitely based on > the OS itself but others are also concerning the general focus and > outlook of the Fedora Project itself. I hope my suggestion are not > regarded as offensive in anyway and they are only meant to highlight > the greatness of Fedora as well as to reflect my strong desire to see > this project take off and propel the Linux OS to new heights. > > First suggestions has to do with the software side of things. We users > need a competent software installer which is graphical based. One that > functions much the same way that the windows installer works. Oh, no we don't! Each Application in the Windows world uses it's own installer; The OS itself has no control over what each installer does and how it registers itself... or even worse, if it's even capable of uninstalling itself. > This installer should track dependencies naturally and place icons on > the desktop or give the option to have icons for the software just > installed to be placed on the desktop of the user as well as in the > applications menu. A. Most Windows installers -do- no track dependencies. At best, they just blindly copy required DLL into the application directory. (Or worse, into System32 and/or common, causing the lovely "DLL Hell" phenomenon) B. Most/all Windows installers are in-capable of downloading dependencies. C. Most Windows installers do no ask you if you want desktop icons (I don't!)... nor do they ask you where you want to installer the icons, or even the application itself. No, we really, -really-, -really- don't want to mimic Microsoft's crappy install system. > Also when watching the Boston Linux conference the suggestion was made > to offer a hard disc manager much like windows offers for formating > and receiving hard drivers etc after installation. ? Anaconda already has such tool. Same goes for lvm. (system-config-lvm) > > My second set of suggestions will deal with the over all focus and > structure of the fedora project. I was listening to a pod cast > interview with the head of the fedora project where in, the topic came > up of some how generating revenue to put back into the project and > make it more self sufficient. So I have a few suggestions which I > think the Redhat company itself should take note of. Firstly Redhat > while promoting Linux among enthusiast is also in the business of > making money. On that front I believe that they should not only > attempt to evangelize Linux in the government, education, and > corporate sectors; they should also attempt to get Linux in each and > every home. The reason being is if people are starting to use Linux in > their homes and they are comfortable with it, employers will be more > likely and willing to deploy a operating system which is different in > many ways to windows on the interactive level. Reason being is when > people have to stop to learn new technology this cuts down on > productivity and as a person who works for a IT department in a major > university I can also vouch for the fact a IT team will not be willing > to suggest an infrastructure restructuring when they know, supporting > users on something foreign to them is going to increase their workload > 10 fold. So bottom line, more users both advanced, intermediate and > beginners need to be converted to the Linux faithful but now the > question becomes how? I doubt that Linux will be joe-six-pack ready any time soon. Come to think about it, I doubt that Windows is joe-six-pack ready. Having said that, pushing Fedora into the hands of home users, is a -great- way to push Linux into enterprises. (and vice versa) > > The Fedora project is the perfect tool for this and here is how. The > fedora team should focus SOLELY on making the operating system run as > smoothly and as fast as possible, interacting with a HUGE number of > hardware configurations. Installation needs to be as smooth as silk > and upgrading needs to be fail proof from version to version. > Previously installed drives As long as open source drivers are being used, upgrade can/should preserve them. Once close source drivers are used, it's PITA. BTW, same goes for Windows; MS can hardly use Windows ME drivers if you upgrade to XP.... > with personal user data needs to be able to be retained without fail > from upgrade to upgrade if the user isn't doing a clean install. ACK. > Now I would like to move on to "partnerships" Fedora project should > look into making "partners" or some other creative term to define > other Linux projects and organizations. In this partnership Fedora > will tightly enforce standards which will ensure that any software > created to run on fedora is following say the OIN and the GPL > standards to the letter to ensure an user friendly and secure/stable > operating system that runs smoothly. Many people in the Linux > community may grumble about this suggestion however life is about > progression and when things do not change and evolve and progress to > new levels then they are doomed to become extinct (think dinosaurs > here) or at the very least remain niche applications. Enforcing people into doing things never works... especially when it comes to FOSS. FOSS is built around being a thriving ecosystem with multiple competing projects... In my view KDE vs. GNOME, OpenOffice vs. koffice, Opera vs. Konq vs Firefox, etc is a -good- thing. Trying to enforce it will only create yet-another Microsoft... I doubt that we want to create such a monster. I do agree on full GPL/OIN, though. > If Fedora project implements such a model, they do not have to worry > about making certain software for the OS which would take far to much > time and man power to create. Prime example would be the hard disk > manager or even the software installer. Ummm... > This sort of work could be left to groups who's soul purpose is to > make such software and by following strict guidelines they would > become Fedora project "partners" and in turn they would be promised > that their software will be included in the fedora core release. Also > by following strict guidelines this software could be implemented in > other Linux distributions which are also following said guidelines. > This would take the pressure off of Fedora and they can then focus on > whats important which is making their OS run like silk. Again let me > stress this approach is keeping in mind that projects such as Fedora > and other Linux distributions desire to penetrate more into the home > desktop market, which then also means more users will or could > eventually equate to greater adoption of the platform in other > industries as a result of user awareness and user comfort with the > Linux platform. I should also mention that those software development > groups that do not comply could be offered as Fedora extras so the > community still has choices which is really part of the appeal of > Linux. I semi agree with you here... do again, I rather have 6 projects trying to achieve goal X, each taking a different route (with the best project wins) then a single, enforced way of doing things. I doubt that FOSS would have been if only GNOME would have existed. (and vice versa) > > Okay so with all that said how could this generate income? Well lets > say Fedora project comes up with one of the first 100% standard > enforced distributions which is as user friendly or even more so than > MS windows. Now say a "ambassador" from Fedora can start making the > rounds to Dell and other companies and attempt to get them to start > offering this FREE Linux distribution on some of their PC models, > which would also allow for lower prices on the retail side for them > (ie Dell, Gateway etc.) as the OS is FREE and that cuts down on cost > which the end user ends up incurring. But we still have not addressed > revenue for the Fedora project, and this can be done by following the > Redhat model of offering technical support. Fedora project could > basically offer technical support certification and training to Dell > staff as an example so they (the PC manufacturer) can then take over > supporting the platform for their end users, which also equates to > revenue for these companies in the long run because they can offer > extended tech support to end users at a premium. Fedora core could > charge a VERY minimal fee for this training, so say charge enough that > it would generate revenue that can then be pumped back into the > project and at the same time would still make it cheaper for Dell and > other companies to go with Linux on some desktop offerings as opposed > to having a windows only offering. Umm.... You are suggesting RedHat drops RHEL and uses Fedora instead, returning to the old "RedHat Linux" model. I can't see what RedHat has to gain by dropping RHEL. > > The future of Linux if to be taken seriously should not be relegated > to just the business, government, and education world as far as > standards, reliability, and software / hardware vendor support is > concerned. The brand will grow far more rapidly if consumers are > adopting the standard at home and at work so basically this is a > bottom up approach. This of this, more desktop users in the home also > means more software sales for major companies because you will have > more people buying video games and other such things which will also > mean more companies willing to adopt the platform because software > offering become greater. ACK. > > There needs to be a consorted effort on the parts of all parties > involved to take Linux to that next phase of existence other wise > Linux as a brand, while it may grow some what will not see its full > potential. With the software being a open and free model we still have > to realize with a flurry of hodge podge coding and no standards > insight the end user ends up losing at least as far as the home front > is concerned. Most people are forced to run duel boot Windows and > Linux systems because software makers and hardware manufactures have > not fully bought into the Linux model and we as a community only have > ourselves to blame for that. Not that again... Sigh.... The FOSS community cannot force hardware manufacturers to release open source drivers. The FOSS community cannot even make sure that they build compatible closed source drivers. More-ever, as an ex Microsoft Beta tester, I can vividly remember the first release versions of Windows NT (3.1, 3.5, 3.5.1, 4) and 2000 which were just as troublesome (driver support wise) as Linux is today. If you wanted to run Windows NT 3.1, you needed NT 3.1 support hardware. Same goes for Windows 2K (when it was released...) And the same goes for Linux. > This approach will also take some evangelizing to the software makers > of such things as yum and KDE however I believe that those who do not > see the need and importants of doing such things will render > themselves obsolete in the long run. Just look at the Unix model, and > we can see what the disasters of not doing this can incur. Doing what? Dropping GPL? Freezing the kernel API by moving into stagnant development mode just so nVidia/ATI won't be required to keep up? What are you suggesting? Gilboa From dcbw at redhat.com Sun Apr 23 17:06:14 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 23 Apr 2006 13:06:14 -0400 Subject: Madwifi/wpa_supplicant packaging In-Reply-To: <1145693184.3602.15.camel@T7.Linux> References: <444967BB.7010504@redfish-solutions.com> <1145693184.3602.15.camel@T7.Linux> Message-ID: <1145811974.2241.2.camel@localhost.localdomain> On Sat, 2006-04-22 at 09:06 +0100, Paul wrote: > Hi, > > > That way if you grab madwifi from ATrpms, and rebuild wpa_supplicant > > from source it will do the right thing... > > Why can't we just have madwifi-ng as a FE package? Because it's not fully FOSS. There's still the binary HAL module that needs to be compiled _into_ the kernel driver. OpenBSD has had some success in reverse-engineering the HAL, but it's not stable yet AFAIK and certainly isn't ready to replace the binary HAL from Atheros. Since it's not fully open, we can't include madwifi-ng in Extras or Core. Therefore, we also can't depend on any such package for wpa_supplicant. Dan From nicolas.mailhot at laposte.net Sun Apr 23 17:50:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 23 Apr 2006 19:50:33 +0200 Subject: Fedora core suggestions In-Reply-To: <1145779386.13391.32.camel@gilboa-work-dev> References: <1145779386.13391.32.camel@gilboa-work-dev> Message-ID: <1145814636.2632.2.camel@rousalka.dyndns.org> Le dimanche 23 avril 2006 ? 11:03 +0300, Gilboa Davara a ?crit : > > Also when watching the Boston Linux conference the suggestion was made > > to offer a hard disc manager much like windows offers for formating > > and receiving hard drivers etc after installation. > > ? > Anaconda already has such tool. > Same goes for lvm. (system-config-lvm) They're not in the same class : - the anaconda tool is only available at install time - the lvm tool is rather weak Compared to the windows tools, they're worse than the printing subsystem and everyone has been complaining about this one lately 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 nicolas.mailhot at laposte.net Sun Apr 23 19:50:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 23 Apr 2006 21:50:24 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <4447BA6D.8050405@hhs.nl> References: <200604160349.25854.nman64@n-man.com> <44479299.3010907@hhs.nl> <4447BA6D.8050405@hhs.nl> Message-ID: <1145821827.2632.9.camel@rousalka.dyndns.org> Le jeudi 20 avril 2006 ? 18:44 +0200, Hans de Goede a ?crit : > Rudolf Kastl wrote: > > 2006/4/20, Hans de Goede : > > Do you have something like a "design document"? atleast as raw as > > specifying what each component has to do? > > > > In my head, yes on paper, no. But if there is serious interest in this > I'm more then willing to produce such a document. > > > from what i understand you want a db with a webfrontend accessible to > > users to add their info? wouldnt the info have to be verified somehow? > > > > Preferably yes, maybe with a voting system or something, anyone know how > linuxprinting does this? How about doing it the full way by doing the hardware db everyone dreams about : 1. a small client that detects all the stuff on a system 2. optionally asks user to rank support for all the bits he got (interactive mode - should be possible to just transparently collect changed hw on boot/hotplug) 3. uploads results to a central db where people can read/comment on them, add config info, with forums dedicated to ranges of hardware, links to authoritative sites, etc (ie the project desktop linux people talked a lot a few months ago but no one worked on as far as I know) 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 seg at haxxed.com Sun Apr 23 20:14:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 23 Apr 2006 15:14:49 -0500 Subject: Fedora core suggestions In-Reply-To: <1145814636.2632.2.camel@rousalka.dyndns.org> References: <1145779386.13391.32.camel@gilboa-work-dev> <1145814636.2632.2.camel@rousalka.dyndns.org> Message-ID: <1145823290.22802.66.camel@localhost.localdomain> On Sun, 2006-04-23 at 19:50 +0200, Nicolas Mailhot wrote: > They're not in the same class : > - the anaconda tool is only available at install time Adapting Disk Druid to function outside of install would be quite nice. > - the lvm tool is rather weak And why replicate the functionality Disk Druid already has... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From codeshepherd at gmail.com Sun Apr 23 20:47:46 2006 From: codeshepherd at gmail.com (Deepan Chakravarthy) Date: Mon, 24 Apr 2006 02:17:46 +0530 Subject: Harvestman in Fedora extras. In-Reply-To: <4447D58D.8060404@redhat.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> <4447BC47.7090806@redhat.com> <20060420175848.GF14128@devserv.devel.redhat.com> <4447D58D.8060404@redhat.com> Message-ID: <444BE7F2.8050807@gmail.com> Harvestman is a web crawler written in python. It is now shipped in debian. I would like to maintain harvestman for fedora extras. How do I add harvestman to fedora extras ?? Please guide me . Thanks Harvestman website: http://harvestman.freezope.org/ -Deepan www.codeshepherd.com From bdpepple at ameritech.net Sun Apr 23 20:55:58 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 23 Apr 2006 16:55:58 -0400 Subject: Harvestman in Fedora extras. In-Reply-To: <444BE7F2.8050807@gmail.com> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <44479672.1040408@redhat.com> <20060420172033.1c1eb2c4@python2> <44479B84.5050900@redhat.com> <20060420193642.7a8a7637@python2> <4447B9D0.4020108@redhat.com> <1145555276.26605.66.camel@orodruin.boston.redhat.com> <4447BC47.7090806@redhat.com> <20060420175848.GF14128@devserv.devel.redhat.com> <4447D58D.8060404@redhat.com> <444BE7F2.8050807@gmail.com> Message-ID: <1145825758.26334.0.camel@shuttle.piedmont.com> On Mon, 2006-04-24 at 02:17 +0530, Deepan Chakravarthy wrote: > Harvestman is a web crawler written in python. It is now shipped in > debian. I would like to maintain harvestman for fedora extras. How do I > add harvestman to fedora extras ?? Please guide me . Thanks > Harvestman website: http://harvestman.freezope.org/ Go to http://fedoraproject.org/wiki/Extras /B -- Brian Pepple 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: 189 bytes Desc: This is a digitally signed message part URL: From usdanskys at rocketmail.com Sun Apr 23 21:56:12 2006 From: usdanskys at rocketmail.com (Steven I Usdansky) Date: Sun, 23 Apr 2006 14:56:12 -0700 (PDT) Subject: X problem - no display with latest update Message-ID: <20060423215612.92401.qmail@web35310.mail.mud.yahoo.com> Averatec 3200-series laptop using the vesa driver. X apparently starts, but the display remains blank. Reinstalling xorg-x11-server-Xorg, xorg-x11-server-utils, all of the various xorg-x11-drv rpms, and the synaptics rpm from FC5 brings back my display. /var/log/Xorg.0.log for the blank display: http://soleil.nfldinet.com/~rockdoctor/Xorg.0.log /etc/X11/xorg.conf: http://soleil.nfldinet.com/~rockdoctor/xorg.conf -- Rock Doctor Registered Linux user #360200 =========================== Steven I. Usdansky, PhD Rock Doctor __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From z at canteiros.org Mon Apr 24 02:53:10 2006 From: z at canteiros.org (Z) Date: Sun, 23 Apr 2006 19:53:10 -0700 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> Message-ID: <444C3D96.4030205@canteiros.org> Joe Desbonnet wrote: > I sent this suggestion to the original poster of the thread and it > may have become lost: > > Project proposal: integrate Suse DeltaRPM software with yum to improve > bandwidth efficiency when updating a distribution. I've experimented > with this and I've got good results > (see http://www.wombat.ie/software/rpmdc/manual.html ). However my > implementation is heavy, requiring Java, Tomcat etc. > > Joe. > What about using bittorrent as a transport? Z From skvidal at linux.duke.edu Mon Apr 24 03:11:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Apr 2006 23:11:04 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <444C3D96.4030205@canteiros.org> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> <444C3D96.4030205@canteiros.org> Message-ID: <1145848264.25417.0.camel@cutter> On Sun, 2006-04-23 at 19:53 -0700, Z wrote: > Joe Desbonnet wrote: > > I sent this suggestion to the original poster of the thread and it > > may have become lost: > > > > Project proposal: integrate Suse DeltaRPM software with yum to improve > > bandwidth efficiency when updating a distribution. I've experimented > > with this and I've got good results > > (see http://www.wombat.ie/software/rpmdc/manual.html ). However my > > implementation is heavy, requiring Java, Tomcat etc. > > > > Joe. > > > > What about using bittorrent as a transport? > Read the logs of this and yum mailing lists. It's been hashed out probably a dozen different times. -sv From bojan at rexursive.com Mon Apr 24 06:13:10 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 24 Apr 2006 16:13:10 +1000 Subject: Mozilla in FC6 Message-ID: <20060424161310.vihr3wl8mco0skw4@www.rexursive.com> So, what was the conclusion regarding Mozilla in FC6 (i.e. as a set of libs for things like Epiphany)? Is it being dropped in favour of FF or is it staying? Don't want to start a flame war, just being curious... -- Bojan From jfrieben at freesurf.fr Mon Apr 24 07:05:55 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 24 Apr 2006 09:05:55 +0200 (CEST) Subject: Mozilla in FC6 In-Reply-To: <20060424161310.vihr3wl8mco0skw4@www.rexursive.com> References: <20060424161310.vihr3wl8mco0skw4@www.rexursive.com> Message-ID: <57360.172.177.236.124.1145862355.squirrel@arlette.freesurf.fr> Replacing "mozilla" is highly overdue, as it still relies on the Gecko 1.7 backend which is completely outdated. One negative effect of this is a much lower printing quality. Newer Gecko versions e.g. allow to print Truetype fonts whereas Gecko 1.7 falls back to using plain PS fonts. See also my earlier bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130697 > So, what was the conclusion regarding Mozilla in FC6 (i.e. as a set of > libs for things like Epiphany)? Is it being dropped in favour of FF or > is it staying? From buildsys at redhat.com Mon Apr 24 07:20:18 2006 From: buildsys at redhat.com (Build System) Date: Mon, 24 Apr 2006 03:20:18 -0400 Subject: rawhide report: 20060424 changes Message-ID: <200604240720.k3O7KIvu011638@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.16-1.2153_FC6 ------------------------ * Sun Apr 23 2006 Dave Jones - 2.6.17rc2-git5 * Sat Apr 22 2006 Dave Jones - Ugly SATA suspend/resume hack de jour. * Sat Apr 22 2006 Juan Quintela - rebase xen. - fix x86_64 xen (thanks chris). - enable xen again. openoffice.org-1:2.0.2-5.10.3 ----------------------------- * Tue Apr 18 2006 Caolan McNamara - 1:2.0.2-5.10 - ooo#64463# don't require Xaw for the use mozilla plugins (e.g flash) in OOo feature - ooo#64508#/rh#189061# honour fontconfig hinting settings Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hal - 0.5.7-4.s390 requires pm-utils >= 0:0.10-1 hal - 0.5.7-4.s390x requires pm-utils >= 0:0.10-1 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From pemboa at gmail.com Mon Apr 24 08:04:19 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 03:04:19 -0500 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145848264.25417.0.camel@cutter> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> <444C3D96.4030205@canteiros.org> <1145848264.25417.0.camel@cutter> Message-ID: <16de708d0604240104i187a8169t6cefd570c302bce2@mail.gmail.com> On 4/23/06, seth vidal wrote: > On Sun, 2006-04-23 at 19:53 -0700, Z wrote: > > Joe Desbonnet wrote: > > > I sent this suggestion to the original poster of the thread and it > > > may have become lost: > > > > > > Project proposal: integrate Suse DeltaRPM software with yum to improve > > > bandwidth efficiency when updating a distribution. I've experimented > > > with this and I've got good results > > > (see http://www.wombat.ie/software/rpmdc/manual.html ). However my > > > implementation is heavy, requiring Java, Tomcat etc. > > > > > > Joe. > > > > > > > What about using bittorrent as a transport? > > > > Read the logs of this and yum mailing lists. > > It's been hashed out probably a dozen different times. > Could you please summarise the conclusion? -- As a boy I jumped through Windows, as a man I play with Penguins. From pemboa at gmail.com Mon Apr 24 08:05:59 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 03:05:59 -0500 Subject: Mozilla in FC6 In-Reply-To: <57360.172.177.236.124.1145862355.squirrel@arlette.freesurf.fr> References: <20060424161310.vihr3wl8mco0skw4@www.rexursive.com> <57360.172.177.236.124.1145862355.squirrel@arlette.freesurf.fr> Message-ID: <16de708d0604240105x3f6fd8c4x893743900ff8b2be@mail.gmail.com> On 4/24/06, Joachim Frieben wrote: > Replacing "mozilla" is highly overdue, as it still relies on the Gecko 1.7 > backend which is completely outdated. One negative effect of this is a much > lower printing quality. Newer Gecko versions e.g. allow to print Truetype > fonts whereas Gecko 1.7 falls back to using plain PS fonts. See also my > earlier bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130697 > > > So, what was the conclusion regarding Mozilla in FC6 (i.e. as a set of > > libs for things like Epiphany)? Is it being dropped in favour of FF or > > is it staying? > It would be nice to see a complete move away from mozilla and to Seamonkey, Mozilla Suite (which is my preference) has numerous rendering issues. And I am just not a fan of Firefox for my majority browsing. -- As a boy I jumped through Windows, as a man I play with Penguins. From mark at borkware.net Mon Apr 24 08:09:27 2006 From: mark at borkware.net (Mark Rosenstand) Date: Mon, 24 Apr 2006 10:09:27 +0200 Subject: Mozilla in FC6 In-Reply-To: <16de708d0604240105x3f6fd8c4x893743900ff8b2be@mail.gmail.com> References: <20060424161310.vihr3wl8mco0skw4@www.rexursive.com> <57360.172.177.236.124.1145862355.squirrel@arlette.freesurf.fr> <16de708d0604240105x3f6fd8c4x893743900ff8b2be@mail.gmail.com> Message-ID: <1145866167.7751.1.camel@hammer> On Mon, 2006-04-24 at 03:05 -0500, Arthur Pemberton wrote: > On 4/24/06, Joachim Frieben wrote: > > Replacing "mozilla" is highly overdue, as it still relies on the Gecko 1.7 > > backend which is completely outdated. One negative effect of this is a much > > lower printing quality. Newer Gecko versions e.g. allow to print Truetype > > fonts whereas Gecko 1.7 falls back to using plain PS fonts. See also my > > earlier bug report: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130697 > > > > > So, what was the conclusion regarding Mozilla in FC6 (i.e. as a set of > > > libs for things like Epiphany)? Is it being dropped in favour of FF or > > > is it staying? > > > > It would be nice to see a complete move away from mozilla and to > Seamonkey, Mozilla Suite (which is my preference) has numerous > rendering issues. And I am just not a fan of Firefox for my majority > browsing. There's also xulrunner which is actually designed to solve this problem. From jfrieben at freesurf.fr Mon Apr 24 09:56:08 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 24 Apr 2006 11:56:08 +0200 (CEST) Subject: Mozilla in FC6 In-Reply-To: <1145866167.7751.1.camel@hammer> References: <1145866167.7751.1.camel@hammer> Message-ID: <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> In principle, it could be dropped as distros like Ubuntu already build "epiphany" against "firefox". In this case, "epiphany" benefits from the improved Gecko backend (> 1.8) which e.g. solves the Truetype printing problem reported earlier. > > So, what was the conclusion regarding Mozilla in FC6 (i.e. as a > set of libs for things like Epiphany)? Is it being dropped in > favour of FF or is it staying? > From alan at redhat.com Mon Apr 24 09:58:47 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 24 Apr 2006 05:58:47 -0400 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <444C3D96.4030205@canteiros.org> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> <444C3D96.4030205@canteiros.org> Message-ID: <20060424095847.GB6775@devserv.devel.redhat.com> On Sun, Apr 23, 2006 at 07:53:10PM -0700, Z wrote: > What about using bittorrent as a transport? Bittorrent is oriented around large data quantities. The notion of grabbing bits of update from anyone is great, but the granularity it works on would probably make it impractical and a lose for anything but openoffice.org From tla-ml at rasmil.dk Mon Apr 24 10:33:23 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 24 Apr 2006 12:33:23 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <16de708d0604240104i187a8169t6cefd570c302bce2@mail.gmail.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606801.2945.12.camel@gibraltar.stuttgart.redhat.com> <1145623542.3099.9.camel@gibraltar.stuttgart.redhat.com> <1cef3e950604210842o425458b0lbb05a2dfc77845ae@mail.gmail.com> <444C3D96.4030205@canteiros.org> <1145848264.25417.0.camel@cutter> <16de708d0604240104i187a8169t6cefd570c302bce2@mail.gmail.com> Message-ID: <444CA973.8050104@rasmil.dk> Arthur Pemberton wrote: > On 4/23/06, seth vidal wrote: > >> On Sun, 2006-04-23 at 19:53 -0700, Z wrote: >> >>> Joe Desbonnet wrote: >>> >>>> I sent this suggestion to the original poster of the thread and it >>>> may have become lost: >>>> >>>> Project proposal: integrate Suse DeltaRPM software with yum to improve >>>> bandwidth efficiency when updating a distribution. I've experimented >>>> with this and I've got good results >>>> (see http://www.wombat.ie/software/rpmdc/manual.html ). However my >>>> implementation is heavy, requiring Java, Tomcat etc. >>>> >>>> Joe. >>>> >>>> >>> What about using bittorrent as a transport? >>> >>> >> Read the logs of this and yum mailing lists. >> >> It's been hashed out probably a dozen different times. >> >> > > Could you please summarise the conclusion? > Here is a place to start: https://lists.dulug.duke.edu/pipermail/yum/2005-June/006895.html Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From P at draigBrady.com Mon Apr 24 10:48:45 2006 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 24 Apr 2006 11:48:45 +0100 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145734368.11471.19.camel@performics.wireless> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145734368.11471.19.camel@performics.wireless> Message-ID: <444CAD0D.8070308@draigBrady.com> Edward S. Marshall wrote: >On Sat, 2006-04-22 at 00:50 +0100, Leon wrote: > > >>Basically they want to divide packages (of course installed by package >>manager; those installed using source, the user has to track >>themselves) into two groups: one is installed by the user (explicitly >>'yum install') and the other is those required to satisfy the >>dependence. >> >> > >See Gentoo's "emerge depclean"; portage flags whether the package was >installed explicitly or via a dependancy, and depclean allows you to >remove any packages not explicitly installed which aren't depended on by >anything. Howeve,r also see how many problems they've had with it; it >can be a very easy way to make a system unbootable. > >It does, however, have a nugget of a good idea embedded in it (which Jef >touched on): making it easier for administrators to manage "leaf node" >packages. Some use cases I've bumped into: > >- Administrator removes a package, and wants to know what other packages >depended on it (and only it), so they can see good candidates for >removal. > > You can do that quite simply with rpm and dpkg currently. See: http://www.pixelbeat.org/scripts/whatrequires P?draig. From rdieter at math.unl.edu Mon Apr 24 11:56:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Apr 2006 06:56:47 -0500 Subject: Mozilla in FC6 In-Reply-To: <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> References: <1145866167.7751.1.camel@hammer> <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> Message-ID: <444CBCFF.3060006@math.unl.edu> Joachim Frieben wrote: > In principle, it could be dropped as distros like Ubuntu already build > "epiphany" against "firefox". FC already uses the browser-independant (ie, not mozilla-specific) nspr and nss packages. -- Rex From mark at borkware.net Mon Apr 24 12:14:48 2006 From: mark at borkware.net (Mark Rosenstand) Date: Mon, 24 Apr 2006 14:14:48 +0200 Subject: Mozilla in FC6 In-Reply-To: <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> References: <1145866167.7751.1.camel@hammer> <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> Message-ID: <1145880888.18645.3.camel@hammer> On Mon, 2006-04-24 at 11:56 +0200, Joachim Frieben wrote: > In principle, it could be dropped as distros like Ubuntu already build > "epiphany" against "firefox". In this case, "epiphany" benefits from the > improved Gecko backend (> 1.8) which e.g. solves the Truetype printing > problem reported earlier. It's cleaner to build both epiphany and firefox against xulrunner. Forcing epiphany users to have firefox installed doesn't make any sense when it's possible to use a neutral backend for both. From avibrazil at gmail.com Mon Apr 24 12:48:21 2006 From: avibrazil at gmail.com (Avi Alkalay) Date: Mon, 24 Apr 2006 09:48:21 -0300 Subject: Fedora Bounties (seeking ideas) In-Reply-To: <1145606930.2945.15.camel@gibraltar.stuttgart.redhat.com> References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606930.2945.15.camel@gibraltar.stuttgart.redhat.com> Message-ID: Well, that was pointed as a problem to be solved. Since Elektra is a GConf-like (but simpler and much lighter) global system and session configuration backend, and since, as far as I know, there is nothing else out there that provides similar funcionatility, thats what I proposed. You are welcome to propose another solution. Thank you, Avi On 4/21/06, Nils Philippsen wrote: > On Thu, 2006-04-20 at 13:26 -0300, Avi Alkalay wrote: > > >From the Bounties page: > > > > ----------------------- > > System G-Conf (or other configuration) backend > > > > Currently, NetworkManager relies on talking to the session GConf > > daemon for configuration. With some of these other interface types, a > > configuration store is needed that would be available even when no > > user session is initialized. > > ----------------------- > > > > I'd like to propose Elektra as this other system-wide configuration backend. > > GConf, in its essence, was not designed to be system wide. It actually > > has too much dependencies for that. > > > > More info here: > > http://www.libelektra.org/ > > http://www.libelektra.org/GConf > > Oh please ... let's ... not ... start ... that ... discussion ... again! > > Every argument for and against either GConf or Elektra has been brought > forth already, nothing to see here, move along. > > Nils From avibrazil at gmail.com Mon Apr 24 13:41:38 2006 From: avibrazil at gmail.com (Avi Alkalay) Date: Mon, 24 Apr 2006 10:41:38 -0300 Subject: What SuSE folks are thinking Message-ID: https://bugzilla.novell.com/show_bug.cgi?id=103734 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clumens at redhat.com Mon Apr 24 13:42:23 2006 From: clumens at redhat.com (Chris Lumens) Date: Mon, 24 Apr 2006 09:42:23 -0400 Subject: any reason why system-config-kickstart requires root? In-Reply-To: <20060422010317.43857.qmail@web38415.mail.mud.yahoo.com> References: <20060422010317.43857.qmail@web38415.mail.mud.yahoo.com> Message-ID: <20060424134223.GA2985@exeter.boston.redhat.com> > I can't think of one, and running > > /usr/share/system-config-kickstart/system-config-kickstart.py > > manually seems to work just fine (I saved my kickstart file without incident). > > Should I file a bug? It requires root because it uses pirut for the package selection screen, and that requires root because it uses yum, which may need to update the cache files in /var/cache/yum. It's working as intended. - Chris From pmatilai at laiskiainen.org Mon Apr 24 13:49:47 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 24 Apr 2006 06:49:47 -0700 (PDT) Subject: any reason why system-config-kickstart requires root? In-Reply-To: <20060424134223.GA2985@exeter.boston.redhat.com> References: <20060422010317.43857.qmail@web38415.mail.mud.yahoo.com> <20060424134223.GA2985@exeter.boston.redhat.com> Message-ID: On Mon, 24 Apr 2006, Chris Lumens wrote: >> I can't think of one, and running >> >> /usr/share/system-config-kickstart/system-config-kickstart.py >> >> manually seems to work just fine (I saved my kickstart file without incident). >> >> Should I file a bug? > > It requires root because it uses pirut for the package selection screen, > and that requires root because it uses yum, which may need to update the > cache files in /var/cache/yum. It's working as intended. Yum supports per-user private cache, that's what most yum-utils use for non-root usage. Look for getCacheDir() usage in yum-utils how to make use of it. - Panu - From vonbrand at inf.utfsm.cl Sun Apr 23 04:22:07 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 23 Apr 2006 00:22:07 -0400 Subject: Fedora core suggestions In-Reply-To: Your message of "Sat, 22 Apr 2006 12:24:02 EST." <1145726644.22802.10.camel@localhost.localdomain> Message-ID: <200604230422.k3N4MFe0007827@quelen.inf.utfsm.cl> Callum Lerwick wrote: > On Fri, 2006-04-21 at 19:27 -0400, Jeff Spaleta wrote: > > -jef"Generally good ideas are generally very bad discussions. Boring, > > mind-numbing detailed specific implementation issues are far more > > constructive discussions"spaleta > > +1 > > Discussions of grand unified plans for whatever belong on fedora-user or > fedora-marketing or anywhere but here. They should be carefully filed in /dev/null. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Sun Apr 23 02:10:43 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sat, 22 Apr 2006 22:10:43 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: Your message of "Sat, 22 Apr 2006 16:07:23 +0200." <1145714843.19696.80.camel@hammer> Message-ID: <200604230210.k3N2AhSo005660@quelen.inf.utfsm.cl> Mark Rosenstand wrote: > On Sat, 2006-04-22 at 06:30 -0700, Panu Matilainen wrote: > > Checking the dependencies is the easy part. What gets less trivial is > > things like this: > > > > [pmatilai at cs181072240 ~]$ rpm -e --test grub > > [pmatilai at cs181072240 ~]$ > > > > Oops, nothing needs grub, so it can be removed safely, right? > The Debian tool assumes that its users are capable of brain activity. Riiight... > I > don't know if this is a problem in the Fedora case. You haven't met many end users, have you? [In any case, a tool like this is completely useless if it /forces/ the user to know about the stuff they have installed... that's 1284 packages currently here, I sure don't know what each one of them does. I'd be real pressed to name more than a hundred. Forget about dependencies...] > Anyway, it does have > a couple of more options than Y/n, one of them being 'i' which prints > the description of the package, so it's easy to get a pretty good clue > if you're uncertain whether you need the package. > Of course this is where the "explicitly installed" attribute is useful. > I assume glibc, grub, udev etc. are all explicitly installed by > anaconda. And why should one not be able to also look at "explicitly installed" stuff? Each Linux user goes through the "a distribution a week" phase, the next one is usually the "install everything" that makes for regular flamewars here, spiced up with "... what I can put my hands on"... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From jspaleta at gmail.com Mon Apr 24 14:01:31 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 10:01:31 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604230210.k3N2AhSo005660@quelen.inf.utfsm.cl> References: <1145714843.19696.80.camel@hammer> <200604230210.k3N2AhSo005660@quelen.inf.utfsm.cl> Message-ID: <604aa7910604240701u4a80816dse577abb0274afec8@mail.gmail.com> On 4/22/06, Horst von Brand wrote: > And why should one not be able to also look at "explicitly installed" > stuff? Each Linux user goes through the "a distribution a week" phase, the > next one is usually the "install everything" that makes for regular > flamewars here, spiced up with "... what I can put my hands on"... Write-up an outline of the stages of the linux user evolutionary process, and let's see if we can get it illustrated. -jef From nphilipp at redhat.com Mon Apr 24 14:23:11 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 24 Apr 2006 16:23:11 +0200 Subject: Fedora Bounties (seeking ideas) In-Reply-To: References: <200604160349.25854.nman64@n-man.com> <16de708d0604191546mac8cf28v7c7230addf7bbc5b@mail.gmail.com> <1145534949.18551.82.camel@sundaram.pnq.redhat.com> <16de708d0604200834p7a3ef000r772e8032e28dac77@mail.gmail.com> <2bb88f20604200841r56ad2ff9p1cee26aa61a793a4@mail.gmail.com> <1145606930.2945.15.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1145888592.2812.13.camel@gibraltar.stuttgart.redhat.com> Avi, On Mon, 2006-04-24 at 09:48 -0300, Avi Alkalay wrote: > You are welcome to propose another solution. you totally misinterpreted me. My sole intent was to not start that discussion again, I purposefully have left out whether I am pro or contra either GConf or Elektra. This is not fedora-advocacy-list. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From ph18 at cornell.edu Mon Apr 24 14:32:05 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 24 Apr 2006 10:32:05 -0400 Subject: FC5 rocks! In-Reply-To: <20060419162248.GB32734@devserv.devel.redhat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> Message-ID: <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> I've been quiet on this list lately but I thought I'd share my impressions of FC5. It's really great. It's clear that many of the concerns that people have had on this list have been listened to. There are a lot of details I could complaint about, but FC5 has raised the bar again for what people can expect from a desktop OS. I like the "Add/Remove Software" feature and pup... Both of these really work in FC5, and make managing software so easy, that it embarasses Windows XP and Mac OS X. I'm not sure where Core ends and Extras start, but there are some games that are actually fun under the "Games" menu now. (ex. Fish Fillets, Neverball) My one substantiative problem is the sorry state of SELinux documentation. There is a lot of stuff here: http://www.nsa.gov/selinux/info/docs.cfm but it's the kind of stuff you find in a conference proceedings, not the kind of stuff that you need to get work done. It's pretty clear to me that I need to understand SELinux to do my day-to-day sysadmin duties and even for some of my development, and it's not clear how to get that understanding. That said, I'm pretty excited about learning SELinux. I'm still having horrible trouble ripping CD's. I haven't had a single Linux 2.6 system that rips CDs reliably, so I end up ripping CDs on Windows and Mac. On my Athlon 64 machine at home with a Plextor drive, I find that the OS loses contact with the drive as soon as the first error happens... And errors happen all the time when I rip CD's. The only way I can get the drive back is to reboot. I'd think it was a fluke, but my IBM laptop has trouble ripping CD's (hacked system that I've compiled mainstream kernels for) and so does my indestructable P3 box that runs RHEL 4. From sundaram at fedoraproject.org Mon Apr 24 14:42:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Apr 2006 20:12:44 +0530 Subject: FC5 rocks! In-Reply-To: <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> Message-ID: <1145889764.3799.13.camel@sundaram.pnq.redhat.com> On Mon, 2006-04-24 at 10:32 -0400, Paul A Houle wrote: > I've been quiet on this list lately but I thought I'd share my impressions > of FC5. > > It's really great. It's clear that many of the concerns that people have > had on this list have been listened to. There are a lot of details I could > complaint about, but FC5 has raised the bar again for what people can > expect from a desktop OS. > > I like the "Add/Remove Software" feature and pup... Both of these really > work in FC5, and make managing software so easy, that it embarasses > Windows XP and Mac OS X. > > I'm not sure where Core ends and Extras start, but there are some games > that are actually fun under the "Games" menu now. (ex. Fish > Fillets, Neverball) > > My one substantiative problem is the sorry state of SELinux > documentation. There is a lot of stuff here: > > http://www.nsa.gov/selinux/info/docs.cfm > > but it's the kind of stuff you find in a conference proceedings, not the > kind of stuff that you need to get work done. Thats the wrong place to look > It's pretty clear to me that > I need to understand SELinux to do my day-to-day sysadmin duties and even > for some of my development, and it's not clear how to get that > understanding. That said, I'm pretty > excited about learning SELinux. Here: http://fedoraproject.org/wiki/SELinux. Tells us what sort of questions is unanswered and we will fix them. > > I'm still having horrible trouble ripping CD's. I haven't had a single > Linux 2.6 system that rips CDs reliably, so I end up ripping CDs on > Windows and Mac. On my Athlon 64 machine at home with a Plextor drive, I > find that the OS loses contact with the drive as soon as the first error > happens... And errors happen all the time when I rip CD's. The only way I > can get the drive back is to reboot. I'd think it was a fluke, but my IBM > laptop has trouble ripping CD's (hacked system that I've compiled > mainstream kernels for) and so does my indestructable P3 box that runs RHEL 4 Does it work better as root user? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179862 Rahul From pemboa at gmail.com Mon Apr 24 15:38:32 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 10:38:32 -0500 Subject: FC5 rocks! In-Reply-To: <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> Message-ID: <16de708d0604240838i69641a04vf369a8dcb28b0d15@mail.gmail.com> On 4/24/06, Paul A Houle wrote: > I've been quiet on this list lately but I thought I'd share my impressions > of FC5. > > It's really great. It's clear that many of the concerns that people have > had on this list have been listened to. There are a lot of details I could > complaint about, but FC5 has raised the bar again for what people can > expect from a desktop OS. > > I like the "Add/Remove Software" feature and pup... Both of these really > work in FC5, and make managing software so easy, that it embarasses > Windows XP and Mac OS X. > > I'm not sure where Core ends and Extras start, but there are some games > that are actually fun under the "Games" menu now. (ex. Fish > Fillets, Neverball) > > My one substantiative problem is the sorry state of SELinux > documentation. There is a lot of stuff here: > > http://www.nsa.gov/selinux/info/docs.cfm > This seems good: http://fedora.redhat.com/docs/selinux-faq/ -- As a boy I jumped through Windows, as a man I play with Penguins. From ajackson at redhat.com Mon Apr 24 14:39:40 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 24 Apr 2006 10:39:40 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <1145726122.22802.7.camel@localhost.localdomain> References: <444696F0.9080801@redhat.com> <4446CB80.6020309@mesias.co.uk> <1145493051.4749.1.camel@yoda.jdub.homelinux.org> <1145614991.2760.18.camel@xpc.home.erwinrol.com> <6280325c0604220035x4aef7f0em561d87e1cb7e7200@mail.gmail.com> <1145695979.2760.47.camel@xpc.home.erwinrol.com> <1145726122.22802.7.camel@localhost.localdomain> Message-ID: <444CE32C.7070202@redhat.com> Callum Lerwick wrote: > For a while now, in XFree86/Xorg, setting depth 24 refers to the actual > color depth, not padding. The driver is to set the actual framebuffer > depth to 24 or 32 bits as is appropriate for the hardware. AFAIK on most > hardware, padding 24bit out to 32 bit performs faster. Correct. And you mean all hardware, at least on PCI systems, since the bus is 32 bits wide and if you do 24bpp packed pixels then most of your pixel accesses will be unaligned and will need two bus cycles. Similar caveats apply to internal memory accesses triggered from the GPU to VRAM, the address calculation and pixel unpacking are significantly more expensive. We will occasionally prefer 24bpp packed pixels, but that's mostly just for vesa(4), which is unaccelerated anyway, and where the memory savings translates to possibly higher resolutions fitting in memory. For the cards that support 30 bit color you're typically still doing 32 bit words, with the extra two either unused or used for alpha. Most of the newer desktop-class cards support this in silicon, but X still has one or two issues that prevent us from supporting it (mostly just bugs as opposed to design flaws). > No idea how Xorg plans to handle this new fangled HDR thing... HDR typically refers to using floating point color buffers; X as currently written just doesn't support that at all. There are various GL extensions (in various states of patent coverage, rrgh) to enable floating point color buffers for either texturing, rendering output, or both. Which we don't support yet, of course. I'm of the opinion that requiring apps to use GL or some pleasant frontend to it in order to get HDR is perfectly okay. - ajax From wtogami at redhat.com Mon Apr 24 15:41:23 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 24 Apr 2006 11:41:23 -0400 Subject: FC5 rocks! In-Reply-To: <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> Message-ID: <444CF1A3.1080909@redhat.com> Paul A Houle wrote: > I've been quiet on this list lately but I thought I'd share my > impressions of FC5. > > It's really great. It's clear that many of the concerns that people > have had on this list have been listened to. There are a lot of details > I could complaint about, but FC5 has raised the bar again for what > people can expect from a desktop OS. > We are happy that you like FC5, but please remember that this is a development discussion list. User support questions like those contained in your post are off-topic here. We would really like to focus the discussion on development topics here in order to make this list more manageable to read for developers. Warren Togami wtogami at redhat.com From ajackson at redhat.com Mon Apr 24 14:44:18 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 24 Apr 2006 10:44:18 -0400 Subject: Xorg signal 11's spontaneously In-Reply-To: <444A18FB.7070107@conversis.de> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> Message-ID: <444CE442.60506@redhat.com> Dennis Jacobfeuerborn wrote: > Dennis Jacobfeuerborn wrote: >> In the last 10 days Xorg crashed three times with a signal 11 >> spontaneously. This is the backtrace I found in the logfile: >> >> Backtrace: >> 0: /usr/bin/Xorg(xf86SigHandler+0x87) [0x80b6d07] >> 1: [0x49a420] >> 2: /usr/lib/xorg/modules/libfb.so [0x134b81] >> 3: /usr/lib/xorg/modules/libfb.so [0x13c80c] >> 4: /usr/lib/xorg/modules/libfb.so(fbCompositeGeneral+0x855) [0x13a4e5] >> 5: /usr/lib/xorg/modules/libfb.so(fbComposite+0x1cd) [0x1433ad] >> 6: /usr/lib/xorg/modules/libxaa.so(XAAComposite+0x261) [0x81f001] >> 7: /usr/bin/Xorg [0x8156d06] >> 8: /usr/bin/Xorg [0x8153915] >> 9: /usr/bin/Xorg(CompositePicture+0x153) [0x8140a13] >> 10: /usr/bin/Xorg [0x814687c] >> 11: /usr/bin/Xorg [0x8143bd5] >> 12: /usr/bin/Xorg(Dispatch+0x19a) [0x80869ba] >> 13: /usr/bin/Xorg(main+0x485) [0x806e3e5] >> 14: /lib/libc.so.6(__libc_start_main+0xdc) [0x4cd7e4] >> 15: /usr/bin/Xorg(FontFileCompleteXLFD+0xbd) [0x806d721] >> >> Fatal server error: >> Caught signal 11. Server aborting >> >> All three crashes happened when I was loading a page in Firefox and >> after the nightly Firefox builds got switched to Cairo as their >> rendering backend so I wonder if Cairo could somehow trigger this. >> >> I'm running Fedora Core Rawhide with the following Xorg packages: >> xorg-x11-server-Xorg-1.0.99.901-5 >> xorg-x11-drv-nv-1.1.1-2 >> >> I'm using the open source nv driver with the AccelMethod set to EXA >> and the 'load "dri"' and 'load "glx"' lines commented out. Neither DRI nor EXA matter at all to the nv driver, which supports neither. > Just happened again and the backtrace looks similar to the one above. If > I can do something to provide better information to debug this please > tell me. Install the debuginfo packages, ssh in from another machine, su, attach gdb to X, 'handle SIGPIPE nostop', and 'cont'. When the server segfaults, 'bt f' should now give you useful backtrace info. May also be related to a crasher recently fixed for x4a4 glyphs; I'll backpatch that into rawhide and stable shortly. - ajax From jfrieben at freesurf.fr Mon Apr 24 15:56:26 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Mon, 24 Apr 2006 17:56:26 +0200 (CEST) Subject: Mozilla in FC6 In-Reply-To: <444CBCFF.3060006@math.unl.edu> References: <444CBCFF.3060006@math.unl.edu> Message-ID: <58545.89.50.33.12.1145894186.squirrel@jose.freesurf.fr> Maybe, however, "rpm -q --requires epiphany" yields quite a couple of dependencies, including: "mozilla = 37:1.7.12". This is intelligible as (current FC5) "epiphany" e.g. requires "libxpcom.so" which is provided by two packages, "firefox-1.5.0.2-1.2.fc5" and "mozilla-1.7.12-5", but which seems to have nothing to do with the "nspr" package mentioned by you. This confirms, that the dependency on "mozilla" might be replaced by that on "firefox". > > FC already uses the browser-independant (ie, not mozilla-specific) nspr > and nss packages. > > -- Rex > From dimi at lattica.com Mon Apr 24 16:04:43 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 24 Apr 2006 12:04:43 -0400 (EDT) Subject: FC5 rocks! In-Reply-To: <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> Message-ID: <33625.207.35.222.39.1145894683.squirrel@lattica.com> On Mon, April 24, 2006 10:32 am, Paul A Houle said: > It's really great. It's clear that many of the concerns that people have > had on this list have been listened to. There are a lot of details I > could > complaint about, but FC5 has raised the bar again for what people can > expect from a desktop OS. While FC5 did add a number of nice touches, I am personally not as impressed. I ended up having more problems with it than with FC4: -- Firefox crashes regurarly, or uses 50% CPU and has 2-3sec latency Yeah, Firefox also has some nice touches, but honestly, browsing experience is sub-par. This is _the_ most important thing people do on their desktops nowadays. -- my Canon SD400 stopped working due to SELinux Now, I lover SELinux, and I have largely ignored calls for its removal, but this is getting to be too much. Working with media on a desktop is right under browsing in importance. Read very. Problem is that the bug has been filled, but is still not fixed on my FC5 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187712) Daniel claims the bug has been fixed, has it been pushed to updates? This is very, very frustrating, as you have no fscking clue why things stopped working magically. I also think that having this sort of functionallity tested before release is an absolute minimum. -- Evolution doesn't print emails This is basic, fundamental functionality! The bug has been present in FC4 too, but it doesn't seem to register of people's radar. I receive invoices, etc that I need to print, and I can't. It is absolutely ridiculous. Not to mention a number of very annoying and branidamaged GNOME fsckups. Of course, I know, "upstream". But whenever I try to report it upstream, I'm told that they don't design for the minority, things are perfect and need no change. And then they complain that the GNOME comunity has lost its spirit! Folks, this is not sustainable. Red Hat has long pushed hard for things like GNOME, Evolution, etc, and for good reason. I am fully behind they decision, I think it was the right one. But they need to stand behind their choices, Fedora or not. They _are_ the 800lbs gorrilla or the Linux world, and their voice matters. A lot. It needs to be a lot more proactive relaying the impressions of their customers to the upstream projects, and to impose some order and direction to this nonsense. Just telling folks like me to shutup and report upstream will do no-one any good. Vast majority of folks will simply give up (and thus we lose a lot of valuable feedback), and you will simply get a lot of disgruntled users. We can complain upstream, but we need to feel that Red Hat is behind us. Otherwise, we all know that its just a big waste of time. Especially when we're talking about GNOME. Nothing changed in their elitiste attitude. It is one of the most frustrating experiences, why would you subject your customers to it? -- Dimi Paun Lattica, Inc. From jspaleta at gmail.com Mon Apr 24 16:10:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 12:10:53 -0400 Subject: FC5 rocks! In-Reply-To: <33625.207.35.222.39.1145894683.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> Message-ID: <604aa7910604240910p1caaa3c8m4e5bec0285d44818@mail.gmail.com> On 4/24/06, Dimi Paun wrote: > > Especially when we're talking about GNOME. Nothing changed in their elitiste > attitude. You might want to report that problem to upstream. -jef"look at me...i shaking my fist violently in your direction...better look at me or I'm going to shake it faster and more forcibly. Why won't you look at me? My arm is getting tired from all this violent fist shaking."spaleta From dimi at lattica.com Mon Apr 24 16:14:11 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 24 Apr 2006 12:14:11 -0400 (EDT) Subject: FC5 rocks! In-Reply-To: <604aa7910604240910p1caaa3c8m4e5bec0285d44818@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com><6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu><33625.207.35.222.39.1145894683.squirrel@lattica.com> <604aa7910604240910p1caaa3c8m4e5bec0285d44818@mail.gmail.com> Message-ID: <56557.207.35.222.39.1145895251.squirrel@lattica.com> On Mon, April 24, 2006 12:10 pm, Jeff Spaleta said: >> Especially when we're talking about GNOME. Nothing changed in their >> elitiste attitude. > > You might want to report that problem to upstream. No need, I'm certain they are very much aware and proud of it. -- Dimi Paun Lattica, Inc. From rdieter at math.unl.edu Mon Apr 24 16:17:55 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Apr 2006 11:17:55 -0500 Subject: Mozilla in FC6 In-Reply-To: <58545.89.50.33.12.1145894186.squirrel@jose.freesurf.fr> References: <444CBCFF.3060006@math.unl.edu> <58545.89.50.33.12.1145894186.squirrel@jose.freesurf.fr> Message-ID: <444CFA33.9030901@math.unl.edu> Joachim Frieben wrote: > Maybe, however, > > "rpm -q --requires epiphany" yields quite a couple of dependencies, > including: > "mozilla = 37:1.7.12". > > This is intelligible as (current FC5) "epiphany" e.g. requires "libxpcom.so" > which is provided by two packages, "firefox-1.5.0.2-1.2.fc5" and > "mozilla-1.7.12-5", but which seems to have nothing to do with the "nspr" > package mentioned by you. This confirms, that the dependency on "mozilla" > might be replaced by that on "firefox". OK, this is yet another dependancy, provided by a theoretical xulrunner package. -- Rex >>FC already uses the browser-independant (ie, not mozilla-specific) nspr >> and nss packages. >> >>-- Rex From sundaram at fedoraproject.org Mon Apr 24 16:18:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 24 Apr 2006 21:48:04 +0530 Subject: FC5 rocks! In-Reply-To: <33625.207.35.222.39.1145894683.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> Message-ID: <1145895484.3799.26.camel@sundaram.pnq.redhat.com> On Mon, 2006-04-24 at 12:04 -0400, Dimi Paun wrote: > On Mon, April 24, 2006 10:32 am, Paul A Houle said: > > It's really great. It's clear that many of the concerns that people have > > had on this list have been listened to. There are a lot of details I > > could > > complaint about, but FC5 has raised the bar again for what people can > > expect from a desktop OS. > > While FC5 did add a number of nice touches, I am personally not as > impressed. I ended up having more problems with it than with FC4: > -- Firefox crashes regurarly, or uses 50% CPU and has 2-3sec latency > Yeah, Firefox also has some nice touches, but honestly, browsing > experience is sub-par. This is _the_ most important thing people > do on their desktops nowadays. Do you have a bug report on this? > -- my Canon SD400 stopped working due to SELinux > Now, I lover SELinux, and I have largely ignored calls for its > removal, but this is getting to be too much. Working with media > on a desktop is right under browsing in importance. Read very. > Problem is that the bug has been filled, but is still not fixed > on my FC5 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187712) > Daniel claims the bug has been fixed, has it been pushed to updates? > This is very, very frustrating, as you have no fscking clue why > things stopped working magically. I also think that having this > sort of functionallity tested before release is an absolute minimum. You would be better off providing that feedback within the bug report itself. AVC denied messages after updating the policy package will help. > -- Evolution doesn't print emails > This is basic, fundamental functionality! The bug has been present > in FC4 too, but it doesn't seem to register of people's radar. > I receive invoices, etc that I need to print, and I can't. It is > absolutely ridiculous. Bug report? > > > Not to mention a number of very annoying and branidamaged GNOME > fsckups. Rants are usually non specific. Not very useful for a development list. Rahul From andy at warmcat.com Mon Apr 24 16:27:09 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 24 Apr 2006 17:27:09 +0100 Subject: FC5 rocks! In-Reply-To: <33625.207.35.222.39.1145894683.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> Message-ID: <444CFC5D.1070800@warmcat.com> Dimi Paun wrote: > Just telling folks like me to shutup and report upstream will do no-one > any good. Vast majority of folks will simply give up (and thus we lose > a lot of valuable feedback), and you will simply get a lot of disgruntled > users. I wrote some similar complaints a year or two ago, there was some discussion about it being nice if Bugzillas talked to each other or some other kind of meta bug reporting. Maybe there is a way to bring in external upstream people on to the RHAT Bugzilla and sort of outsource the bugs for the upstream project while it remains hosted at RHAT's central Bugzilla since it was reported on a Fedora ticket. > We can complain upstream, but we need to feel that Red Hat is behind us. > Otherwise, we all know that its just a big waste of time. Especially when > we're talking about GNOME. Nothing changed in their elitiste attitude. > It is one of the most frustrating experiences, why would you subject your > customers to it? I also felt at that time that RHAT should bang the drum upstream for the bugs that annoyed me. Where it would do some good is where the RHAT folks are already inside the upstream and understood there as contributors, eg, the kernel and xorg where the relationship is bidirectional and quite strong. But for a lot of packages that's not so much the case, a Redhat guy turning up on the upstream mailing list as the representative for grumpy users would require a lot of time and tact and be a pretty thankless task. Evolution seems to be a case in point, if the upstream project has gone all floppy then unless RHAT are going to airlift para-developers into it, someone from Redhat representing myriad problems might not pay off. I can see why it makes people say "go there yourself and champion your bug" because really RHAT doesn't owe us the work. Maybe all one can hope for is that the Fedora packager, since he would be relatively familiar with at the least the structure of the project, might want to spend some time managing RHAT bugzilla complaints with the upstream for those projects, and that the upstream is ready for that. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From dimi at lattica.com Mon Apr 24 17:23:59 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 24 Apr 2006 13:23:59 -0400 (EDT) Subject: FC5 rocks! In-Reply-To: <444CFC5D.1070800@warmcat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu><33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> Message-ID: <46642.207.35.222.39.1145899439.squirrel@lattica.com> On Mon, April 24, 2006 12:27 pm, Andy Green said: > Dimi Paun wrote: > I can see why it makes people say "go there yourself and champion > your bug" because really RHAT doesn't owe us the work. Absolutely. I would never expect RHAT to relay my problems from one mailing list to another. That would be stupid and counter productive. But this is not at all what I'm asking for. Truth is that by the nature of the people Red Hat hired, they have quite a number of folks involved in highly visible projects. The oppinions of these guys matter in those projects. I would like RHAT to listen to their customers (like any decent company), and push for changes that they consider worthwhile where they can. And this can be done in a lot of places, especially in difficult to talk to projects like GNOME. This _is_ a development related issue, and I think it is very much on topic for this list. We were told Fedora is essential part of RHAT model, which was pretty clear from the beginning. That's fine. I have used RHAT since 4.0, and I'm glad to see RHAT acknowladge this fact. However, this comes with some responsabilities, and one of it is listening to customer feedback (within limits, of course). Is RHAT willing to do that? -- Dimi Paun Lattica, Inc. From smooge at gmail.com Mon Apr 24 17:31:57 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 24 Apr 2006 11:31:57 -0600 Subject: FC5 rocks! In-Reply-To: <46642.207.35.222.39.1145899439.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> Message-ID: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> On 4/24/06, Dimi Paun wrote: > > On Mon, April 24, 2006 12:27 pm, Andy Green said: > > Dimi Paun wrote: > > I can see why it makes people say "go there yourself and champion > > your bug" because really RHAT doesn't owe us the work. > > Absolutely. I would never expect RHAT to relay my problems from > one mailing list to another. That would be stupid and counter > productive. > > But this is not at all what I'm asking for. Truth is that by the > nature of the people Red Hat hired, they have quite a number of > folks involved in highly visible projects. The oppinions of these > guys matter in those projects. I would like RHAT to listen to their > customers (like any decent company), and push for changes that they > consider worthwhile where they can. And this can be done in a lot > of places, especially in difficult to talk to projects like GNOME. > > This _is_ a development related issue, and I think it is very much > on topic for this list. We were told Fedora is essential part of RHAT > model, which was pretty clear from the beginning. That's fine. I have > used RHAT since 4.0, and I'm glad to see RHAT acknowladge this fact. > However, this comes with some responsabilities, and one of it is listening > to customer feedback (within limits, of course). Is RHAT willing to > do that? > Do you have ideas on how this can be done cleanly? There are tons of issues and they need to be evaluated in the order of getting them fixed/changed. I mean I would love spatial sent back to the Windows95 heck it belongs in... but that doesnt mean everyone else does. Gathering the information, prioritizing it, and then championing it. -- Stephen J Smoogen. CSIRT/Linux System Administrator From jspaleta at gmail.com Mon Apr 24 17:42:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 13:42:08 -0400 Subject: FC5 rocks! In-Reply-To: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> Message-ID: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> On 4/24/06, Stephen John Smoogen wrote: > I mean I would love spatial sent back to the Windows95 > heck it belongs in... but that doesnt mean everyone else does. I love spatial.. lets fight about it. The winner will be decided based on the haiku supporting our positions which uses the most words from the 2004 SAT-prep vocabulary list published by ETS. This will be a 3 round contest. Use of non-clinical terms for body parts, or use of baby-language will count as a disqualification -jef"spatial is for me you sir are a poopyhead middle-click works well"spaleta From andy at warmcat.com Mon Apr 24 17:46:41 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 24 Apr 2006 18:46:41 +0100 Subject: FC5 rocks! In-Reply-To: <46642.207.35.222.39.1145899439.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu><33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> Message-ID: <444D0F01.6050907@warmcat.com> Dimi Paun wrote: > folks involved in highly visible projects. The oppinions of these > guys matter in those projects. I would like RHAT to listen to their > customers (like any decent company), and push for changes that they > consider worthwhile where they can. And this can be done in a lot > of places, especially in difficult to talk to projects like GNOME. > > This _is_ a development related issue, and I think it is very much > on topic for this list. We were told Fedora is essential part of RHAT > model, which was pretty clear from the beginning. That's fine. I have Well one doesn't have to go there, since many packages in Fedora are in RHEL and Desktop, so Redhat are already 'on the side of the user' in the sense of being commercially motivated to get those shared packages in a great state. For the evolution case or whatever it doesn't even need mentioning if it must be renovated for Fedora or for RHEL, we can see RHAT's will to do something in a good direction on it and that will be there for us in both cases. But it's true for most specific bugs that it's the user who is suffering it on his machine that is the #1 motivated person in the whole scheme of things to see that particular bug fixed. > used RHAT since 4.0, and I'm glad to see RHAT acknowladge this fact. > However, this comes with some responsabilities, and one of it is listening > to customer feedback (within limits, of course). Is RHAT willing to > do that? Over on fedora-list there have been many many claims on RHAT to listen to customers/feedback/demands/complaints and so on, some of them pretty unfair and senseless, and I have come to shrink away from doing it myself and instead appreciate what they actually do for us. RHAT don't really have responsibilities to us as users at all since they give us all this work without strings except the mostly inherited licensing. To some extent this assumption that they must listen to their 'customers' (at least, the ones who pay them no money) is another thoughtpattern like 'marketing' that comes over from the commercial software world and is a poor fit for Free software. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From smooge at gmail.com Mon Apr 24 17:49:13 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 24 Apr 2006 11:49:13 -0600 Subject: FC5 rocks! In-Reply-To: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> Message-ID: <80d7e4090604241049s4b0a84cj7855e0ab7b4e5ce4@mail.gmail.com> On 4/24/06, Stephen John Smoogen wrote: > On 4/24/06, Dimi Paun wrote: > > > > Do you have ideas on how this can be done cleanly? There are tons of > issues and they need to be evaluated in the order of getting them > fixed/changed. I mean I would love spatial sent back to the Windows95 > heck it belongs in... but that doesnt mean everyone else does. > Gathering the information, prioritizing it, and then championing it. > > That came across more negatively than I meant. I am looking for ideas on how it can be sanely done per release.. say each release 5 things get focused on (doing more than 5 in a 6 month period would be hard in my opinion) What are they? Who decides and when? Who champions them ? > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > -- Stephen J Smoogen. CSIRT/Linux System Administrator From dimi at lattica.com Mon Apr 24 18:05:45 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 24 Apr 2006 14:05:45 -0400 (EDT) Subject: FC5 rocks! In-Reply-To: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><20060418035409.GP16508@redhat.com><20060419145947.GA21899@wolff.to><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com><6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu><33625.207.35.222.39.1145894683.squirrel@lattica.com><444CFC5D.1070800@warmcat.com><46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> Message-ID: <58019.207.35.222.39.1145901945.squirrel@lattica.com> On Mon, April 24, 2006 1:31 pm, Stephen John Smoogen said: > Do you have ideas on how this can be done cleanly? There are tons of > issues and they need to be evaluated in the order of getting them > fixed/changed. I mean I would love spatial sent back to the Windows95 > heck it belongs in... but that doesnt mean everyone else does. > Gathering the information, prioritizing it, and then championing it. As a matter of fact I do. First and foremost RHAT has to take a more proactive role leading the Linux desktop effort. It can not take the responisbility of pushing for every change to every upstream project, and it doesn't need to. However, there are a number of fundamental aspects of the desktop experience that users identify with the "distributions". These are things like: interactivity feel, spatial Nautilus, open window in backgroud, etc. Telling someone to go complain upstream about these is as if they were told to shut the fsck up. Correctly or not, these are the type of things people perceive as a distribution aspect, and the vendor needs to act on such feedback. Second, RHAT employs guys that are maintainers or at the very least have a very high status in almost all important desktop-related projects: kernel, dbus, hal, cairo, pango, gtk+, gnome, metacity, firefox, etc. For all important/highly debated issues, we need to hear RHAT's possition on the issue, so that we know what RHAT will push for. For example, if I hear that RHAT will push for changing the spatial experim^H^H^H^H^H^H^H feature to a more reasonable default, I would feel a lot happier. It will save a lot of useless flamewars in a number of lists, and I think it will really help everybody. Third, RHAT needs to listen and relay the opinion of people that use this stuff in production. It is a fundamentally different position. OSS develpers do stuff for fun, and a lot of them do it for the joy of playing with technology. They like to experiment, they like to play with stuff. See spatial, window-in-background, etc. That's fine, but a real production user is _conservative_. A lot of this changes are really trivial (they improve nothing really), but annoy the hell out of people that are just trying to get a job done. OSS developers don't work for these people, RHAT does. It needs to represent these concerns to the upstream. For example, in terms of UI, we have a model that is well known and works well: Windows. Don't deviate from the norm, unless you have _very_ good reason to do so. If you do, offer it as an option. If you think you can change the default, offer a simple way to revert the behaviour. Boring, I know, but effective. OSS developers don't like boring, this is why RHAT is making the big bucks. RHAT developers need to listen to fedora-devel. Like it or not, this is a forum for the future of fedora. Aggregate the input, and let us know where you stand. Tell us where you can push upstream, and where you can't. Don't just mindlessly send us on wild goosechases upstream. -- Dimi Paun Lattica, Inc. From smooge at gmail.com Mon Apr 24 18:12:54 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 24 Apr 2006 12:12:54 -0600 Subject: FC5 rocks! In-Reply-To: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> Message-ID: <80d7e4090604241112n1566f8b3i3a655030a55116bd@mail.gmail.com> On 4/24/06, Jeff Spaleta wrote: > On 4/24/06, Stephen John Smoogen wrote: > > I mean I would love spatial sent back to the Windows95 > > heck it belongs in... but that doesnt mean everyone else does. > > I love spatial.. lets fight about it. The winner will be decided based > on the haiku supporting our positions which uses the most words from > the 2004 SAT-prep vocabulary list published by ETS. This will be a 3 > round contest. Use of non-clinical terms for body parts, or use of > baby-language will count as a disqualification > > -jef"spatial is for me > you sir are a poopyhead > middle-click works well"spaleta > spring artic days may freeze; you find yourself trying to haiku a zen breeze. middle-click hides much but later all is windows unless you beagle -- Stephen J Smoogen. CSIRT/Linux System Administrator From lists at arctur.us Mon Apr 24 18:20:09 2006 From: lists at arctur.us (Mitch Skinner) Date: Mon, 24 Apr 2006 11:20:09 -0700 Subject: FC5 rocks! In-Reply-To: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> Message-ID: <1145902809.11663.60.camel@firebolt> On Mon, 2006-04-24 at 13:42 -0400, Jeff Spaleta wrote: > -jef"spatial is for me > you sir are a poopyhead > middle-click works well"spaleta Screw mailing list rants, we need some user testing. Sorry to pile on. From tibbs at math.uh.edu Mon Apr 24 18:24:29 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 24 Apr 2006 13:24:29 -0500 Subject: FC5 rocks! In-Reply-To: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> (Jeff Spaleta's message of "Mon, 24 Apr 2006 13:42:08 -0400") References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> Message-ID: >>>>> "JS" == Jeff Spaleta writes: JS> spatial is for me JS> you sir are a poopyhead JS> middle-click works well mean coders remove configurability switch to KDE - J< From denis at poolshark.org Mon Apr 24 19:13:40 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 24 Apr 2006 12:13:40 -0700 Subject: FC5 rocks! In-Reply-To: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> Message-ID: <444D2364.20107@poolshark.org> Jeff Spaleta wrote: > middle-click works well"spaleta While we're on the subject, somebody at Gnome is in love with the middle button, since it seems more and more important features are moved to it. Do you know how hard it is to click the middle button on a mouse when that middle button is actually the mouse wheel (i.e. 90% of them) ? Grrrr. I'm out! -denis From jspaleta at gmail.com Mon Apr 24 19:24:22 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 15:24:22 -0400 Subject: FC5 rocks! In-Reply-To: <444D2364.20107@poolshark.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> Message-ID: <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> On 4/24/06, Denis Leroy wrote: > While we're on the subject, somebody at Gnome is in love with the middle > button, since it seems more and more important features are moved to it. > Do you know how hard it is to click the middle button on a mouse when > that middle button is actually the mouse wheel (i.e. 90% of them) ? > Grrrr. I'm out! Hey I have an idea... lets build an input device which includes a button that depresses AND scrolls... and do so in a way that makes it difficult for users to use the button press functionality.. so they then complain when software developers attempt to utilize that action in a useful way. If i was a conspiracy theorist I'd claim your hardware manufacturer was deliberately trying to cripple the functionality of the middle-click button. Oh wait I am a conspiracy theorist and they are deliberately trying to cripple the functionality of the middle-click button. Explain the me the point of including the middle-click functionality in an input device and making it delibrately difficult to use. Sounds like pathetically poor hardware design to me. -jef"I have no problem with my clickable scroll-wheel mouse. Then again i spend a lot of time flipping people the bird so my middle finger may be super-humanly dexterous from all the exercise"spaleta From denis at poolshark.org Mon Apr 24 19:50:59 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 24 Apr 2006 12:50:59 -0700 Subject: FC5 rocks! In-Reply-To: <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> Message-ID: <444D2C23.1020902@poolshark.org> Jeff Spaleta wrote: > Hey I have an idea... lets build an input device which includes a > button that depresses AND scrolls... and do so in a way that makes it > difficult for users to use the button press functionality.. so they > then complain when software developers attempt to utilize that action > in a useful way. If i was a conspiracy theorist I'd claim your > hardware manufacturer was deliberately trying to cripple the > functionality of the middle-click button. Oh wait I am a conspiracy > theorist and they are deliberately trying to cripple the functionality > of the middle-click button. Explain the me the point of including the > middle-click functionality in an input device and making it > delibrately difficult to use. Sounds like pathetically poor hardware > design to me. Ouch!! I must have forgotten a smilie somewhere. Well it's a Logitech, like most mouse these days. I swear it's tough to bring up a popup menu with the pressable mouse-wheel, you always end up scrolling things by accident. But the most difficult is the dynamic window resize (Alt + middle-button), a key feature for me. Doing this with the mouse-wheel is particularly akward. I just which i could change this with gconf, but i can't. I used to maintain a metacity patch, but you eventually tire of this. -denis From kevin.kofler at chello.at Mon Apr 24 19:52:23 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Apr 2006 19:52:23 +0000 (UTC) Subject: Fedora core suggestions References: Message-ID: Alo Tsum gmail.com> writes: > First > suggestions has to do with the software side of things. We users need > a competent software installer which is graphical based. Pirut is just that, as are the alternatives available from Extras (Yumex, KYum, Smart, and probably soon Synaptic with the new apt with repomd and multilib support). > One that > functions much the same way that the windows installer works. I think the previous posters have explained pretty well why that's not a good idea. > This > installer should track dependencies naturally Pirut does that. > and place icons on the > desktop or give the option to have icons for the software just > installed to be placed on the desktop of the user as well as in the > applications menu. Pirut doesn't do that, but due to how RPMs and .desktop files are packaged, this would probably be best implemented within menu editors such as Alacarte (so you would select menu entry, pick "Copy to desktop", and it would be copied there) or within the menu itself (as already implemented in KDE, you can right-click on any menu entry in KDE's Kicker and copy it to the KDE desktop from the context menu!). > Also when watching the Boston Linux conference the > suggestion was made to offer a hard disc manager much like windows > offers for formating and receiving hard drivers etc after > installation. Well, depending on what you're trying to do, either QtParted/GParted (both available in Extras) or system-config-lvm may do the job. What seems to be missing though is an easy way to add partitions to the fstab. (This has been brought up recently, and indeed there doesn't seem to be one. And no, I'm not talking about automounting removable drives, but mounting fixed drives to a fixed place in the file system, which can be at any point in the FHS, not just under /media, so editing /etc/fstab really is needed for that use case.) Kevin Kofler From esr at thyrsus.com Mon Apr 24 19:09:07 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 24 Apr 2006 15:09:07 -0400 Subject: X problem - no display with latest update In-Reply-To: <20060423215612.92401.qmail@web35310.mail.mud.yahoo.com> References: <20060423215612.92401.qmail@web35310.mail.mud.yahoo.com> Message-ID: <20060424190907.GA5543@thyrsus.com> Steven I Usdansky : > Averatec 3200-series laptop using the vesa driver. X apparently starts, > but the display remains blank. Reinstalling xorg-x11-server-Xorg, > xorg-x11-server-utils, all of the various xorg-x11-drv rpms, and the > synaptics rpm from FC5 brings back my display. > > /var/log/Xorg.0.log for the blank display: > http://soleil.nfldinet.com/~rockdoctor/Xorg.0.log > > /etc/X11/xorg.conf: http://soleil.nfldinet.com/~rockdoctor/xorg.conf I've observed the same problem on a Thinkpad X40 using i810 graphics. -- Eric S. Raymond From tromey at redhat.com Mon Apr 24 19:55:11 2006 From: tromey at redhat.com (Tom Tromey) Date: 24 Apr 2006 13:55:11 -0600 Subject: FC5 rocks! In-Reply-To: <444CFC5D.1070800@warmcat.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> Message-ID: >>>>> "Andy" == Andy Green writes: Andy> I wrote some similar complaints a year or two ago, there was some Andy> discussion about it being nice if Bugzillas talked to each other or Andy> some other kind of meta bug reporting. Maybe there is a way to bring Andy> in external upstream people on to the RHAT Bugzilla and sort of Andy> outsource the bugs for the upstream project while it remains hosted at Andy> RHAT's central Bugzilla since it was reported on a Fedora ticket. Yeah, this would be convenient in a number of situations. Maybe file it in bugzilla? :-) (If you do please tell me the bug number.) Tom From Lam at Lam.pl Mon Apr 24 20:35:48 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 24 Apr 2006 22:35:48 +0200 Subject: FC5 rocks! In-Reply-To: <444D2C23.1020902@poolshark.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D2C23.1020902@poolshark.org> Message-ID: <1145910948.15927.21.camel@pensja.lam.pl> Dnia 24-04-2006, pon o godzinie 12:50 -0700, Denis Leroy napisa?(a): > Well it's a Logitech, With my Logitech (M-SBF69) it's impossible to accidentaly turn the wheel when trying to press the middle button and vice versa. I suggest to buy a new mouse every time your current one starts to be over-sensitive :) In general, software is not always the best way and in many cases not even an option to minimize the impact of broken hardware. What's next? People patching GIMP to print the picture after every change because the monitor doesn't display green? In past I've seen patches to Linux kernel which made the memory subsystem omit broken pages detected my memtest86. I don't know a person using those, I wonder why? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From andy at warmcat.com Mon Apr 24 20:39:49 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 24 Apr 2006 21:39:49 +0100 Subject: FC5 rocks! In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> Message-ID: <444D3795.3040305@warmcat.com> Tom Tromey wrote: >>>>>> "Andy" == Andy Green writes: > > Andy> I wrote some similar complaints a year or two ago, there was some > Andy> discussion about it being nice if Bugzillas talked to each other or > Andy> some other kind of meta bug reporting. Maybe there is a way to bring > Andy> in external upstream people on to the RHAT Bugzilla and sort of > Andy> outsource the bugs for the upstream project while it remains hosted at > Andy> RHAT's central Bugzilla since it was reported on a Fedora ticket. > > Yeah, this would be convenient in a number of situations. > > Maybe file it in bugzilla? :-) > (If you do please tell me the bug number.) Hi Tom - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189813 I have a presentiment I will be told to file it upstream :-) -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From lists at arctur.us Mon Apr 24 20:43:48 2006 From: lists at arctur.us (Mitch Skinner) Date: Mon, 24 Apr 2006 13:43:48 -0700 Subject: FC5 rocks! In-Reply-To: <444D2C23.1020902@poolshark.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D2C23.1020902@poolshark.org> Message-ID: <1145911428.11663.64.camel@firebolt> On Mon, 2006-04-24 at 12:50 -0700, Denis Leroy wrote: > I swear it's tough to bring up a popup menu > with the pressable mouse-wheel, you always end up scrolling things by > accident. Is there a software solution to this? Say, ignoring scroll events that come within x milliseconds of a middle button press. Mitch From seg at haxxed.com Mon Apr 24 20:53:25 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 24 Apr 2006 15:53:25 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604230210.k3N2AhSo005660@quelen.inf.utfsm.cl> References: <200604230210.k3N2AhSo005660@quelen.inf.utfsm.cl> Message-ID: <1145912006.22802.76.camel@localhost.localdomain> On Sat, 2006-04-22 at 22:10 -0400, Horst von Brand wrote: > Mark Rosenstand wrote: > > The Debian tool assumes that its users are capable of brain activity. > > Riiight... Well actually Debian packages have the ability to flag themselves as essential, thus preventing their removal without dire warnings of doom and gloom. i --\ bash 3.1-2 Description: The GNU Bourne Again SHell Essential: yes Priority: required On the other hand: i --\ grub 0.95+cvs20 Description: GRand Unified Bootloader Priority: optional -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From camilo at mesias.co.uk Mon Apr 24 21:01:15 2006 From: camilo at mesias.co.uk (Cam) Date: Mon, 24 Apr 2006 22:01:15 +0100 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> Message-ID: <444D3C9B.8080106@mesias.co.uk> Jeff while you're considering conspiracies, what about the legion of notebooks that lack a middle button? I have such a machine. Yes it's my fault for buying it, but sometimes it's hard to turn down an otherwise perfect machine at a good price. Plus, I assumed that the touchpad would detect multi finger taps - it doesn't :( -Cam -- <-- camilo at mesias.co.uk From Lam at Lam.pl Mon Apr 24 21:07:19 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 24 Apr 2006 23:07:19 +0200 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <444D3C9B.8080106@mesias.co.uk> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> Message-ID: <1145912839.15927.24.camel@pensja.lam.pl> Dnia 24-04-2006, pon o godzinie 22:01 +0100, Cam napisa?(a): > what about the legion of > notebooks that lack a middle button? FC5 has middle button emulation enabled by default. Personally I hate it, but it works - press left and right button at the same time - that's it! Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From gemi at bluewin.ch Mon Apr 24 21:10:18 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 24 Apr 2006 23:10:18 +0200 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <444D3C9B.8080106@mesias.co.uk> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> Message-ID: <1145913018.7870.2.camel@scriabin.tannenrauch.ch> On Mon, 2006-04-24 at 22:01 +0100, Cam wrote: > Jeff > > while you're considering conspiracies, what about the legion of > notebooks that lack a middle button? I have such a machine. Yes it's my > fault for buying it, but sometimes it's hard to turn down an otherwise > perfect machine at a good price. Plus, I assumed that the touchpad would > detect multi finger taps - it doesn't :( If I remember correctly, in 1993, the time I first used Linux, many X apps made use of the middle mouse button (this is valid of course for other UNIX systems with X11). So, the middle mouse button has some tradition in the Linux world. I would say that combining the middle mouse button with the wheel is a design error. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From pemboa at gmail.com Mon Apr 24 21:16:10 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 16:16:10 -0500 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> [ snip ] > Well, depending on what you're trying to do, either QtParted/GParted (both > available in Extras) or system-config-lvm may do the job. What seems to be > missing though is an easy way to add partitions to the fstab. (This has been > brought up recently, and indeed there doesn't seem to be one. And no, I'm not > talking about automounting removable drives, but mounting fixed drives to a > fixed place in the file system, which can be at any point in the FHS, not just > under /media, so editing /etc/fstab really is needed for that use case.) > > Kevin Kofler > Yes, in all fairness, FC should at least auto dete and mount vfat partions, for that matter, it should offer to mount any fixed partion whose FS it can detect. And with no offense to the creater of Pirut, I find console+yum several times easier to use than Pirut - interface wise. Arthur -- As a boy I jumped through Windows, as a man I play with Penguins. From camilo at mesias.co.uk Mon Apr 24 21:20:09 2006 From: camilo at mesias.co.uk (Cam) Date: Mon, 24 Apr 2006 22:20:09 +0100 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <1145912839.15927.24.camel@pensja.lam.pl> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> <1145912839.15927.24.camel@pensja.lam.pl> Message-ID: <444D4109.8010007@mesias.co.uk> Leszek >> what about the legion of >> notebooks that lack a middle button? > FC5 has middle button emulation enabled by default. Personally I hate > it, but it works - press left and right button at the same time - that's > it! I do that for pasting - but it's incredibly fiddly if you want to hit two real buttons and drag at the same time. Another workaround is that I've set the trackpad to detect corner taps as a button-2 click. Again this is OK for pasting but an ergonomic disaster for dragging :( Strangely I've got a separate mouse, and I find the overloaded click and scroll doesn't cause me problems. -Cam -- <-- camilo at mesias.co.uk From pemboa at gmail.com Mon Apr 24 21:20:55 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 16:20:55 -0500 Subject: FC5 rocks! In-Reply-To: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> Message-ID: <16de708d0604241420l78d2ce6er414589e9d8629b08@mail.gmail.com> [ snip ] > > Do you have ideas on how this can be done cleanly? There are tons of > issues and they need to be evaluated in the order of getting them > fixed/changed. I mean I would love spatial sent back to the Windows95 > heck it belongs in... but that doesnt mean everyone else does. > Gathering the information, prioritizing it, and then championing it. > A reliable , transperent voting system would be nice - however I do understand that the nature of OSS development doesn't lend itself very well to such a model. -- As a boy I jumped through Windows, as a man I play with Penguins. From denis at poolshark.org Mon Apr 24 21:24:04 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 24 Apr 2006 14:24:04 -0700 Subject: FC5 rocks! In-Reply-To: <1145910948.15927.21.camel@pensja.lam.pl> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D2C23.1020902@poolshark.org> <1145910948.15927.21.camel@pensja.lam.pl> Message-ID: <444D41F4.9040004@poolshark.org> Leszek Matok wrote: > In general, software is not always the best way and in many cases not > even an option to minimize the impact of broken hardware. What's next? > People patching GIMP to print the picture after every change because the > monitor doesn't display green? No this is not broken hardware. I don't know how many Logitech mice i've owned, but it's many, even including prototypes i got from a friend at Logitech. It's simply difficult, or rather, akward to perform a drag movement when you have to sustain a higher-than-normal pressure on the button, which is typically what you have to do when pressing the mousewheel. I'll try to look up your model if i have a chance. -denis From dimi at lattica.com Mon Apr 24 21:26:02 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 24 Apr 2006 17:26:02 -0400 (EDT) Subject: FC5 rocks! In-Reply-To: <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com><1145461239.3085.56.camel@laptopd505.fenrus.org><20060419162248.GB32734@devserv.devel.redhat.com><6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu><33625.207.35.222.39.1145894683.squirrel@lattica.com><444CFC5D.1070800@warmcat.com><46642.207.35.222.39.1145899439.squirrel@lattica.com><80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com><604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com><444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> Message-ID: <54150.207.35.222.39.1145913962.squirrel@lattica.com> On Mon, April 24, 2006 3:24 pm, Jeff Spaleta said: > of the middle-click button. Explain the me the point of including the > middle-click functionality in an input device and making it > delibrately difficult to use. Sounds like pathetically poor hardware > design to me. That's just pissing against the wind. And I don't know about you, but this is certainly not a smart thing to do in a group :) The market has spoken and they like the wheel a lot more than the middle button. Until market condition changes, there's no point debating it. Now, the fact that the middle button switched misteriously for me on my Logitech MX 1000 laser mouse during the FC4 -> FC5 update from the 'middle' wheel to a side obscure button doesn't help users get the warm and fuzzy about its use. Needless to say, I was sure pasting got b0rken for misterious reasons until I discovered the new button... -- Dimi Paun Lattica, Inc. From rhl-devel-list at lnx.ro Mon Apr 24 21:27:18 2006 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Tue, 25 Apr 2006 00:27:18 +0300 Subject: FC5 rocks! In-Reply-To: <16de708d0604241420l78d2ce6er414589e9d8629b08@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <16de708d0604241420l78d2ce6er414589e9d8629b08@mail.gmail.com> Message-ID: <1145914038.5013.1.camel@localhost> ?n data de Lu, 24-04-2006 la 16:20 -0500, Arthur Pemberton a scris: > A reliable , transperent voting system would be nice - And let's put that proverbial million flies to vote and watch shit going into whatever it is voting about. > however I do > understand that the nature of OSS development doesn't lend itself very > well to such a model. Guess why :) -- Cioby From gauret at free.fr Mon Apr 24 21:33:41 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Apr 2006 23:33:41 +0200 Subject: Fedora core suggestions References: <44491C48.4010101@warmcat.com> <1145644743.6606.27.camel@fortinbras.dpniner.net> <4449328C.2040606@warmcat.com> <1145657739.27565.19.camel@localhost.localdomain> <604aa7910604211634m49310079pc327e5cd231f123b@mail.gmail.com> <20060422121801.GA909@imperial.ac.uk> <604aa7910604220630t14b3ac45m48b03f20be3a6bb3@mail.gmail.com> <20060422144610.GB5746@imperial.ac.uk> <604aa7910604220809i32dfc1c0r13a733d62a02311f@mail.gmail.com> <16de708d0604220957ne713fd3g744ff9e8aec0d701@mail.gmail.com> Message-ID: Jack Tanner wrote: > - Selinux needs to let NX do its thing (under FC5). Already reported upstream. For the moment, you can run : semanage fcontext -a -t textrel_shlib_t /usr/NX/lib/libXcomp.so.1 semanage fcontext -a -t textrel_shlib_t /usr/NX/lib/libjpeg.so.62 chcon -t textrel_shlib_t /usr/NX/lib/libXcomp.so.1 chcon -t textrel_shlib_t /usr/NX/lib/libjpeg.so.62 (as root of course) Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Growth for the sake of growth is the ideology of the cancer cell. From nicolas.mailhot at laposte.net Mon Apr 24 21:34:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 24 Apr 2006 23:34:24 +0200 Subject: FC5 rocks! In-Reply-To: <444D41F4.9040004@poolshark.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D2C23.1020902@poolshark.org> <1145910948.15927.21.camel@pensja.lam.pl> <444D41F4.9040004@poolshark.org> Message-ID: <1145914467.3401.12.camel@rousalka.dyndns.org> Le lundi 24 avril 2006 ? 14:24 -0700, Denis Leroy a ?crit : > No this is not broken hardware. I don't know how many Logitech mice i've > owned, but it's many, even including prototypes i got from a friend at > Logitech. It's simply difficult, or rather, akward to perform a drag > movement when you have to sustain a higher-than-normal pressure on the > button, which is typically what you have to do when pressing the > mousewheel. I'll try to look up your model if i have a chance. For this kind of mouse operation, something like the MS Trackball explorer works real well -- 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 jspaleta at gmail.com Mon Apr 24 21:41:27 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 17:41:27 -0400 Subject: Fedora core suggestions In-Reply-To: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> Message-ID: <604aa7910604241441m5e081ab4o1b9f84617c174703@mail.gmail.com> On 4/24/06, Arthur Pemberton wrote: > Yes, in all fairness, FC should at least auto dete and mount vfat > partions, for that matter, it should offer to mount any fixed partion > whose FS it can detect. The policy to ignore fixed partitions by default was the result of security arguments associated with multiuser server systems. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177177#c19 If you incorrectly define the fedora core mandate as being primarily a single-user desktop system, then its very easy to say that vfat fixed disks should be treated like the plugged media devices. But once you start thinking beyond that very narrow usage case, into other situations which are more common in data center, or moderatelly sized multi-user environments, the scenario becomes problematic and its not so simple an issue as you would originally think. But don't confuse the lack of an optimal solution right now as evidence that people don't care about this and that they are not working to fix it. The PolicyKit work that is going on upstream with regard to hal is evidence of real effort to make progress on a thorny issue which has to strike a balance between single-user scenarios and server scenarios for Fedora Core's "general use" mandate. -jef"you got your desktop software on my server you got your server software on my desktop mmmmmmmmmmmmm to horribly incompatible usage scenarios which taste great together! "spaleta From jspaleta at gmail.com Mon Apr 24 21:46:18 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 17:46:18 -0400 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <444D3C9B.8080106@mesias.co.uk> References: <1145312535.16371.51.camel@coyote.rexursive.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> Message-ID: <604aa7910604241446g4dfd6d78q36217e0410d7feac@mail.gmail.com> On 4/24/06, Cam wrote: > Jeff > > while you're considering conspiracies, what about the legion of > notebooks that lack a middle button? I say buy and Apple laptop and suffer the absolute pain of the one big ass mouse button + keyboard modifier keys so you can gain perspective on the luxury that is a 2 button mouse. -jef"screw this whole mouse button crap.. i want affordable eye tracking technology which I can configure to count rapid eye blinks as both mouse clicks and keyboard actions. I'm tired of having to move my hands at all."spaleta From pemboa at gmail.com Mon Apr 24 21:52:49 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 16:52:49 -0500 Subject: Fedora core suggestions In-Reply-To: <604aa7910604241441m5e081ab4o1b9f84617c174703@mail.gmail.com> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <604aa7910604241441m5e081ab4o1b9f84617c174703@mail.gmail.com> Message-ID: <16de708d0604241452o1b16efe3s7622601769bb7517@mail.gmail.com> On 4/24/06, Jeff Spaleta wrote: > On 4/24/06, Arthur Pemberton wrote: > > Yes, in all fairness, FC should at least auto dete and mount vfat > > partions, for that matter, it should offer to mount any fixed partion > > whose FS it can detect. > > The policy to ignore fixed partitions by default was the result of > security arguments associated with multiuser server systems. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177177#c19 > > If you incorrectly define the fedora core mandate as being primarily a > single-user desktop system, then its very easy to say that vfat fixed > disks should be treated like the plugged media devices. But once you > start thinking beyond that very narrow usage case, into other > situations which are more common in data center, or moderatelly sized > multi-user environments, the scenario becomes problematic and its not > so simple an issue as you would originally think. > > But don't confuse the lack of an optimal solution right now as > evidence that people don't care about this and that they are not > working to fix it. The PolicyKit work that is going on upstream with > regard to hal is evidence of real effort to make progress on a thorny > issue which has to strike a balance between single-user scenarios and > server scenarios for Fedora Core's "general use" mandate. > Ok, fair enough. Thanks for that information. But wouldn't something on the firstboot or Anaconda side solve that problem? Or am I misunderstanding the problem? -- As a boy I jumped through Windows, as a man I play with Penguins. From jspaleta at gmail.com Mon Apr 24 22:04:48 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 18:04:48 -0400 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <1145913018.7870.2.camel@scriabin.tannenrauch.ch> References: <1145312535.16371.51.camel@coyote.rexursive.com> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> <1145913018.7870.2.camel@scriabin.tannenrauch.ch> Message-ID: <604aa7910604241504p5c797b24m2028f0e20cbf779b@mail.gmail.com> On 4/24/06, G?rard Milmeister wrote: > If I remember correctly, in 1993, the time I first used Linux, many > X apps made use of the middle mouse button (this is valid of course > for other UNIX systems with X11). -jef"xfig: the ultimate vector drawing program in 1993, as long as you had a 3 button mouse.. otherwise not particular useful at all"spaleta From jspaleta at gmail.com Mon Apr 24 22:00:05 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Apr 2006 18:00:05 -0400 Subject: Fedora core suggestions In-Reply-To: <16de708d0604241452o1b16efe3s7622601769bb7517@mail.gmail.com> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <604aa7910604241441m5e081ab4o1b9f84617c174703@mail.gmail.com> <16de708d0604241452o1b16efe3s7622601769bb7517@mail.gmail.com> Message-ID: <604aa7910604241500w17c1be4ei76e28e6986d0eebb@mail.gmail.com> On 4/24/06, Arthur Pemberton wrote: > Ok, fair enough. Thanks for that information. But wouldn't something > on the firstboot or Anaconda side solve that problem? Or am I > misunderstanding the problem? You are most likely underestimating the complexity of the problem. As I said readup on the role PolicyKit is going to play in how hal operates to learn how this is going to work in the not so distant future of 20 minutes from now. -jef"I miss Max Headroom"spaleta From gemi at bluewin.ch Mon Apr 24 22:07:02 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 25 Apr 2006 00:07:02 +0200 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <604aa7910604241504p5c797b24m2028f0e20cbf779b@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> <1145913018.7870.2.camel@scriabin.tannenrauch.ch> <604aa7910604241504p5c797b24m2028f0e20cbf779b@mail.gmail.com> Message-ID: <1145916423.7870.4.camel@scriabin.tannenrauch.ch> On Mon, 2006-04-24 at 18:04 -0400, Jeff Spaleta wrote: > On 4/24/06, G?rard Milmeister wrote: > > If I remember correctly, in 1993, the time I first used Linux, many > > X apps made use of the middle mouse button (this is valid of course > > for other UNIX systems with X11). > > -jef"xfig: the ultimate vector drawing program in 1993, as long as you > had a 3 button mouse.. otherwise not particular useful at all"spaleta And, of course, pasting text. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From pemboa at gmail.com Mon Apr 24 22:15:00 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 24 Apr 2006 17:15:00 -0500 Subject: Fedora core suggestions In-Reply-To: <604aa7910604241500w17c1be4ei76e28e6986d0eebb@mail.gmail.com> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <604aa7910604241441m5e081ab4o1b9f84617c174703@mail.gmail.com> <16de708d0604241452o1b16efe3s7622601769bb7517@mail.gmail.com> <604aa7910604241500w17c1be4ei76e28e6986d0eebb@mail.gmail.com> Message-ID: <16de708d0604241515g1bf59ca0x50a27c10492384f8@mail.gmail.com> On 4/24/06, Jeff Spaleta wrote: > On 4/24/06, Arthur Pemberton wrote: > > Ok, fair enough. Thanks for that information. But wouldn't something > > on the firstboot or Anaconda side solve that problem? Or am I > > misunderstanding the problem? > > You are most likely underestimating the complexity of the problem. As > I said readup on the role PolicyKit is going to play in how hal > operates to learn how this is going to work in the not so distant > future of 20 minutes from now. > > -jef"I miss Max Headroom"spaleta Will do - Peace -- As a boy I jumped through Windows, as a man I play with Penguins. From bojan at rexursive.com Mon Apr 24 22:53:40 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 24 Apr 2006 22:53:40 +0000 (UTC) Subject: FC5 kernel updates References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> <1145470563.11909.69.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > I did the night shift -- .8 and .9 were both built while you were > sleeping :) And here we go again - .11 available now. PS. It's a server manufacturer conspiracy, I'm sure. They want Red Hat to buy brand new machines to be able to build new kernels faster ;-) -- Bojan From seg at haxxed.com Mon Apr 24 23:34:12 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 24 Apr 2006 18:34:12 -0500 Subject: FC5 rocks! In-Reply-To: <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> Message-ID: <1145921652.22802.84.camel@localhost.localdomain> On Mon, 2006-04-24 at 13:42 -0400, Jeff Spaleta wrote: > -jef"spatial is for me > you sir are a poopyhead > middle-click works well"spaleta I was about to bitch about how there's no key combination for this, but I just tried it and apparently shift-doubleclick does it these days. Kick ass. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Tue Apr 25 00:17:45 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 24 Apr 2006 17:17:45 -0700 Subject: Mozilla in FC6 In-Reply-To: <1145880888.18645.3.camel@hammer> References: <1145866167.7751.1.camel@hammer> <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> <1145880888.18645.3.camel@hammer> Message-ID: <444D6AA9.4090504@thecodergeek.com> Mark Rosenstand wrote: > It's cleaner to build both epiphany and firefox against xulrunner. > Forcing epiphany users to have firefox installed doesn't make any sense > when it's possible to use a neutral backend for both. Agreed. I'm a big fan of Epiphany, and I think it'd be great if we could get this into Fedora in time for Core 6 testing. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at linux.duke.edu Tue Apr 25 00:50:18 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 24 Apr 2006 20:50:18 -0400 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> <1145470563.11909.69.camel@pmac.infradead.org> Message-ID: <1145926218.31773.4.camel@cutter> On Mon, 2006-04-24 at 22:53 +0000, Bojan Smojver wrote: > David Woodhouse infradead.org> writes: > > > I did the night shift -- .8 and .9 were both built while you were > > sleeping :) > > And here we go again - .11 available now. > > PS. It's a server manufacturer conspiracy, I'm sure. They want Red Hat to buy > brand new machines to be able to build new kernels faster ;-) > If, in order to do this, they find and fix security bugs then I'd say it seems like a pretty fair deal. :) -sv From jdogalt at yahoo.com Mon Apr 24 23:54:22 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Mon, 24 Apr 2006 16:54:22 -0700 (PDT) Subject: any reason why system-config-kickstart requires root? In-Reply-To: Message-ID: <20060424235422.30205.qmail@web38405.mail.mud.yahoo.com> --- Panu Matilainen wrote: > On Mon, 24 Apr 2006, Chris Lumens wrote: > > >> I can't think of one, and running > >> > >> /usr/share/system-config-kickstart/system-config-kickstart.py > >> > >> manually seems to work just fine (I saved my kickstart file without > incident). > >> > >> Should I file a bug? > > > > It requires root because it uses pirut for the package selection screen, > > and that requires root because it uses yum, which may need to update the > > cache files in /var/cache/yum. It's working as intended. > > Yum supports per-user private cache, that's what most yum-utils use for > non-root usage. Look for getCacheDir() usage in yum-utils how to make use > of it. Thanks. I'm aiming to create a livecd generation tool, with heavy usage of kickstart, and without requiring root priveleges, so the above will help me mogrify sysconfig-kickstart into a gui for my tool, while maintaining the safety of not becoming root. If nobody gets around to it first, I'll try to also submit a patch for sysconfig-kickstart, since it would be another tool which would be nice to run as a user, without risking system corruption by running it as root. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From seg at haxxed.com Tue Apr 25 01:02:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 24 Apr 2006 20:02:02 -0500 Subject: FC5 rocks! In-Reply-To: <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> Message-ID: <1145926922.22802.92.camel@localhost.localdomain> On Mon, 2006-04-24 at 11:31 -0600, Stephen John Smoogen wrote: > I mean I would love spatial sent back to the Windows95 > heck it belongs in... but that doesnt mean everyone else does. Windows 95? Its a Mac thing. I find it incredibly ironic that Gnome switched to a spatial file manager right about the same time Mac OSX was catching on, which switched Mac users away from spatial to a browser file manager... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Apr 25 01:10:48 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 24 Apr 2006 20:10:48 -0500 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <1145927449.22802.95.camel@localhost.localdomain> On Mon, 2006-04-24 at 19:52 +0000, Kevin Kofler wrote: > Pirut doesn't do that, but due to how RPMs and .desktop files are packaged, > this would probably be best implemented within menu editors such as Alacarte > (so you would select menu entry, pick "Copy to desktop", and it would be copied > there) or within the menu itself (as already implemented in KDE, you can > right-click on any menu entry in KDE's Kicker and copy it to the KDE desktop > from the context menu!). Gnome does this too. No need for menu editors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Tue Apr 25 01:17:28 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 24 Apr 2006 20:17:28 -0500 Subject: FC5 kernel updates In-Reply-To: <1145926218.31773.4.camel@cutter> References: <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> <1145470563.11909.69.camel@pmac.infradead.org> <1145926218.31773.4.camel@cutter> Message-ID: <20060425011728.GA11762@yoda.jdub.homelinux.org> On Mon, Apr 24, 2006 at 08:50:18PM -0400, seth vidal wrote: > On Mon, 2006-04-24 at 22:53 +0000, Bojan Smojver wrote: > > David Woodhouse infradead.org> writes: > > > > > I did the night shift -- .8 and .9 were both built while you were > > > sleeping :) > > > > And here we go again - .11 available now. > > > > PS. It's a server manufacturer conspiracy, I'm sure. They want Red Hat to buy > > brand new machines to be able to build new kernels faster ;-) > > > > If, in order to do this, they find and fix security bugs then I'd say it > seems like a pretty fair deal. :) Yeah, definitely. They -stable team has a pretty thankless job, but it's important and we're lucky they keep up with it. Even when we groan about daily kernel compiles. josh From seg at haxxed.com Tue Apr 25 01:26:34 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 24 Apr 2006 20:26:34 -0500 Subject: FC5 rocks! In-Reply-To: <444D2364.20107@poolshark.org> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> Message-ID: <1145928394.22802.109.camel@localhost.localdomain> On Mon, 2006-04-24 at 12:13 -0700, Denis Leroy wrote: > Jeff Spaleta wrote: > > middle-click works well"spaleta > > While we're on the subject, somebody at Gnome is in love with the middle > button, since it seems more and more important features are moved to it. > Do you know how hard it is to click the middle button on a mouse when > that middle button is actually the mouse wheel (i.e. 90% of them) ? > Grrrr. I'm out! All middle clicks should (And usually do) have an alternate way to do the same thing. Really, the middle click is supposed to be the alternate shortcut to whatever it is. Usually its on the context menu, and likely also available with a shift or ctrl or alt click... If there's not, its a bug IMHO. Personally I use five button trackballs, which makes it easy to remap middle click away from the scroll wheel. (Now if only I could figure out how to use the extra two buttons for something useful...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Tue Apr 25 06:13:02 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 25 Apr 2006 02:13:02 -0400 Subject: FC5 kernel updates In-Reply-To: References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <20060419162525.GD16298@redhat.com> <1145470563.11909.69.camel@pmac.infradead.org> Message-ID: <20060425061302.GB2828@redhat.com> On Mon, Apr 24, 2006 at 10:53:40PM +0000, Bojan Smojver wrote: > David Woodhouse infradead.org> writes: > > > I did the night shift -- .8 and .9 were both built while you were > > sleeping :) > > And here we go again - .11 available now. Work in progress errata here.. http://people.redhat.com/davej/kernels/Fedora/FC4/ http://people.redhat.com/davej/kernels/Fedora/FC5/ has been updated to .11 yesterday. I'm holding off on pushing these out as an official update, as .12 is in the works for release by the end of the week, and I'm fishing through bugzilla over the next few days for low-hanging fruit. > PS. It's a server manufacturer conspiracy, I'm sure. They want Red Hat to buy > brand new machines to be able to build new kernels faster ;-) Indeed. Dave -- http://www.codemonkey.org.uk From buildsys at redhat.com Tue Apr 25 07:44:08 2006 From: buildsys at redhat.com (Build System) Date: Tue, 25 Apr 2006 03:44:08 -0400 Subject: rawhide report: 20060425 changes Message-ID: <200604250744.k3P7i83Z023233@porkchop.devel.redhat.com> Updated Packages: anthy-7622-1 ------------ * Mon Apr 24 2006 Akira TAGOH 7622-1 - New upstream snapshot release. - removed unnecessary patches: - anthy-2832.patch - anthy-2834.patch cups-1:1.2-0.5.rc3.1 -------------------- * Mon Apr 24 2006 Tim Waugh 1:1.2-0.5.rc3.1 - 1.2rc3. - Ship an snmp.conf. * Fri Apr 21 2006 Tim Waugh 1:1.2-0.4.rc2.2 - Updated to svn 5446. * Wed Apr 19 2006 Tim Waugh - Ignore .rpmnew and .rpmsave banner files. gcc-4.1.0-10 ------------ * Fri Apr 21 2006 Jakub Jelinek 4.1.0-10 - update from gcc-4_1-branch (-r113110:113149) - PRs libgcj/21941, libgcj/27170, libgcj/27231, libgfortran/27138, libstdc++/26424, mudflap/26789 - improve dir/../-stripping code to support /usr/lib64 and /usr/lib in separate AFS mountpoints (Alexandre Oliva, #137200) - fix fortran real(16) transpose and reshape on 32-bit architectures (PR fortran/26769) - fix i?86/x86_64 vector extraction (Alexandre Oliva, #187450) - fix testcase for ppc32 va_arg bug - fix testsuite log uuencoding - fix acats timeout framework ghostscript-8.15.1-10 --------------------- * Mon Apr 24 2006 Tim Waugh 8.15.1-10 - Fix emacs interaction (bug #189321, STR #1570). gimp-help-2-0.1.0.10.1 ---------------------- * Mon Apr 24 2006 Nils Philippsen - version 2-0.10 glibc-kernheaders-3.0-7 ----------------------- * Mon Apr 24 2006 Jakub Jelinek - 3.0-7 - fix typo in the i386 fstatat64 change - Add new syscalls up to 2006-04-24 gnome-games-1:2.14.1-3 ---------------------- * Mon Apr 24 2006 Matthias Clasen - 1:2.14.1-3 - Update the extra data to 2.14.0 gnome-vfs2-2.14.1-4 ------------------- * Sat Apr 22 2006 Matthias Clasen - 2.14.1-4 - fix a typo * Thu Apr 20 2006 Matthias Clasen - 2.14.1-2 - update to 2.14.1 hal-0.5.7-5 ----------- * Mon Apr 24 2006 John (J5) Palmieri - 0.5.7-5 - ifnarch the pm-utils requires for s390 and s390x icon-naming-utils-0.7.1-1 ------------------------- lftp-3.4.4-1.FC6 ---------------- * Fri Apr 21 2006 Jason Vas Dias - 3.4.4-1 - Upgrade to upstream version 3.4.4 libstdc++so7-4.2.0-0.4.20060203 ------------------------------- * Mon Apr 24 2006 Jens Petersen - 4.2.0-0.4 - use ppc64 as target for ppc like gcc does (#188446) - define and use gcc_target_platform from gcc41.spec ncompress-4.2.4-44 ------------------ * Fri Apr 21 2006 Peter Vrabec 4.2.4-44 - fix problems with compressing zero-sized files (#189215, #189216) nut-2.0.3-1 ----------- * Mon Apr 24 2006 Than Ngo 2.0.3-1 - update to 2.0.3 - drop nut-2.0.2-buffer.patch, it's included in new upstream - add udev rule #189674, #187105 openoffice.org-1:2.0.2-5.11.3 ----------------------------- * Mon Apr 24 2006 Caolan McNamara - 1:2.0.2-5.11 - ooo#64063# Finally 2.0.X Tamil translation updates star-1.5a74-1 ------------- * Mon Apr 24 2006 Peter Vrabec 1.5a74-1 - upgrade * Wed Mar 22 2006 Peter Vrabec 1.5a73-1 - upgrade * Wed Mar 01 2006 Peter Vrabec 1.5a72-1 - upgrade tar-1.15.1-16 ------------- * Mon Apr 24 2006 Peter Vrabec 1.15.1-16 - fix problem when options at the end of command line were not recognized (#188707) xorg-x11-server-1.0.99.901-6 ---------------------------- * Mon Apr 24 2006 Adam Jackson 1.0.99.901-6 - Backport a Render crash fix from HEAD. * Thu Apr 13 2006 Kristian H??gsberg 1.0.99.901-5 - Update spiffiffity patch to only suppress move damage events for manually redirected windows. * Wed Apr 12 2006 Kristian H??gsberg 1.0.99.901-4 - Bump for rawhide build. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From mpeters at mac.com Tue Apr 25 11:08:53 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Apr 2006 04:08:53 -0700 Subject: Fedora core suggestions In-Reply-To: References: Message-ID: <1145963333.19354.59.camel@atlantis.mpeters.local> On Fri, 2006-04-21 at 10:42 -0400, Alo Tsum wrote: > > First suggestions has to do with the software side of things. We users > need a competent software installer which is graphical based. One that > functions much the same way that the windows installer works. This > installer should track dependencies naturally and place icons on the > desktop or give the option to have icons for the software just > installed to be placed on the desktop of the user as well as in the > applications menu. I would like to see "Install Software" (what you get by right clicking on an rpm file) patched to use yum localinstall rather than just rpm directly - but other than that, right clicking on an application does what should be done. A properly packaged rpm will make the necessary menu entries. > Also when watching the Boston Linux conference the suggestion was > made to offer a hard disc manager much like windows offers for > formating and receiving hard drivers etc after installation. You can do that with System -> Administration -> Logical Volume Management. If you don't intent to use a hard drive as part of an LVM, then gparted (from Fedora Extras) is just a yum away. > > Firstly Redhat while promoting Linux among enthusiast is also in the > business of making money. On that front I believe that they should not > only attempt to evangelize Linux in the government, education, and > corporate sectors; they should also attempt to get Linux in each and > every home. Time and a place for each marketing endeavor. Think too big and you run out of money and accomplish nothing. If an OEM can make money doing it, I'm sure Red Hat would be willing to talk with them about bundling RHEL - or they can adapt Fedora (being careful of the trademark issues) themselves without too much difficulty. From mpeters at mac.com Tue Apr 25 11:15:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Apr 2006 04:15:45 -0700 Subject: Fedora core suggestions In-Reply-To: <1145709556.19696.65.camel@hammer> References: <16de708d0604211602m6aac8846r11c162429d7da4b2@mail.gmail.com> <1145709556.19696.65.camel@hammer> Message-ID: <1145963746.19354.63.camel@atlantis.mpeters.local> On Sat, 2006-04-22 at 14:39 +0200, Mark Rosenstand wrote: > On Fri, 2006-04-21 at 18:02 -0500, Arthur Pemberton wrote: > > On 4/21/06, Alo Tsum wrote: > > > > > First suggestions has to do with the software side of things. We users need > > > a competent software installer which is graphical based. > > > > The problem here is that there are several options, and Fedora has > > chosen to stick with Pirut. I am personally not a fan of the GUI style > > used by Pirut, but it is quite possible that I am in the minority in > > this regard. > > Perhaps a minority, but definately not alone. It's hard to believe that > it comes from the same vendor that proposed the HIG. > Pirut is good for getting the OS installed fast and then installing groups of software. Individual packages is better done with yum. pirut might benefit from some interface changes, but imho it also needs to be able to install updates to existing software at the same time it installs new software - so that after installing Fedora, you can just use pirut to pick your packages - and at the same yum transaction it will install available updates. From dwmw2 at infradead.org Tue Apr 25 12:13:56 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Apr 2006 13:13:56 +0100 Subject: FC5 rocks! / middle mouseless angst In-Reply-To: <604aa7910604241446g4dfd6d78q36217e0410d7feac@mail.gmail.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <604aa7910604241042w515f61aej84ec37f4eb5d75a5@mail.gmail.com> <444D2364.20107@poolshark.org> <604aa7910604241224lb36bf21p115af0789cd862a4@mail.gmail.com> <444D3C9B.8080106@mesias.co.uk> <604aa7910604241446g4dfd6d78q36217e0410d7feac@mail.gmail.com> Message-ID: <1145967236.11909.382.camel@pmac.infradead.org> On Mon, 2006-04-24 at 17:46 -0400, Jeff Spaleta wrote: > I say buy and Apple laptop and suffer the absolute pain of the one big > ass mouse button + keyboard modifier keys so you can gain perspective > on the luxury that is a 2 button mouse. I hate trackpads anyway. My Apple laptop is lovely in Fedora.... with its bluetooth 3-button mouse. :) -- dwmw2 From rdieter at math.unl.edu Tue Apr 25 12:33:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Apr 2006 07:33:50 -0500 Subject: Mozilla in FC6 In-Reply-To: <444D6AA9.4090504@thecodergeek.com> References: <1145866167.7751.1.camel@hammer> <39521.89.50.36.80.1145872568.squirrel@arlette.freesurf.fr> <1145880888.18645.3.camel@hammer> <444D6AA9.4090504@thecodergeek.com> Message-ID: <444E172E.7090607@math.unl.edu> Peter Gordon wrote: > Agreed. I'm a big fan of Epiphany, and I think it'd be great if we could > get this into Fedora in time for Core 6 testing. Sounds like an excellent candidate for Fedora Extras. -- Rex From jkeating at j2solutions.net Tue Apr 25 12:46:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 25 Apr 2006 08:46:18 -0400 Subject: Fedora core suggestions In-Reply-To: <1145963333.19354.59.camel@atlantis.mpeters.local> References: <1145963333.19354.59.camel@atlantis.mpeters.local> Message-ID: <1145969178.3006.0.camel@yoda.loki.me> On Tue, 2006-04-25 at 04:08 -0700, Michael A. Peters wrote: > I would like to see "Install Software" (what you get by right clicking > on an rpm file) patched to use yum localinstall rather than just rpm > directly - but other than that, right clicking on an application does > what should be done. > Have you tried double clicking an rpm lately, or downloading one from Firefox? It uses the same backend code that pirut and pup use to install it, as well as gathering deps IIRC. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From d.jacobfeuerborn at conversis.de Tue Apr 25 13:16:31 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 25 Apr 2006 15:16:31 +0200 Subject: Xorg signal 11's spontaneously In-Reply-To: <444CE442.60506@redhat.com> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> <444CE442.60506@redhat.com> Message-ID: <444E212F.70606@conversis.de> Adam Jackson wrote: > Dennis Jacobfeuerborn wrote: >> Dennis Jacobfeuerborn wrote: >>> In the last 10 days Xorg crashed three times with a signal 11 >>> spontaneously. This is the backtrace I found in the logfile: >>> >>> Backtrace: >>> 0: /usr/bin/Xorg(xf86SigHandler+0x87) [0x80b6d07] >>> 1: [0x49a420] >>> 2: /usr/lib/xorg/modules/libfb.so [0x134b81] >>> 3: /usr/lib/xorg/modules/libfb.so [0x13c80c] >>> 4: /usr/lib/xorg/modules/libfb.so(fbCompositeGeneral+0x855) [0x13a4e5] >>> 5: /usr/lib/xorg/modules/libfb.so(fbComposite+0x1cd) [0x1433ad] >>> 6: /usr/lib/xorg/modules/libxaa.so(XAAComposite+0x261) [0x81f001] >>> 7: /usr/bin/Xorg [0x8156d06] >>> 8: /usr/bin/Xorg [0x8153915] >>> 9: /usr/bin/Xorg(CompositePicture+0x153) [0x8140a13] >>> 10: /usr/bin/Xorg [0x814687c] >>> 11: /usr/bin/Xorg [0x8143bd5] >>> 12: /usr/bin/Xorg(Dispatch+0x19a) [0x80869ba] >>> 13: /usr/bin/Xorg(main+0x485) [0x806e3e5] >>> 14: /lib/libc.so.6(__libc_start_main+0xdc) [0x4cd7e4] >>> 15: /usr/bin/Xorg(FontFileCompleteXLFD+0xbd) [0x806d721] >>> >>> Fatal server error: >>> Caught signal 11. Server aborting >>> >>> All three crashes happened when I was loading a page in Firefox and >>> after the nightly Firefox builds got switched to Cairo as their >>> rendering backend so I wonder if Cairo could somehow trigger this. >>> >>> I'm running Fedora Core Rawhide with the following Xorg packages: >>> xorg-x11-server-Xorg-1.0.99.901-5 >>> xorg-x11-drv-nv-1.1.1-2 >>> >>> I'm using the open source nv driver with the AccelMethod set to EXA >>> and the 'load "dri"' and 'load "glx"' lines commented out. > > Neither DRI nor EXA matter at all to the nv driver, which supports neither. > >> Just happened again and the backtrace looks similar to the one above. >> If I can do something to provide better information to debug this >> please tell me. > > Install the debuginfo packages, ssh in from another machine, su, attach > gdb to X, 'handle SIGPIPE nostop', and 'cont'. When the server > segfaults, 'bt f' should now give you useful backtrace info. I filed bug 6704 about this in the fdo bugzilla and there someone pointed me the appropriate wiki page for debugging the X server. Since I don't have a second machine nearby right now I'll try the single machine approach described in the wiki. > May also be related to a crasher recently fixed for x4a4 glyphs; I'll > backpatch that into rawhide and stable shortly. Is there a way to deliberately trigger that bug? I haven't found a way to trigger the crash I'm seeing but if the glyph bug would result in the same backtrace as above then we'd know if this is really the same problem. Right now I've set the NoTrapSignal option and enabled core dumping and now have to wait until X dies again. Regards, Dennis From mpeters at mac.com Tue Apr 25 13:19:16 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Apr 2006 06:19:16 -0700 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> Message-ID: <1145971156.6969.3.camel@atlantis.mpeters.local> On Sat, 2006-04-22 at 00:50 +0100, Leon wrote: > > I think you didn't get the idea right. > > Basically they want to divide packages (of course installed by package > manager; those installed using source, the user has to track > themselves) into two groups: one is installed by the user (explicitly > 'yum install') and the other is those required to satisfy the > dependence. > > Ubuntu put this *high* priority for the next release after > dapper. After reading its wiki page, it make sense to me. And I > believe it will be useful. I want the mathml-fonts fonts installed. I know that "yum install abiword" which I also want will grab them as a dependency. But suppose I decide that I'm not using AbiWord anymore because I'm doing everything in LaTeX. So I remove AbiWord. mathml-fonts I still want though - but it was installed as a dependency to abiword, which I have since removed. Does that mean mathml-fonts will get automatically removed out from under me? From fedora at camperquake.de Tue Apr 25 13:23:18 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Apr 2006 15:23:18 +0200 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145971156.6969.3.camel@atlantis.mpeters.local> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> Message-ID: <20060425152318.24f0497f@duras.int.addix.net> Hi. On Tue, 25 Apr 2006 06:19:16 -0700, Michael A. Peters wrote: > Does that mean mathml-fonts will get automatically removed out from > under me? It may, which is one of the problems with this approach. From kevin.kofler at chello.at Tue Apr 25 13:23:52 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 25 Apr 2006 13:23:52 +0000 (UTC) Subject: Fedora core suggestions References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> Message-ID: > Yes, in all fairness, FC should at least auto dete and mount vfat > partions, for that matter, it should offer to mount any fixed partion > whose FS it can detect. Maybe that's just me, but even on my single-user system, I want my VFAT partitions mounted at predictable, easy-to-remember locations (/c for C:, /d for D:, /e for E: and /f for F:), not some arbitrary /media/diskn locations which aren't even consistent from boot to boot. (As for ext2/ext3 partitions, if I had any other than /, they'd of course have to go to the right place in the FHS, not /media/diskn.) Kevin Kofler From mpeters at mac.com Tue Apr 25 13:26:46 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Apr 2006 06:26:46 -0700 Subject: Fedora core suggestions In-Reply-To: <1145969178.3006.0.camel@yoda.loki.me> References: <1145963333.19354.59.camel@atlantis.mpeters.local> <1145969178.3006.0.camel@yoda.loki.me> Message-ID: <1145971607.6969.6.camel@atlantis.mpeters.local> On Tue, 2006-04-25 at 08:46 -0400, Jesse Keating wrote: > On Tue, 2006-04-25 at 04:08 -0700, Michael A. Peters wrote: > > I would like to see "Install Software" (what you get by right clicking > > on an rpm file) patched to use yum localinstall rather than just rpm > > directly - but other than that, right clicking on an application does > > what should be done. > > > > Have you tried double clicking an rpm lately, or downloading one from > Firefox? It uses the same backend code that pirut and pup use to > install it, as well as gathering deps IIRC. Well, heh, if that's the case - then it does exactly what I want. But no - I haven't tried with apps that need dependencies installed. I'll do that and see what happens. From d.jacobfeuerborn at conversis.de Tue Apr 25 13:46:57 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 25 Apr 2006 15:46:57 +0200 Subject: Xorg signal 11's spontaneously In-Reply-To: <444E212F.70606@conversis.de> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> <444CE442.60506@redhat.com> <444E212F.70606@conversis.de> Message-ID: <444E2851.3030209@conversis.de> Dennis Jacobfeuerborn wrote: [snip] > Adam Jackson wrote: >> Install the debuginfo packages, ssh in from another machine, su, >> attach gdb to X, 'handle SIGPIPE nostop', and 'cont'. When the server >> segfaults, 'bt f' should now give you useful backtrace info. > > I filed bug 6704 about this in the fdo bugzilla and there someone > pointed me the appropriate wiki page for debugging the X server. Since I > don't have a second machine nearby right now I'll try the single machine > approach described in the wiki. > >> May also be related to a crasher recently fixed for x4a4 glyphs; I'll >> backpatch that into rawhide and stable shortly. > > Is there a way to deliberately trigger that bug? I haven't found a way > to trigger the crash I'm seeing but if the glyph bug would result in the > same backtrace as above then we'd know if this is really the same problem. > Right now I've set the NoTrapSignal option and enabled core dumping and > now have to wait until X dies again. Tracked down a testcase using the Xorg changelog but I get a different backtrace when triggering that bug so this seems to be a different problem. Unfortunately I also didn't get a core dump and I'm not sure why. I added the line DAEMON_COREFILE_LIMIT="unlimited" to /etc/sysconfig/init and changed the line in /etc/profile to "ulimit -S -c unlimited > /dev/null 2>&1" but after crashing X I now no longer get a backtrace in the Xorg.log (due to the NoTrapSignal option?) but I also don't see a core dump in the home directories. What else do I have to do to get a core dump I can feed to gdb? Regards, Dennis From Lam at Lam.pl Tue Apr 25 13:56:55 2006 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 25 Apr 2006 15:56:55 +0200 Subject: Fedora core suggestions In-Reply-To: References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> Message-ID: <1145973415.2748.12.camel@pensja.lam.pl> Dnia 25-04-2006, wto o godzinie 13:23 +0000, Kevin Kofler napisa?(a): > Maybe that's just me, but even on my single-user system, I want my VFAT > partitions mounted at predictable, easy-to-remember locations (/c for C:, /d > for D:, /e for E: and /f for F:) 1. You can add any partition to fstab in almost any location you want (you can't use /dev/null for example, but other than existing files, you're really free to do what you want). Anaconda has a GUI for it and it worked every time I tried. 2. It's hard or impossible to know which partition is Windows D: and which is E:, because: a) newer Windows versions allow you to change the drives letters on the fly, you'd have to mount the boot partition (and know which one is that), read some files from it (when the settings are stored), understand their format and then remount partitions in appropriate locations, that's hard I guess, and b) if you have two Windows versions (i.e. 98 and XP), they can see the drives with different letters, so which one is more important? > some arbitrary /media/diskn locations > which aren't even consistent from boot to boot. This is a real problem, but I remember discussions regarding it, so it will get better and better with time. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From gilboad at gmail.com Tue Apr 25 14:04:45 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 25 Apr 2006 17:04:45 +0300 Subject: Fedora core suggestions In-Reply-To: <1145973415.2748.12.camel@pensja.lam.pl> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <1145973415.2748.12.camel@pensja.lam.pl> Message-ID: <1145973885.28657.22.camel@gilboa-work-dev> On Tue, 2006-04-25 at 15:56 +0200, Leszek Matok wrote: > Dnia 25-04-2006, wto o godzinie 13:23 +0000, Kevin Kofler napisa?(a): > > Maybe that's just me, but even on my single-user system, I want my VFAT > > partitions mounted at predictable, easy-to-remember locations (/c for C:, /d > > for D:, /e for E: and /f for F:) > 1. You can add any partition to fstab in almost any location you want > (you can't use /dev/null for example, but other than existing files, > you're really free to do what you want). Anaconda has a GUI for it and > it worked every time I tried. > 2. It's hard or impossible to know which partition is Windows D: and > which is E:, because: > a) newer Windows versions allow you to change the drives letters on the > fly, you'd have to mount the boot partition (and know which one is > that), read some files from it (when the settings are stored), > understand their format and then remount partitions in appropriate > locations, that's hard I guess, and > b) if you have two Windows versions (i.e. 98 and XP), they can see the > drives with different letters, so which one is more important? > > > some arbitrary /media/diskn locations > > which aren't even consistent from boot to boot. > This is a real problem, but I remember discussions regarding it, so it > will get better and better with time. > > Lam > -- Actually is much -much- worse. Windows 2K and above, keep a UUID to drive letter map in their registry. It's entirely possible to have two Windows OS on the same disk (hda1, hda2), each displaying a third partition (hda3) with a different drive latter. So, even if you mount each Windows drive, open it's registry and read the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\DosDevices[CDE...] keys, you might have conflicting drive letters. Gilboa From camilo at mesias.co.uk Tue Apr 25 14:08:53 2006 From: camilo at mesias.co.uk (Cam) Date: Tue, 25 Apr 2006 15:08:53 +0100 Subject: Fedora core suggestions In-Reply-To: <1145973415.2748.12.camel@pensja.lam.pl> References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <1145973415.2748.12.camel@pensja.lam.pl> Message-ID: <444E2D75.9010004@mesias.co.uk> Leszek > b) if you have two Windows versions (i.e. 98 and XP), they can see the > drives with different letters, so which one is more important? I suppose it doesn't matter so much what other OSs do, as being able to configure these partitions to reliably mount in a specific location. I have seen something strange. On a notebook with SATA disk (/dev/sda), I have a PCMCIA Compact Flash adapter. When I plug in a CF, I find a new drive /dev/hda, but it never mounts automatically. The same CF plugged into a USB CF reader *will* mount automatically. On a different machine the main disk is /dev/hda and the CF over USB is /dev/sda. I'm concerned that this is an accident waiting to happen. If the GUI doesn't start auto-mounting these with an intuitive name then I'll continue to be at risk of umounting or mkfs the wrong device... -Cam -- camilo at mesias.co.uk <-- From jspaleta at gmail.com Tue Apr 25 14:13:36 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Apr 2006 10:13:36 -0400 Subject: Fedora core suggestions In-Reply-To: References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> Message-ID: <604aa7910604250713k1b00e25fyb022f29747e70534@mail.gmail.com> On 4/25/06, Kevin Kofler wrote: > Maybe that's just me, but even on my single-user system, I want my VFAT > partitions mounted at predictable, easy-to-remember locations (/c for C:, /d > for D:, /e for E: and /f for F:), not some arbitrary /media/diskn locations > which aren't even consistent from boot to boot. (As for ext2/ext3 partitions, > if I had any other than /, they'd of course have to go to the right place in > the FHS, not /media/diskn.) P-O-L-I-C-Y-K-I-T -jef" Butterfly in the sky, I can go twice as high Take a look, it's in a book - Reading Rainbow. I can go anywhere! Friends to know and ways to grow - Reading Rainbow. I can be anything! Take a look, it's in a book - Reading Rainbow. Reading Rainbow, Reading Rainbow, Reading Rainbow, Reading Rainbow! "spaleta From dragoran at feuerpokemon.de Tue Apr 25 14:53:37 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 25 Apr 2006 16:53:37 +0200 Subject: pup broken on mulitlib systems (was Re: yum + mulitarch + updates) In-Reply-To: <4431026F.7050603@feuerpokemon.de> References: <442F6F0B.2040706@feuerpokemon.de> <4431026F.7050603@feuerpokemon.de> Message-ID: <444E37F1.4010307@feuerpokemon.de> dragoran wrote: > Ian Burrell schrieb: >> On 4/1/06, dragoran wrote: >> >>> I have noticed that when I have package foo-1.0.i386 installed and some >>> other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the >>> i386 one. >>> (livna mplayerplug-in was it here). >>> Updates should not be crossarch a i386 package should only be >>> updated to >>> a i386 one (same for x86_64). >>> Any reason for doing this? Or is this a bug thats needs to be filled? >>> >>> >> >> Can you give an actual example? >> >> Also, did you change your /etc/yum.conf file? There is a setting, >> exactarch, which controls whether yum will upgrade to across >> architectures. The default is exactarch=1. It is even more strict >> than x86_64/i386; it won't upgrade between glibc.i386 and glibc.i686 >> for exampe. >> >> - Ian >> >> > no yum.conf is stock (checked) > here is the output of yum check-update > azureus.x86_64 2.4.0.3-0.20060328cvs_ extras > ffmpeg.x86_64 0.4.9-0.21.20051228.lv livna > gwget.x86_64 0.97-3.fc5 extras > mplayerplug-in.x86_64 3.21-1.lvn5 livna > xine-lib.x86_64 1.1.1-5.lvn5 livna > xine-lib-devel.x86_64 1.1.1-5.lvn5 livna > ---- > rpm -q mplayerplug-in > mplayerplug-in-3.21-fc4 > rpm -q mplayerplug-in --queryformat %{ARCH} > i386 > so this is a bug? > hello this happend again now: pup tryes to update mplayer.i386 to mplayer.x86_64 while yum does not try to do this ... why? does pup ignore exactarch=1 or what else does happen? From dragoran at feuerpokemon.de Tue Apr 25 15:03:18 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 25 Apr 2006 17:03:18 +0200 Subject: pup broken on mulitlib systems (was Re: yum + mulitarch + updates) In-Reply-To: <444E37F1.4010307@feuerpokemon.de> References: <442F6F0B.2040706@feuerpokemon.de> <4431026F.7050603@feuerpokemon.de> <444E37F1.4010307@feuerpokemon.de> Message-ID: <444E3A36.8070307@feuerpokemon.de> dragoran wrote: > dragoran wrote: >> Ian Burrell schrieb: >>> On 4/1/06, dragoran wrote: >>> >>>> I have noticed that when I have package foo-1.0.i386 installed and >>>> some >>>> other (x86_64) repo has foo-1.1.x86_64 yum updates foo and removes the >>>> i386 one. >>>> (livna mplayerplug-in was it here). >>>> Updates should not be crossarch a i386 package should only be >>>> updated to >>>> a i386 one (same for x86_64). >>>> Any reason for doing this? Or is this a bug thats needs to be filled? >>>> >>>> >>> >>> Can you give an actual example? >>> >>> Also, did you change your /etc/yum.conf file? There is a setting, >>> exactarch, which controls whether yum will upgrade to across >>> architectures. The default is exactarch=1. It is even more strict >>> than x86_64/i386; it won't upgrade between glibc.i386 and glibc.i686 >>> for exampe. >>> >>> - Ian >>> >>> >> no yum.conf is stock (checked) >> here is the output of yum check-update >> azureus.x86_64 2.4.0.3-0.20060328cvs_ extras >> ffmpeg.x86_64 0.4.9-0.21.20051228.lv livna >> gwget.x86_64 0.97-3.fc5 extras >> mplayerplug-in.x86_64 3.21-1.lvn5 livna >> xine-lib.x86_64 1.1.1-5.lvn5 livna >> xine-lib-devel.x86_64 1.1.1-5.lvn5 livna >> ---- >> rpm -q mplayerplug-in >> mplayerplug-in-3.21-fc4 >> rpm -q mplayerplug-in --queryformat %{ARCH} >> i386 >> so this is a bug? >> > hello > this happend again now: > pup tryes to update mplayer.i386 to mplayer.x86_64 > while yum does not try to do this ... > why? does pup ignore exactarch=1 or what else does happen? > ok this was happening because of mencoder.x86_64 which was installed using nodeps... From ajackson at redhat.com Tue Apr 25 14:11:15 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 25 Apr 2006 10:11:15 -0400 Subject: Xorg signal 11's spontaneously In-Reply-To: <444E2851.3030209@conversis.de> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> <444CE442.60506@redhat.com> <444E212F.70606@conversis.de> <444E2851.3030209@conversis.de> Message-ID: <444E2E03.6040009@redhat.com> Dennis Jacobfeuerborn wrote: > Tracked down a testcase using the Xorg changelog but I get a different > backtrace when triggering that bug so this seems to be a different > problem. Unfortunately I also didn't get a core dump and I'm not sure > why. I added the line DAEMON_COREFILE_LIMIT="unlimited" to > /etc/sysconfig/init and changed the line in /etc/profile to "ulimit -S > -c unlimited > /dev/null 2>&1" but after crashing X I now no longer get > a backtrace in the Xorg.log (due to the NoTrapSignal option?) but I also > don't see a core dump in the home directories. What else do I have to do > to get a core dump I can feed to gdb? IIRC it's something like 'chmod 4755 `which Xorg`' and possibly also run the server as root, the kernel will try really really hard to not dump core for suid binaries (rightly so). - ajax From smooge at gmail.com Tue Apr 25 16:00:16 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 25 Apr 2006 10:00:16 -0600 Subject: FC5 rocks! In-Reply-To: <1145926922.22802.92.camel@localhost.localdomain> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <444CFC5D.1070800@warmcat.com> <46642.207.35.222.39.1145899439.squirrel@lattica.com> <80d7e4090604241031h66d60e31r1387e9e80e8c05f9@mail.gmail.com> <1145926922.22802.92.camel@localhost.localdomain> Message-ID: <80d7e4090604250900q49e49699t2e2c7a7e6542a136@mail.gmail.com> On 4/24/06, Callum Lerwick wrote: > On Mon, 2006-04-24 at 11:31 -0600, Stephen John Smoogen wrote: > > I mean I would love spatial sent back to the Windows95 > > heck it belongs in... but that doesnt mean everyone else does. > > Windows 95? Its a Mac thing. My only experience with spatial was with Windows 95. The MacOS boxes I worked on were only used as Xterms.. so I never went beyond the very simple double-click start Hummingbird X > > I find it incredibly ironic that Gnome switched to a spatial file > manager right about the same time Mac OSX was catching on, which > switched Mac users away from spatial to a browser file manager... > Well I am guessing Apple will find the error of its ways and go back to it. -- Stephen J Smoogen. CSIRT/Linux System Administrator From pemboa at gmail.com Tue Apr 25 16:08:05 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 25 Apr 2006 11:08:05 -0500 Subject: Fedora core suggestions In-Reply-To: References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> Message-ID: <16de708d0604250908m2af3506dja52ec28509025b92@mail.gmail.com> On 4/25/06, Kevin Kofler wrote: > > Yes, in all fairness, FC should at least auto dete and mount vfat > > partions, for that matter, it should offer to mount any fixed partion > > whose FS it can detect. > > Maybe that's just me, but even on my single-user system, I want my VFAT > partitions mounted at predictable, easy-to-remember locations (/c for C:, /d > for D:, /e for E: and /f for F:), not some arbitrary /media/diskn locations > which aren't even consistent from boot to boot. (As for ext2/ext3 partitions, > if I had any other than /, they'd of course have to go to the right place in > the FHS, not /media/diskn.) > > Kevin Kofler > No, it is not just you, this is how I had thing ssetup before. And it is a good, and easy to understand way of mounting Window's based partions. -- As a boy I jumped through Windows, as a man I play with Penguins. From lamont at gurulabs.com Tue Apr 25 17:33:07 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 25 Apr 2006 11:33:07 -0600 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145971156.6969.3.camel@atlantis.mpeters.local> References: <1145971156.6969.3.camel@atlantis.mpeters.local> Message-ID: <200604251133.07752.lamont@gurulabs.com> On Tuesday 25 April 2006 07:19am, Michael A. Peters wrote: > On Sat, 2006-04-22 at 00:50 +0100, Leon wrote: > > I think you didn't get the idea right. > > > > Basically they want to divide packages (of course installed by package > > manager; those installed using source, the user has to track > > themselves) into two groups: one is installed by the user (explicitly > > 'yum install') and the other is those required to satisfy the > > dependence. > > > > Ubuntu put this *high* priority for the next release after > > dapper. After reading its wiki page, it make sense to me. And I > > believe it will be useful. > > I want the mathml-fonts fonts installed. > I know that "yum install abiword" which I also want will grab them as a > dependency. > > But suppose I decide that I'm not using AbiWord anymore because I'm > doing everything in LaTeX. So I remove AbiWord. > > mathml-fonts I still want though - but it was installed as a dependency > to abiword, which I have since removed. > > Does that mean mathml-fonts will get automatically removed out from > under me? That's why I never never run "yum -y remove splat" ("yum -y install splat" for that matter). In such a situation, it would be very nice to be able to selectively "uncheck" packages from the dependency list that were automatically selected for removal, too. But that's probably best handled by the GUI if you want it to be interactive. On the command line (i.e., just the yum command), I would say "n" to removing the packages, yum exits, I press the Up Arrow key and edit the line to read "yum --exclude=mathml-fonts remove splat". Then again, I don't believe that any application package should "depend" on font packages, in general. However, it the automatic removal selection mechanism is added to yum, it should be possible to mark "soft" dependencies in an RPM (like an Include: directive, for example) that says, "Hey, it's good to also include that package when you install this one." Of course, I just opened a very XL can-o-worms there, didn't I? Just to be clear, though, I'm for the idea of automatic dependency resolution for removal. If nothing else depends on a package once those items that did are removed, why keep the clutter around? I know disk space is _really_ cheap, but I still like to keep my systems tidy. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Tue Apr 25 17:33:58 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 25 Apr 2006 11:33:58 -0600 Subject: Fedora core suggestions In-Reply-To: <1145963746.19354.63.camel@atlantis.mpeters.local> References: <1145709556.19696.65.camel@hammer> <1145963746.19354.63.camel@atlantis.mpeters.local> Message-ID: <200604251133.58658.lamont@gurulabs.com> On Tuesday 25 April 2006 05:15am, Michael A. Peters wrote: > On Sat, 2006-04-22 at 14:39 +0200, Mark Rosenstand wrote: > > On Fri, 2006-04-21 at 18:02 -0500, Arthur Pemberton wrote: > > > On 4/21/06, Alo Tsum wrote: > > > > First suggestions has to do with the software side of things. We > > > > users need a competent software installer which is graphical based. > > > > > > The problem here is that there are several options, and Fedora has > > > chosen to stick with Pirut. I am personally not a fan of the GUI style > > > used by Pirut, but it is quite possible that I am in the minority in > > > this regard. > > > > Perhaps a minority, but definately not alone. It's hard to believe that > > it comes from the same vendor that proposed the HIG. > > Pirut is good for getting the OS installed fast and then installing > groups of software. > > Individual packages is better done with yum. > > pirut might benefit from some interface changes, but imho it also needs > to be able to install updates to existing software at the same time it > installs new software - so that after installing Fedora, you can just > use pirut to pick your packages - and at the same yum transaction it > will install available updates. Here, here! -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pjones at redhat.com Tue Apr 25 18:02:22 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 25 Apr 2006 14:02:22 -0400 Subject: New Ideas - how about a GUI for /etc/fstab In-Reply-To: <20060422174556.GA23589@wolves.durham.nc.us> References: <20060422174556.GA23589@wolves.durham.nc.us> Message-ID: <1145988143.14889.29.camel@localhost.localdomain> On Sat, 2006-04-22 at 13:45 -0400, G.Wolfe Woodbury wrote: > There are some automatic tools that manipulate parts of the fstab, > but there isn't a GUI that understands all of the various pieces and > options that go into the fstab of a Fedora Core system. > > It would be nice if there were a GUI editor that would allow the addition > of NFS, CIFS and other network filesystems to the fstab with some handling > of the options that they require. Gah, no it wouldn't be nice. It'd be nice if users never had to know about those files at all. -- Peter From ggw at wolves.durham.nc.us Tue Apr 25 19:20:02 2006 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Tue, 25 Apr 2006 15:20:02 -0400 Subject: New Ideas - how about a GUI for /etc/fstab In-Reply-To: <1145988143.14889.29.camel@localhost.localdomain> References: <20060422174556.GA23589@wolves.durham.nc.us> <1145988143.14889.29.camel@localhost.localdomain> Message-ID: <20060425192002.GA3071@wolves.durham.nc.us> On Tue, Apr 25, 2006 at 02:02:22PM -0400, Peter Jones wrote: > On Sat, 2006-04-22 at 13:45 -0400, G.Wolfe Woodbury wrote: > > There are some automatic tools that manipulate parts of the fstab, > > but there isn't a GUI that understands all of the various pieces and > > options that go into the fstab of a Fedora Core system. > > > > It would be nice if there were a GUI editor that would allow the addition > > of NFS, CIFS and other network filesystems to the fstab with some handling > > of the options that they require. > > Gah, no it wouldn't be nice. It'd be nice if users never had to know > about those files at all. > -- > Peter Then are there going to be tools that seek and mount NFS and CIFS/SMB shares on the network? Automount is *not* user-friendly, and some means of dealing with the existence of network shares is needed. G.Wolfe Woodbury -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Tue Apr 25 19:30:26 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 26 Apr 2006 05:30:26 +1000 Subject: Mozilla 1.7.13 for FC5 updates Message-ID: <1145993426.14509.55.camel@coyote.rexursive.com> Is this in the works? -- Bojan From seg at haxxed.com Tue Apr 25 19:44:31 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 25 Apr 2006 14:44:31 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <20060425152318.24f0497f@duras.int.addix.net> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> Message-ID: <1145994273.22802.121.camel@localhost.localdomain> On Tue, 2006-04-25 at 15:23 +0200, Ralf Ertzinger wrote: > Hi. > > On Tue, 25 Apr 2006 06:19:16 -0700, Michael A. Peters wrote: > > > Does that mean mathml-fonts will get automatically removed out from > > under me? > > It may, which is one of the problems with this approach. Why do people feel the need to argue about problems that were solved years ago? aptitude already provides a very nice interface for this. Its entirely transparent, packages that are flagged auto installed have an "A" flag to the left. This flag can be toggled with a single keystroke. And to top it all off, aptitude gives you a very nice summary of exactly everything its going to do any why before it does it. You can even modify package flags and status right there on the preview page: http://www.haxxed.com/rpms/Screenshot-aptitude.png This is how it should be done. Now either just use aptitude, or implement similar functionality in yumex... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Apr 25 19:48:36 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 25 Apr 2006 14:48:36 -0500 Subject: New Ideas - how about a GUI for /etc/fstab In-Reply-To: <20060425192002.GA3071@wolves.durham.nc.us> References: <20060422174556.GA23589@wolves.durham.nc.us> <1145988143.14889.29.camel@localhost.localdomain> <20060425192002.GA3071@wolves.durham.nc.us> Message-ID: <1145994518.22802.124.camel@localhost.localdomain> On Tue, 2006-04-25 at 15:20 -0400, G.Wolfe Woodbury wrote: > Then are there going to be tools that seek and mount NFS and CIFS/SMB shares > on the network? Hint: Seeking out and mounting file shares through SMB browsing or zeroconf service discovery isn't that much different from hotplugging USB drives. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Apr 25 19:54:36 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 25 Apr 2006 19:54:36 +0000 (UTC) Subject: Fedora core suggestions References: <16de708d0604241416h1dbf402o1f1426ab8254bddf@mail.gmail.com> <1145973415.2748.12.camel@pensja.lam.pl> Message-ID: Leszek Matok Lam.pl> writes: > > Maybe that's just me, but even on my single-user system, I want my VFAT > > partitions mounted at predictable, easy-to-remember locations (/c for C:, /d > > for D:, /e for E: and /f for F:) > 1. You can add any partition to fstab in almost any location you want > (you can't use /dev/null for example, but other than existing files, > you're really free to do what you want). Anaconda has a GUI for it and > it worked every time I tried. I know. This is exactly why I think fstab is a better solution for fixed disks than automounting. What is missing is a GUI tool to edit fstab after installation. I don't need it, but less experienced people would have a use for it. > 2. It's hard or impossible to know which partition is Windows D: and > which is E:, because: > a) newer Windows versions allow you to change the drives letters on the > fly, you'd have to mount the boot partition (and know which one is > that), read some files from it (when the settings are stored), > understand their format and then remount partitions in appropriate > locations, that's hard I guess, and > b) if you have two Windows versions (i.e. 98 and XP), they can see the > drives with different letters, so which one is more important? Which is why I believe letting the user set things up to his/her liking is better than try to automatically guess a location. By definition, fixed disks rarely change, why'd you want to figure out the mount point from scratch again at each boot? (This causes both unnecessary work during bootup and the infamous unpredictable mount points.) I don't mean to offend the people working on automatic mounting, their efforts are very appreciated (having to mount floppies, CDs, USB sticks or whatever by hand after plugging it in is so yesterday), but I think trying to use the same scheme for fixed disks is oversimplifying things. "If all you have is a hammer, every problem starts looking a lot like a nail." Trying to hammer in a screw is a bad idea. ;-) Kevin Kofler From vikasx.aggarwal at intel.com Tue Apr 25 21:31:09 2006 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Tue, 25 Apr 2006 14:31:09 -0700 Subject: corrupt package message during FC5 install from NFS. Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A085EA675@orsmsx408> Hi Paul, I moved onto using FC5 Gold, earlier I was on FC5test3. I am trying to run "anaconda --test -m nfs:/FC5 ". After giving the root password in the installation steps, installer pops same error box again which I used to get with FC5test3. It says -- "Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated. failure: repodata/repomd.xml from anaconda: [Errno 256] No more mirros to try." The contents of FC5 are directly copied from CD{1-5}. I built and installed anaconda from SOURCE.rpm (anaconda-11.0.5). What can be the problem? Appreciate your help. Thanks -vikas aggarwal -----Original Message----- From: Paul Nasrat [mailto:pnasrat at redhat.com] Sent: Friday, April 21, 2006 1:15 PM To: Aggarwal, VikasX Cc: Anaconda-devel-list at redhat.com; fedora-devel-list at redhat.com Subject: RE: corrupt package message during FC5 install from NFS. On Fri, 2006-04-21 at 13:05 -0700, Aggarwal, VikasX wrote: > Thanks !! > Now I have this error for my custom distro. > " Unable to read package metadata. This may be due to a missing > repodata directory. Please ensure that your install tree has been > correctly generated. failure: repodata/repomd.xml from anaconda: [Errno > 256] No more mirros to try." > > I am doing anaconda --test -m nfs:/fedora ls /fedora ls /fedora/repodata I'd expect /fedora/base /fedora/RPMS /fedora/repodata Then repomd.xml primary.xml.gz and some other files in repodata: comps.xml filelists.xml.gz other.xml.gz primary.xml.gz repomd.xml Paul From d.jacobfeuerborn at conversis.de Tue Apr 25 23:22:16 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Wed, 26 Apr 2006 01:22:16 +0200 Subject: Xorg signal 11's spontaneously In-Reply-To: <444E2E03.6040009@redhat.com> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> <444CE442.60506@redhat.com> <444E212F.70606@conversis.de> <444E2851.3030209@conversis.de> <444E2E03.6040009@redhat.com> Message-ID: <444EAF28.2090609@conversis.de> Adam Jackson wrote: > Dennis Jacobfeuerborn wrote: >> Tracked down a testcase using the Xorg changelog but I get a different >> backtrace when triggering that bug so this seems to be a different >> problem. Unfortunately I also didn't get a core dump and I'm not sure >> why. I added the line DAEMON_COREFILE_LIMIT="unlimited" to >> /etc/sysconfig/init and changed the line in /etc/profile to "ulimit -S >> -c unlimited > /dev/null 2>&1" but after crashing X I now no longer >> get a backtrace in the Xorg.log (due to the NoTrapSignal option?) but >> I also don't see a core dump in the home directories. What else do I >> have to do to get a core dump I can feed to gdb? > > IIRC it's something like 'chmod 4755 `which Xorg`' and possibly also run > the server as root, the kernel will try really really hard to not dump > core for suid binaries (rightly so). I set /proc/sys/fs/suid_dumpable to convince the kernel that I really really want a dump anyway but it still doesn't work. Anyway I borrowed a laptop from a friend and have gdb attached to the running Xorg right now waiting for it to crash (hopefully soon, now there is something I don't say very often). Regards, Dennis From rodd at clarkson.id.au Tue Apr 25 22:36:27 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 26 Apr 2006 08:36:27 +1000 Subject: AIGLX questions -- the x86_64 bit question In-Reply-To: References: Message-ID: <1146004587.2802.3.camel@localhost.localdomain> On Fri, 2006-04-21 at 09:48 -0700, alan wrote: > Have the x86_64 problems been resolved? The AIGLX wiki has not been > updated since FC5t3. > > Also, what is the status of the NVIDIA drivers? (I find it weird that XGL > has NVIDIA working but not ATI and AIGLX has ATI working, but not NVIDIA.) XGL and AIGLX work in very different ways. XGL worked inside the existing X framework to achieve it's ends, while AIGLX required some changes to X. NVIDIA is happy to support the changes that AIGLX requires, but won't be getting to it until they release the next version of their driver. I'm as bummed as you are ;-] R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Tue Apr 25 22:54:49 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 26 Apr 2006 08:54:49 +1000 Subject: FC5 rocks! In-Reply-To: <56557.207.35.222.39.1145895251.squirrel@lattica.com> References: <1145312535.16371.51.camel@coyote.rexursive.com> <20060418035409.GP16508@redhat.com> <20060419145947.GA21899@wolff.to> <1145461239.3085.56.camel@laptopd505.fenrus.org> <20060419162248.GB32734@devserv.devel.redhat.com> <6.2.1.2.2.20060424101251.03715eb0@postoffice6.mail.cornell.edu> <33625.207.35.222.39.1145894683.squirrel@lattica.com> <604aa7910604240910p1caaa3c8m4e5bec0285d44818@mail.gmail.com> <56557.207.35.222.39.1145895251.squirrel@lattica.com> Message-ID: <1146005689.2802.7.camel@localhost.localdomain> On Mon, 2006-04-24 at 12:14 -0400, Dimi Paun wrote: > On Mon, April 24, 2006 12:10 pm, Jeff Spaleta said: > >> Especially when we're talking about GNOME. Nothing changed in their > >> elitiste attitude. > > > > You might want to report that problem to upstream. > > No need, I'm certain they are very much aware and proud of it. You know, this is all just a difference of opinion really. Gnome developers (and users) think that a better desktop comes from limiting options and making things simple. KDE developers (and users) think that a better desktop comes from having an option for almost anything you can. Both could be considered elitist attitudes about what's Right and Wrong (TM), but really they are just two different ways to skin the proverbial cat. Get over it and move on. ;-] R. -- "It's a fine line between denial and faith. It's much better on my side" From mpeters at mac.com Wed Apr 26 05:37:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Apr 2006 22:37:45 -0700 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1145994273.22802.121.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> Message-ID: <1146029865.6969.65.camel@atlantis.mpeters.local> On Tue, 2006-04-25 at 14:44 -0500, Callum Lerwick wrote: > On Tue, 2006-04-25 at 15:23 +0200, Ralf Ertzinger wrote: > > Hi. > > > > On Tue, 25 Apr 2006 06:19:16 -0700, Michael A. Peters wrote: > > > > > Does that mean mathml-fonts will get automatically removed out from > > > under me? > > > > It may, which is one of the problems with this approach. > > Why do people feel the need to argue about problems that were solved > years ago? aptitude already provides a very nice interface for this. Its > entirely transparent, packages that are flagged auto installed have an > "A" flag to the left. This flag can be toggled with a single keystroke. > And to top it all off, aptitude gives you a very nice summary of exactly > everything its going to do any why before it does it. You can even > modify package flags and status right there on the preview page: That assumes that the end user knows what a package is and what it does. Say I had no clue that mathml-fonts were needed to properly view the blog of my Physics professor. I might not even know what mathml is. It just works because something else pulled them in as a dependency. Now I remove abiword, and the next time I visit his blog, it does not properly display, and I'm clueless as to why. I think that automatic dependency removal solves a problem that no longer exists when 160 GB hard drives are dirt cheap. The only benefit I see is that with less packages, less bandwidth is needed to keep a system up to date with patches. From hendrik.wiese at siemens.com Wed Apr 26 07:11:26 2006 From: hendrik.wiese at siemens.com (Wiese, Hendrik) Date: Wed, 26 Apr 2006 09:11:26 +0200 Subject: Still much more than 350 sockets needed! Message-ID: Hello again, we still need to know how to increase the maximum number of possible open sockets per IP address! Here we got the problem that no more than 350 sockets are possible. On another Linux (based on LFS) it is no problem to open far more than 5.000 connections on the same way. So we know that it is possible. So how can we break this limitation? Some kind of sysctl? Kernel patch needed? Anything else? It's urgent, so any kind of help would be greatly appreciated. Thanks a lot!!! regards, H. Wiese -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Wed Apr 26 07:13:02 2006 From: buildsys at redhat.com (Build System) Date: Wed, 26 Apr 2006 03:13:02 -0400 Subject: rawhide report: 20060426 changes Message-ID: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> Updated Packages: Xaw3d-1.5E-8 ------------ * Tue Apr 25 2006 Adam Jackson 1.5E-8 - Rebuild for new imake build rules * Tue Feb 28 2006 Than Ngo 1.5E-7 - update Url #183314 beagle-0.2.5-3 -------------- * Fri Apr 21 2006 Alexander Larsson - 0.2.5-3 - Update to 0.2.5 - Update patches cairo-1.1.2-1 ------------- * Tue Apr 25 2006 Carl Worth - 1.1.2-1 - Update to new upstream 1.1.2 - Port forward the embedded bitmaps patch (now committed upstream to 1.1.3) - Drop build-fix and chunk-glyphs patches which now come from upstream cracklib-2.8.9-2 ---------------- * Tue Apr 25 2006 Nalin Dahyabhai - 2.8.9-2 - update to 2.8.9 - only create compat symlinks for the dictionaries if we aren't installing them into the old locations cups-1:1.2-0.5.rc3.2 -------------------- * Tue Apr 25 2006 Tim Waugh 1:1.2-0.5.rc3.2 - Patch pdftops to understand 'includeifexists', and use that in the pdftops.conf file (bug #189809). dbus-0.61-5 ----------- * Tue Apr 25 2006 John (J5) Palmieri - 0.61-5 - Backport patch from dbus-connection.c - Allows interfaces to be NULL in the message header as per the spec - Fixes a problem with pendings calls blocking on a data starved socket ethereal-0.99.0-1 ----------------- * Tue Apr 25 2006 Radek Vok??l 0.99.0-1 - update to 0.99.0 * Tue Apr 25 2006 Radek Vok??l 0.99.0-0.svn.2 - fix crash when tuning columns (#189428) gcc-4.1.0-11 ------------ * Tue Apr 25 2006 Jakub Jelinek 4.1.0-11 - update from gcc-4_1-branch (-r113149:113242) - PRs c/25875, c/26774, fortran/18803, fortran/25597, fortran/25669, fortran/26787, fortran/26822, fortran/26834, fortran/27089, fortran/27113, fortran/27122, fortran/27124, target/21283, target/26961 - fix number of iterations computation (Zdenek Dvorak, #189376, PR tree-optimization/27285) - fix handling of volatile in the inliner (Andrew Pinski, Richard Guenther, PR tree-optimization/27236) - strip useless type conversions in the inliner (Andrew Pinski, Richard Guenther, PR tree-optimization/27218) ghostscript-8.15.2-2 -------------------- * Tue Apr 25 2006 Tim Waugh 8.15.2-2 - 8.15.2. - No longer need build, krgb, pdfwrite, str1570 patches. glibc-2.4.90-1 -------------- * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 - update from CVS * Mon Apr 24 2006 Jakub Jelinek 2.4-6 - update from CVS - NIS+ fixes - don't segfault on too large argp key values (#189545) - getaddrinfo fixes for RFC3484 (#188364) gnome-power-manager-2.15.1-1 ---------------------------- * Tue Apr 25 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 gnome-terminal-2.14.1-11 ------------------------ * Tue Apr 25 2006 Kristian H??gsberg 2.14.1-11 - Bump for rawhide build. * Tue Apr 25 2006 Kristian H??gsberg - 2.14.1-10 - Fix selection atom name intialization (patch from Kjartan Maaras). - Lower vte requirement to 0.12.0-2 which is what fc5-bling has. imake-1.0.1-4 ------------- * Tue Apr 25 2006 Adam Jackson 1.0.1-4 - Fix ExtraXawReqs to reflect reality (libXp is unneeded) isdn4k-utils-3.2-45 ------------------- * Tue Apr 25 2006 Adam Jackson 3.2-45 - Rebuild for updated imake build rules * Tue Apr 25 2006 Than Ngo 3.2-44 - add capi service kde-i18n-1:3.5.2-3 ------------------ * Tue Apr 25 2006 Than Ngo 1:3.5.2-3 - add kde-i18n-Lithuanian kernel-2.6.16-1.2157_FC6 ------------------------ * Tue Apr 25 2006 David Woodhouse - Drop the last remnants of the 'make bzImage on all arches' silliness netdump-0.7.16-1 ---------------- * Tue Apr 25 2006 Thomas Graf - 0.7.16-1 - update to version 0.7.16 pam-0.99.3.0-3 -------------- * Tue Apr 25 2006 Tomas Mraz 0.99.3.0-3 - added pam_namespace module written by Janak Desai (per-user /tmp support) - new pam-redhat modules version * Fri Feb 24 2006 Tomas Mraz 0.99.3.0-2 - added try_first_pass option to pam_cracklib - use try_first_pass for pam_unix and pam_cracklib in system-auth (#182350) * Fri Feb 10 2006 Jesse Keating - 0.99.3.0-1.2 - bump again for double-long bug on ppc(64) pm-utils-0.18-1 --------------- * Tue Apr 25 2006 Peter Jones - 0.18-1 - Make it work cross-distro rhythmbox-0.9.4.1-2 ------------------- * Tue Apr 25 2006 Matthias Clasen - 0.9.4.1-2 - Update to 0.9.4.1 rpm-4.4.2-19 ------------ * Tue Apr 25 2006 Paul Nasrat - 4.4.2-19 - Add --trusted stubs from upstream selinux-policy-2.2.35-2 ----------------------- * Tue Apr 25 2006 James Antill 2.2.35-2 - Add xm policy - Fix policygentool * Mon Apr 24 2006 Dan Walsh 2.2.35-1 - Update to upstream - Fix postun to only disable selinux on full removal of the packages tar-1.15.90-2 ------------- * Tue Apr 25 2006 Peter Vrabec 1.15.90-2 - exclude listed02.at from testsuite again, because it still fails on s390 * Tue Apr 25 2006 Peter Vrabec 1.15.90-1 - upgrade wpa_supplicant-1:0.4.8-9.fc6 ---------------------------- * Tue Apr 25 2006 Dan Williams - 0.4.8-9 - Enable Wired driver, PKCS12, and Smartcard options (#rh189805#) * Tue Apr 11 2006 Dan Williams - 0.4.8-8 - Fix control interface key obfuscation a bit xfig-3.2.4-19 ------------- * Tue Apr 25 2006 Adam Jackson 3.2.4-19 - Rebuild for updated imake build rules xorg-x11-server-utils-1.0.1-3 ----------------------------- * Tue Apr 25 2006 Adam Jackson 1.0.1-3 - Eliminate a spurious Xprint dependency from xset. xorg-x11-utils-1.0.1-2 ---------------------- * Tue Apr 25 2006 Adam Jackson 1.0.1-2 - Remove a spurious Xprint dependency from xdpyinfo. * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From lists at dresco.co.uk Wed Apr 26 07:31:41 2006 From: lists at dresco.co.uk (Jon Escombe) Date: Wed, 26 Apr 2006 07:31:41 +0000 (UTC) Subject: ipw3945 packaging Message-ID: I've been looking at what would be involved in packaging the Intel 3945 wireless driver. The biggest obstacle appears to be the requirement for updated ieee80211 files[1]. Are there any plans to merge these updates into the FC5 kernel? And, if so, any plans for a ipw3945 driver package from Fedora? Note I am talking about the open source driver only - the firmware and regulatory daemon would of course still be out of bounds for Fedora. Regards, Jon. [1] ATrpms is the only 3rd party repo with a full package at the moment, and they've done it by replacing the shipped ieee80211 kernel modules - something that the 'better behaved' 3rd party repositories won't do... From tmus at tmus.dk Wed Apr 26 08:10:37 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 26 Apr 2006 10:10:37 +0200 Subject: firefox miniicon has extra black pixels In-Reply-To: References: Message-ID: Leon wrote: > Dear all, > > I attach two screenshots of firefox in SuSE 9.3 and FC5. It seems the > mini icon of firefox in FC5 has an ugly black line along the bottom and > right-hand side of the icon. > > I think this might be a very small bug. > Just looks like a different icon to me, which could be expected since those are completely different distros released with a loong time between them. /Thomas From tmus at tmus.dk Wed Apr 26 08:47:59 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 26 Apr 2006 10:47:59 +0200 Subject: Still much more than 350 sockets needed! In-Reply-To: References: Message-ID: Wiese, Hendrik wrote: > Hello again, > > we still need to know how to increase the maximum number of > possible open sockets per IP address! Here we got the problem > that no more than 350 sockets are possible. On another Linux > (based on LFS) it is no problem to open far more than 5.000 > connections on the same way. So we know that it is possible. > So how can we break this limitation? Some kind of sysctl? > Kernel patch needed? Anything else? > > It's urgent, so any kind of help would be greatly appreciated. > > Thanks a lot!!! > > regards, > H. Wiese > My /proc/net/sockstat says that i have 541 used sockets on a standard laptop??? could you a simplified version of the code to create all these sockets the way you do it? That would allow perhaps more people to understand the problem/see for themselves. /Thomas From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 26 09:17:04 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 26 Apr 2006 11:17:04 +0200 Subject: ipw3945 packaging In-Reply-To: References: Message-ID: <20060426111704.4e1d8df6@python2> Jon Escombe wrote : > I've been looking at what would be involved in packaging the Intel 3945 wireless > driver. The biggest obstacle appears to be the requirement for updated ieee80211 > files[1]. Are there any plans to merge these updates into the FC5 kernel? And, > if so, any plans for a ipw3945 driver package from Fedora? > > Note I am talking about the open source driver only - the firmware and > regulatory daemon would of course still be out of bounds for Fedora. > > Regards, > Jon. > > [1] ATrpms is the only 3rd party repo with a full package at the moment, and > they've done it by replacing the shipped ieee80211 kernel modules - something > that the 'better behaved' 3rd party repositories won't do... Apart from either convincing the Fedora kernel packagers to patch the current ieee80211 module in the rawhide kernels (not likely, but could happen if one of them owns the hardware for instance) or waiting for a recent enough version to go into the upstream kernel sources, I think you're pretty much stuck. I've packaged the firmware and daemon on freshrpms.net too, but decided that "you're on your own" for the kernel modules part for now... not sure which is worst between my approach and Axel's, though :-) The proper way to fix this issue is to get the ieee80211 modules updated upstream anyway. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2147_FC6 Load : 0.22 0.20 0.19 From Axel.Thimm at ATrpms.net Wed Apr 26 09:26:59 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Apr 2006 11:26:59 +0200 Subject: ipw3945 packaging In-Reply-To: <20060426111704.4e1d8df6@python2> References: <20060426111704.4e1d8df6@python2> Message-ID: <20060426092659.GE17533@neu.nirvana> On Wed, Apr 26, 2006 at 11:17:04AM +0200, Matthias Saou wrote: > Jon Escombe wrote : > > > I've been looking at what would be involved in packaging the Intel 3945 wireless > > driver. The biggest obstacle appears to be the requirement for updated ieee80211 > > files[1]. Are there any plans to merge these updates into the FC5 kernel? And, > > if so, any plans for a ipw3945 driver package from Fedora? > > > > Note I am talking about the open source driver only - the firmware and > > regulatory daemon would of course still be out of bounds for Fedora. > > > > Regards, > > Jon. > > > > [1] ATrpms is the only 3rd party repo with a full package at the moment, and > > they've done it by replacing the shipped ieee80211 kernel modules - something > > that the 'better behaved' 3rd party repositories won't do... They only get "replaced" (which they don't, but anyway ...) if you explicity ask them to. A yum upgrade will not "replace" any kernel module bit ... ATrpms just offers an *optional* set of packages that don't get automatically installed for those people having ipw3945 hardware and wanting to get it run under FC and RHEL. What exactly is not "well behaved"? As you noted yourself, if you want to run this hardware you will *need* to "replace" ieee80211 (which they are not ...). And did I mention it only happens on a voluntarily basis invoked by the user sitting in front of his keyboard? Please be careful with characterizations about "well behaved", it may turn out that the only thing not "well behavied" is the statement itself. > Apart from either convincing the Fedora kernel packagers to patch > the current ieee80211 module in the rawhide kernels (not likely, but > could happen if one of them owns the hardware for instance) or > waiting for a recent enough version to go into the upstream kernel > sources, I think you're pretty much stuck. I've packaged the > firmware and daemon on freshrpms.net too, but decided that "you're > on your own" for the kernel modules part for now... not sure which > is worst between my approach and Axel's, though :-) What use is it w/o the kernel modules? It's like if you had packaged alsa-libs w/o packaging the kernel modules at RH9 time (or whenever the RH kernels didn't have alsa bits in them, RH9 is just a guess). > The proper way to fix this issue is to get the ieee80211 modules updated > upstream anyway. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 26 09:46:00 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 26 Apr 2006 11:46:00 +0200 Subject: ipw3945 packaging In-Reply-To: <20060426092659.GE17533@neu.nirvana> References: <20060426111704.4e1d8df6@python2> <20060426092659.GE17533@neu.nirvana> Message-ID: <20060426114600.7a39c83d@python2> Axel Thimm wrote : > > Apart from either convincing the Fedora kernel packagers to patch > > the current ieee80211 module in the rawhide kernels (not likely, but > > could happen if one of them owns the hardware for instance) or > > waiting for a recent enough version to go into the upstream kernel > > sources, I think you're pretty much stuck. I've packaged the > > firmware and daemon on freshrpms.net too, but decided that "you're > > on your own" for the kernel modules part for now... not sure which > > is worst between my approach and Axel's, though :-) > > What use is it w/o the kernel modules? It's like if you had packaged > alsa-libs w/o packaging the kernel modules at RH9 time (or whenever > the RH kernels didn't have alsa bits in them, RH9 is just a guess). It gets users half the way, which is better than nothing. > > The proper way to fix this issue is to get the ieee80211 modules updated > > upstream anyway. ...and when that happens, with also the possible inclusion of the ipw3945 module, freshrpms.net will already be ready. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2147_FC6 Load : 0.09 0.26 0.34 From n0dalus+redhat at gmail.com Wed Apr 26 09:46:52 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 26 Apr 2006 19:16:52 +0930 Subject: firefox miniicon has extra black pixels In-Reply-To: References: Message-ID: <6280325c0604260246p1941e83cq5bbc80373c04af35@mail.gmail.com> On 4/26/06, Thomas M Steenholdt wrote: > > Just looks like a different icon to me, which could be expected since > those are completely different distros released with a loong time > between them. The Firefox tarballs have the proper icon, but ever since December 2004 it's been being replaced in Fedora's source rpm. I think this could have been done to make the xpm more seperate, but they must have used a really ancient xpm to do it. Instead of bundling an xpm with the source rpm, the spec should be copying the xpm from the firefox official icon directory in the tarball. I'd say it's almost certainly a bug, and I suppose should be filed if it's not in bugzilla already. n0dalus. From hendrik.wiese at siemens.com Wed Apr 26 11:49:15 2006 From: hendrik.wiese at siemens.com (Wiese, Hendrik) Date: Wed, 26 Apr 2006 13:49:15 +0200 Subject: AW: Still much more than 350 sockets needed! Message-ID: > > > Hello again, > > > > we still need to know how to increase the maximum number of > > possible open sockets per IP address! Here we got the problem > > that no more than 350 sockets are possible. On another Linux > > (based on LFS) it is no problem to open far more than 5.000 > > connections on the same way. So we know that it is possible. > > So how can we break this limitation? Some kind of sysctl? > > Kernel patch needed? Anything else? > > > > It's urgent, so any kind of help would be greatly appreciated. > > > > Thanks a lot!!! > > > > regards, > > H. Wiese > > > > My /proc/net/sockstat says that i have 541 used sockets on a standard > laptop??? > > could you a simplified version of the code to create all these sockets > the way you do it? > > That would allow perhaps more people to understand the problem/see for > themselves. > > /Thomas Please try to open that many tcp connections between two IPs and tell me if it works! Finding out in which way our software opens the sockets would be enough work for two persons for at least two days. It's old software we try to get running on a new system. Very (very very) old sources! ;) Some guy told me that maybe iptables is the cause of this problem. You think he's right? We have to verify that. May take a few days since the collegue responsible for this isn't in the office right now. Just that much about "it's urgent" (my team leader's definition). *laugh* Thanks for your interest in this problem. I'll keep you up to date. Hendrik From aph at redhat.com Wed Apr 26 12:51:58 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Apr 2006 13:51:58 +0100 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: Message-ID: <17487.27886.76252.698013@zapata.pink> Wiese, Hendrik writes: > > > > > Hello again, > > > > > > we still need to know how to increase the maximum number of > > > possible open sockets per IP address! Here we got the problem > > > that no more than 350 sockets are possible. On another Linux > > > (based on LFS) it is no problem to open far more than 5.000 > > > connections on the same way. So we know that it is possible. > > > So how can we break this limitation? Some kind of sysctl? > > > Kernel patch needed? Anything else? > > > > > > It's urgent, so any kind of help would be greatly appreciated. > > > > > > Thanks a lot!!! > > > > > > regards, > > > H. Wiese > > > > > > > My /proc/net/sockstat says that i have 541 used sockets on a standard > > laptop??? > > > > could you a simplified version of the code to create all these sockets > > > the way you do it? > > > > That would allow perhaps more people to understand the problem/see for > > > themselves. > > > > /Thomas > > Please try to open that many tcp connections between two IPs and tell me > if it works! Try it yourself. I reckon you'll run out of file descriptors before you hit a socket limit. To do any more you'll have to fork() in the server and client. Andrew. #include #include #include #include #include #include #include #include int main (int argc, char *argv[]) { struct sockaddr_in sock, work; int wsd, sd; int addlen; int rv; sd = socket (AF_INET, SOCK_STREAM, 0); if (sd == -1) { perror ("No socket"); exit (1); } sock.sin_family = AF_INET; sock.sin_port = htons (5000); sock.sin_addr.s_addr = INADDR_ANY; rv = bind (sd, (struct sockaddr *) &sock, sizeof (struct sockaddr_in)); if (rv == -1) { perror ("Bad Bind"); exit (1); } rv = listen (sd, 2); if (rv == -1) { perror ("Bad listen"); exit (1); } int i; for (i = 0;; i++) { wsd = accept (sd, (struct sockaddr *) &work, &addlen); fprintf (stdout, "Connection %d\n", i); } while (1); } #include #include #include #include #include #include #include #include #include int main (int argc, char *argv[]) { struct sockaddr_in sock; int sd; int addlen; int rv; while (1) { sd = socket (AF_INET, SOCK_STREAM, 0); if (sd == -1) { perror ("No socket"); exit (1); } sock.sin_family = AF_INET; sock.sin_port = htons (5000); sock.sin_addr.s_addr = inet_addr("127.0.0.1"); rv = connect (sd, (struct sockaddr *) &sock, sizeof (struct sockaddr_in)); if (rv == -1) { perror ("Bad Connect"); exit (1); } } } From katzj at redhat.com Wed Apr 26 15:08:27 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Apr 2006 11:08:27 -0400 Subject: ipw3945 packaging In-Reply-To: References: Message-ID: <1146064107.16554.32.camel@orodruin.boston.redhat.com> On Wed, 2006-04-26 at 07:31 +0000, Jon Escombe wrote: > I've been looking at what would be involved in packaging the Intel 3945 wireless > driver. The biggest obstacle appears to be the requirement for updated ieee80211 > files[1]. Actually, it's easy enough to pull the two or three functions needed from the updated ieee80211 stack and make them private to the driver. It then builds and works fine. > Are there any plans to merge these updates into the FC5 kernel? And, > if so, any plans for a ipw3945 driver package from Fedora? The answer as always for drivers in the main kernel package is "get it upstream". And for better or worse, I think that the regulatory daemon is likely to be a big sticking point for the driver going upstream :( Jeremy From ellson at research.att.com Wed Apr 26 15:51:31 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 26 Apr 2006 11:51:31 -0400 Subject: CAUTION: Breaks sshd! [Re: rawhide report: 20060426 changes] In-Reply-To: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> References: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> Message-ID: <444F9703.40000@research.att.com> Build System wrote: > > > > glibc-2.4.90-1 > -------------- > * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 > - update from CVS > > * Mon Apr 24 2006 Jakub Jelinek 2.4-6 > - update from CVS > - NIS+ fixes > - don't segfault on too large argp key values (#189545) > - getaddrinfo fixes for RFC3484 (#188364) > > CAUTION!! This update breaks sshd for me on i386 and x86_64. Reverting to glibc-2.4-5 fixes the problem. I will file a bug report momentarily...... John From Axel.Thimm at ATrpms.net Wed Apr 26 15:58:19 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Apr 2006 17:58:19 +0200 Subject: ipw3945 packaging In-Reply-To: <1146064107.16554.32.camel@orodruin.boston.redhat.com> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> Message-ID: <20060426155819.GA12750@neu.nirvana> On Wed, Apr 26, 2006 at 11:08:27AM -0400, Jeremy Katz wrote: > The answer as always for drivers in the main kernel package is "get it > upstream". And for better or worse, I think that the regulatory daemon > is likely to be a big sticking point for the driver going upstream :( It sounded like this was more liked than the firmware approach. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Apr 26 16:00:16 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Apr 2006 12:00:16 -0400 Subject: ipw3945 packaging In-Reply-To: <20060426155819.GA12750@neu.nirvana> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> Message-ID: <1146067216.16554.54.camel@orodruin.boston.redhat.com> On Wed, 2006-04-26 at 17:58 +0200, Axel Thimm wrote: > On Wed, Apr 26, 2006 at 11:08:27AM -0400, Jeremy Katz wrote: > > The answer as always for drivers in the main kernel package is "get it > > upstream". And for better or worse, I think that the regulatory daemon > > is likely to be a big sticking point for the driver going upstream :( > > It sounded like this was more liked than the firmware approach. By who? I read exactly the opposite :) Jeremy From ellson at research.att.com Wed Apr 26 16:01:17 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 26 Apr 2006 12:01:17 -0400 Subject: CAUTION: Breaks sshd! [Re: rawhide report: 20060426 changes] In-Reply-To: <444F9703.40000@research.att.com> References: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> <444F9703.40000@research.att.com> Message-ID: <444F994D.5000507@research.att.com> John Ellson wrote: > Build System wrote: >> >> >> >> glibc-2.4.90-1 >> -------------- >> * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 >> - update from CVS >> >> * Mon Apr 24 2006 Jakub Jelinek 2.4-6 >> - update from CVS >> - NIS+ fixes >> - don't segfault on too large argp key values (#189545) >> - getaddrinfo fixes for RFC3484 (#188364) >> >> > > > CAUTION!! This update breaks sshd for me on i386 and x86_64. > > Reverting to glibc-2.4-5 fixes the problem. > > > I will file a bug report momentarily...... > > > John > Reported as BZ# 19003 John From jvdias at redhat.com Wed Apr 26 16:05:17 2006 From: jvdias at redhat.com (Jason Vas Dias) Date: Wed, 26 Apr 2006 12:05:17 -0400 Subject: CAUTION: Breaks sshd! [Re: rawhide report: 20060426 changes] In-Reply-To: <444F9703.40000@research.att.com> References: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> <444F9703.40000@research.att.com> Message-ID: <200604261205.17640.jvdias@redhat.com> On Wednesday 26 April 2006 11:51, John Ellson wrote: > Build System wrote: > > > > > > > > glibc-2.4.90-1 > > -------------- > > * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 > > - update from CVS > > > > * Mon Apr 24 2006 Jakub Jelinek 2.4-6 > > - update from CVS > > - NIS+ fixes > > - don't segfault on too large argp key values (#189545) > > - getaddrinfo fixes for RFC3484 (#188364) > > > > > > > CAUTION!! This update breaks sshd for me on i386 and x86_64. > > Reverting to glibc-2.4-5 fixes the problem. > > > I will file a bug report momentarily...... > > > John > glibc-2.4.90-1 and sshd works fine for me . Could it be an issue with the new pam-0.99.3.0-3, which installs its new system-auth as /etc/pam.d/system-auth.rpmnew ? I copied this to /etc/pam.d/system-auth-ac and reran authconfig - all works OK for me. Regards, Jason From Axel.Thimm at ATrpms.net Wed Apr 26 16:07:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Apr 2006 18:07:17 +0200 Subject: ipw3945 packaging In-Reply-To: <1146067216.16554.54.camel@orodruin.boston.redhat.com> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> Message-ID: <20060426160717.GB12750@neu.nirvana> On Wed, Apr 26, 2006 at 12:00:16PM -0400, Jeremy Katz wrote: > On Wed, 2006-04-26 at 17:58 +0200, Axel Thimm wrote: > > On Wed, Apr 26, 2006 at 11:08:27AM -0400, Jeremy Katz wrote: > > > The answer as always for drivers in the main kernel package is "get it > > > upstream". And for better or worse, I think that the regulatory daemon > > > is likely to be a big sticking point for the driver going upstream :( > > > > It sounded like this was more liked than the firmware approach. > > By who? I read exactly the opposite :) I read an article by thl on heise.de (in german), where it was supposed to be considered better that propriatry kernel stuff or. Maybe I should check the original tone. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Wed Apr 26 16:14:27 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 26 Apr 2006 18:14:27 +0200 Subject: ipw3945 packaging In-Reply-To: <20060426160717.GB12750@neu.nirvana> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> <20060426160717.GB12750@neu.nirvana> Message-ID: <1146068068.7016.19.camel@laptopd505.fenrus.org> On Wed, 2006-04-26 at 18:07 +0200, Axel Thimm wrote: > On Wed, Apr 26, 2006 at 12:00:16PM -0400, Jeremy Katz wrote: > > On Wed, 2006-04-26 at 17:58 +0200, Axel Thimm wrote: > > > On Wed, Apr 26, 2006 at 11:08:27AM -0400, Jeremy Katz wrote: > > > > The answer as always for drivers in the main kernel package is "get it > > > > upstream". And for better or worse, I think that the regulatory daemon > > > > is likely to be a big sticking point for the driver going upstream :( > > > > > > It sounded like this was more liked than the firmware approach. > > > > By who? I read exactly the opposite :) > > I read an article by thl on heise.de (in german), where it was > supposed to be considered better that propriatry kernel stuff > or. Maybe I should check the original tone. proprietary kernel stuff != firmware :) From Axel.Thimm at ATrpms.net Wed Apr 26 16:18:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Apr 2006 18:18:18 +0200 Subject: ipw3945 packaging In-Reply-To: <1146068068.7016.19.camel@laptopd505.fenrus.org> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> <20060426160717.GB12750@neu.nirvana> <1146068068.7016.19.camel@laptopd505.fenrus.org> Message-ID: <20060426161818.GC12750@neu.nirvana> On Wed, Apr 26, 2006 at 06:14:27PM +0200, Arjan van de Ven wrote: > On Wed, 2006-04-26 at 18:07 +0200, Axel Thimm wrote: > > On Wed, Apr 26, 2006 at 12:00:16PM -0400, Jeremy Katz wrote: > > > On Wed, 2006-04-26 at 17:58 +0200, Axel Thimm wrote: > > > > On Wed, Apr 26, 2006 at 11:08:27AM -0400, Jeremy Katz wrote: > > > > > The answer as always for drivers in the main kernel package is "get it > > > > > upstream". And for better or worse, I think that the regulatory daemon > > > > > is likely to be a big sticking point for the driver going upstream :( > > > > > > > > It sounded like this was more liked than the firmware approach. > > > > > > By who? I read exactly the opposite :) > > > > I read an article by thl on heise.de (in german), where it was > > supposed to be considered better that propriatry kernel stuff > > or. Maybe I should check the original tone. > > proprietary kernel stuff != firmware :) sorry, I'll take it back. I found the article (for German readers): http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/70092&words=ipw3945 and the quote was from Dax Kelson: http://article.gmane.org/gmane.linux.network/32622 So, indeed no love for ipw3945. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ellson at research.att.com Wed Apr 26 16:48:31 2006 From: ellson at research.att.com (John Ellson) Date: Wed, 26 Apr 2006 12:48:31 -0400 Subject: CAUTION: Breaks sshd! [Re: rawhide report: 20060426 changes] In-Reply-To: <200604261205.17640.jvdias@redhat.com> References: <200604260713.k3Q7D2FP004430@porkchop.devel.redhat.com> <444F9703.40000@research.att.com> <200604261205.17640.jvdias@redhat.com> Message-ID: <444FA45F.6040309@research.att.com> Jason Vas Dias wrote: > On Wednesday 26 April 2006 11:51, John Ellson wrote: > >> Build System wrote: >> > >> > >> > >> > glibc-2.4.90-1 >> > -------------- >> > * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 >> > - update from CVS >> > >> > * Mon Apr 24 2006 Jakub Jelinek 2.4-6 >> > - update from CVS >> > - NIS+ fixes >> > - don't segfault on too large argp key values (#189545) >> > - getaddrinfo fixes for RFC3484 (#188364) >> > >> > >> >> >> CAUTION!! This update breaks sshd for me on i386 and x86_64. >> >> Reverting to glibc-2.4-5 fixes the problem. >> >> >> I will file a bug report momentarily...... >> >> >> John >> > > > glibc-2.4.90-1 and sshd works fine for me . > Could it be an issue with the new pam-0.99.3.0-3, which > installs its new system-auth as /etc/pam.d/system-auth.rpmnew ? > I copied this to /etc/pam.d/system-auth-ac and reran authconfig - > all works OK for me. > > Regards, > Jason > I don't see a /etc/pam.d/system-auth.rpmnew I had previously tried downgrading pam to see if that fixed it for me, and it didn't. I then re-upgraded it. Its possible I lost the .rpmnew in the shuffle. John From lamont at gurulabs.com Wed Apr 26 16:59:24 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 26 Apr 2006 10:59:24 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: Message-ID: <200604261059.24311.lamont@gurulabs.com> On Wednesday 26 April 2006 05:49am, Wiese, Hendrik wrote: [snip] > Some guy told me that maybe iptables is the cause of this problem. You > think he's right? I don't see how that could be, so I'll say, "No. Not a chance." That just doesn't make sense. But, if you want to test it to be sure, then flush out everything and unload the "ipt_*" kernel modules. > We have to verify that. May take a few days since the > collegue responsible for this isn't in the office right now. Just that > much about "it's urgent" (my team leader's definition). *laugh* Yup. Been there, done that. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lists at dresco.co.uk Wed Apr 26 17:53:36 2006 From: lists at dresco.co.uk (Jon Escombe) Date: Wed, 26 Apr 2006 17:53:36 +0000 (UTC) Subject: ipw3945 packaging References: <20060426111704.4e1d8df6@python2> <20060426092659.GE17533@neu.nirvana> Message-ID: Axel Thimm ATrpms.net> writes: > ATrpms just offers an *optional* set of packages that don't get > automatically installed for those people having ipw3945 hardware and > wanting to get it run under FC and RHEL. What exactly is not "well > behaved"? As you noted yourself, if you want to run this hardware you > will *need* to "replace" ieee80211 (which they are not ...). And did I > mention it only happens on a voluntarily basis invoked by the user > sitting in front of his keyboard? > > Please be careful with characterizations about "well behaved", it may > turn out that the only thing not "well behavied" is the statement > itself. Apologies, no offense intended. By 'better behaved' I was referring to the rpmforge approach of not "messing with files installed by kernel and kernel-devel packages". Perhaps a poor choice of words.. ;/ I understand the necessity to update the iee80211 modules to make this work, and I do appreciate the packages you have created. I was simply inquiring whether we could get these changes into the Fedora kernel to make life easier for everyone... Regards, Jon. From tmus at tmus.dk Wed Apr 26 18:50:29 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 26 Apr 2006 20:50:29 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <17487.27886.76252.698013@zapata.pink> References: <17487.27886.76252.698013@zapata.pink> Message-ID: Andrew Haley wrote: > Wiese, Hendrik writes: > > > > > > > Hello again, > > > > > > > > we still need to know how to increase the maximum number of > > > > possible open sockets per IP address! Here we got the problem > > > > that no more than 350 sockets are possible. On another Linux > > > > (based on LFS) it is no problem to open far more than 5.000 > > > > connections on the same way. So we know that it is possible. > > > > So how can we break this limitation? Some kind of sysctl? > > > > Kernel patch needed? Anything else? > > > > > > > > It's urgent, so any kind of help would be greatly appreciated. > > > > > > > > Thanks a lot!!! > > > > > > > > regards, > > > > H. Wiese > > > > > > > > > > My /proc/net/sockstat says that i have 541 used sockets on a standard > > > laptop??? > > > > > > could you a simplified version of the code to create all these sockets > > > > > the way you do it? > > > > > > That would allow perhaps more people to understand the problem/see for > > > > > themselves. > > > > > > /Thomas > > > > Please try to open that many tcp connections between two IPs and tell me > > if it works! > > Try it yourself. I reckon you'll run out of file descriptors before > you hit a socket limit. To do any more you'll have to fork() in the > server and client. > > Andrew. > Well... I get way past 350 with these two test processes... Got to 1020, then the process bailed with : No socket: Too many open files /Thomas From aph at redhat.com Wed Apr 26 18:56:22 2006 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Apr 2006 19:56:22 +0100 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: <17487.27886.76252.698013@zapata.pink> Message-ID: <17487.49750.664511.86829@zapata.pink> Thomas M Steenholdt writes: > Andrew Haley wrote: > > Wiese, Hendrik writes: > > > > > > > > > Hello again, > > > > > > > > > > we still need to know how to increase the maximum number of > > > > > possible open sockets per IP address! Here we got the problem > > > > > that no more than 350 sockets are possible. On another Linux > > > > > (based on LFS) it is no problem to open far more than 5.000 > > > > > connections on the same way. So we know that it is possible. > > > > > So how can we break this limitation? Some kind of sysctl? > > > > > Kernel patch needed? Anything else? > > > > > > > > > > It's urgent, so any kind of help would be greatly appreciated. > > > > > > Please try to open that many tcp connections between two IPs and tell me > > > if it works! > > > > Try it yourself. I reckon you'll run out of file descriptors before > > you hit a socket limit. To do any more you'll have to fork() in the > > server and client. > > Well... > > I get way past 350 with these two test processes... > Got to 1020, then the process bailed with : > No socket: Too many open files So, there you go. Whoever said that no more than 350 sockets are possible was mistaken. :-) Andrew. From lamont at gurulabs.com Wed Apr 26 19:13:46 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 26 Apr 2006 13:13:46 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <17487.27886.76252.698013@zapata.pink> References: <17487.27886.76252.698013@zapata.pink> Message-ID: <200604261313.51488.lamont@gurulabs.com> On Wednesday 26 April 2006 06:51am, Andrew Haley wrote: > Wiese, Hendrik writes: [snip] > > Please try to open that many tcp connections between two IPs and tell me > > if it works! > > Try it yourself. I reckon you'll run out of file descriptors before > you hit a socket limit. To do any more you'll have to fork() in the > server and client. [snip] I tried out that simple on my notebook (FC5) and on a pair of SLES9 test boxes. In both cases, the client ran out of file descriptors to open sockets after opening 1020 (on my notebook) and 1021 (on the SLES9 boxes) simultaneous connections. The exact error message when the client dies is "No socket: Too many open files". On my notebook, I ran the tests over loopback, so both the client and server had a connection at the same time. I checked on my notebook and there were 32 network sockets open before (and after) the test that had nothing to do with the test. So, it starts to look like the client is being stopped from opening more file handles, simultaneously. I reran the multi-host test using a second client to simultaneously connect to the same server. The server never dies (I'm running the server unprivileged, too). The clients both died at the same point as before. The next test was one client connecting to two servers. The result was that one server got 510 connections and the other got 511 before the client died. Seems to reinforce the theory that the client isn't being allowed any more file handles than 1024 total (remember handles 0, 1 & 2 are stdin, stdout & stderr, respectively). The last test I ran was to repeat the one client -> two servers test, running the client as root. The result was the same as running the client as an unprivileged user. So, let's take a look at /proc/sys/fs/: nothing obvious there. The next thing I would do is to look for other /proc/sys/ parameters that indicate a limit of 1024 open file handles for the process, but, I've already spent 20 minutes on this and I have other things to finish up today. At this point, I have to think that the problem Hendrik Wiese is reporting (they're system is limited to only 350 simultaneous connections between two IPs) is due to either a lack of memory, the client already has lots of open file handles or a bug in the client code (which is impossible for me to determine without looking at that code). Personally, no.2 feels the most likely. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Wed Apr 26 19:15:12 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 26 Apr 2006 13:15:12 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: <17487.27886.76252.698013@zapata.pink> Message-ID: <200604261315.13247.lamont@gurulabs.com> On Wednesday 26 April 2006 12:50pm, Thomas M Steenholdt wrote: > Andrew Haley wrote: [snip] > Well... > > I get way past 350 with these two test processes... > Got to 1020, then the process bailed with : > No socket: Too many open files You had 1021 sockets. I didn't immediately notice that the counting started at 0, either. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galibert at pobox.com Wed Apr 26 20:17:27 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 26 Apr 2006 22:17:27 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604261315.13247.lamont@gurulabs.com> References: <17487.27886.76252.698013@zapata.pink> <200604261315.13247.lamont@gurulabs.com> Message-ID: <20060426201727.GA64153@dspnet.fr.eu.org> On Wed, Apr 26, 2006 at 01:15:12PM -0600, Lamont R. Peterson wrote: > On Wednesday 26 April 2006 12:50pm, Thomas M Steenholdt wrote: > > Andrew Haley wrote: > [snip] > > Well... > > > > I get way past 350 with these two test processes... > > Got to 1020, then the process bailed with : > > No socket: Too many open files > > You had 1021 sockets. I didn't immediately notice that the counting started > at 0, either. 1021+stdin+stdout+stderr = 1024, which is the default "descriptors" limit. If you're root, you can raise it to up to 1048576 (1024*1024). Not sure why it stops there, but I suspect that it's quite enough for the time being (1024 is a tad small to my taste for a default, but that's another problem entirely). OG. From Lam at Lam.pl Wed Apr 26 20:18:26 2006 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 26 Apr 2006 22:18:26 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604261315.13247.lamont@gurulabs.com> References: <17487.27886.76252.698013@zapata.pink> <200604261315.13247.lamont@gurulabs.com> Message-ID: <1146082706.4967.16.camel@pensja.lam.pl> Dnia 26-04-2006, ?ro o godzinie 13:15 -0600, Lamont R. Peterson napisa?(a): > You had 1021 sockets. Plus 3 other open descriptors (stdin, stdout, stderr), which make 1024. As root you can type: limit descriptors 1048576 which is the hard limit for root under FC5. But even as root I get the soft limit set to 1024 when I do su - by default. Maybe the discussion grandparent was running a program which uses 3 open descriptors for every connection (separate logfiles for every connection, probably? Separate "control" and "data" connections, as in FTP?) and on another distro he was getting bigger default soft limit for root? Now my question. It's impossible to make 5000 connections as user under Fedora. Can I change it? I thought it's controlled by #define OPEN_MAX in kernel source (I guess it means files not file descriptors then), but kernel-devel's limit.h has OPEN_MAX set to 256 and everyone here confirms the limit is truly 1024, which is fs.h's INR_OPEN (and root's hard limit is NR_OPEN). Does that mean the 1024 open connections are kernel maximum changed only at compile time and there's no sysctl for it? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From lamont at gurulabs.com Wed Apr 26 20:34:55 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 26 Apr 2006 14:34:55 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <1146082706.4967.16.camel@pensja.lam.pl> References: <200604261315.13247.lamont@gurulabs.com> <1146082706.4967.16.camel@pensja.lam.pl> Message-ID: <200604261434.59704.lamont@gurulabs.com> On Wednesday 26 April 2006 02:18pm, Leszek Matok wrote: > Dnia 26-04-2006, ?ro o godzinie 13:15 -0600, Lamont R. Peterson > > napisa?(a): > > You had 1021 sockets. > > Plus 3 other open descriptors (stdin, stdout, stderr), which make 1024. Yes, as I pointed out in the other email in this thread, which is why I didn't elaborate here. Sorry for any confusion. > As root you can type: limit descriptors 1048576 which is the hard limit > for root under FC5. Where do you put that? There is no "limit" command and ulimit doesn't accept "descriptors" as a parameter. > But even as root I get the soft limit set to 1024 > when I do su - by default. > Maybe the discussion grandparent was running > a program which uses 3 open descriptors for every connection (separate > logfiles for every connection, probably? Separate "control" and "data" > connections, as in FTP?) and on another distro he was getting bigger > default soft limit for root? Good theory (see my other post). But I don't know the answer. > Now my question. It's impossible to make 5000 connections as user under > Fedora. Can I change it? I thought it's controlled by #define OPEN_MAX > in kernel source (I guess it means files not file descriptors then), but > kernel-devel's limit.h has OPEN_MAX set to 256 and everyone here > confirms the limit is truly 1024, which is fs.h's INR_OPEN (and root's > hard limit is NR_OPEN). Does that mean the 1024 open connections are > kernel maximum changed only at compile time and there's no sysctl for > it? Ah, the $64,000 question. So far, in just glancing through /proc/sys/, I didn't find a sysctl for it. Would be nice. But from your paragraph, I wonder if it's actually fs.h that sets the "soft limit" to begin with. I'd certainly like to know the answer, too. BTW: With 1GB RAM minimum on all my notebooks and workstations (and on a couple of my personal servers), it wouldn't bother me to increase that default to 5120 or 10240 even. Of course, that change could require a much more in depth conversation. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galibert at pobox.com Wed Apr 26 20:51:26 2006 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 26 Apr 2006 22:51:26 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604261434.59704.lamont@gurulabs.com> References: <200604261315.13247.lamont@gurulabs.com> <1146082706.4967.16.camel@pensja.lam.pl> <200604261434.59704.lamont@gurulabs.com> Message-ID: <20060426205126.GB64153@dspnet.fr.eu.org> On Wed, Apr 26, 2006 at 02:34:55PM -0600, Lamont R. Peterson wrote: > Where do you put that? There is no "limit" command and ulimit doesn't accept > "descriptors" as a parameter. limit descriptors is (t)csh, the (ba)sh equivalent is ulimit -n. Use ulimit -a for the complete list. > I'd certainly like to know the answer, too. /etc/security/limits.conf is I think what you want. > BTW: With 1GB RAM minimum on all my notebooks and workstations (and on a > couple of my personal servers), it wouldn't bother me to increase that > default to 5120 or 10240 even. Of course, that change could require a much > more in depth conversation. I'd agree. I'd love to know the kernel memory cost for a fd though. OG. From lamont at gurulabs.com Wed Apr 26 21:17:47 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 26 Apr 2006 15:17:47 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <20060426205126.GB64153@dspnet.fr.eu.org> References: <200604261434.59704.lamont@gurulabs.com> <20060426205126.GB64153@dspnet.fr.eu.org> Message-ID: <200604261517.52571.lamont@gurulabs.com> On Wednesday 26 April 2006 02:51pm, Olivier Galibert wrote: > On Wed, Apr 26, 2006 at 02:34:55PM -0600, Lamont R. Peterson wrote: > > Where do you put that? There is no "limit" command and ulimit doesn't > > accept "descriptors" as a parameter. > > limit descriptors is (t)csh, the (ba)sh equivalent is ulimit -n. Use > ulimit -a for the complete list. Oh, duh! OK. Running "ulimit -n 2048" on the client box in my 3-box setup, yielded the result that 2045 network connections could be made, as root. Trying to run that ulimit command as an unprivileged user results in an error message (as expected). So, in order to solve Hendrik Wiese's problem, they can either launch their client program as root, increase the limit to whatever they feel is appropriate, and then drop root privileges, or use pam_limits.so by editing /etc/security/limits.conf and adding lines like: * soft nofile 1024 * hard nofile 65535 Of course, set values that make sense for the soft limit, since unprivileged users can't change that. On RHEL & FC, pam_limit.so is loaded in /etc/pam.d/system-auth, so no modifications will be needed. > > I'd certainly like to know the answer, too. > > /etc/security/limits.conf is I think what you want. I agree; that's the best way. > > BTW: With 1GB RAM minimum on all my notebooks and workstations (and on a > > couple of my personal servers), it wouldn't bother me to increase that > > default to 5120 or 10240 even. Of course, that change could require a > > much more in depth conversation. > > I'd agree. I'd love to know the kernel memory cost for a fd though. I don't have the kernel source (or headers) handy at the moment. If I did, I'd find out by starting with the fs.h header and working from there. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dax at gurulabs.com Wed Apr 26 21:42:42 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 26 Apr 2006 15:42:42 -0600 Subject: ipw3945 packaging In-Reply-To: <20060426161818.GC12750@neu.nirvana> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> <20060426160717.GB12750@neu.nirvana> <1146068068.7016.19.camel@laptopd505.fenrus.org> <20060426161818.GC12750@neu.nirvana> Message-ID: <1146087763.2681.8.camel@mentorng.gurulabs.com> On Wed, 2006-04-26 at 18:18 +0200, Axel Thimm wrote: > sorry, I'll take it back. I found the article (for German readers): > > http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/70092&words=ipw3945 > > and the quote was from Dax Kelson: > > http://article.gmane.org/gmane.linux.network/32622 > > So, indeed no love for ipw3945. Correct, my quote was not about the firmware it was: "It is very disappointing to see this binary user space daemon (that must run as root, presumably to write into /sys/) requirement. I recognize that it is a better poison than a binary kernel module." Basically, I'd rather have a closed userspace app whisper the secret numbers to the hardware than have a close/binary only kernel module do the same. Presumable somebody can sniff out what those secret numbers are (in a legal fashion) then the someone can fork a new driver that includes that functionality. Goodbye closed userspace app! The question is, would Jeff Garzik / Linus accept the forked driver into the kernel? Dax Kelson From Axel.Thimm at ATrpms.net Wed Apr 26 23:07:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 27 Apr 2006 01:07:28 +0200 Subject: ipw3945 packaging In-Reply-To: <1146087763.2681.8.camel@mentorng.gurulabs.com> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> <20060426160717.GB12750@neu.nirvana> <1146068068.7016.19.camel@laptopd505.fenrus.org> <20060426161818.GC12750@neu.nirvana> <1146087763.2681.8.camel@mentorng.gurulabs.com> Message-ID: <20060426230728.GC25506@neu.nirvana> On Wed, Apr 26, 2006 at 03:42:42PM -0600, Dax Kelson wrote: > Basically, I'd rather have a closed userspace app whisper the secret > numbers to the hardware than have a close/binary only kernel module do > the same. > > Presumable somebody can sniff out what those secret numbers are (in a > legal fashion) then the someone can fork a new driver that includes that > functionality. Goodbye closed userspace app! > > The question is, would Jeff Garzik / Linus accept the forked driver into > the kernel? Maybe that's the purpose of the binary userland bits to help reverse engineer it. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wes.shull at gmail.com Wed Apr 26 23:54:14 2006 From: wes.shull at gmail.com (Wes Shull) Date: Wed, 26 Apr 2006 16:54:14 -0700 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <17487.27886.76252.698013@zapata.pink> References: <17487.27886.76252.698013@zapata.pink> Message-ID: On 4/26/06, Andrew Haley wrote: > #include [snip] I don't think Andrew's code is showing the real problem here, because it's not actually trying to send anything over the connections after they've been opened, to make sure they're still alive. At first I thought Hendrik was on crack, but I'm able to reproduce something similar on my FC5 system. It's not related to the open file ulimit. I hacked up the Tcl code at the bottom to open a bunch of sockets, connect to itself, and pass data back and forth; run it and see what you get. On my 2.6.16-1.2080_FC5 system, all but 19 of the connections die after the client side sends some initial data. I'm thinking that some connection tracker (i.e. iptables/netfilter) is losing track of them and so kicking back a reset. I don't think my code is bad; on my XP SP2 box at work, it works fine (there I have to keep numsocks at about 150 to keep Windows from running out of buffer space, but at least it's not randomly closing connections) However, when I unload iptables (made sure no modules were still loaded) it still does the same thing. That really doesn't fit my theory... Are some of the tunables in /proc/sys/net/ipv4/netfilter/ perhaps relevant to this? If my theory somehow is correct, could it be a hash function falling down with a bunch of connections with a very similar signature? I'm running selinux enforcing, tried setenforce 0, didn't seem to help either. #!/usr/bin/tclsh set baseport 3000 set numsocks 500 ;# keep <= (`ulimit -n` - 3) / 2 set remote_host 127.0.0.1 set command marco set reply polo proc server_accepted {serverport sock address port} { puts "server: $serverport accepted" fconfigure $sock -buffering line fileevent $sock readable [list server_readable $sock $serverport] } proc server_readable {sock port} { fileevent $sock readable {} gets $sock line if [eof $sock] { puts "server_readable: $port went away" close $sock return } puts "server: $port<-$line" if {$line eq $::command} { fileevent $sock writable [list server_writable $sock $port] } } proc server_writable {sock port} { fileevent $sock writable {} if [eof $sock] { puts "server_writable: $port went away" close $sock return } puts $sock $::reply puts "server: $port->$::reply" fileevent $sock readable [list server_readable $sock $port] } proc client_readable {sock port} { fileevent $sock readable {} gets $sock line if [eof $sock] { puts "client_readable: $port went away" close $sock return } puts "client: $port->$line" if {$line eq $::reply} { fileevent $sock writable [list client_writable $sock $port] } } proc client_writable {sock port} { fileevent $sock writable {} if [eof $sock] { puts "client_writable: $port went away" close $sock return } puts $sock $::command puts "client: $port<-$::command" fileevent $sock readable [list client_readable $sock $port] } # main for {set port $baseport} {$port < $baseport + $numsocks} {incr port} { puts "Creating listener on $port" socket -server [list server_accepted $port] $port puts "Connecting to listener on $remote_host:$port" set sock [socket -async $remote_host $port] fconfigure $sock -buffering line fileevent $sock writable [list client_writable $sock $port] } vwait forever From seg at haxxed.com Thu Apr 27 04:24:50 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 26 Apr 2006 23:24:50 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146029865.6969.65.camel@atlantis.mpeters.local> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> Message-ID: <1146111894.7621.8.camel@localhost.localdomain> On Tue, 2006-04-25 at 22:37 -0700, Michael A. Peters wrote: > That assumes that the end user knows what a package is and what it does. > Say I had no clue that mathml-fonts were needed to properly view the > blog of my Physics professor. I might not even know what mathml is. It > just works because something else pulled them in as a dependency. Grasping at straws, eh? If firefox supports mathml and needs mathml-fonts to display properly, then perhaps firefox should be depending on mathml-fonts. Or at least putting up some kind of message like "This page cannot be displayed properly, you need mathml-fonts". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From n0dalus+redhat at gmail.com Thu Apr 27 04:35:53 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 27 Apr 2006 14:05:53 +0930 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146111894.7621.8.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> Message-ID: <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> On 4/27/06, Callum Lerwick wrote: > > Grasping at straws, eh? If firefox supports mathml and needs > mathml-fonts to display properly, then perhaps firefox should be > depending on mathml-fonts. Or at least putting up some kind of message > like "This page cannot be displayed properly, you need mathml-fonts". > The problem is that there's not a good way yet of giving packages 'Suggests'/'Enhances' tags. At the moment all we provide are packages with either 'Requires' or nothing. The idea would be that the package manager would ask the user which suggests/enhances to install (with suggests selected by default). I would agree that Firefox should show a message about it though. n0dalus. From seg at haxxed.com Thu Apr 27 04:53:20 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 26 Apr 2006 23:53:20 -0500 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: <17487.27886.76252.698013@zapata.pink> Message-ID: <1146113601.7621.22.camel@localhost.localdomain> On Wed, 2006-04-26 at 16:54 -0700, Wes Shull wrote: > Are some of the tunables in /proc/sys/net/ipv4/netfilter/ perhaps > relevant to this? If my theory somehow is correct, could it be a hash > function falling down with a bunch of connections with a very similar > signature? $ cat /proc/sys/net/ipv4/ip_conntrack_max 32760 Near as I can tell its auto-tuned based on RAM size, which means on any system capable of running Fedora it should be plenty big. (This system has 512mb) On a Broadcom based Belkin wireless router with 8mb RAM, it tends to need to be increased a bit from default if you want to bittorrent... And I don't know if this affects local connections at all. My guess is it can depending on how you set up your iptables... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Apr 27 04:38:35 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Apr 2006 00:38:35 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146111894.7621.8.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> Message-ID: <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> On 4/27/06, Callum Lerwick wrote: > Grasping at straws, eh? If firefox supports mathml and needs > mathml-fonts to display properly, then perhaps firefox should be > depending on mathml-fonts. Or at least putting up some kind of message > like "This page cannot be displayed properly, you need mathml-fonts". "need" and "optional" are distinct concepts. The point he's trying to make is that a package which is a hard package requirement may in fact be useful in other context than those explicitly encoded by the limited range of relationships which can be encoded in an rpm package. Just because a user did not explictly request a particular package when installing something else does not mean that the dependacy does not itself have value to the user. By automatically removing things that were not placed on the system explicitly, with no other attempts to check as to whether the files in those packages are being used outside the bounds of the strict "requires" packaging dependancy relationship, all you end up doing is creating situations where users have to go back and explicitly reinstall those items... a pointless waste of time which puts more demands on the user to know exactly which package does what. Automatic removal of dependancies can not be done without human review as to which of those packages are still locally needed, and I think its far more appropriate to expect users who want to clean up their system to do that review before items are removed than it is to automatically remove deps and expect users to review which items should be put back on the system to keep the functionality they expect. -jef"look on the side of the road, a dead horse! Let's go over there and beat it!"spaleta From seg at haxxed.com Thu Apr 27 05:15:30 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 00:15:30 -0500 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604261517.52571.lamont@gurulabs.com> References: <200604261434.59704.lamont@gurulabs.com> <20060426205126.GB64153@dspnet.fr.eu.org> <200604261517.52571.lamont@gurulabs.com> Message-ID: <1146114932.7621.43.camel@localhost.localdomain> On Wed, 2006-04-26 at 15:17 -0600, Lamont R. Peterson wrote: > * soft nofile 1024 > * hard nofile 65535 > > Of course, set values that make sense for the soft limit, since unprivileged > users can't change that. On RHEL & FC, pam_limit.so is loaded > in /etc/pam.d/system-auth, so no modifications will be needed. Why change the soft limit at all? Leave it be, and just do a ulimit -n before starting the descriptor eating process. Also, * is probably dangerous, put a specific username there. Or at least a group. Azureus likes to eat file descriptors. (It seems to keep every file open at all times on every active torrent. Ugh.) Its impossible to activate a torrent with lots of small files unless you raise the limit. I raised my hard limit in limits.conf, then I have a script that starts up Azureus like this: #!/bin/sh ulimit -n 16384 cd ~/azureus JAVA_PROGRAM_DIR="/usr/lib/jvm/jre-1.5.0-sun/bin/" \ exec nice -1 ./azureus Works nice. Note that greatly raising a users descriptor limit opens the possibility of a user or two running into the *kernel* descriptor limit, which IIRC is set at compile time. I imagine this could cause a nasty DoS situation. I've never tried it so I dunno... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Apr 27 05:24:37 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 00:24:37 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> Message-ID: <1146115478.7621.50.camel@localhost.localdomain> On Thu, 2006-04-27 at 00:38 -0400, Jeff Spaleta wrote: > Automatic removal of dependancies can not be done without human review > as to which of those packages are still locally needed, and I think > its far more appropriate to expect users who want to clean up their > system to do that review before items are removed than it is to > automatically remove deps and expect users to review which items > should be put back on the system to keep the functionality they > expect. Now we're just splitting hairs about what "automatic removal" means. Yes, review is good. aptitude has a nice transaction preview screen, giving you a chance to review everything its going to do, and won't perform a transaction without showing it first. > -jef"look on the side of the road, a dead horse! Let's go over there > and beat it!"spaleta *whap* *whap* *whap* *thunk* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Thu Apr 27 05:24:58 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 26 Apr 2006 22:24:58 -0700 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146111894.7621.8.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> Message-ID: <1146115498.2341.31.camel@atlantis.mpeters.local> On Wed, 2006-04-26 at 23:24 -0500, Callum Lerwick wrote: > On Tue, 2006-04-25 at 22:37 -0700, Michael A. Peters wrote: > > That assumes that the end user knows what a package is and what it does. > > Say I had no clue that mathml-fonts were needed to properly view the > > blog of my Physics professor. I might not even know what mathml is. It > > just works because something else pulled them in as a dependency. > > Grasping at straws, eh? If firefox supports mathml and needs > mathml-fonts to display properly, then perhaps firefox should be > depending on mathml-fonts. Or at least putting up some kind of message > like "This page cannot be displayed properly, you need mathml-fonts". Firefox does notify the user that they are missing fonts. It then directs them to instructions (if I remember) that are a sub-optimal way of installing them on a system that already has the packaged. The point is that there will be software users have need for that they don't necessarily know they have a need for. From seg at haxxed.com Thu Apr 27 06:07:55 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 01:07:55 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> Message-ID: <1146118075.7621.69.camel@localhost.localdomain> On Thu, 2006-04-27 at 14:05 +0930, n0dalus wrote: > The problem is that there's not a good way yet of giving packages > 'Suggests'/'Enhances' tags. At the moment all we provide are packages > with either 'Requires' or nothing. The idea would be that the package > manager would ask the user which suggests/enhances to install (with > suggests selected by default). Which is something Debian packages support. Meh, I've always figured RPM systems seem to get along okay without it, and most of all on my Debian systems I never find myself actually using or caring about Suggests / Recommends anyway, but I guess it's not a horrible idea. What would be nice if we're going to do it is a human friendly short %description as to what exactly each optional dependency enhances or adds. And while we're swiping stuff from Debian, how about something like debconf... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Apr 27 06:45:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Apr 2006 02:45:19 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146115478.7621.50.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> <1146115478.7621.50.camel@localhost.localdomain> Message-ID: <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> On 4/27/06, Callum Lerwick wrote: > Now we're just splitting hairs about what "automatic removal" means. No I'm not... let me be as clear. Any mechanism that allows people to dialog their way through removals of non-explictly installed deps, that does not try to accurately account for file access outside the context of the strictly defined package management relationship will undoubtable mislead novice users into removing packages that provide functionality that they were in fact depending on. For users who know enough to know whether they(or scripts/applications on their system) are not in fact using a particular package.. those more advanced users can very easily create a list of "leaves" from something like package-cleanup and then review, per package, whether the package provides needed functionality or not. Any attempt to provide an application which makes it any easier to remove a collection of packages solely use information with regard to 'explicit' installation of a package will ultimately lead to numerous unexpected, untested and hard to reproduce problems for the very class of users who do not have the skills or the experience to troubleshoot a loss of functionality after-the-fact. And I have no doubt that the 3% of the population who know enough about their systems and their packages to be able to use such an "automated" removal feature in an infromed manner would find it a convient feature... because they are human and they are lazy bastards. But I dare say that its not worth making such an application widely available, or easily accessible, nor a "core" part of the distribution because it will lead the other 97% of the userbase who do not know enough about packaging into situations where the tool removes functionality they were using. > > Yes, review is good. aptitude has a nice transaction preview screen, > giving you a chance to review everything its going to do, and won't > perform a transaction without showing it first. You keep pimping aptitude like its a solution to the underlying problem. It isn't. I'm quite sure that aptitude or something like it is very handy for people who know what they are doing. For novice users, I think such a set of tools will in fact cause an unacceptable amount problems if the tools make no effort to make additional tests such as file access which attempt to account for usage of the packages which fall outside the strictly defined package mangement relationships. Since aptitude's interactivity/review give no information as to out of package manager file access... a novice user is given no information which can be used to warn them that the packages in the list to be removed are in fact being used by something the packager didn't expect. Aptitude or similar tool requires its users to have a keen understanding of how packages are being used on their own. And that sort of assumption is absolutely inappropriate for a tool which people want to expose as a generally available feature exposed to the entire fedora userbase. I really really hope the Ubuntu people figure out a way to track out of package manager context file access which can account for prelink activity as the integrate the feature into their desktop oriented distro, ( which was what started this hellaish thread of the damned). I dare say the demographics of the Ubuntu userbase are not well correlated with the debian userbase, so whatever the typically experience is with aptitude in debian will not automatically be the typical experience with a similiar tool in Ubuntu. Babies will be eaten, and this time it won't be my fault. -jef"Isn't it enough to know that I ruined a pony making a gift for you? --Jonathan Coulton"spaleta From buildsys at redhat.com Thu Apr 27 07:32:30 2006 From: buildsys at redhat.com (Build System) Date: Thu, 27 Apr 2006 03:32:30 -0400 Subject: rawhide report: 20060427 changes Message-ID: <200604270732.k3R7WUPK023598@porkchop.devel.redhat.com> New package unifdef Unifdef tool for removing ifdef'd lines Updated Packages: coreutils-5.94-4 ---------------- * Wed Apr 26 2006 Tim Waugh 5.94-4 - Avoid redeclared 'tee' function. - Fix 'cp -Z' when the destination exists (bug #189967). fontconfig-2.3.95-2 ------------------- * Wed Apr 26 2006 Bill Nottingham - 2.3.95-2 - fix fonts.conf typo * Wed Apr 26 2006 Matthias Clasen - 2.3.95-1 - Update to 2.3.95 gcalctool-5.8.9-1 ----------------- * Wed Apr 26 2006 Matthias Clasen 5.8.9-1 - Update to 5.8.9 gdm-1:2.14.4-2 -------------- * Wed Apr 26 2006 Matthias Clasen - 1:2.14.4-2 - Update to 2.14.4 glibc-2.4.90-2 -------------- * Wed Apr 26 2006 Jakub Jelinek 2.4.90-2 - update from CVS - fix getaddrinfo (#190002) - add auto-propagate nscd.conf options (#177154) - fix nscd auditing (#169148) glibc-kernheaders-3.0-14 ------------------------ * Thu Apr 27 2006 David Woodhouse 3.0-14 - Fix asm/s390/{ptrace.h,page.h} * Thu Apr 27 2006 David Woodhouse 3.0-13 - Work around libaudit.h defining audit_rule_data * Thu Apr 27 2006 David Woodhouse 3.0-12 - ... and remove the inclusion of from it. kernel-2.6.16-1.2171_FC6 ------------------------ * Wed Apr 26 2006 Dave Jones - 2.6.17rc3 - 2.6.17rc2-git8 * Wed Apr 26 2006 David Woodhouse - Don't include /usr/include/scsi in kernel-headers for now, because glibc ships those for itself. Update header cleanup patches so that glibc actually builds against the resulting headers * Wed Apr 26 2006 Juan Quintela - Delete figlet form xen hypervisor. libgdiplus-1.1.13.6-2 --------------------- * Wed Apr 26 2006 Alexander Larsson - 1.1.13.6-2 - Upgrade to 1.1.13.6 libtiff-3.8.2-1 --------------- * Wed Apr 26 2006 Matthias Clasen - 3.8.2-1 - Update to 3.8.2 mono-1.1.13.7-2 --------------- * Wed Apr 26 2006 Alexander Larsson - 1.1.13.7-2 - Update to 1.1.13.7 openoffice.org-1:2.0.2-5.12.3 ----------------------------- * Tue Apr 25 2006 Caolan McNamara - 1:2.0.2-5.12 - ooo#64743# continuing my epic battle with CJK and Indic glyph fallback (rh#189760#) - ooo#64726# "untranslate" bengali keyboard shortcuts (rh#189760#) pam-0.99.3.0-4 -------------- * Wed Apr 26 2006 Tomas Mraz 0.99.3.0-4 - fixed console device class for irda (#189966) - make pam_console_apply fail gracefully when a class is missing system-config-date-1.8.3-1 -------------------------- * Tue Mar 14 2006 Nils Philippsen 1.8.3 - feed timezone po files from anaconda (#131528, patch by Andrew Martynov) tetex-3.0-22 ------------ * Mon Apr 24 2006 Jindrich Novy 3.0-22 - don't package documentation for removed preview package (#189753) - enhance Japanese support, thanks to Matsuura Takanori: - modify vfontmap (#178411) - update ptex-src to 3.1.9, ptex-texmf to 2.4, pdvips to 5.95a-p1.7a, pxdvi to 22.84.9 j1.31, and mendexk to 2.6d - package pxdvi config files as %config xen-3.0.2-2 ----------- * Wed Apr 26 2006 Jeremy Katz - 3.0.2-2 - -m64 patch isn't needed anymore either * Tue Apr 25 2006 Jeremy Katz - 3.0.2-1 - update to post 3.0.2 snapshot (changeset: 9744:1ad06bd6832d) - stop applying patches that are upstreamed - add patches for bootloader to run on all domain creations - make xenguest-install create a persistent uuid - use libvirt for domain creation in xenguest-install, slightly improve error handling yum-2.6.1-1 ----------- * Wed Apr 26 2006 Jeremy Katz - 2.6.1-1 - update to 2.6.1 with fixes for #181406, #185309, #161190, #185946 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5smp GFS-kernel-smp - 2.6.15.1-5.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.i686 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5smp cman-kernel-smp - 2.6.15.1-0.FC5.18.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5smp dlm-kernel-smp - 2.6.15.1-0.FC5.16.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.i686 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5smp gnbd-kernel-smp - 2.6.15-5.FC5.25.i686 requires kernel-smp = 0:2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.i686 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.i686 requires /lib/modules/2.6.16-1.2080_FC5xenU Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 GFS-kernel - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 cman-kernel - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.18.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 dlm-kernel - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.16.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires kernel = 0:2.6.16-1.2080_FC5 gnbd-kernel - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.25.x86_64 requires kernel-xen0 = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires kernel-xenU = 0:2.6.16-1.2080_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.25.x86_64 requires /lib/modules/2.6.16-1.2080_FC5xenU From seg at haxxed.com Thu Apr 27 08:42:43 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 03:42:43 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> <1146115478.7621.50.camel@localhost.localdomain> <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> Message-ID: <1146127363.7621.111.camel@localhost.localdomain> On Thu, 2006-04-27 at 02:45 -0400, Jeff Spaleta wrote I don't know why you keep flogging the newbie angle. There's a reason I recommended this functionality go into yumex, or simply remain in aptitude, and not yum itself or pup or pirut or whatever. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aph at redhat.com Thu Apr 27 09:42:39 2006 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Apr 2006 10:42:39 +0100 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: <17487.27886.76252.698013@zapata.pink> Message-ID: <17488.37391.181678.824942@zapata.pink> Wes Shull writes: > On 4/26/06, Andrew Haley wrote: > > #include > > [snip] > > I don't think Andrew's code is showing the real problem here, because > it's not actually trying to send anything over the connections after > they've been opened, to make sure they're still alive. > > At first I thought Hendrik was on crack, but I'm able to reproduce > something similar on my FC5 system. It's not related to the open file > ulimit. > > I hacked up the Tcl code at the bottom to open a bunch of sockets, > connect to itself, and pass data back and forth; run it and see what > you get. On my 2.6.16-1.2080_FC5 system, all but 19 of the > connections die after the client side sends some initial data. I'm > thinking that some connection tracker (i.e. iptables/netfilter) is > losing track of them and so kicking back a reset. > It works for me, bouncing data back and forth. What does it do on your box? What is the output? Andrew. From arjan at fenrus.demon.nl Thu Apr 27 11:06:41 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 27 Apr 2006 13:06:41 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: Message-ID: <1146136002.2894.30.camel@laptopd505.fenrus.org> > Please try to open that many tcp connections between two IPs and tell me > if it works! Finding out in which way our software opens the sockets > would be enough work for two persons for at least two days. It's old > software we try to get running on a new system. Very (very very) old > sources! ;) > > Some guy told me that maybe iptables is the cause of this problem. You > think he's right? We have to verify that. May take a few days since the > collegue responsible for this isn't in the office right now. Just that > much about "it's urgent" (my team leader's definition). *laugh* > > Thanks for your interest in this problem. I'll keep you up to date. the number 350 rings another bell: if your software uses one thread per connection, and uses the default stack size (which is 8 to 10Mb on modern linux/glibc) you'll run out of 32 bit virtual address space around 350. If that's the case you probably really want to tell the pthreads library that you know what you are doing and that you want a smaller stack size please ;) From pmatilai at laiskiainen.org Thu Apr 27 13:50:43 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 27 Apr 2006 06:50:43 -0700 (PDT) Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146118075.7621.69.camel@localhost.localdomain> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> Message-ID: On Thu, 27 Apr 2006, Callum Lerwick wrote: > On Thu, 2006-04-27 at 14:05 +0930, n0dalus wrote: >> The problem is that there's not a good way yet of giving packages >> 'Suggests'/'Enhances' tags. At the moment all we provide are packages >> with either 'Requires' or nothing. The idea would be that the package >> manager would ask the user which suggests/enhances to install (with >> suggests selected by default). > > Which is something Debian packages support. Meh, I've always figured RPM > systems seem to get along okay without it, and most of all on my Debian > systems I never find myself actually using or caring about Suggests / > Recommends anyway, but I guess it's not a horrible idea. What would be > nice if we're going to do it is a human friendly short %description as > to what exactly each optional dependency enhances or adds. Recent rpm versions support soft dependencies, eg Requires(hint): foo Provides(hint): bar ..and have corresponding "aliases" for spec file syntax: Suggests: foo Enhances: bar Too bad it doesn't seem like we're getting a version of rpm supporting those anytime soon :-/ - Panu - From dimi at lattica.com Thu Apr 27 13:53:48 2006 From: dimi at lattica.com (Dimi Paun) Date: Thu, 27 Apr 2006 09:53:48 -0400 (EDT) Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com><1145971156.6969.3.camel@atlantis.mpeters.local><20060425152318.24f0497f@duras.int.addix.net><1145994273.22802.121.camel@localhost.localdomain><1146029865.6969.65.camel@atlantis.mpeters.local><1146111894.7621.8.camel@localhost.localdomain><6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com><1146118075.7621.69.camel@localhost.localdomain> Message-ID: <40802.207.35.222.39.1146146028.squirrel@lattica.com> On Thu, April 27, 2006 9:50 am, Panu Matilainen said: > Too bad it doesn't seem like we're getting a version of rpm > supporting those anytime soon :-/ Why is that BTW? -- Dimi Paun Lattica, Inc. From jkeating at j2solutions.net Thu Apr 27 14:29:56 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 27 Apr 2006 10:29:56 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> Message-ID: <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote: > Recent rpm versions support soft dependencies, eg > Requires(hint): foo > Provides(hint): bar > > ..and have corresponding "aliases" for spec file syntax: > Suggests: foo > Enhances: bar How is this supposed to work an an automated installation? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tjb at unh.edu Thu Apr 27 14:54:38 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 27 Apr 2006 10:54:38 -0400 Subject: Panel Clock Calendar Starting on Wrong Day Message-ID: <1146149678.4346.7.camel@raptor.sr.unh.edu> I reported a bug against tzdata for FC5 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189718) about my panel clock starting on Monday instead of Sunday. My rawhide system doesn't have the problem, it starts correctly on Sunday. Both systems have the locale set to en_US.UTF-8 and both tzdata rpms look the same (tzdata-2006d-1 and tzdata-2006d-1.fc5). I've read that my problem is due to incorrect locate data which i assumed came from tzdata. I reported the bug on Sunday but haven't received any response. Is anyone else seeing this error on FC5 or rawhide? Is tzdata where the locale data is packaged? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From pmatilai at laiskiainen.org Thu Apr 27 15:13:41 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 27 Apr 2006 18:13:41 +0300 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> On Thu, 2006-04-27 at 10:29 -0400, Jesse Keating wrote: > On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote: > > Recent rpm versions support soft dependencies, eg > > Requires(hint): foo > > Provides(hint): bar > > > > ..and have corresponding "aliases" for spec file syntax: > > Suggests: foo > > Enhances: bar > > How is this supposed to work an an automated installation? You either don't install soft dependencies or install them all, the latter hardly being a sane option. One would probably want two levels of soft requires - the syntax is implemented in rpm but not sure if they're currently distinguishable outside the spec syntax: Requires(missingok) and Requires(hint) where "missingok" is something you'd want to install by default but removing of the dependency wont break the package, "hint" being .. well, a hint that this might be useful with this software but not installed automatically. Enhances is basically Suggests reversed for situations where Suggests cannot be used because the main package has no knowledge of the enhancing package. - Panu - From jkeating at j2solutions.net Thu Apr 27 15:24:13 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 27 Apr 2006 11:24:13 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> Message-ID: <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-04-27 at 18:13 +0300, Panu Matilainen wrote: > One would probably want two levels of soft requires - the syntax is > implemented in rpm but not sure if they're currently distinguishable > outside the spec syntax: > Requires(missingok) and Requires(hint) where "missingok" is something > you'd want to install by default but removing of the dependency wont > break the package, "hint" being .. well, a hint that this might be > useful with this software but not installed automatically. Enhances is > basically Suggests reversed for situations where Suggests cannot be > used > because the main package has no knowledge of the enhancing package. This seems to be spiraling into major complexity and lots of ways for developers to get it wrong. Boo. I've never been very thrilled with the idea of soft deps, and I really haven't seen it done right. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Thu Apr 27 15:37:06 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 27 Apr 2006 08:37:06 -0700 (PDT) Subject: rawhide report: 20060427 changes In-Reply-To: <200604270732.k3R7WUPK023598@porkchop.devel.redhat.com> Message-ID: <20060427153706.51358.qmail@web51501.mail.yahoo.com> >kernel-2.6.16-1.2171_FC6 >------------------------ >* Wed Apr 26 2006 Dave Jones >- 2.6.17rc3 >- 2.6.17rc2-git8 On x86_64, I get: Starting udev: BUG: spinlock bad magic on CPU#0, events/0/5 (Not tainted) lock: ffff810037c90280, .magic: 00000000, .owner: /-1, .owner_cpu: 0 Kernel panic - not syncing: bad locking -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From n0dalus+redhat at gmail.com Thu Apr 27 15:38:25 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 28 Apr 2006 01:08:25 +0930 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> References: <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <6280325c0604270838j7add2a32m3a5e377b580e6fb6@mail.gmail.com> On 4/28/06, Jesse Keating wrote: > > This seems to be spiraling into major complexity and lots of ways for > developers to get it wrong. Boo. I've never been very thrilled with > the idea of soft deps, and I really haven't seen it done right. > If the developers can't grasp the concept of a 3 level requires/suggests/enhances, they can just use the normal one level 'requires' and nobody will get hurt. The implementation of 'soft deps' as you call them is not really for rpm(8) anyway, it's for package managers. If you don't like the way it's been done so far, then make sure whatever package manager you use implements it correctly. If for you that means simply treating suggestions as requires and ignoring enhances (as is more or less the current way of setting package requirements in Fedora), then so be it -- don't complain that the functionality is there for those who want to use it. My 2c, n0dalus. From nutello at sweetness.com Thu Apr 27 16:42:47 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 27 Apr 2006 18:42:47 +0200 Subject: libm Message-ID: <20060427164247.GS445@plain.rackshack.net> Hello, I have a couple of questions that maybe someone can help with. Exhibit A is an x86_64 FC3 system: # objdump -p /usr/lib64/libfftw.so | grep -A20 Version Version References: required from libm.so.6: 0x09691a75 0x00 03 GLIBC_2.2.5 required from libc.so.6: 0x0d696913 0x00 04 GLIBC_2.3 0x09691a75 0x00 02 GLIBC_2.2.5 # rpm -qi fftw | grep ^[VRI] Version : 2.1.5 Vendor: (none) Release : 5 Build Date: Tue 14 Dec 2004 06:56:25 PM CST Install Date: Wed 23 Mar 2005 04:14:50 PM CST Build Host: extras64.linux.duke.edu Exhibit B is an x86_64 FC5 system: # objdump -p /usr/lib64/libfftw.so | grep -A20 Version Version References: required from libc.so.6: 0x0d696913 0x00 05 GLIBC_2.3 0x0d696914 0x00 04 GLIBC_2.4 0x09691a75 0x00 03 GLIBC_2.2.5 0x09691974 0x00 02 GLIBC_2.3.4 # rpm -qi fftw2 | grep ^[VRI] Version : 2.1.5 Vendor: (none) Release : 12.fc5 Build Date: Sat 18 Feb 2006 04:08:15 AM CST Install Date: Wed 26 Apr 2006 05:00:30 PM CDT Build Host: hammer2.fedora.redhat.com The FC3 fftw references libm, the FC5 one doesn't. Is one of the two behaviours considered more proper? Scons' autoconf-like test fails with the FC5 libfftw because it can't resolve sin() and cos(). The FC3 libfftw seems to reference those, too, but the reference to libm takes care of that. More in general, though, isn't a call to sin() and cos() expensive and shouldn't the compiler just use inline native FP code? In the case of FFTW those two are only used in the setup stages, with the actual FFTs implemented with multiplications and additions (gcc uses SSE as expected on x86_64), but not all code is going to be like that. Are there reasons for them not to be inlined? Thanks. -- Rudi From seg at haxxed.com Thu Apr 27 17:43:24 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 12:43:24 -0500 Subject: libm In-Reply-To: <20060427164247.GS445@plain.rackshack.net> References: <20060427164247.GS445@plain.rackshack.net> Message-ID: <1146159805.7621.120.camel@localhost.localdomain> On Thu, 2006-04-27 at 18:42 +0200, Rudi Chiarito wrote: > More in general, though, isn't a call to sin() and cos() expensive and > shouldn't the compiler just use inline native FP code? In the case of > FFTW those two are only used in the setup stages, with the actual FFTs > implemented with multiplications and additions (gcc uses SSE as > expected on x86_64), but not all code is going to be like that. Are > there reasons for them not to be inlined? Isn't this what --ffast-math does? Some gritty details seem to be here: http://gcc.gnu.org/wiki/Math%20Optimization%20Flags gcc is far smarter than many seem to realize. Sometimes far too smart... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lamont at gurulabs.com Thu Apr 27 18:32:01 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 27 Apr 2006 12:32:01 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <1146114932.7621.43.camel@localhost.localdomain> References: <200604261517.52571.lamont@gurulabs.com> <1146114932.7621.43.camel@localhost.localdomain> Message-ID: <200604271232.02086.lamont@gurulabs.com> On Wednesday 26 April 2006 11:15pm, Callum Lerwick wrote: > On Wed, 2006-04-26 at 15:17 -0600, Lamont R. Peterson wrote: > > * soft nofile 1024 > > * hard nofile 65535 > > > > Of course, set values that make sense for the soft limit, since > > unprivileged users can't change that. On RHEL & FC, pam_limit.so is > > loaded > > in /etc/pam.d/system-auth, so no modifications will be needed. > > Why change the soft limit at all? For those who didn't catch it earlier (this is from the email you just quoted): "OK. Running "ulimit -n 2048" on the client box in my 3-box setup, yielded the result that 2045 network connections could be made, as root. Trying to run that ulimit command as an unprivileged user results in an error message (as expected)." Note that "ulimit -n" did *not* work for unprivileged users. > Leave it be, and just do a ulimit -n > before starting the descriptor eating process. Also, * is probably > dangerous, put a specific username there. Or at least a group. So, unless they are running their client app as root, ulimit -n will not work. > Azureus likes to eat file descriptors. (It seems to keep every file open > at all times on every active torrent. Ugh.) Its impossible to activate a > torrent with lots of small files unless you raise the limit. I raised my > hard limit in limits.conf, then I have a script that starts up Azureus > like this: > > #!/bin/sh > ulimit -n 16384 > cd ~/azureus > JAVA_PROGRAM_DIR="/usr/lib/jvm/jre-1.5.0-sun/bin/" \ > exec nice -1 ./azureus It would seem that you run that as root. Otherwise, the ulimit command wouldn't work. > Works nice. Note that greatly raising a users descriptor limit opens the > possibility of a user or two running into the *kernel* descriptor limit, > which IIRC is set at compile time. I imagine this could cause a nasty > DoS situation. I've never tried it so I dunno... On my notebook: # cat /proc/sys/fs/file-max 102640 # echo "10000000" > /proc/sys/fs/file-man # cat /proc/sys/fs/file-max 10000000 So, that's tunable. But, is there a compiled in ceiling that such a setting passes? Will the echo command fail if I hit such a limit? If I hd the kernel source handy (and if I had time, today), I'd go hunt it down. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Thu Apr 27 18:44:40 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 27 Apr 2006 20:44:40 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604271232.02086.lamont@gurulabs.com> References: <200604261517.52571.lamont@gurulabs.com> <1146114932.7621.43.camel@localhost.localdomain> <200604271232.02086.lamont@gurulabs.com> Message-ID: <1146163480.2894.39.camel@laptopd505.fenrus.org> > So, that's tunable. But, is there a compiled in ceiling that such a setting > passes? Will the echo command fail if I hit such a limit? If I hd the > kernel source handy (and if I had time, today), I'd go hunt it down. probably 2^32 or so. But you can't get there anyway because you'll run out of memory first :) From lamont at gurulabs.com Thu Apr 27 18:46:50 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 27 Apr 2006 12:46:50 -0600 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: Message-ID: <200604271246.50811.lamont@gurulabs.com> All, Here are a couple of suggestions of how add auto-no-longer-used-dependency removal to yum. 1. Enhance RPM to track a new flag from each package to indicate whether or not it was installed auto-selected-for-dependency. Then, "yum remove foo" could automatically select to remove all packages that "foo" depends on that are no longer depended on by any other installed packages. 2. Take what we have with "yum deplist" and create a new command ("removedeps" ?) that automatically adds those packages that are no longer depended on by anything else that is installed, to the list of packages to remove. 3. Same as 2, but integrate the ability into the existing "yum remove" command. When packages are found that qualify for auto-inclusion-for-removal, list them and make the question take 3 possible answers: y/a/N (yes, auto/all, no). If you pick "a", then you get the whole smash. If you pick "y", you get the exact same behavior we have today and you do not remove those auto-no-longer-used-dependency packages. If you pick "n" (the default if you hit enter), you get the same behavior we have today, which is to bail out. Comments? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Apr 27 18:52:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 27 Apr 2006 14:52:04 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604271246.50811.lamont@gurulabs.com> References: <200604271246.50811.lamont@gurulabs.com> Message-ID: <1146163924.15614.68.camel@cutter> On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote: > All, > > Here are a couple of suggestions of how add auto-no-longer-used-dependency > removal to yum. > > 1. Enhance RPM to track a new flag from each package to indicate whether or > not it was installed auto-selected-for-dependency. Then, "yum remove foo" > could automatically select to remove all packages that "foo" depends on that > are no longer depended on by any other installed packages. > > 2. Take what we have with "yum deplist" and create a new command > ("removedeps" ?) that automatically adds those packages that are no longer > depended on by anything else that is installed, to the list of packages to > remove. > > 3. Same as 2, but integrate the ability into the existing "yum remove" > command. When packages are found that qualify for > auto-inclusion-for-removal, list them and make the question take 3 possible > answers: y/a/N (yes, auto/all, no). If you pick "a", then you get the whole > smash. If you pick "y", you get the exact same behavior we have today and > you do not remove those auto-no-longer-used-dependency packages. If you pick > "n" (the default if you hit enter), you get the same behavior we have today, > which is to bail out. You could do #3 or #2 as a plugin if you'd like to try it. I think #1 is unlikely to happen. -sv From galibert at pobox.com Thu Apr 27 19:01:13 2006 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 27 Apr 2006 21:01:13 +0200 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <200604271232.02086.lamont@gurulabs.com> References: <200604261517.52571.lamont@gurulabs.com> <1146114932.7621.43.camel@localhost.localdomain> <200604271232.02086.lamont@gurulabs.com> Message-ID: <20060427190113.GB48397@dspnet.fr.eu.org> On Thu, Apr 27, 2006 at 12:32:01PM -0600, Lamont R. Peterson wrote: > So, unless they are running their client app as root, ulimit -n will not work. In fact, no. ulimit is stupid, that's all, in that it changes both soft and hard limit when going down. But if as root you change the hard limit to 2048 without touching the soft one then start a user shell, you'll see that you can raise your limit with ulimit -n 2048, but if you ever reduce it you can't raise it again. (t)csh limit changes only the soft limit unless you add -h. OG. From seg at haxxed.com Thu Apr 27 19:16:00 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 14:16:00 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604271246.50811.lamont@gurulabs.com> References: <200604271246.50811.lamont@gurulabs.com> Message-ID: <1146165361.7621.127.camel@localhost.localdomain> On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote: > 1. Enhance RPM to track a new flag from each package to indicate whether or > not it was installed auto-selected-for-dependency. Then, "yum remove foo" > could automatically select to remove all packages that "foo" depends on that > are no longer depended on by any other installed packages. In the long term, if such functionality becomes common, it would be nice to have RPM allow a flag to be stored within the package database, so that multiple front ends can share it. As is, aptitude tracks it in its own database. (Even on its native Debian) Which means any packages installed outside aptitude are assumed to be explicit installs. For now, just track it in the front end, and help prove its useful and desirable functionality. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Apr 27 19:22:05 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 14:22:05 -0500 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <20060427190113.GB48397@dspnet.fr.eu.org> References: <200604261517.52571.lamont@gurulabs.com> <1146114932.7621.43.camel@localhost.localdomain> <200604271232.02086.lamont@gurulabs.com> <20060427190113.GB48397@dspnet.fr.eu.org> Message-ID: <1146165726.7621.133.camel@localhost.localdomain> On Thu, 2006-04-27 at 21:01 +0200, Olivier Galibert wrote: > On Thu, Apr 27, 2006 at 12:32:01PM -0600, Lamont R. Peterson wrote: > > So, unless they are running their client app as root, ulimit -n will not work. > > In fact, no. ulimit is stupid, that's all, in that it changes both > soft and hard limit when going down. But if as root you change the > hard limit to 2048 without touching the soft one then start a user > shell, you'll see that you can raise your limit with ulimit -n 2048, > but if you ever reduce it you can't raise it again. Ah, that's a gotcha I wasn't aware of. All the more reason to use a wrapper script. Just up the limit for the app that needs it, so you never have to decrease it. (Or maybe patch the app to up it itself...) ulimit changes are only supposed to affect the current process and its children, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lamont at gurulabs.com Thu Apr 27 19:22:30 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 27 Apr 2006 13:22:30 -0600 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <20060427190113.GB48397@dspnet.fr.eu.org> References: <200604271232.02086.lamont@gurulabs.com> <20060427190113.GB48397@dspnet.fr.eu.org> Message-ID: <200604271322.37249.lamont@gurulabs.com> On Thursday 27 April 2006 01:01pm, Olivier Galibert wrote: > On Thu, Apr 27, 2006 at 12:32:01PM -0600, Lamont R. Peterson wrote: > > So, unless they are running their client app as root, ulimit -n will not > > work. > > In fact, no. ulimit is stupid, that's all, in that it changes both > soft and hard limit when going down. But if as root you change the > hard limit to 2048 without touching the soft one then start a user > shell, you'll see that you can raise your limit with ulimit -n 2048, > but if you ever reduce it you can't raise it again. Well, I tried that on SLES9 and FC5 (which both happen to be handy at the moment) and that didn't work. An unprivileged user can not run ulimit -n, period. Also, why would you set the hard limit so low? FC5 does not have default limits set, so I'm not sure where it gets 1024 as the default soft limit. From bash (not likely)? From glibc (also not likely)? From the kernel (probably; found in fs.h, perhaps)? A quick test (run as root): for i in $(seq 16 21); do ulimit -n $(echo "2^${i}" | bc -l) ulimit -aH | grep "open files" done Produced: open files (-n) 65536 open files (-n) 131072 open files (-n) 262144 open files (-n) 524288 open files (-n) 1048576 -bash: ulimit: open files: cannot modify limit: Operation not permitted open files (-n) 1048576 I'm sure that's not an exact test, but it was quick. > (t)csh limit changes only the soft limit unless you add -h. Yeah. I love (t)csh. But then, I'm a programmer at heart. :) -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Thu Apr 27 19:27:01 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 27 Apr 2006 13:27:01 -0600 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146163924.15614.68.camel@cutter> References: <200604271246.50811.lamont@gurulabs.com> <1146163924.15614.68.camel@cutter> Message-ID: <200604271327.01808.lamont@gurulabs.com> On Thursday 27 April 2006 12:52pm, seth vidal wrote: > On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote: > > All, > > > > Here are a couple of suggestions of how add > > auto-no-longer-used-dependency removal to yum. > > > > 1. Enhance RPM to track a new flag from each package to indicate whether > > or not it was installed auto-selected-for-dependency. Then, "yum remove > > foo" could automatically select to remove all packages that "foo" depends > > on that are no longer depended on by any other installed packages. > > > > 2. Take what we have with "yum deplist" and create a new command > > ("removedeps" ?) that automatically adds those packages that are no > > longer depended on by anything else that is installed, to the list of > > packages to remove. > > > > 3. Same as 2, but integrate the ability into the existing "yum remove" > > command. When packages are found that qualify for > > auto-inclusion-for-removal, list them and make the question take 3 > > possible answers: y/a/N (yes, auto/all, no). If you pick "a", then you > > get the whole smash. If you pick "y", you get the exact same behavior we > > have today and you do not remove those auto-no-longer-used-dependency > > packages. If you pick "n" (the default if you hit enter), you get the > > same behavior we have today, which is to bail out. > > You could do #3 or #2 as a plugin if you'd like to try it. I think I'll take a crack at it. > I think #1 is unlikely to happen. I agree. I only included it for completeness sake, since it was obvious. However, #1 does have the advantage of taking place at the RPM DB level, and thus being available to anything built atop the RPM libs, though, it would still require awareness in the higher level apps (like yum) to make it useable. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Thu Apr 27 19:27:59 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 27 Apr 2006 13:27:59 -0600 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146165361.7621.127.camel@localhost.localdomain> References: <200604271246.50811.lamont@gurulabs.com> <1146165361.7621.127.camel@localhost.localdomain> Message-ID: <200604271327.59255.lamont@gurulabs.com> On Thursday 27 April 2006 01:16pm, Callum Lerwick wrote: > On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote: > > 1. Enhance RPM to track a new flag from each package to indicate whether > > or not it was installed auto-selected-for-dependency. Then, "yum remove > > foo" could automatically select to remove all packages that "foo" depends > > on that are no longer depended on by any other installed packages. > > In the long term, if such functionality becomes common, it would be nice > to have RPM allow a flag to be stored within the package database, so > that multiple front ends can share it. That's what I meant, for the flag to be stored in the RPM DB. Sorry for not being clear about that. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From my.accountnow at ntlworld.com Thu Apr 27 19:31:02 2006 From: my.accountnow at ntlworld.com (ded) Date: Thu, 27 Apr 2006 20:31:02 +0100 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> <1146115478.7621.50.camel@localhost.localdomain> <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> Message-ID: <20060427193102.GA8700@ntlworld.com> On Thu, Apr 27, 2006 at 02:45:19AM -0400, Jeff Spaleta wrote: > You keep pimping aptitude like its a solution to the underlying > problem. It isn't. I'm quite sure that aptitude or something like it > is very handy for people who know what they are doing. For novice > users, I think such a set of tools will in fact cause an unacceptable > amount problems if the tools make no effort to make additional tests > such as file access which attempt to account for usage of the packages > which fall outside the strictly defined package mangement > relationships. > Since aptitude's interactivity/review give no > information as to out of package manager file access... a novice user > is given no information which can be used to warn them that the > packages in the list to be removed are in fact being used by something > the packager didn't expect. Aptitude or similar tool requires its > users to have a keen understanding of how packages are being used on > their own. And that sort of assumption is absolutely inappropriate for > a tool which people want to expose as a generally available feature > exposed to the entire fedora userbase. I don't know what aptitude you are familiar with, but apparently it isn't the same one I've used on a daily basis for six years or so. It's an excellent front end to dpkg, which new users seem to use as well. It's a shame you're so dismissive of it. Really, when's the last time you used aptitude? > I really really hope the Ubuntu people figure out a way to track out > of package manager context file access which can account for prelink > activity as the integrate the feature into their desktop oriented > distro Ubuntu huh? If it is "the Ubuntu peopel" odds are it will be a DD that Shuttleworth paid for. D -- BOFH excuse #148: Insert coin for new game -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Thu Apr 27 19:50:54 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 14:50:54 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <20060427193102.GA8700@ntlworld.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> <1146115478.7621.50.camel@localhost.localdomain> <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> <20060427193102.GA8700@ntlworld.com> Message-ID: <1146167456.7621.139.camel@localhost.localdomain> On Thu, 2006-04-27 at 20:31 +0100, ded wrote: > I don't know what aptitude you are familiar with, but apparently it > isn't the same one I've used on a daily basis for six years or so. > It's an excellent front end to dpkg, which new users seem > to use as well. It's a shame you're so dismissive of it. Fedora lesson #1: Jeff's job is to dismiss any and every idea that comes up. :) Some loyal dissension is good for keeping everyone honest and grounded, but past a certain point its just plain stubbornness... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Apr 27 19:54:08 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 27 Apr 2006 14:54:08 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604271327.59255.lamont@gurulabs.com> References: <200604271246.50811.lamont@gurulabs.com> <1146165361.7621.127.camel@localhost.localdomain> <200604271327.59255.lamont@gurulabs.com> Message-ID: <1146167650.7621.143.camel@localhost.localdomain> On Thu, 2006-04-27 at 13:27 -0600, Lamont R. Peterson wrote: > That's what I meant, for the flag to be stored in the RPM DB. Sorry for not > being clear about that. S'okay. I just feel its necessary to stress the point that at most, all we expect RPM itself to do, is store a single measly flag per installed package... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From benny+usenet at amorsen.dk Thu Apr 27 20:16:59 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 27 Apr 2006 22:16:59 +0200 Subject: [NEW IDEA] Automatic removal of dependencies References: <200604271246.50811.lamont@gurulabs.com> Message-ID: >>>>> "LRP" == Lamont R Peterson writes: LRP> All, Here are a couple of suggestions of how add LRP> auto-no-longer-used-dependency removal to yum. LRP> 1. Enhance RPM to track a new flag from each package to indicate LRP> whether or not it was installed auto-selected-for-dependency. LRP> Then, "yum remove foo" could automatically select to remove all LRP> packages that "foo" depends on that are no longer depended on by LRP> any other installed packages. How about simply adding a flag to rpm packages, saying that they are useless for anything except as dependencies? Most libraries would fit that. It would be yet another thing for package maintainers to get right, of course. /Benny From wes.shull at gmail.com Thu Apr 27 20:37:34 2006 From: wes.shull at gmail.com (Wes Shull) Date: Thu, 27 Apr 2006 13:37:34 -0700 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <17488.37391.181678.824942@zapata.pink> References: <17487.27886.76252.698013@zapata.pink> <17488.37391.181678.824942@zapata.pink> Message-ID: On 4/27/06, Andrew Haley wrote: > It works for me, bouncing data back and forth. What does it do on > your box? What is the output? unadultered output at http://kuoi.asui.uidaho.edu/~wes/out.txt ; here is an abbreviated annotated version: Creating listener on 3000 Connecting to listener on 127.0.0.1:3000 [...] Creating listener on 3499 Connecting to listener on 127.0.0.1:3499 I'm doing the connect asynchronously so all this really says it that it's not hitting the file descriptor limit... client: 3499<-marco server: 3499 accepted [...] client: 3482<-marco server: 3482 accepted 18 of the connections are made and the server side sees the data, but... client: 3481<-marco [...] client: 3000<-marco The other 500-18 connections are never accepted. Tcl channels also go writable on error (and I just realized my code doesn't check for that) so it's probable it shouldn't even have been trying to send on these because they never connected. client_readable: 3000 went away [...] client_readable: 3481 went away Here the client side catches that the other 500-18 connections didn't make it server: 3482<-marco [...] server: 3499<-marco server: 3499->polo [...] server: 3482->polo client: 3482->polo [...] client: 3499->polo client: 3499<-marco [...] client: 3482<-marco These last four sequences continue ad infinitum; it's successfully passing data back and forth, but only on those 18 connections. Just for S&G, I ran this on a FreeBSD 6.0-RELEASE-p4 system, and while it doesn't behave exactly the same, it didn't do what I expected there either. Just to make sure I'm not running into some issue with different Tcl builds (limited event queue length, limited # of active connections), I'll rewrite this in C (bleah) tonight and see if it behaves any better. --wes From mattdm at mattdm.org Thu Apr 27 20:39:59 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 27 Apr 2006 16:39:59 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <200604271246.50811.lamont@gurulabs.com> Message-ID: <20060427203959.GA28290@jadzia.bu.edu> On Thu, Apr 27, 2006 at 10:16:59PM +0200, Benny Amorsen wrote: > How about simply adding a flag to rpm packages, saying that they are > useless for anything except as dependencies? Most libraries would fit > that. If you want to go this [*] route, why have a flag? Just make your yum plug in consider all packages which only install things into /lib and/or /usr/lib + optionally docs. > It would be yet another thing for package maintainers to get right, of > course. Presto, there's that problem solved. :) [*] crazy, if you ask me, but no one did -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From my.accountnow at ntlworld.com Thu Apr 27 20:46:56 2006 From: my.accountnow at ntlworld.com (ded) Date: Thu, 27 Apr 2006 21:46:56 +0100 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146167456.7621.139.camel@localhost.localdomain> References: <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <604aa7910604262138p2b36896n3f0cd815e655f7d@mail.gmail.com> <1146115478.7621.50.camel@localhost.localdomain> <604aa7910604262345s48a7fcaeoff56333275b91bbf@mail.gmail.com> <20060427193102.GA8700@ntlworld.com> <1146167456.7621.139.camel@localhost.localdomain> Message-ID: <20060427204656.GA10968@ntlworld.com> On Thu, Apr 27, 2006 at 02:50:54PM -0500, Callum Lerwick wrote: > On Thu, 2006-04-27 at 20:31 +0100, ded wrote: > > I don't know what aptitude you are familiar with, but apparently it > > isn't the same one I've used on a daily basis for six years or so. > > It's an excellent front end to dpkg, which new users seem > > to use as well. It's a shame you're so dismissive of it. > Fedora lesson #1: Jeff's job is to dismiss any and every idea that comes > up. :) > Some loyal dissension is good for keeping everyone honest and grounded, > but past a certain point its just plain stubbornness... Point taken :) Kind Regards, D -- BOFH excuse #148: Insert coin for new game -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jburgess at uklinux.net Thu Apr 27 21:38:35 2006 From: jburgess at uklinux.net (Jon Burgess) Date: Thu, 27 Apr 2006 22:38:35 +0100 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: References: <17487.27886.76252.698013@zapata.pink> <17488.37391.181678.824942@zapata.pink> Message-ID: <1146173916.28767.86.camel@shark.home> On Thu, 2006-04-27 at 13:37 -0700, Wes Shull wrote: > On 4/27/06, Andrew Haley wrote: > > It works for me, bouncing data back and forth. What does it do on > > your box? What is the output? > > unadultered output at http://kuoi.asui.uidaho.edu/~wes/out.txt ; here > is an abbreviated annotated version: > > Creating listener on 3000 > Connecting to listener on 127.0.0.1:3000 > [...] > Creating listener on 3499 > Connecting to listener on 127.0.0.1:3499 > > I'm doing the connect asynchronously so all this really says it that > it's not hitting the file descriptor limit... > > client: 3499<-marco > server: 3499 accepted > [...] > client: 3482<-marco > server: 3482 accepted > > 18 of the connections are made and the server side sees the data, but... > > client: 3481<-marco > [...] > client: 3000<-marco > > The other 500-18 connections are never accepted. Tcl channels also go > writable on error (and I just realized my code doesn't check for that) > so it's probable it shouldn't even have been trying to send on these > because they never connected. > > client_readable: 3000 went away > [...] > client_readable: 3481 went away > > Here the client side catches that the other 500-18 connections didn't make it > > server: 3482<-marco > [...] > server: 3499<-marco > > server: 3499->polo > [...] > server: 3482->polo > > client: 3482->polo > [...] > client: 3499->polo > > client: 3499<-marco > [...] > client: 3482<-marco > > These last four sequences continue ad infinitum; it's successfully > passing data back and forth, but only on those 18 connections. > > Just for S&G, I ran this on a FreeBSD 6.0-RELEASE-p4 system, and while > it doesn't behave exactly the same, it didn't do what I expected there > either. Just to make sure I'm not running into some issue with > different Tcl builds (limited event queue length, limited # of active > connections), I'll rewrite this in C (bleah) tonight and see if it > behaves any better. Seems it is the kernel refusing to accept() any more connections, the reason being that it takes 2 descriptors for each of your listeners:- $ strace -e trace=socket,accept,connect ./sock.tcl Creating listener on 3000 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 Connecting to listener on 127.0.0.1:3000 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) Creating listener on 3001 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 Connecting to listener on 127.0.0.1:3001 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8 connect(8, {sa_family=AF_INET, sin_port=htons(3001), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) ... So when you come to connect you only get: ulimit(1024) - 2*500 - initialFD(5) = 19 for new connections:- server: 3484 accepted client: 3483<-marco accept(971, {sa_family=AF_INET, sin_port=htons(44952), sin_addr=inet_addr("127.0.0.1")}, [8589934608]) = 1021 server: 3483 accepted client: 3482<-marco accept(969, {sa_family=AF_INET, sin_port=htons(56034), sin_addr=inet_addr("127.0.0.1")}, [8589934608]) = 1022 server: 3482 accepted client: 3481<-marco accept(967, {sa_family=AF_INET, sin_port=htons(38003), sin_addr=inet_addr("127.0.0.1")}, [8589934608]) = 1023 server: 3481 accepted client: 3480<-marco accept(965, 0x7fffffa7d020, [8589934608]) = -1 EMFILE (Too many open files) client: 3479<-marco accept(963, 0x7fffffa7d020, [8589934608]) = -1 EMFILE (Too many open files) client: 3478<-marco accept(961, 0x7fffffa7d020, [8589934608]) = -1 EMFILE (Too many open files) client: 3477<-marco accept(959, 0x7fffffa7d020, [8589934608]) = -1 EMFILE (Too many open files) client: 3476<-marco ... If run as root with and raise the limit to 10k then you see 1500 file descriptors once the test is fully connected. Perhaps the most confusing thing is that the second FD for each listener doesn't appear in /proc//fd until something connects. Notice how you only see odd numbered FD's for the unconnected listeners below. $ ls -l /proc/29381/fd | sort -n -k 9 0 -> /dev/pts/0 1 -> /home/jburgess/socket/out 2 -> /home/jburgess/socket/out 3 -> pipe:[8919517] 4 -> pipe:[8919517] 5 -> socket:[8919518] 7 -> socket:[8919520] 9 -> socket:[8919522] 11 -> socket:[8919524] 13 -> socket:[8919526] Jon From pjones at redhat.com Thu Apr 27 21:41:49 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 27 Apr 2006 17:41:49 -0400 Subject: ipw3945 packaging In-Reply-To: <1146087763.2681.8.camel@mentorng.gurulabs.com> References: <1146064107.16554.32.camel@orodruin.boston.redhat.com> <20060426155819.GA12750@neu.nirvana> <1146067216.16554.54.camel@orodruin.boston.redhat.com> <20060426160717.GB12750@neu.nirvana> <1146068068.7016.19.camel@laptopd505.fenrus.org> <20060426161818.GC12750@neu.nirvana> <1146087763.2681.8.camel@mentorng.gurulabs.com> Message-ID: <44513A9D.2010101@redhat.com> Dax Kelson wrote: > On Wed, 2006-04-26 at 18:18 +0200, Axel Thimm wrote: > >> sorry, I'll take it back. I found the article (for German readers): >> >> http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/70092&words=ipw3945 >> >> and the quote was from Dax Kelson: >> >> http://article.gmane.org/gmane.linux.network/32622 >> >> So, indeed no love for ipw3945. > > Correct, my quote was not about the firmware it was: > > "It is very disappointing to see this binary user space daemon (that > must run as root, presumably to write into /sys/) requirement. I > recognize that it is a better poison than a binary kernel module." > > Basically, I'd rather have a closed userspace app whisper the secret > numbers to the hardware than have a close/binary only kernel module do > the same. > > Presumable somebody can sniff out what those secret numbers are (in a > legal fashion) then the someone can fork a new driver that includes that > functionality. Goodbye closed userspace app! > > The question is, would Jeff Garzik / Linus accept the forked driver into > the kernel? Also, will Intel, who are the only ones who know what the card is doing, continue to contribute to the driver? I suspect it'd actually be better to keep it split, and just replace the proprietary userland daemon with a free one, even though there's not strictly a *technical* need to have it there. -- Peter From bojan at rexursive.com Fri Apr 28 00:01:07 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 28 Apr 2006 00:01:07 +0000 (UTC) Subject: Mozilla 1.7.13 for FC5 updates References: <1145993426.14509.55.camel@coyote.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Is this in the works? Just another ping... RHEL4 already received the update. Can we get one for FC5? Or is it a little bit more complicated than that? -- Bojan From pjones at redhat.com Fri Apr 28 00:39:15 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 27 Apr 2006 20:39:15 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <200604271246.50811.lamont@gurulabs.com> References: <200604271246.50811.lamont@gurulabs.com> Message-ID: <1146184755.4883.5.camel@localhost.localdomain> On Thu, 2006-04-27 at 12:46 -0600, Lamont R. Peterson wrote: > All, > > Here are a couple of suggestions of how add auto-no-longer-used-dependency > removal to yum. > > 1. Enhance RPM to track a new flag from each package to indicate whether or > not it was installed auto-selected-for-dependency. How do you plan on discovering this data? During installation, basically everything is the latter, or equivalent, except for packages selected individually in a ks.cfg . -- Peter From rhally at mindspring.com Fri Apr 28 03:15:24 2006 From: rhally at mindspring.com (Richard Hally) Date: Thu, 27 Apr 2006 23:15:24 -0400 Subject: rhgb hangs Message-ID: <445188CC.5010903@mindspring.com> Has anyone run into the problem where booting with rhgb hangs the boot process at the point where X tries to start (to display the rhgb) and all you get is the large "X" in the middle of the screen? Ctrl-alt-backspace can be used to kill X and the boot continues. X starts normally later in the boot sequence. This is on a fully updated rawhide system. From tibbs at math.uh.edu Fri Apr 28 04:35:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 27 Apr 2006 23:35:01 -0500 Subject: Recent rawhide updates seem to have broken Gauche Message-ID: I'm reviewing the Gauche scheme compiler (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188168) and today after updating my rawhide mirror I found that the package that built yesterday no longer builds. I last updated yesterday, so I think it might be the recent glibc-kernheaders update. It's kind of hard to tell; a lot has changed recently. I've attached a complete failed build log to the above bug; here's where it starts to go off: source='os_dep.c' object='os_dep.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/sh ./depcomp \ /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"6.7\" -DPACKAGE_STRING=\"gc\ 6.7\" -DPACKAGE_BUGREPORT=\"Hans.Boehm at hp.com\" -DGC_VERSION_MAJOR=6 -DGC_VERSION_MINOR=7 -DPACKAGE=\"gc\" -DVERSION=\"6.7\" -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -DDONT_ADD_BYTE_AT_END=1 -DLARGE_CONFIG=1 -I./include -fexceptions -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fexceptions -c -o os_dep.lo os_dep.c os_dep.c:20:30: error: linux/version.h: No such file or directory In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:6:27: error: linux/linkage.h: No such file or directory In file included from /usr/include/asm-x86_64/signal.h:7, from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/linux/time.h:9: error: redefinition of 'struct timespec' /usr/include/linux/time.h:15: error: redefinition of 'struct timeval' /usr/include/linux/time.h:42: error: redefinition of 'struct itimerspec' In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:15: error: conflicting types for 'sigset_t' /usr/include/signal.h:50: error: previous declaration of 'sigset_t' was here In file included from /usr/include/asm/signal.h:5, from os_dep.c:27: /usr/include/asm-x86_64/signal.h:102: error: redefinition of 'struct sigaction' /usr/include/asm-x86_64/signal.h:103: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token /usr/include/asm-x86_64/signal.h:113: error: redefinition of 'struct sigaltstack' Any idea what's happening here? - J< From dakingun at gmail.com Fri Apr 28 04:44:56 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 28 Apr 2006 00:44:56 -0400 Subject: rhgb hangs In-Reply-To: <445188CC.5010903@mindspring.com> References: <445188CC.5010903@mindspring.com> Message-ID: On 4/27/06, Richard Hally wrote: > Has anyone run into the problem where booting with rhgb hangs the boot > process at the point where X tries to start (to display the rhgb) and > all you get is the large "X" in the middle of the screen? > Ctrl-alt-backspace can be used to kill X and the boot continues. X > starts normally later in the boot sequence. > me too. From wes.shull at gmail.com Fri Apr 28 07:02:15 2006 From: wes.shull at gmail.com (Wes Shull) Date: Fri, 28 Apr 2006 00:02:15 -0700 Subject: AW: Still much more than 350 sockets needed! In-Reply-To: <1146173916.28767.86.camel@shark.home> References: <17487.27886.76252.698013@zapata.pink> <17488.37391.181678.824942@zapata.pink> <1146173916.28767.86.camel@shark.home> Message-ID: On 4/27/06, Jon Burgess wrote: > Seems it is the kernel refusing to accept() any more connections, the > reason being that it takes 2 descriptors for each of your listeners:- Oh duh, right. One for the listener, and one for the server-side socket spawned when a connection comes in. Pay no attention to the idiot behind the curtain! I modified my script to use just a single listener, and then it does indeed work perfectly as expected. So I'm not seeing Hendrik's problem after all. --wes From buildsys at redhat.com Fri Apr 28 07:19:14 2006 From: buildsys at redhat.com (Build System) Date: Fri, 28 Apr 2006 03:19:14 -0400 Subject: rawhide report: 20060428 changes Message-ID: <200604280719.k3S7JEVC013001@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.15.1-5.FC5.20 ---------------------------- PyQt-3.16-1 ----------- * Thu Apr 27 2006 Than Ngo 3.16-1 - update to 3.16 - built with %{optflags} cman-kernel-2.6.15.1-0.FC5.19 ----------------------------- cyrus-sasl-2.1.21-11 -------------------- * Thu Apr 27 2006 Nalin Dahyabhai 2.1.21-11 - add unapplied patch which makes the DIGEST-MD5 plugin omit the realm argument when the environment has $CYRUS_SASL_DIGEST_MD5_OMIT_REALM set to a non-zero value, for testing purposes - add missing buildrequires on zlib-devel (#190113) dlm-kernel-2.6.15.1-0.FC5.17 ---------------------------- glibc-2.4.90-3 -------------- * Thu Apr 27 2006 Jakub Jelinek 2.4.90-3 - update from CVS - fix a typo in nscd.conf (#190085) - fix handling of SIGHUP in nscd when some caches are disabled (#189978) - make nscd paranoia mode working with non-root server-user (#189779) * Wed Apr 26 2006 Jakub Jelinek 2.4.90-2 - update from CVS - fix getaddrinfo (#190002) - add auto-propagate nscd.conf options (#177154) - fix nscd auditing (#169148) * Tue Apr 25 2006 Jakub Jelinek 2.4.90-1 - update from CVS glibc-kernheaders-3.0-18 ------------------------ * Thu Apr 27 2006 David Woodhouse 3.0-17 - Remove 'extern int errno;' from linux/unistd.h * Thu Apr 27 2006 David Woodhouse 3.0-17 - Fix mii.h, ethtool.h, version.h, blkpg.h * Thu Apr 27 2006 David Woodhouse 3.0-16 - ...this time with the right tarball so it's actually changed gnbd-kernel-2.6.15-5.FC5.26 --------------------------- gnu-efi-3.0c-1 -------------- * Thu Apr 27 2006 Chris Lumens 3.0c-1 - Upgrade to gnu-efi-3.0c. - Enable build on i386. groff-1.18.1.1-11 ----------------- * Wed Apr 26 2006 Adam Jackson - 1.18.1.1-11 - Rebuild for updated imake build rules. libICE-1.0.1-1 -------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libSM-1.0.1-1 ------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXaw-1.0.2-1 -------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 libXcursor-1.1.6-1 ------------------ * Thu Apr 27 2006 Adam Jackson 1.1.6-1 - Update to 1.1.6 libXdamage-1.0.3-1 ------------------ * Thu Apr 27 2006 Adam Jackson 1.0.3-1 - Update to 1.0.3 libXdmcp-1.0.1-1 ---------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXevie-1.0.1-1 ---------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXext-1.0.1-1 --------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXfontcache-1.0.2-1 --------------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 libXi-1.0.1-1 ------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXmu-1.0.1-1 -------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXpm-3.5.5-1 -------------- * Wed Apr 26 2006 Adam Jackson 3.5.5-1 - Update to 3.5.5 libXrandr-1.1.1-1 ----------------- * Thu Apr 27 2006 Adam Jackson 1.1.1-1 - Update to 1.1.1 libXrender-0.9.1-1 ------------------ * Thu Apr 27 2006 Adam Jackson 0.9.1-1 - Update to 0.9.1 libXres-1.0.1-1 --------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXvMC-1.0.2-1 --------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2. Drop #180902 patch, already fixed upstream. libXxf86dga-1.0.1-1 ------------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXxf86misc-1.0.1-1 -------------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libXxf86vm-1.0.1-1 ------------------ * Thu Apr 27 2006 Adam Jackson 1.0.1-1 - Update to 1.0.1 libdmx-1.0.2-1 -------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 libfontenc-1.0.2-1 ------------------ * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 libxkbfile-1.0.3-1 ------------------ * Thu Apr 27 2006 Adam Jackson 1.0.3-1 - Update to 1.0.3 libxkbui-1.0.2-1 ---------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update to 1.0.2 mkinitrd-5.0.36-1 ----------------- * Wed Apr 26 2006 Bill Nottingham - 5.0.36-1 - NFS root fixes - fix typo nss_ldap-250-1 -------------- * Thu Apr 27 2006 Nalin Dahyabhai - 250-1 - update to 250 - configure default time limits for binding/searching/idling openldap-2.3.21-2 ----------------- * Thu Apr 27 2006 Jay Fenlason 2.3.21-2 - Upgrade to 2.3.21 - Add two upstream patches for db-4.4.20 rpm-4.4.2-20 ------------ * Thu Apr 27 2006 Paul Nasrat - 4.4.2-20 - Update --trusted stubs for rpmk breakage scim-tables-0.5.6-5 ------------------- * Thu Apr 27 2006 Jens Petersen - 0.5.6-5 - obsolete old scim-tables-{japanese,korean} subpackages sip-4.4.3-1 ----------- * Thu Apr 27 2006 Than Ngo 4.4.3-1 - update to 4.4.3 - built with %{optflags} sysfsutils-1.3.0-2 ------------------ * Thu Apr 27 2006 Jeremy Katz - 1.3.0-2 - move .so to devel subpackage sysreport-1.4.3-6 ----------------- * Thu Apr 27 2006 Than Ngo 1.4.3-6 - fix #190053, Sysreport text refers to Red Hat Linux vte-0.12.1-2 ------------ * Fri Apr 28 2006 Matthias Clasen 0.12.1-2 - Update to 0.12.1 wpa_supplicant-1:0.4.8-10.fc6 ----------------------------- * Thu Apr 27 2006 Dan Williams - 0.4.8-10 - Add fix for madwifi and WEP (wpa_supplicant/hostap bud #140) (#rh190075#) - Fix up madwifi-ng private ioctl()s for r1331 and later - Update madwifi headers to r1475 xorg-x11-apps-1.0.3-1 --------------------- * Thu Apr 27 2006 Adam Jackson 1.0.3-1 - Updated xclock and xconsole xorg-x11-font-utils-1:1.0.2-2 ----------------------------- * Wed Apr 26 2006 Adam Jackson 1:1.0.2-2 - Update mkfontdir xorg-x11-proto-devel-7.0-12 --------------------------- * Thu Apr 27 2006 Adam Jackson 7.0-12 - Update to xproto 7.0.5 for misc fixes xorg-x11-server-utils-1.0.1-4 ----------------------------- * Thu Apr 27 2006 Adam Jackson 1.0.1-4 - Updated xmodmap, xrandr, xrdb, and xset. xorg-x11-xdm-1:1.0.4-1 ---------------------- * Thu Apr 27 2006 Adam Jackson 1:1.0.4-1 - Updated to version 1.0.4 xorg-x11-xfs-1:1.0.2-1 ---------------------- * Thu Apr 27 2006 Adam Jackson 1:1.0.2-1 - Update xfs and fstobdf xorg-x11-xinit-1.0.2-1 ---------------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update xinit to 1.0.2 xorg-x11-xkb-utils-1.0.2-1 -------------------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update setxkbmap, xkbevd, and xkbcomp * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xsm-1.0.2-1 -------------------- * Thu Apr 27 2006 Adam Jackson 1.0.2-1 - Update smproxy and rstart * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From pmatilai at laiskiainen.org Fri Apr 28 09:16:59 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 28 Apr 2006 02:16:59 -0700 (PDT) Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> Message-ID: On Thu, 27 Apr 2006, Jesse Keating wrote: > On Thu, 2006-04-27 at 18:13 +0300, Panu Matilainen wrote: >> One would probably want two levels of soft requires - the syntax is >> implemented in rpm but not sure if they're currently distinguishable >> outside the spec syntax: >> Requires(missingok) and Requires(hint) where "missingok" is something >> you'd want to install by default but removing of the dependency wont >> break the package, "hint" being .. well, a hint that this might be >> useful with this software but not installed automatically. Enhances is >> basically Suggests reversed for situations where Suggests cannot be >> used >> because the main package has no knowledge of the enhancing package. > > This seems to be spiraling into major complexity and lots of ways for > developers to get it wrong. Boo. I've never been very thrilled with > the idea of soft deps, and I really haven't seen it done right. What's so difficult about this: 1) It's hard dependency, without it the package will not run. 2) It's something that should be installed for "best user experience" but the package will run without it. Depsolvers treat it as any old hard dependency expect dont whine about it if it's removed. A good example of this would be evolution requiring spamassassin - evo will work just fine without spamassassin and in many environments the spamassassin is completely redundant to have on every workstation. 3) It's something that will bring in additional functionality useful for some users. Nothing more than a hint that a depsolver (GUI) might list "you might additionally find some of these useful". An example of this would be xmms + it's myriad of plugins: xmms-sid isn't something most people will care about. - Panu - From d.jacobfeuerborn at conversis.de Fri Apr 28 11:50:54 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 28 Apr 2006 13:50:54 +0200 Subject: Xorg signal 11's spontaneously In-Reply-To: <444CE442.60506@redhat.com> References: <4449077C.1050705@conversis.de> <444A18FB.7070107@conversis.de> <444CE442.60506@redhat.com> Message-ID: <4452019E.6010700@conversis.de> Adam Jackson wrote: [snip] > > Install the debuginfo packages, ssh in from another machine, su, attach > gdb to X, 'handle SIGPIPE nostop', and 'cont'. When the server > segfaults, 'bt f' should now give you useful backtrace info. > > May also be related to a crasher recently fixed for x4a4 glyphs; I'll > backpatch that into rawhide and stable shortly. After a couple of days the SIGSEGV happened again and this time I got a gdb backtrace which I attached to the fdo bug: https://bugs.freedesktop.org/show_bug.cgi?id=6704 Regards, Dennis From rdieter at math.unl.edu Fri Apr 28 11:59:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Apr 2006 06:59:39 -0500 Subject: Mozilla 1.7.13 for FC5 updates References: <1145993426.14509.55.camel@coyote.rexursive.com> Message-ID: Bojan Smojver wrote: > Bojan Smojver rexursive.com> writes: > >> Is this in the works? > > Just another ping... > > RHEL4 already received the update. Can we get one for FC5? Or is it a > little bit more complicated than that? Put it in bugzilla.redhat.com then. -- Rex From steve at silug.org Fri Apr 28 13:43:28 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 28 Apr 2006 08:43:28 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <20060428134327.GA29544@osiris.silug.org> On Fri, Apr 28, 2006 at 02:16:59AM -0700, Panu Matilainen wrote: > 3) It's something that will bring in additional functionality useful > for some users. Nothing more than a hint that a depsolver (GUI) might > list "you might additionally find some of these useful". An example of > this would be xmms + it's myriad of plugins: xmms-sid isn't something > most people will care about. Stupid question, but how hard would it be for a depsolver to work this out in reverse? For example, xmms-sid requires xmms, so when I'm installing xmms, notice that xmms-sid requires it, and suggest it as a possible enhancement? I could see something like that being *really* handy with perl-Kwiki and the dozen or so plugins that are available in Extras right now. It would suck if I had to modify the main perl-Kwiki package every time someone packages up another plugin. (That is, of course, assuming that someone other than me packages some plugins... ;) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From pmatilai at laiskiainen.org Fri Apr 28 14:50:21 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 28 Apr 2006 17:50:21 +0300 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <20060428134327.GA29544@osiris.silug.org> References: <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> <20060428134327.GA29544@osiris.silug.org> Message-ID: <1146235821.21492.25.camel@weasel.turre.laiskiainen.org> On Fri, 2006-04-28 at 08:43 -0500, Steven Pritchard wrote: > On Fri, Apr 28, 2006 at 02:16:59AM -0700, Panu Matilainen wrote: > > 3) It's something that will bring in additional functionality useful > > for some users. Nothing more than a hint that a depsolver (GUI) might > > list "you might additionally find some of these useful". An example of > > this would be xmms + it's myriad of plugins: xmms-sid isn't something > > most people will care about. > > Stupid question, but how hard would it be for a depsolver to work this > out in reverse? For example, xmms-sid requires xmms, so when I'm > installing xmms, notice that xmms-sid requires it, and suggest it as a > possible enhancement? I've thought about this - getting the reverse dependencies is not hard at all, basically the depsolver could do the equivalent of this: [root at weasel ~]# repoquery --whatrequires --alldeps perl-Kwiki perl-Kwiki-Attachments-0:0.18-1.fc5.noarch perl-Kwiki-UserName-0:0.14-3.fc5.noarch perl-Kwiki-NewPage-0:0.12-3.fc5.noarch perl-Kwiki-ModPerl-0:0.09-2.fc5.noarch perl-Kwiki-Search-0:0.12-3.fc5.noarch perl-Kwiki-Archive-Rcs-0:0.15-4.fc5.noarch perl-Kwiki-Revisions-0:0.15-3.fc5.noarch perl-Kwiki-Raw-0:0.02-2.fc5.noarch perl-Kwiki-0:0.38-3.fc5.noarch perl-Kwiki-UserPreferences-0:0.13-3.fc5.noarch perl-Kwiki-Diff-0:0.03-2.fc5.noarch perl-Kwiki-Users-Remote-0:0.04-2.fc5.noarch perl-Kwiki-RecentChanges-0:0.13-3.fc5.noarch What's problematic with this approach is that it only works for certain types of packages, something resembling an application in other words. Try it on a library and the results are probably not what you want. If there was a good way to distinguish application vs pure library packages that might well be sufficient as a suggests/enhances mechanism. Unfortunately it's not that clear. Taking perl-Kwiki as an example, it lists "Development/Libraries" as it's rpm group, it doesn't belong to any comps groups and it doesn't look like an application in the sense that it doesn't put anything into your path (which is a very bad heuristics anyway since many library packages have some utility binaries) etc. It'd be very likely to be classified as a library of sorts by any obvious heuristics to determine whether "suggests/enhances"-reverse depends logic should be applied. > I could see something like that being *really* handy with perl-Kwiki > and the dozen or so plugins that are available in Extras right now. > It would suck if I had to modify the main perl-Kwiki package every > time someone packages up another plugin. (That is, of course, > assuming that someone other than me packages some plugins... ;) That's what Enhances is all about: the main package wouldn't have to be aware of those other packages, those plugin packages would just have to add "Enhances: perl-Kwiki". - Panu - From kevin.kofler at chello.at Fri Apr 28 15:43:33 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 28 Apr 2006 15:43:33 +0000 (UTC) Subject: [NEW IDEA] Automatic removal of dependencies References: <200604271246.50811.lamont@gurulabs.com> <1146184755.4883.5.camel@localhost.localdomain> Message-ID: Peter Jones redhat.com> writes: > How do you plan on discovering this data? During installation, > basically everything is the latter, or equivalent, except for packages > selected individually in a ks.cfg . Well, I'd say (for an interactive install) everything with a checkmark next to it (no matter whether that's because it's part of defaults of a selected group and hasn't been unchecked or because it has been checked explicitly) is "explicitly installed". Everything else (which either is not listed as an explicit option at all or was unchecked, but had to be pulled in anyway as a dependency) is "automatically installed". (Of course, that requires cooperation from the installer and from RPM. If the flags are kept track of only by some higher-level app like aptitude, then marking everything installed at install time "explicitly installed" is the only option, and apparently that's what aptitude does.) Kevin Kofler From sdl.web at gmail.com Fri Apr 28 15:54:53 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 28 Apr 2006 16:54:53 +0100 Subject: firefox miniicon has extra black pixels References: <6280325c0604260246p1941e83cq5bbc80373c04af35@mail.gmail.com> Message-ID: n0dalus writes: > On 4/26/06, Thomas M Steenholdt wrote: >> >> Just looks like a different icon to me, which could be expected since >> those are completely different distros released with a loong time >> between them. > > The Firefox tarballs have the proper icon, but ever since December > 2004 it's been being replaced in Fedora's source rpm. I think this > could have been done to make the xpm more seperate, but they must have > used a really ancient xpm to do it. Instead of bundling an xpm with > the source rpm, the spec should be copying the xpm from the firefox > official icon directory in the tarball. > > I'd say it's almost certainly a bug, and I suppose should be filed if > it's not in bugzilla already. > > n0dalus. n0dalus, There is something wrong with my bugzilla account. Do you mind submitting the bug report? Cheers, -- Leon From pjones at redhat.com Fri Apr 28 16:05:13 2006 From: pjones at redhat.com (Peter Jones) Date: Fri, 28 Apr 2006 12:05:13 -0400 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <200604271246.50811.lamont@gurulabs.com> <1146184755.4883.5.camel@localhost.localdomain> Message-ID: <1146240313.1491.9.camel@localhost.localdomain> On Fri, 2006-04-28 at 15:43 +0000, Kevin Kofler wrote: > Peter Jones redhat.com> writes: > > How do you plan on discovering this data? During installation, > > basically everything is the latter, or equivalent, except for packages > > selected individually in a ks.cfg . > > Well, I'd say (for an interactive install) everything with a checkmark next to > it (no matter whether that's because it's part of defaults of a selected group > and hasn't been unchecked or because it has been checked explicitly) is > "explicitly installed". Everything else (which either is not listed as an > explicit option at all or was unchecked, but had to be pulled in anyway as a > dependency) is "automatically installed". So that basically means that you want to mark everything which is listed in comps but isn't in "base" or "core" as user-installed. That's going to result in a view of "safe to remove" that doesn't reflect what users want or expect. > (Of course, that requires cooperation from the installer and from RPM. If the > flags are kept track of only by some higher-level app like aptitude, then > marking everything installed at install time "explicitly installed" is the only > option, and apparently that's what aptitude does.) I think that's the only way to actually behave conservatively enough to match user expectations. I also think it stinks. -- Peter From n0dalus+redhat at gmail.com Fri Apr 28 16:46:33 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 29 Apr 2006 02:16:33 +0930 Subject: firefox miniicon has extra black pixels In-Reply-To: References: <6280325c0604260246p1941e83cq5bbc80373c04af35@mail.gmail.com> Message-ID: <6280325c0604280946s7927a04coc3eaed617e67c6d3@mail.gmail.com> On 4/29/06, Leon wrote: > > There is something wrong with my bugzilla account. Do you mind > submitting the bug report? > No problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190188 n0dalus. From mike at miketc.com Fri Apr 28 17:15:52 2006 From: mike at miketc.com (Mike Chambers) Date: Fri, 28 Apr 2006 12:15:52 -0500 Subject: Email list down? Message-ID: <1146244553.11053.1.camel@scrappy.miketc.com> I don't seem to be getting any emails from any Fedora list, maybe few more. So I am asking if any or all of them are down or not? Sent on Apr 28th at 12:15 CST. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you aren't getting any!" From sdl.web at gmail.com Fri Apr 28 17:27:09 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 28 Apr 2006 18:27:09 +0100 Subject: firefox miniicon has extra black pixels References: <6280325c0604260246p1941e83cq5bbc80373c04af35@mail.gmail.com> <6280325c0604280946s7927a04coc3eaed617e67c6d3@mail.gmail.com> Message-ID: n0dalus writes: > On 4/29/06, Leon wrote: >> >> There is something wrong with my bugzilla account. Do you mind >> submitting the bug report? >> > > No problem. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190188 > > n0dalus. That's awesome! -- Leon From mpeters at mac.com Fri Apr 28 17:35:49 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 28 Apr 2006 10:35:49 -0700 Subject: Email list down? In-Reply-To: <1146244553.11053.1.camel@scrappy.miketc.com> References: <1146244553.11053.1.camel@scrappy.miketc.com> Message-ID: <1146245750.2456.46.camel@atlantis.mpeters.local> On Fri, 2006-04-28 at 12:15 -0500, Mike Chambers wrote: > I don't seem to be getting any emails from any Fedora list, maybe few > more. So I am asking if any or all of them are down or not? I received this at 10:33 PST - but yesterday, I was getting some replies before the original message by a good hour or so (including some I sent) so I think there were (are?) some burps in the list server. Obviously some people got them first, so maybe (with me) it was a burp in my incoming mail server. From jspaleta at gmail.com Fri Apr 28 18:00:43 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Apr 2006 14:00:43 -0400 Subject: How should i file this prelink hiccup? Message-ID: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> Summary: prelink is not operating on firefox-bin this seems to be because the libraries libmozjs.so and libxpcom.so are not in the standard linking path. So when prelink goes to prelink firefox-bin it gets confused and aborts. Now this isnt a problem for normal firefox operation because the firefox shell script redefines where libraries are being looked for. But that shell trickery seems to be confusing the default prelinking. Don't we weant firefox-bin to be prelinked like other binaries? If the answer is yes, how do we adjust things so the nightly prelink script does its job on firefox-bin and mozilla-bin? And how exactly do i file this issue in bugzilla? -jef From rdieter at math.unl.edu Fri Apr 28 18:34:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Apr 2006 13:34:36 -0500 Subject: How should i file this prelink hiccup? In-Reply-To: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> References: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > Summary: > prelink is not operating on firefox-bin > > this seems to be because the libraries libmozjs.so and libxpcom.so are > not in the standard linking path. So when prelink goes to prelink > firefox-bin it gets confused and aborts. > > Now this isnt a problem for normal firefox operation because the > firefox shell script redefines where libraries are being looked for. > But that shell trickery seems to be confusing the default prelinking. > Don't we weant firefox-bin to be prelinked like other binaries? If > the answer is yes, how do we adjust things so the nightly prelink > script does its job on firefox-bin and mozilla-bin? > And how exactly do i file this issue in bugzilla? I'd say file against firefox. They *used* to have a hack/workaround for this in mozilla's (and firefox's?) rpm packaging to help prelink, and that was to use linker flags something like: -Wl,-rpath,/usr/lib/firefox-1.5 -- Rex From arjan at fenrus.demon.nl Fri Apr 28 18:38:05 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 28 Apr 2006 20:38:05 +0200 Subject: How should i file this prelink hiccup? In-Reply-To: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> References: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> Message-ID: <1146249485.3126.31.camel@laptopd505.fenrus.org> On Fri, 2006-04-28 at 14:00 -0400, Jeff Spaleta wrote: > > Now this isnt a problem for normal firefox operation because the > firefox shell script redefines where libraries are being looked for. > But that shell trickery seems to be confusing the default prelinking. > Don't we weant firefox-bin to be prelinked like other binaries? If > the answer is yes, how do we adjust things so the nightly prelink > script does its job on firefox-bin and mozilla-bin? > And how exactly do i file this issue in bugzilla? maybe a good question is asking why on earth firefox is doing this ? ;) From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 28 18:57:27 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 28 Apr 2006 20:57:27 +0200 Subject: How should i file this prelink hiccup? In-Reply-To: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> (Jeff Spaleta's message of "Fri, 28 Apr 2006 14:00:43 -0400") References: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> Message-ID: <87bqul7cko.fsf@kosh.bigo.ensc.de> jspaleta at gmail.com ("Jeff Spaleta") writes: > prelink is not operating on firefox-bin > > this seems to be because the libraries libmozjs.so and libxpcom.so are > not in the standard linking path. So when prelink goes to prelink > firefox-bin it gets confused and aborts. > > Now this isnt a problem for normal firefox operation because the > firefox shell script redefines where libraries are being looked for. Perhaps it would help to set an $ORIGIN/lib rpath for firefox-bin? Enrico From jspaleta at gmail.com Fri Apr 28 19:01:03 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Apr 2006 15:01:03 -0400 Subject: How should i file this prelink hiccup? In-Reply-To: <87bqul7cko.fsf@kosh.bigo.ensc.de> References: <604aa7910604281100g5ea2b107ra7dbe114bccf0a97@mail.gmail.com> <87bqul7cko.fsf@kosh.bigo.ensc.de> Message-ID: <604aa7910604281201u7195d7ach1502f92d24cf77fd@mail.gmail.com> On 4/28/06, Enrico Scholz wrote: > Perhaps it would help to set an $ORIGIN/lib rpath for firefox-bin? set an environment variable in the scope of prelink's normal cronjob? -jef From tibbs at math.uh.edu Fri Apr 28 19:02:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 28 Apr 2006 14:02:27 -0500 Subject: Recent rawhide updates seem to have broken Gauche In-Reply-To: (Jason L. Tibbitts, III's message of "Thu, 27 Apr 2006 23:35:01 -0500") References: Message-ID: This seems to be fixed with last night's glibc-kernheaders update. - J< From mpeters at mac.com Fri Apr 28 19:12:51 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 28 Apr 2006 12:12:51 -0700 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> Message-ID: <1146251572.2456.58.camel@atlantis.mpeters.local> On Thu, 2006-04-27 at 06:50 -0700, Panu Matilainen wrote: > > Recent rpm versions support soft dependencies, eg > Requires(hint): foo > Provides(hint): bar > > ..and have corresponding "aliases" for spec file syntax: > Suggests: foo > Enhances: bar > > Too bad it doesn't seem like we're getting a version of rpm > supporting those anytime soon :-/ I was told on the rpm list by an rpm developer that it would probably be at least a year before repository front ends properly supported those new features anyway - so if I used them, don't expect them to do what I want in repositories for awhile. From mpeters at mac.com Fri Apr 28 19:22:07 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 28 Apr 2006 12:22:07 -0700 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> References: <604aa7910604211608i3be2e8c2ra00bcb5a31fd3949@mail.gmail.com> <1145971156.6969.3.camel@atlantis.mpeters.local> <20060425152318.24f0497f@duras.int.addix.net> <1145994273.22802.121.camel@localhost.localdomain> <1146029865.6969.65.camel@atlantis.mpeters.local> <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146252128.2456.67.camel@atlantis.mpeters.local> On Thu, 2006-04-27 at 11:24 -0400, Jesse Keating wrote: > > This seems to be spiraling into major complexity and lots of ways for > developers to get it wrong. Boo. I've never been very thrilled with > the idea of soft deps, and I really haven't seen it done right. I like them. I'm sure they can be abused, but for example - perl-Readonly) It's a perl module (am I observant or what?? ;) Anyway - applications that use it will require perl(Readonly) perl-Readonly gets a performance boost from perl(Readonly::XS) but does not explicitly require it. That is a case where using a soft dependency will help. A perl program requires perl(Readonly) which suggests perl(Readonly::XS). perl(Readonly) is pure perl, noarch. perl(Readonly::XS) is a binary. If there were a problem building the binary on one or more platform, it might not be available, so we don't want to have it be required by perl-Readonly. A suggest though we _do_ want. We also can't have perl(Readonly::XS) required by the perl-Readonly rpm because that causes a circular dependency at build time - as perl-Readonly-XS requires perl(Readonly) to build. But a suggest - the build machine could (should) ignore suggests. That's why it is a good thing to have suggests. From jkeating at j2solutions.net Fri Apr 28 20:48:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 28 Apr 2006 16:48:28 -0400 Subject: rhgb hangs In-Reply-To: <445188CC.5010903@mindspring.com> References: <445188CC.5010903@mindspring.com> Message-ID: <1146257308.13972.15.camel@ender> On Thu, 2006-04-27 at 23:15 -0400, Richard Hally wrote: > Has anyone run into the problem where booting with rhgb hangs the > boot > process at the point where X tries to start (to display the rhgb) and > all you get is the large "X" in the middle of the screen? > Ctrl-alt-backspace can be used to kill X and the boot continues. X > starts normally later in the boot sequence. This is due to networking being slightly busted with this kernel. Networking is broken even to the point of RHGB connecting to itself or something like that. Revert your kernel and all will work. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From steve at silug.org Fri Apr 28 21:09:54 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 28 Apr 2006 16:09:54 -0500 Subject: [NEW IDEA] Automatic removal of dependencies In-Reply-To: <1146235821.21492.25.camel@weasel.turre.laiskiainen.org> References: <1146111894.7621.8.camel@localhost.localdomain> <6280325c0604262135m73f59414te5849c6f96bab2be@mail.gmail.com> <1146118075.7621.69.camel@localhost.localdomain> <1146148196.2730.103.camel@dhcp83-49.boston.redhat.com> <1146150821.7567.20.camel@weasel.turre.laiskiainen.org> <1146151453.11688.3.camel@dhcp83-49.boston.redhat.com> <20060428134327.GA29544@osiris.silug.org> <1146235821.21492.25.camel@weasel.turre.laiskiainen.org> Message-ID: <20060428210954.GA3418@osiris.silug.org> On Fri, Apr 28, 2006 at 05:50:21PM +0300, Panu Matilainen wrote: > On Fri, 2006-04-28 at 08:43 -0500, Steven Pritchard wrote: > > Stupid question, but how hard would it be for a depsolver to work this > > out in reverse? For example, xmms-sid requires xmms, so when I'm > > installing xmms, notice that xmms-sid requires it, and suggest it as a > > possible enhancement? > > I've thought about this - getting the reverse dependencies is not hard > at all, basically the depsolver could do the equivalent of this: > > [root at weasel ~]# repoquery --whatrequires --alldeps perl-Kwiki [...] > What's problematic with this approach is that it only works for certain > types of packages, something resembling an application in other words. > Try it on a library and the results are probably not what you want. So how would you fix that? Walk through all the file provides/requires and all the other implicit dependencies? And if you did all that, how painful would it be? :-) > Taking perl-Kwiki as an example, it lists "Development/Libraries" as > it's rpm group, That's because cpanspec is hard-coded to add that Group: tag. > it doesn't belong to any comps groups That's because I haven't added any of my packages to comps. (Shame on me, I know, it's on my todo list.) > and it doesn't look like an application in the sense that it doesn't > put anything into your path There's just the "kwiki" script in /usr/bin/... > (which is a very bad heuristics anyway since many library packages > have some utility binaries) etc. It'd be very likely to be classified > as a library of sorts by any obvious heuristics to determine whether > "suggests/enhances"-reverse depends logic should be applied. Even having this available as a convoluted command involving repoquery would be pretty cool. :-) > That's what Enhances is all about: the main package wouldn't have to be > aware of those other packages, those plugin packages would just have to > add "Enhances: perl-Kwiki". Ah, my sleep-deprived mind was reading that backwards. That makes a whole lot more sense. ;-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From rhally at mindspring.com Fri Apr 28 23:31:54 2006 From: rhally at mindspring.com (Richard Hally) Date: Fri, 28 Apr 2006 19:31:54 -0400 Subject: rhgb hangs In-Reply-To: <1146257308.13972.15.camel@ender> References: <445188CC.5010903@mindspring.com> <1146257308.13972.15.camel@ender> Message-ID: <4452A5EA.7040003@mindspring.com> Jesse Keating wrote: > On Thu, 2006-04-27 at 23:15 -0400, Richard Hally wrote: >> Has anyone run into the problem where booting with rhgb hangs the >> boot >> process at the point where X tries to start (to display the rhgb) and >> all you get is the large "X" in the middle of the screen? >> Ctrl-alt-backspace can be used to kill X and the boot continues. X >> starts normally later in the boot sequence. > > This is due to networking being slightly busted with this kernel. > Networking is broken even to the point of RHGB connecting to itself or > something like that. Revert your kernel and all will work. > > Thanks for the info Jesse! It is easy enough to just hit Ctrl-alt-backspace and continue the boot. Richard From seg at haxxed.com Sat Apr 29 03:25:01 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 28 Apr 2006 22:25:01 -0500 Subject: Beware of bash 3.1 Message-ID: <1146281102.7621.192.camel@localhost.localdomain> Okay, I originally posted about this a few months ago: http://www.redhat.com/archives/rhl-devel-list/2006-January/msg00491.html A seemingly harmless corner case. Here's another one: one of my guys ran a java install script as sudo and fubar'd the box he was following these instructions http://fedorasolved.org/browser-solutions/java-i386/ Step 9, which looks like this: cat < /etc/profile.d/java.sh export JAVA_HOME=/opt/jre1.5.0_06 export PATH=$JAVA_HOME/bin:$PATH EOF Results in this: # cat /etc/profile.d/java.sh export JAVA_HOME=/opt/jre1.5.0_06 export PATH=/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin Which is wrong. The fix is of course: # cat < ~/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=\$JAVA_HOME/bin:\$PATH > EOF # cat ~/java.sh export JAVA_HOME=/opt/jre1.5.0_06 export PATH=$JAVA_HOME/bin:$PATH So... bash 3.1 has definitely changed the way variable expansion is done, namely it expands things it didn't used to expand. Bug or feature? Either way, beware. (And there's the larger issue, being that those instructions suck, instead you should be using http://www.city-fan.org/tips/JpackageJava which is linked from http://www.fedoraproject.org/wiki/JavaFAQ and thus appears to be officially blessed. But that's not really an issue for -devel...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Apr 29 03:59:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 28 Apr 2006 22:59:49 -0500 Subject: Beware of bash 3.1 (never mind, kinda) In-Reply-To: <1146281102.7621.192.camel@localhost.localdomain> References: <1146281102.7621.192.camel@localhost.localdomain> Message-ID: <1146283189.7621.201.camel@localhost.localdomain> Okay, I was dumb and didn't actually test on bash 3.0. No more FC4 boxes around. And my debian box is up to 3.1 now as well. Here's my gentoo embedded chroot: burgertime / # bash --version GNU bash, version 3.00.16(1)-release (i586-gentoo-linux-uclibc) Copyright (C) 2004 Free Software Foundation, Inc. burgertime / # cat < asfasdfasd > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=$JAVA_HOME/bin:$PATH > EOF burgertime / # cat asfasdfasd export JAVA_HOME=/opt/jre1.5.0_06 export PATH=/bin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/seg/bin And going back to my original bug: burgertime ~ # echo ${PWD/#$HOME/~} ~ burgertime ~ # echo ~ /home/seg And under FC5: $ echo ${PWD/#$HOME/~} /home/seg $ echo ~ /home/seg So now I'm confused and embarrassed, and those instructions are broken on FC4 as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Apr 29 04:02:40 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 28 Apr 2006 23:02:40 -0500 Subject: Beware of bash 3.1 (never mind, kinda) In-Reply-To: <1146283189.7621.201.camel@localhost.localdomain> References: <1146281102.7621.192.camel@localhost.localdomain> <1146283189.7621.201.camel@localhost.localdomain> Message-ID: <1146283361.7621.203.camel@localhost.localdomain> On Fri, 2006-04-28 at 22:59 -0500, Callum Lerwick wrote: > So now I'm confused and embarrassed, and those instructions are broken > on FC4 as well. Edit: Sonar Guy fixed 'em. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Sat Apr 29 04:07:44 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 28 Apr 2006 22:07:44 -0600 Subject: Beware of bash 3.1 In-Reply-To: <1146281102.7621.192.camel@localhost.localdomain> References: <1146281102.7621.192.camel@localhost.localdomain> Message-ID: <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> On 4/28/06, Callum Lerwick wrote: > Okay, I originally posted about this a few months ago: > > http://www.redhat.com/archives/rhl-devel-list/2006-January/msg00491.html > > A seemingly harmless corner case. Here's another one: > > one of my guys ran a java install script as sudo and fubar'd > the box > he was following these instructions > http://fedorasolved.org/browser-solutions/java-i386/ > > Step 9, which looks like this: > > cat < /etc/profile.d/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=$JAVA_HOME/bin:$PATH > EOF > > Results in this: > > # cat /etc/profile.d/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin > > Which is wrong. The fix is of course: > > # cat < ~/java.sh > > export JAVA_HOME=/opt/jre1.5.0_06 > > export PATH=\$JAVA_HOME/bin:\$PATH > > EOF > > # cat ~/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=$JAVA_HOME/bin:$PATH > > So... bash 3.1 has definitely changed the way variable expansion is > done, namely it expands things it didn't used to expand. Bug or feature? > Either way, beware. > In my bash addled brain.. I would say it is a bug. Expanding out data that is being done in an EOF does not look in any way sh/ksh/etc compliant.. and just prone to breaking too many things. -- Stephen J Smoogen. CSIRT/Linux System Administrator From smooge at gmail.com Sat Apr 29 04:11:46 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 28 Apr 2006 22:11:46 -0600 Subject: Beware of bash 3.1 In-Reply-To: <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> References: <1146281102.7621.192.camel@localhost.localdomain> <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> Message-ID: <80d7e4090604282111t2afc06adlee835f46cb93b392@mail.gmail.com> On 4/28/06, Stephen John Smoogen wrote: > > cat < /etc/profile.d/java.sh > > export JAVA_HOME=/opt/jre1.5.0_06 > > export PATH=$JAVA_HOME/bin:$PATH > > EOF > > > > > In my bash addled brain.. I would say it is a bug. Expanding out data > that is being done in an EOF does not look in any way sh/ksh/etc > compliant.. and just prone to breaking too many things. > Ok definately need sleep. It is doing what it is supposed to do in EOF sections. I am going to bed.. nevermind -- Stephen J Smoogen. CSIRT/Linux System Administrator From seg at haxxed.com Sat Apr 29 04:14:19 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 28 Apr 2006 23:14:19 -0500 Subject: Beware of bash 3.1 In-Reply-To: <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> References: <1146281102.7621.192.camel@localhost.localdomain> <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> Message-ID: <1146284060.7621.208.camel@localhost.localdomain> On Fri, 2006-04-28 at 22:07 -0600, Stephen John Smoogen wrote: > In my bash addled brain.. I would say it is a bug. Expanding out data > that is being done in an EOF does not look in any way sh/ksh/etc > compliant.. and just prone to breaking too many things. Yeah I now realize I've hit this before, with people putting config files inside specs instead of sourcing them. Icky. Several layers of variable/macro expansion is fun... (NOTABUG in bash 3.1 after all...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Apr 29 08:22:41 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 29 Apr 2006 10:22:41 +0200 Subject: Beware of bash 3.1 In-Reply-To: <80d7e4090604282111t2afc06adlee835f46cb93b392@mail.gmail.com> References: <1146281102.7621.192.camel@localhost.localdomain> <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> <80d7e4090604282111t2afc06adlee835f46cb93b392@mail.gmail.com> Message-ID: <20060429102241.1618f83b@python2> Stephen John Smoogen wrote : > On 4/28/06, Stephen John Smoogen wrote: > > > > cat < /etc/profile.d/java.sh > > > export JAVA_HOME=/opt/jre1.5.0_06 > > > export PATH=$JAVA_HOME/bin:$PATH > > > EOF > > > > > > > > > In my bash addled brain.. I would say it is a bug. Expanding out data > > that is being done in an EOF does not look in any way sh/ksh/etc > > compliant.. and just prone to breaking too many things. > > > > Ok definately need sleep. It is doing what it is supposed to do in EOF > sections. I am going to bed.. nevermind Yeah, isn't the proper fix to simply single quote 'EOF'? Like this : cat << 'EOF' > /etc/profile.d/java.sh export JAVA_HOME=/opt/jre1.5.0_06 export PATH=$JAVA_HOME/bin:$PATH EOF This should keep the $VARIABLES from being expanded in the resulting file. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2171_FC6 Load : 0.01 0.08 0.04 From ellson at research.att.com Sat Apr 29 14:44:22 2006 From: ellson at research.att.com (John Ellson) Date: Sat, 29 Apr 2006 10:44:22 -0400 Subject: Confused about /usr/bin/nm, linker, and stripped libs Message-ID: <44537BC6.1080201@research.att.com> These days rpm installs most libs stripped of their symbols, which is fine as it makes them smaller and presumably load faster. But how does the linker resolve symbols against stripped libs? And if the linker can do it, why can't /usr/bin/nm ? John From mitr at volny.cz Sat Apr 29 14:50:15 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 29 Apr 2006 16:50:15 +0200 Subject: Confused about /usr/bin/nm, linker, and stripped libs In-Reply-To: <44537BC6.1080201@research.att.com> References: <44537BC6.1080201@research.att.com> Message-ID: <44537D27.6060406@volny.cz> Hello, John Ellson napsal(a): > These days rpm installs most libs stripped of their symbols, which is > fine as it makes them smaller and presumably load faster. > > But how does the linker resolve symbols against stripped libs? And if > the linker can do it, why can't /usr/bin/nm ? There are two types of symbol information: - ELF symbols, used for linking (both static and dynamic) - debugging information, used only by the debugger. strip and nm works on debugging information, not ELF symbols. You can use e.g. readelf to see the ELF symbols. Mirek From philipp_subx at redfish-solutions.com Sat Apr 29 16:29:32 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 29 Apr 2006 10:29:32 -0600 Subject: Q. about debugging/troubleshooting Thunderbird Message-ID: <4453946C.60501@redfish-solutions.com> I was trying to build an image of Thunderbird from the FC3 SRPM's, and tweaked the .spec and sources to include a patch someone sent me and to replace the --disable-debug in the config file with --enable-debug instead. Unfortunately, when I run the build image, there's no sign at all of where the output is going. What am I missing? If I kick off the process from the command line, and then do a "ps", I see a couple of wrapper processes hanging around, and then the binary itself as the youngest child process... Doing an "lsof" on that process shows various .so's open, .jars, .msf's... sockets, etc... And yes, even the controlling terminal. But the printf's don't seem to be going anywhere. Any ideas? Thanks, -Philip From seandarcy2 at gmail.com Sat Apr 29 18:34:57 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 29 Apr 2006 14:34:57 -0400 Subject: kernel-2.6.16-1.2171_FC6 : "Cannot allocate memory" Message-ID: Using kernel-2.6.16-1.2171_FC6 on amd64. On boot, both ntpd and nfsd fail: Apr 29 14:14:13 localhost ntpdate[1877]: sendto(127.127.1.0): Cannot allocate memory Apr 29 14:15:30 localhost nfsd[1914]: nfssvc: Cannot allocate memory 2.6.16-1.2153_FC6 works fine. There some trick with the new kernel?? sean From casimiro.barreto at gmail.com Sat Apr 29 18:51:50 2006 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 29 Apr 2006 15:51:50 -0300 Subject: kernel-2.6.16-1.2171_FC6 : "Cannot allocate memory" In-Reply-To: References: Message-ID: <4453B5C6.70000@gmail.com> Hello, Little of toppic: where is available for download the yum.repos.d kernel.repo file??? Best wishes, Casimiro sean escreveu: > Using kernel-2.6.16-1.2171_FC6 on amd64. On boot, both ntpd and nfsd > fail: > > Apr 29 14:14:13 localhost ntpdate[1877]: sendto(127.127.1.0): Cannot > allocate memory > Apr 29 14:15:30 localhost nfsd[1914]: nfssvc: Cannot allocate memory > > 2.6.16-1.2153_FC6 works fine. > > There some trick with the new kernel?? > > sean > From arjan at fenrus.demon.nl Sat Apr 29 21:28:35 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 29 Apr 2006 23:28:35 +0200 Subject: Confused about /usr/bin/nm, linker, and stripped libs In-Reply-To: <44537BC6.1080201@research.att.com> References: <44537BC6.1080201@research.att.com> Message-ID: <1146346115.3125.16.camel@laptopd505.fenrus.org> On Sat, 2006-04-29 at 10:44 -0400, John Ellson wrote: > These days rpm installs most libs stripped of their symbols, which is > fine as it makes them smaller and presumably load faster. > > But how does the linker resolve symbols against stripped libs? And if > the linker can do it, why can't /usr/bin/nm ? just pass -D to nm... or use eu-readelf ;) From smooge at gmail.com Sun Apr 30 01:00:23 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 29 Apr 2006 19:00:23 -0600 Subject: Beware of bash 3.1 In-Reply-To: <20060429102241.1618f83b@python2> References: <1146281102.7621.192.camel@localhost.localdomain> <80d7e4090604282107t49741e94iba0bac307c5f6890@mail.gmail.com> <80d7e4090604282111t2afc06adlee835f46cb93b392@mail.gmail.com> <20060429102241.1618f83b@python2> Message-ID: <80d7e4090604291800v18c37ffex70057eac50fa31a3@mail.gmail.com> On 4/29/06, Matthias Saou wrote: > Stephen John Smoogen wrote : > > > On 4/28/06, Stephen John Smoogen wrote: > > > > > > cat < /etc/profile.d/java.sh > > > > export JAVA_HOME=/opt/jre1.5.0_06 > > > > export PATH=$JAVA_HOME/bin:$PATH > > > > EOF > > > > > > Yeah, isn't the proper fix to simply single quote 'EOF'? Like this : > > cat << 'EOF' > /etc/profile.d/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=$JAVA_HOME/bin:$PATH > EOF > > This should keep the $VARIABLES from being expanded in the resulting file. > Yes I think it is. I prefer to stay away from EOF data's because of forgetting one thing or another can cause weird thing to happen. I think I have used it more in Perl (and maybe Awk) than I have in Bash/Ksh -- Stephen J Smoogen. CSIRT/Linux System Administrator From cmadams at hiwaay.net Sun Apr 30 02:14:34 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 29 Apr 2006 21:14:34 -0500 Subject: Beware of bash 3.1 In-Reply-To: <1146281102.7621.192.camel@localhost.localdomain> References: <1146281102.7621.192.camel@localhost.localdomain> Message-ID: <20060430021434.GA629749@hiwaay.net> Once upon a time, Callum Lerwick said: > Step 9, which looks like this: > > cat < /etc/profile.d/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=$JAVA_HOME/bin:$PATH > EOF > > Results in this: > > # cat /etc/profile.d/java.sh > export JAVA_HOME=/opt/jre1.5.0_06 > export PATH=/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin > So... bash 3.1 has definitely changed the way variable expansion is > done, namely it expands things it didn't used to expand. Bug or feature? > Either way, beware. Nope, nope, and nope. base 3.1 hasn't changed that, it isn't a bug, nor a "feature". It is the standard documented behavior and I believe the behavior all the way back to the beginning of the Bourne shell. The only bug is in poor (and apparently untested) instructions. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From seandarcy2 at gmail.com Sun Apr 30 02:21:35 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 29 Apr 2006 22:21:35 -0400 Subject: Something screwy with new glibc-kernheaders Message-ID: With glibc-kernheaders-3.0-18.x86_64.rpm I get thiss error trying to build kino: if g++ -DHAVE_CONFIG_H -I. -I. -I.. -Wall -I/usr/include/alsa -I/usr/include/libxml2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/ffmpeg -D_FILE_OFFSET_BITS=64 -DKINO_PLUGINDIR=\""/usr/lib64/kino-gtk2"\" -DDATADIR=\""/usr/share"\" -D_REENTRANT -O2 -fPIC -funswitch-loops -fvisibility-inlines-hidden -ftree-vectorize -march=k8 -pipe -mfpmath=sse -frename-registers -MT jogshuttle.o -MD -MP -MF ".deps/jogshuttle.Tpo" -c -o jogshuttle.o jogshuttle.cc; \ then mv -f ".deps/jogshuttle.Tpo" ".deps/jogshuttle.Po"; else rm -f ".deps/jogshuttle.Tpo"; exit 1; fi /usr/include/linux/input.h:803: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:807: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:808: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:809: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:810: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:811: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:812: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:813: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:814: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:815: error: 'kernel_ulong_t' does not name a type /usr/include/linux/input.h:817: error: 'kernel_ulong_t' does not name a type make[3]: *** [jogshuttle.o] Error 1 Going back to glibc-kernheaders-3.0-6.x86_64.rpm fixes it. sean From kevin.kofler at chello.at Sun Apr 30 04:36:22 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 30 Apr 2006 04:36:22 +0000 (UTC) Subject: [NEW IDEA] Automatic removal of dependencies References: <200604271246.50811.lamont@gurulabs.com> <1146184755.4883.5.camel@localhost.localdomain> <1146240313.1491.9.camel@localhost.localdomain> Message-ID: Peter Jones redhat.com> writes: > So that basically means that you want to mark everything which is listed > in comps but isn't in "base" or "core" as user-installed. That's going > to result in a view of "safe to remove" that doesn't reflect what users > want or expect. So maybe special-case "base" and "core"? Let's mark those packages "explicitly installed" (or maybe "essential", but from my past experience with apt-rpm, that doesn't work too well if you can have more than one version installed, such as for kernels: you get a scary warning if you remove an old kernel, but that could probably be fixed in apt (it should warn only if you remove all versions of the essential package) and yum could get it right right away). But a package which is not a base/core package nor has been checked explicitly is by definition "automatically installed for dependencies". Kevin Kofler From itamar at ispbrasil.com.br Sat Apr 29 23:50:13 2006 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Sat, 29 Apr 2006 20:50:13 -0300 Subject: Grub Booting-fallback-systems Message-ID: <000601c66c13$5894c100$0100000a@lualele> Anyone have tested this ? http://www.gnu.org/software/grub/manual/grub.html#Booting-fallback-systems why fc5 doesn?t have grub-set-default ? From sdl.web at gmail.com Sun Apr 30 07:03:51 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 30 Apr 2006 08:03:51 +0100 Subject: [BUG] yelp depends on mozilla? Message-ID: Hi all, I hope this is the right mail list to raise this question. I'm running FC5 and both mozilla and firefox are installed. But when I removed mozilla, yelp is also removed. I think there is a bug here. Any comments? -- Leon From peter at thecodergeek.com Sun Apr 30 07:30:58 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 30 Apr 2006 00:30:58 -0700 Subject: [BUG] yelp depends on mozilla? In-Reply-To: References: Message-ID: <445467B2.30903@thecodergeek.com> Leon wrote: > Hi all, > > I hope this is the right mail list to raise this question. I'm running > FC5 and both mozilla and firefox are installed. But when I removed > mozilla, yelp is also removed. I think there is a bug here. Any > comments? > As I understand it, Yelp internally makes use of Mozilla's Gecko engine for rendering and whatnot. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From sdl.web at gmail.com Sun Apr 30 08:12:26 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 30 Apr 2006 09:12:26 +0100 Subject: [BUG] yelp depends on mozilla? References: <445467B2.30903@thecodergeek.com> Message-ID: Peter Gordon writes: > Leon wrote: >> Hi all, >> >> I hope this is the right mail list to raise this question. I'm running >> FC5 and both mozilla and firefox are installed. But when I removed >> mozilla, yelp is also removed. I think there is a bug here. Any >> comments? >> > As I understand it, Yelp internally makes use of Mozilla's Gecko > engine for rendering and whatnot. Can it use firefox instead? -- Leon From fedora at soeterbroek.com Sun Apr 30 09:55:53 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Sun, 30 Apr 2006 11:55:53 +0200 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) Message-ID: <445489A9.4000000@soeterbroek.com> Hi, I have a question regarding Changelog entries in spec files. When packaging for a new upstream version of a given package you have to deal with 2 different changelog informations: 1) upstream/source specific changelog information 2) spec file/packager specific changelog information I am unsure how best to deal with both of these. The FE guidelines regarding Changelogs in http://fedoraproject.org/wiki/Packaging/Guidelines only mentions spec file specific changelog info, but says nothing about upstream. I do think it is relevant to include upstream changelog also. As an example, I have just bumped the heartbeat package in Fedora Extras from 2.0.4-2 to 2.0.5-1. I ended up using a combination of minuses for the package specific changelog entries and indented plusses for the upstream changelog which seemed acceptable to rpmlint, as in: %changelog * Date Name Packager - package changelog + upstream changelog Example for heartbeat package: %changelog * Thu Apr 27 2006 Joost Soeterbroek - 2.0.5-1 - upstream version 2.0.5 - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer set in cts/CM_LinuxHAv2.py.in + Version 2.0.5 - significant bug fixes and a few feature deficits fixed + various portability fixes + enable GUI to run with pygtk 2.4 + significant GUI improvements and speedups Comments,ideas? Joost From fedora at soeterbroek.com Sun Apr 30 10:01:20 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Sun, 30 Apr 2006 12:01:20 +0200 Subject: Best practices wrt. Changelog entries in spec file (upstream vs. specfile) In-Reply-To: <445489A9.4000000@soeterbroek.com> References: <445489A9.4000000@soeterbroek.com> Message-ID: <44548AF0.8010109@soeterbroek.com> I meant to send this to fedora-extras list, not fedora-devel list, sorry Joost Joost Soeterbroek wrote: > Hi, > > I have a question regarding Changelog entries in spec files. When > packaging for a new upstream version of a given package you have to deal > with 2 different changelog informations: > > 1) upstream/source specific changelog information > 2) spec file/packager specific changelog information > > I am unsure how best to deal with both of these. The FE guidelines > regarding Changelogs in > http://fedoraproject.org/wiki/Packaging/Guidelines only mentions spec > file specific changelog info, but says nothing about upstream. I do > think it is relevant to include upstream changelog also. > > As an example, I have just bumped the heartbeat package in Fedora Extras > from 2.0.4-2 to 2.0.5-1. I ended up using a combination of minuses for > the package specific changelog entries and indented plusses for the > upstream changelog which seemed acceptable to rpmlint, as in: > > %changelog > * Date Name Packager > - package changelog > + upstream changelog > > Example for heartbeat package: > > %changelog > * Thu Apr 27 2006 Joost Soeterbroek - 2.0.5-1 > - upstream version 2.0.5 > - removed patch2 - ownership of /heartbeat/crm/cib.xml is no longer > set in cts/CM_LinuxHAv2.py.in > + Version 2.0.5 - significant bug fixes and a few feature deficits fixed > + various portability fixes > + enable GUI to run with pygtk 2.4 > + significant GUI improvements and speedups > > Comments,ideas? > > Joost > From kms at passback.co.uk Sun Apr 30 10:33:49 2006 From: kms at passback.co.uk (Keith Sharp) Date: Sun, 30 Apr 2006 11:33:49 +0100 Subject: [BUG] yelp depends on mozilla? In-Reply-To: References: <445467B2.30903@thecodergeek.com> Message-ID: <1146393229.4541.10.camel@animal.passback.co.uk> On Sun, 2006-04-30 at 09:12 +0100, Leon wrote: > Peter Gordon writes: > > > Leon wrote: > >> Hi all, > >> > >> I hope this is the right mail list to raise this question. I'm running > >> FC5 and both mozilla and firefox are installed. But when I removed > >> mozilla, yelp is also removed. I think there is a bug here. Any > >> comments? > >> > > As I understand it, Yelp internally makes use of Mozilla's Gecko > > engine for rendering and whatnot. > > Can it use firefox instead? There has been a relatively recent discussion on this: https://www.redhat.com/archives/fedora-devel-list/2006-April/msg01195.html I didn't follow the entire thread, but I believe the long term plan is that applications needing an HTML rendering component will switch to use Xulrunner: http://developer.mozilla.org/en/docs/XULRunner When this is scheduled to happen I do not know. Keith. From nicolas.mailhot at laposte.net Sun Apr 30 11:09:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 30 Apr 2006 13:09:32 +0200 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <1146393229.4541.10.camel@animal.passback.co.uk> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> Message-ID: <1146395413.10326.16.camel@rousalka.dyndns.org> Le dimanche 30 avril 2006 ? 11:33 +0100, Keith Sharp a ?crit : > There has been a relatively recent discussion on this: > > https://www.redhat.com/archives/fedora-devel-list/2006-April/msg01195.html > > I didn't follow the entire thread, but I believe the long term plan is > that applications needing an HTML rendering component will switch to use > Xulrunner: > > http://developer.mozilla.org/en/docs/XULRunner > > When this is scheduled to happen I do not know. Don't get your hopes too high, having a sane shareable mozilla HTML rendering component has been a goal since before firefox existed. One has to wonder after all this time if the moz code is not too badly designed for it to ever happen. -- Nicolas Mailhot -------------- 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 sdl.web at gmail.com Sun Apr 30 14:20:17 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 30 Apr 2006 15:20:17 +0100 Subject: [BUG] yelp depends on mozilla? References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot writes: > Le dimanche 30 avril 2006 ? 11:33 +0100, Keith Sharp a ?crit : > >> There has been a relatively recent discussion on this: >> >> https://www.redhat.com/archives/fedora-devel-list/2006-April/msg01195.html >> >> I didn't follow the entire thread, but I believe the long term plan is >> that applications needing an HTML rendering component will switch to use >> Xulrunner: >> >> http://developer.mozilla.org/en/docs/XULRunner >> >> When this is scheduled to happen I do not know. > > Don't get your hopes too high, having a sane shareable mozilla HTML > rendering component has been a goal since before firefox existed. > > One has to wonder after all this time if the moz code is not too badly > designed for it to ever happen. > > -- > Nicolas Mailhot However there is no need for yelp to depend on mozilla. It could depend on firefox, right? -- Leon From d.jacobfeuerborn at conversis.de Sun Apr 30 15:28:28 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 30 Apr 2006 17:28:28 +0200 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <1146395413.10326.16.camel@rousalka.dyndns.org> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> Message-ID: <4454D79C.4020402@conversis.de> Nicolas Mailhot wrote: > Le dimanche 30 avril 2006 ? 11:33 +0100, Keith Sharp a ?crit : > >> There has been a relatively recent discussion on this: >> >> https://www.redhat.com/archives/fedora-devel-list/2006-April/msg01195.html >> >> I didn't follow the entire thread, but I believe the long term plan is >> that applications needing an HTML rendering component will switch to use >> Xulrunner: >> >> http://developer.mozilla.org/en/docs/XULRunner >> >> When this is scheduled to happen I do not know. > > Don't get your hopes too high, having a sane shareable mozilla HTML > rendering component has been a goal since before firefox existed. > > One has to wonder after all this time if the moz code is not too badly > designed for it to ever happen. IIRC the release is planned for Q1 2007 because it is based on Geckos 1.9 branch. You can get a stable preview release (still based on 1.8) at the above URL. Regards, Dennis From marco at gnome.org Sun Apr 30 14:38:31 2006 From: marco at gnome.org (Marco Pesenti Gritti) Date: Sun, 30 Apr 2006 10:38:31 -0400 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <1146395413.10326.16.camel@rousalka.dyndns.org> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> Message-ID: <4454CBE7.5010602@gnome.org> Nicolas Mailhot wrote: > Le dimanche 30 avril 2006 ? 11:33 +0100, Keith Sharp a ?crit : > > >> There has been a relatively recent discussion on this: >> >> https://www.redhat.com/archives/fedora-devel-list/2006-April/msg01195.html >> >> I didn't follow the entire thread, but I believe the long term plan is >> that applications needing an HTML rendering component will switch to use >> Xulrunner: >> >> http://developer.mozilla.org/en/docs/XULRunner >> >> When this is scheduled to happen I do not know. >> > > Don't get your hopes too high, having a sane shareable mozilla HTML > rendering component has been a goal since before firefox existed. > > One has to wonder after all this time if the moz code is not too badly > designed for it to ever happen. > There are good news about this, it's finally happening. XULRunner 1.8 works pretty well (I actually made some experimental rpms). Yelp, epiphany and the other gtkmozembed applications should run just fine with it. I think running firefox on the top of xulrunner requires 1.9 though (which will be released 2007 Q1). Marco From Curtis at GreenKey.net Sun Apr 30 22:25:40 2006 From: Curtis at GreenKey.net (Curtis Doty) Date: Sun, 30 Apr 2006 15:25:40 -0700 Subject: Grub Booting-fallback-systems In-Reply-To: <000601c66c13$5894c100$0100000a@lualele> References: <000601c66c13$5894c100$0100000a@lualele> Message-ID: <44553964.8010702@GreenKey.net> Itamar Reis Peixoto wrote: > Anyone have tested this ? > > http://www.gnu.org/software/grub/manual/grub.html#Booting-fallback-systems > > why fc5 doesn?t have grub-set-default ? > The Fedora patch proceeds the upstream feature and apparently nobody has yet to request a merge in bugzilla. See this prior thread: http://www.redhat.com/archives/fedora-devel-list/2006-March/msg00475.html Warren Togami's howto for crazy sysads http://togami.com/~warren/guides/remoteraidcrazies/ is a very helpful explanation of the current Fedoraesque --once feature. Last month it saved me a trip from California to Hong Kong to clean up some wrongly provisioned cluster boxen. ../C