Re: Installing F12-Beta
On Mon, 2009-11-02 at 15:47 +0800, Steven James Drinnan wrote: David why you are so upset? No need to get nasty. I simply posted a message about my problems installing F12. I did not Hijack any thread (see the subject name). I thought this was a public forum. I sent this to the whole mailing list. My apologies if I offended you. I'm not upset, and wasn't nasty. I was just trying to help you communicate more effectively, and without adding noise to other discussions. You _did_ hijack the thread -- you replied to Adam's message, using your 'reply' button instead of composing a new message to the list. Your mail is clearly marked, in its headers which I quoted, as a reply to that previous message -- as part of that older thread. It should have been a _new_ thread, not a reply to the existing thread. Please don't do that. And, while we're at it, please don't top-post either. And please remember to quote only what you actually need for context rather than repeating the _whole_ of the message to which you're replying. You may find http://david.woodhou.se/email.html to be useful reading. All I can tell you is what happened. Which is I put the DVD in the drive and after a while it came up with a recursive error and said it was fixed but needed to restart the computer. You _still_ didn't actually post the precise text of the error you saw, along with any output leading up to it. It's almost as if you don't _want_ people to be able to help you. Now that you posted the actual bug number rather than just teasing us with I put it in bugzilla but I'm not telling you where as you did in your previous mail, I can see that you didn't post the full error there, either. Please, show us the words you actually see on the screen -- or take a photo, perhaps. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing F12-Beta
On Mon, 2009-11-02 at 08:29 +0800, Steven James Drinnan wrote: In-reply-to: 1257111085.2314.154.ca...@adam.local.net References: adf480660910311031h5889985by4fb8d4ac7f342...@mail.gmail.com 1257111085.2314.154.ca...@adam.local.net Steven, please could you explain the relationship between your message on 'Installing F12-Beta' and the message to which you replied, which was about upstream developers becoming co-maintainers. If there is no relationship, then you've just hijacked an existing thread by posting your unrelated query as a reply to it -- please don't do that. You may also find that you'll get more help if you provide a more coherent bug report. You neglected to give any useful details about the error you see. Giving the full error message might have helped. Or even telling us at which stage of the boot it happens might have given a clue. I'd look in the bug you filed to see if you provided that information there... but you didn't even bother to tell us the bug number. My crystal ball isn't working today, so I _couldn't_ help you, even if I _didn't_ have a policy of not helping thread-hijackers until they post their problem politely ;) -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: On 09-10-28 18:24:49, Josh Boyer wrote: On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: Sorry to bug developers, but I didn't get any bites from PPC users on fedora-list. Does Fedora PPC work or install on oldworld PCI Macs, such as a beige G3 desktop? My impression is that no one has tried it on an oldworld No, it doesn't. The ppc specific release notes cover that here: http://docs.fedoraproject.org/release-notes/f11/en-US/ index.html#sect-Release_Notes-Hardware_Requirements I'd looked at the release notes. They says Minimum CPU: PowerPC G3... and Although Old World machines should work, they require a special bootloader which is not included in the Fedora distribution. My question is whether anyone has tried it in any recent Fedora release and knows whether should means do or don't. (FWIW, the special bootloader is BootX, and Debian Lenny is installing now, so /some/ form of Linux works. I just don't know anything but hearsay about Debian. I see it uses apt.) I don't know of anyone who's tried it recently, but in the past we've fixed things in the kernel to make it work properly on OldWorld Macs and it _has_ been known to work fine. It _ought_ to work if you sort out the bootloader. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Cannot rely on /dev being present in %post scripts?
According to bug #517013, %post scripts should not assume that /dev is available -- so we can't do anything that requires the existence of /dev/null, /dev/urandom, etc. Is this a known and expected packaging rule, or is it a bug in the way that the user is attempting to install the packages? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, 2009-07-02 at 16:28 +0100, Peter Robinson wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 Unrelated to this issue, but please use make V=1 so we see the actual build command lines in the build.log (see the thread about the new automake). With V=1 http://koji.fedoraproject.org/koji/getfile?taskID=1450335name=build.log You know you can have access to a real box to test this on if you want it, right? You don't have to do it all in koji and look at the build logs. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, 2009-06-17 at 02:55 +0200, Kevin Kofler wrote: Bruno Wolff III wrote: Is there going to be a way to tell which binaries actually use sse2 instructions, so that the others can be inherited by a secondary arch? Due to how GCC works, if the compiler flags enable SSE/SSE2, basically all the binaries will be using some SSE/SSE2 instructions. And on the various SSE-capable CPUs, how much benefit does that actually give us? I'm after a system-wide answer, not a microbenchmark for zlib or crypto code. It should take into account any overheads involved in saving/restoring registers on context switch that wouldn't otherwise have to be saved/restored. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? There are _some_ kinds of bug (feature requests, etc.) which it's reasonable for any decent maintainer to punt upstream. There are other kinds of bugs (crashes, security issues -- perhaps even _anything_ that's a real bug rather than an RFE) which the maintainer really _ought_ to deal with directly. Opinions vary on precisely where the boundary between those classes should be, but I'm fairly adamant it should be 'RFE vs. bug'. Any packager who _isn't_ capable of handling the latter class of bug probably shouldn't be maintaining the package without the assistance of a co-packager or their sponsor. Note that you don't _have_ to be able to code to handle a real bug in an acceptable fashion -- decent coordination with upstream can be perfectly sufficient, if upstream are responsive enough. But just closing the bug in our bugzilla as 'upstream' is rarely acceptable for a _real_ bug, IMHO. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: The repository scoring problem - a proposal
On Sun, 2006-03-12 at 18:34 +0100, Nicolas Mailhot wrote: Why do you need a separate header/field/whatever ? You *already* have this field - that's the GPG signature. Assign weights to signing keys and you're done Not always sufficient. Most of the time I want yum to prioritise, it's when it downloads a package from a remote repository which is actually also available from a local one (with a file:// URL). I'd want to priorities my local caches over the remote repositories, which can't be done with the signature (although yum arguably ought to do that one for itself anyway). -- dwmw2
Re: rawhide report: 20060307 changes
On Wed, 2006-03-08 at 09:32 +0100, Igor Jagec wrote: Speaking about NM, are there any plans for supporting static IP addresses? Doesn't NM work with static IP addresses? It obeys static IP addresses in /etc/sysconfig/network-scripts/ifcfg-eth1 for me -- it confused me by doing so a couple of weeks ago. -- dwmw2
Re: Recommended laptop for FC5, was: glxgears
Roberto Ragusa m...@robertoragusa.it wrote: Seth Vidal wrote: And how do you define library? There's no reliable way to distinguish them from applications. This is part of the problem. It would be nice to have all things which are strictly libraries add a provides: Library something and, of course, to have all libs split from all apps. Why should libraries be special? They are not. Libraries dragged as dependencies are candidate for removal when nothing currently installed is depending on them. Libraries installed explicitly by the user must not be removed (maybe I need them for a not-packaged or manually compiled app). s/Libraries/Apps - same rules have to apply Apps dragged as dependencies could be volatile, apps the user decided to install must stay. Please do not limit the issue to lib/not-lib. Things are more complex (well, maybe they are actually simpler...) For example: a) wireshark-gnome (depends on wireshark) b) wireshark (depends on libpcap) c) libpcap (depends on libutilswhichsomedevelopersliketouse) d) libutilswhichsomedevelopersliketouse It makes a lot of difference if a user - has installed a) and dragged b) c) d) for dependencies (removing a) could try to remove everything) or - has installed c) and d) for own use/development, then some day installs a) which drags b) (removing a) should only try to remove b) ) - has installed c) and d) for own use/development, then some day installs b), then some day installs a) (removing a) should not try to remove anything else ) There is only one use case a little tricky: if I have a), which dragged b) c) and d), and now I want to mark b) as wanted, what should I do? maybe: # yum install b) To be installed: none To be updated: none To be marked as user-installed: b) Proceed? (y/n) y Operation complete. This means the overloaded user has to remember to mark as used the stuff she is using so it doesn't get pulled out from under her feet by deleting unrelated packages. What should now happen if, say, (c) gets updated, but nothing else in the stack? What if ethereal gets renamed to wireshark? What if (c) gets replaced upstream by a functionally equivalent, but different code base, package? What if the whole stack gets replaced by functionally equivalent, but API-wise completely different (and even divided into completely different layers), stuff? It seems to me that most of this nonsense is easy to get right with no further effort than just creating your own RPMs and installing those, instead of futzing around installing _systemwide_ from source. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
