Re: RFE: Never, ever steal focus.
On 01/06/2010 01:27 PM, Fulko Hew wrote: On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson a...@redhat.com mailto:a...@redhat.com wrote: On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: Quoting Adam Jackson (a...@redhat.com mailto:a...@redhat.com): On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. And now make that work for the case where firefox decides to take 10 secs to start up, so you start in another window, then firefox jumps up and grabs focus. Thanks. There is no case where I want a new window or popup to take focus. Makes for an easy algorithm. (hitting r in mutt is not a problem :) There is no case where _you_ want this, sure. I'd say... only take focus if its a child/creation of the window currently in focus. Some people also do things like set EDITOR=gvim and set their mail client to run $EDITOR when composing a message. There are cases where many people do expect and even desire for pop-ups to take focus, and they're not necessarily even crazy. -- Peter Space, is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On 01/06/2010 03:21 PM, Till Maas wrote: How about making the gnome-panel give away its focus to the newly created window? Within the gnome-panel, it should be pretty obvious which actions should give away the focus and which should not. I do not know, how easy to implement it is, though. That's pretty difficult for a launcher - how does the panel know that the launcher is going to create a window vs which is not? And how does it know what window it is? If you click on the firefox launcher, it runs a shell script. That script (may) eventually run an X application, but it in itself isn't one. What's the launcher telling the wm in that case under your proposed model? -- Peter Space, is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On 12/16/2009 11:43 AM, Seth Vidal wrote: you're an experienced user? You're comfortable knowing what does and what does not require a reboot? Then why are you using PK? Disable pk and do the updates directly via yum. Bam - no more requests to reboot. I get what you're saying, and it's kindof a fair point, but there's also some utility to having the system automatically, proactively notify you of updates. -- Peter For some reason it has always seemed to me that the term software engineering contains some very optimistic assumptions about the nature of reality. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: kernel/accounting question ...
On 10/19/2006 08:23 AM, William W. Austin wrote: Not that I've got an answer for your question, but you might want to tell your computer that it's not 2006. -- Peter When privacy is outlawed only outlaws will have privacy. -- Zimmermann -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: trouble with signals and skb_rec_datagram()
It's likely that some people have not noticed this message because you replied to an unrelated thread instead of starting with a new message entirely. This is best avoided. On 12/14/2009 02:45 PM, William Reich wrote: Hello List... I am working on trying to port a LINUX kernel driver from RedHat AS 4/5 to Fedora 11 12. Is this is a third-party driver that RH doesn't ship in RHEL? I'm going to assume it is, and respond with that in mind. It would probably be better to focus on porting it to the upstream kernel, and getting it submitted there. That helps a great deal to keep you from having to do this again -- when interfaces like skb_rec_datagram() change, the entire upstream kernel tends to get fixed along with the change. [...] Does anyone know if the behavior of skb_rec_datagram() has changed in the newer kernels ? Sounds like a question for linux-netdev rather than for fedora-devel. If you actually try to get your driver ready for upstream, the linux-netdev are likely to be quite helpful. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wiki Feature Dashboard Additional Category
On 12/14/2009 11:45 PM, John Poelstra wrote: You have an interesting idea about tagging feature pages needing an owner. In reality that pretty much represents all the pages in 'Category:FeaturePageIncomplete' If they had an active owner or developer working on the feature they wouldn't be there. As somebody who's owned a feature page put into this category, I just don't think this is true at all. There are a couple of reasons for this. Certainly, the cost/benefit of working on updating the wiki, which can sometimes consume a significant amount of time, vs that of working on the feature itself skews heavily towards the decision to work on the feature instead of updating the page immediately, which means the Feature page on the wiki suffers. It's also useful, as a developer, to queue changes to the Feature page instead of re-editing it every time anything on it changes - it's just easier to work on one thing at a time. The form also puts a lot of burden on whomever is developing a feature (and maintaining the form), for several reasons, listed below. Some of these reasons are probably more true for people working in an RH office than for RH remotees or non-RH contributors. To wit: a) The form isn't especially clear - the field names are basically all you've got to go on, and they're not terribly descriptive. It's hard to know what put in several places, and many people have different expectations. If you don't get it right (and it's not possible to get it right) you wind up having people coming to tell you so on a fairly constant basis. And they'll conflict, of course. b) There's a strong pressure to update the forms *very often*, even for features which it's clear will be slow to make progress. c) There's not really a clear audience to the form. Is it for the general population of Fedora users? Fedora developers? FESCo? The Board? RH management? Clearly a feature that's submitted is queued for FESCo's approval, though it's still unclear as to why FESCo has to actually *approve* every feature, or is interested in doing so, especially since it's obvious to everybody that they *don't* approve every feature, nor would they be able to if everybody implementing a feature actually filled out a Feature page and submitted it. Thus raising item d: d) Some member of every group I listed above thinks they're not only the target audience for the form, but also that if there's something on it they don't understand or even just don't see, they're going to lose their livelihood if that's not rectified *immediately*. e) Many of the people mentioned in d seem to be basically unwilling to actually read the content of the form in order to get their question answered. If they think something is missing from Benefit to Fedora, the odds are you'll get an email (or worse, they'll show up at your desk and interrupt you in real time) about the Benefit to Fedora section even if the confusion is easily solved by reading the Summary or Detailed Description sections. Which brings us to: f) There are several fields which are basically redundant. If neither Summary nor Detailed description adequately include at least some large amount of Benefit to Fedora, then the form really just isn't filled in. Likewise, if Scope, Dependencies, and User Experience are left empty or are sparse, it's it's likely because the developer filling out the form thought that had been explained well enough already and was tired of explaining things repeatedly. g) There are fields that don't /actually/ have a purpose. You'll get complaints if Documentation is empty, but not if you put in link to a pdf that's irrelevant to the actual Feature. h) There are fields that are essentially punitive. Not every Feature needs a release note (though some would argue that it's the only reason to bother with the Feature process at all...), but if you don't put text there for one, you're back in email-flood land. And it's really there because we don't trust developers to actually submit things for the release notes, anyway. Yes, there's plenty of data to support the fact that we usually won't write release notes, but this isn't a very good way to fix that. It's certainly not a convenient place to track it - especially since you've got to put something in that field even before you've actually implemented the feature, when you basically can't possibly know what would go there. But if you don't put something there when you first propose the Feature, guess whatyour inbox looks like? i) There's a field that's just there for people who don't understand wikis, AFAICT. I randomly sampled some Features in Category:FeatureAcceptedF11 (since that's pretty stable data at this point in time) to see what they said for Comments and Discussion. All of them just listed a link to the Feature page's Talk: page. Surely this field
Re: X on UEFI systems.
On 12/11/2009 02:41 PM, Adam Williamson wrote: On Thu, 2009-12-10 at 08:57 +0100, Matěj Cepl wrote: Dne 10.12.2009 07:36, Vasily Levchenko napsal(a): Does it not work without an xorg.conf, that would be the first goal. No. File a bug please, attaching your xorg.conf, Xorg.0.log and output of the dmesg command (all from inside of VB virtual machine, of course). ...nd (oh boy, I love it when a plan comes together) mark it as blocking F13Beta , because I reckon this breaks beta criterion #4: https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria I like the sentiment here, but I'm not sure this is really in the spirit of the criteria - Vasily, as I understand it, is still in the process of implementing the support for UEFI on VirtualBox. Which is to say, yes, we need to fix the parts that are distro problems, but I'm not sure we've gotten to the point where VirtualBox+UEFI is expected to be a working system in the first place. But maybe I'm wrong - Vasily, what do you think? -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
On 12/04/2009 03:57 AM, Panu Matilainen wrote: - glibc32, glibc64 (dead packages?) These packages are used in the build system so we don't have to install .i686 glibc packages in the x86_64 buildroot, and other things of that nature. They're not dead, but they very rarely need modification. -- Peter When in doubt, debug-on-entry the function you least suspect has anything to do with something. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 12:24 AM, Ralf Corsepius wrote: On 12/02/2009 06:40 PM, Jesse Keating wrote: People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? This very much seems to me like it's a vast majority of kickstarts that happen. -- Peter Power corrupts. Absolute power is kind of neat. -- John Lehman, Secretary of the Navy, 1981-1987 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/03/2009 08:20 AM, Seth Vidal wrote: On Thu, 3 Dec 2009, Adam Williamson wrote: On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. Well, if we're talking about removing them from Fedora/ but leaving them in Everything/ (am I understanding the current form of the proposal correctly?), then it's not really significantly more difficult, but it is one more process that needs modification in order to enact such a plan. -- Peter If the facts don't fit the theory, change the facts. -- Einstein -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 09:12 PM, Kevin Kofler wrote: Seth Vidal wrote: If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. The problem is, a few of those starting letters still correspond to A LOT of packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of stuff (especially Perl and Python). And adding python3-* (and perl6-*, or are we going to use the rakudo-* namespace there?) won't make it any less. Even still, separating p out to a subdirectory means that subdirectory has an order of magnitude fewer files than the previous way. That's a really big difference. -- Peter If the facts don't fit the theory, change the facts. -- Einstein -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 12/01/2009 11:49 AM, Sir Gallantmon wrote: Couldn't something like that be implemented into GRUB/GRUB2? Unlike PLoP, GRUB doesn't really have a size restriction, so maybe smarter methods of detection could be implemented. The approach of loading what amounts to DOS TSRs is something you could do with pretty much any x86 bootloader (though it's worlds simpler with syslinux than grub). But we're still basically talking about writing a bunch of 16-bit device drivers. I'm thinking it's not going to happen. -- Peter Growth for the sake of growth is the ideology of the cancer cell. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
(on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/ # contains packages named 0 through 3* 4/ # 4 through 9* a/ # a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:03 PM, Jesse Keating wrote: On Wed, 2009-12-02 at 15:52 -0500, Seth Vidal wrote: Isn't this, eventually, what the packagedb is supposed to be able to do? I gather it's a ls in a directory kind of thing, not an interface to one tool or another kind of thing. But I could be wrong. Sure, but the better optimization for this is don't do it. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. Well, you just wouldn't get the benefits of this if you're using a mirror. Which, yes, is pretty lame. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/# contains packages named 0 through 3* 4/# 4 through 9* a/# a through ay* az/# az through bw* bx/# bx through cz* da/# da through whatever's next ... so that every directory has about the same number of things. If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. Yeah, I buy that. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 12/02/2009 06:05 PM, James Antill wrote: On Wed, 2009-12-02 at 17:46 -0500, Peter Jones wrote: so that every directory has about the same number of things. This should be fairly easy to code, but has a big downside: Packages will move directories. 1. This will upset yum (old repo. MD == no packages download). 2. This might upset mirrors. 3. This will probably upset users: i. URLs will only be safe until the next mash, they won't even be able to bookmark prefix/y if they just want to see yum each time. ii. Users have to look/parse the directory layout each time they visit to see what blah is. Yeah. Seth makes a good point - first letter is such vast improvement that we probably don't need to worry about doing better - at least for now. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/30/2009 01:27 PM, Peter Jones wrote: On 11/30/2009 12:27 PM, Matthias Clasen wrote: 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid the 'Can't boot USB' problem. Did we figure out how Mandriva are doing it ? No, we didn't. There are some things we might be able to do here, though, which may solve this problem without actually chain-booting. The most obvious is to make sure the live image's initrd searches for a USB device with the right filesystem label (and possibly other criteria) and mounts that as root, and then build a liveboot.iso with one boot image and no[1] real filesystem. The boot image would contain the kernel and initrd as the only boot option. This is fairly trivial to do, actually. [1] It'd have to have an iso9660 filesystem with the isolinux/ directory much like our current boot.iso does, but the kernel and initrd there would be the ones from the live image, and we wouldn't put the rest of the live OS on the disc. Further research[1] seems to indicate that this is almost exactly what they're doing. [1] Adam pointed me at http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/drakx/trunk/rescue/make_flash_rescue?revision=263686view=markup -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 12/01/2009 10:42 AM, Sir Gallantmon wrote: I found another tool that claims to be able to search and boot a USB device, from a floppy disk no less! The tool is called PLoP[1], and it is a custom boot manager that can boot USB, CD, and hard disks. Maybe that will help some people figure out how it is done. [1]: http://www.plop.at/en/bootmanager.html That's pretty neat, but probably not much help to us. What this is is a custom (proprietary, closed source, it seems) bootloader which basically does this: 1) installs what amounts to a DOS TSR driver for each of: a) IDE (of some unspecified variety) b) [EOU]HCI c) ATAPI and similar (i.e. SCSI MMC/SBC command sets along with encapsulation for CDROM and USB-storage) d) notably not any SATA/AHCI/etc 2) acts as a chainloading boot loader for whatever bootloader is on media that it finds. Which is also just a fancy way of saying it /replaces/ some of your BIOS's int 13h routines with what are plausibly slightly smarter (but also plausibly slightly dumber) ones. If somebody wants to implement an open source version of this, it could be helpful, I guess. But it's a lot of fairly difficult work, and the only real advantage it has over the other scheme I've discussed is that the CD (or whatever) you're booting from doesn't have to match the OS being booted. Anyway, if somebody's looking for a truly complex and isolating project to work on, go right ahead, but I'm not going to ;) -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On 11/27/2009 02:25 PM, Casey Dahlin wrote: On 11/27/2009 06:03 AM, Richard W.M. Jones wrote: On Fri, Nov 27, 2009 at 03:28:19AM -0500, Gregory Maxwell wrote: A literal zero prior to preprocessing is either a bug, or some kind of dead- code causing place-holder. Not necessarily .. the C code itself may be generated from something else. Rich. In which case the C code is no longer source and should be excluded from the analysis. No, when swig (or whatever) produces bad code, we still want the compiler to identify it and toss it. It's then up to the packager to realize it's swig producing the bad code, but it isn't magically good code that doesn't result in real bugs. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking for testers: RPM 4.8 pre-release snapshots available
On 11/27/2009 03:05 AM, Panu Matilainen wrote: For an idea what to expect, see the draft release notes at http://rpm.org/wiki/Releases/4.8.0 I notice that explicit ordering syntax that doesn't trigger a strict requires isn't on this list. It's really something we need sooner rather than later, and it's been requested by many people for quite some time now. What needs to be done to get this prioritized? There is a mounting set of features we're implementing parts of very poorly because of the lack of this functionality. -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On 11/27/2009 04:56 PM, Felix Miata wrote: Physics don't. A two dimensional screen will never be able to more than simulate 3D. 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce. This isn't necessarily the case, in theory or in practice. I used an ammeter to do some measurements of this on my T41[1] several releases ago[2], and in general compositing the desktop using 3d hardware used slightly less energy than running with desktop effects turned off. Which is to say, if the 3d hardware can do something easily, it may use more energy for the GPU than using 2d acceleration only, but that translates to less energy doesn't necessarily mean more power for the whole system. If you do more complex 3d things, yes, it will take more power, but the act of using the 3d hardware instead of the 2d hardware can be more efficient in terms of energy. [1] that's 2373-9FU for those wondering. [2] a bit after compiz came into existance -- Peter I'd like to start a religion. That's where the money is. -- L. Ron Hubbard to Lloyd Eshbach, in 1949; quoted by Eshbach in _Over My Shoulder_. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: memset bugs.
On 11/30/2009 11:39 AM, Casey Dahlin wrote: On 11/30/2009 10:39 AM, Peter Jones wrote: On 11/27/2009 02:25 PM, Casey Dahlin wrote: On 11/27/2009 06:03 AM, Richard W.M. Jones wrote: On Fri, Nov 27, 2009 at 03:28:19AM -0500, Gregory Maxwell wrote: A literal zero prior to preprocessing is either a bug, or some kind of dead- code causing place-holder. Not necessarily .. the C code itself may be generated from something else. Rich. In which case the C code is no longer source and should be excluded from the analysis. No, when swig (or whatever) produces bad code, we still want the compiler to identify it and toss it. It's then up to the packager to realize it's swig producing the bad code, but it isn't magically good code that doesn't result in real bugs. The compiler isn't doing these checks, but point taken. Go read Jakub's reply again ;) https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01966.html -- Peter Sanity's just a one trick pony anyway. You only get one trick -- rational thinking -- but when you're good and crazy, the sky's the limit! -- The Tick -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/30/2009 12:27 PM, Matthias Clasen wrote: 3. 'Chain-booting' from cd to usb sounds like an elegant way to avoid the 'Can't boot USB' problem. Did we figure out how Mandriva are doing it ? No, we didn't. There are some things we might be able to do here, though, which may solve this problem without actually chain-booting. The most obvious is to make sure the live image's initrd searches for a USB device with the right filesystem label (and possibly other criteria) and mounts that as root, and then build a liveboot.iso with one boot image and no[1] real filesystem. The boot image would contain the kernel and initrd as the only boot option. This is fairly trivial to do, actually. [1] It'd have to have an iso9660 filesystem with the isolinux/ directory much like our current boot.iso does, but the kernel and initrd there would be the ones from the live image, and we wouldn't put the rest of the live OS on the disc. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/23/2009 07:01 PM, Gregory Maxwell wrote: On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating jkeat...@j2solutions.net wrote: This is precisely the dialog that has been removed from F12 and is not planned to be returned. My understanding was that this was removed because collecting the root password during a user session is insecure because there could be a sniffer or the dialog could be faked. That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. The way around this is role-based privileges, which is what polkit is implementing - it means that for some actions, the user is automatically authorized by being assigned a role (for some actions, that is by being a member of the desktop_admin_r group). For some actions, the user may need to prove that he's who he says by entering /his/ password, but not the root password. The user does not thus get trained to enter the root password into dialog boxes. The important part here is that there's granularity on the actions - it's not assume root access, it's assume access to start $task that performs $action, so a) if the fake dialog attack does occur, it's a password with limited abilities which gets betrayed, and b) the admin is not necessarily giving free reign to the user in the first place. The model here is actually pretty good. The policy was clearly not what it should have been, and documentation/communication of the various roles and the rollout plan could have been better. Though tbf, on the polkit side there's plenty of how this works documentation that is useful and thorough; the communication of the roles and associated policy itself, that is, how PackageKit is using polkit and what admins need to know to lock a machine down, is what I'm talking about. If I understand you correctly you are saying that even if this weakness were addressed (e.g. through whatever means make fast user switching secure) that the feature would not be re-introduced. Am I misunderstanding? I don't understand what it is you think fast user switching does. You're just logged on as a different user. It's just like being logged in with a different getty on tty2 than on tty1. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/24/2009 03:49 PM, James Antill wrote: On Tue, 2009-11-24 at 14:22 -0500, Peter Jones wrote: That reason isn't /quite/ right. One big problem is that if you train a user to input the root password over and over, what he learns is to type the root password into a dialog box. The result is that when some non-privileged application asks for the root password so it can do bad things with it later, the user will type in the root password, and voila, a local attack against a user is now a root exploit. Sure, that's _a_ problem ... That's what I said, yes. assuming the user has been trained. But that's a _big_ assumption, No, not that they /have been/ trained. That the policy in question has the ability to train many users. I think this is ,in fact, a very /small/ assumption. esp. when we are only talking about installing _new_ packages (doesn't happen often, so the user isn't trained to accept it). We were discussing the dialog box in general, and not necessarily only this specific use of it. But, of course, taking advantage of a user trained to input a password without thinking is not the only attack ... another area of attack would be when you have an assumed small privilege escalation, that has no authentication (hence this thread). Yes, but it's often helpful to talk about specific improvements that can be made, not merely all problems that may emerge on a system. Or, to put that a different way, your thesis in this statement is that everywhere there's privilege escalation without secondary authentication is a risk. While that's certainly not incorrect, I don't think there's really much utility in discussing potential attack vectors in /bin/ping in *this* thread. The way around this is role-based privileges, which is what polkit is implementing In so far as role-based privileges is code for can be configured to N number of actual checks, including the auth_as_root check we are comparing it against. Then sure, it has to be at least as secure as auth_as_root because it can be auth_as_root¹. It's a fair point that the policy as defined for the role still needs to be a good one, but I think some people on this thread are dwelling on the mistake that was made, while at the same time placing blame incorrectly on the mechanism. That doesn't help us. The mechanism does improve things if used well by application developers and admins. But suggesting that whatever polkit is configured to use is automatically better than auth_as_root is, at best, misleading. I wasn't meaning to suggest that the system as a whole is necessarily more secure if you use a mechanism which allows for policy and role based decision making. I am suggesting that it certainly appears to be a good method to make a system which allows for /less/ privilege escalation on the whole while at the same time making a system which is more usable where individual authorized users don't /need/ more privileges. That's improvement. For it to also be more secure, it's true that the policies that govern the mechanism also have to be crafted in such a way as to enforce security. But that's true with what we had before, too. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt + X Error = zillions of duplicate bug reports?
On 11/24/2009 02:15 PM, Adam Williamson wrote: We came up with several possible courses of action. First, we acknowledge that abrt team is working on improving duplicate detection, but Matej noted that this is intrinsically hard work and abrt will likely never be able to eliminate or even come close to eliminating duplicate reporting. What's the technical limitation to coming close here? It seems likely that there will be some edge cases, but I would think that the majority of cases aren't all that exceptional, and are fundamentally straightforward to work out. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/24/2009 04:25 PM, Adam Williamson wrote: On Tue, 2009-11-24 at 16:17 -0500, Peter Jones wrote: On 11/24/2009 04:07 PM, Sir Gallantmon wrote: If there are systems that cannot boot to USB, why not offer a boot disc that would automatically search for USB drives, offer a list of bootable USB drives, and allow the user to select one to boot from? Not that I actually believe in these systems that are i686 or newer and won't boot off of usb-storage devices, but if they were to exist, you wouldn't be able to do what you're saying on them. When the bootloader is running, it can only see devices BIOS provides to it. If a system can't boot off of a usb-storage device, it's because the BIOS isn't enumerating it. So it's not a case of we can start from another device and then look at the device we meant to be using - you can't see the device at all, regardless of your starting point. Mandriva Flash - Mandriva's commercial system-on-a-USB-stick thingy - does exactly what you confidently proclaim to be impossible. It comes with a CD ISO you can burn onto a CD (or mini-CD) that allows you to 'chain-boot' the Flash on systems with crappy BIOSes that can't boot from a USB stick (yes, they exist, but are getting progressively rarer, obviously). I don't suppose you can easily fish out a url for the source to this? I'd like to see what they're actually doing. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: livecds in the future
On 11/24/2009 04:58 PM, John Reiser wrote: On 11/24/2009 01:38 PM, Peter Jones wrote: On 11/24/2009 04:25 PM, Adam Williamson wrote: Mandriva Flash - Mandriva's commercial system-on-a-USB-stick thingy - does exactly what you confidently proclaim to be impossible. It comes with a CD ISO you can burn onto a CD (or mini-CD) that allows you to 'chain-boot' the Flash on systems with crappy BIOSes that can't boot from a USB stick (yes, they exist, but are getting progressively rarer, obviously). I don't suppose you can easily fish out a url for the source to this? I'd like to see what they're actually doing. I've done it using Fedora 12, on an old Dell i686 laptop whose BIOS cannot boot USB. A typical GRUB stanza has a line such as: kernel /vmlinuz ro root=live:label='Feodra 12 i386 DVD' rootfstype=auto ... where /vmlinuz is the kernel on the CD, and root=live:label='...' designates the label of the device for the root (and init, and ...), which can be USB, DVD, another CD, any block device that the Linux kernel /vmlinuz can enumerate and understand. This is a different thing than what was being discussed - they were talking about chain booting device B from device A, not about booting off of A and mounting a root fs that's on B. The latter is obviously trivial, and indeed something our installer can already set up (though as a permanent installation, not as another form of install media.) -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On 11/23/2009 01:24 PM, Gregory Maxwell wrote: I haven't tried the the fast user switching in fedora... Hopefully it is using some kernel mode secure path to prevent users from stealing each others credentials, if it isn't then one should be established for it. Why not use the same facility to switch to a system administration desktop, locked down a bit by default (use SE linux to make various unsafe user tasks like firefox, open office, etc unable to run in this admin context) to discourage casual use. Wait, you're arguing for this *instead* of finer-grained elevations of privilege governed by policy files which can be locally overridden safely? Surely this would be preferable to reducing the security against common casual threats. I think you've characterized things backwards here. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/18/2009 08:47 PM, King InuYasha wrote: In any case, 32-bit shouldn't be considered legacy until every type of computer sold is 64-bit. And the fact is, that isn't true. Netbooks are entirely 32-bit currently, and a majority of low end desktops are still 32-bit only. This simply isn't factually the case. Most new low end desktops on the market right now will run 64-bit quite happily, and http://www.google.com/search?q=atom+330+netbook yields plenty of results. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/18/2009 08:11 PM, Chris Adams wrote: Once upon a time, Mike McGrath mmcgr...@redhat.com said: I think that's too subjective though. What is subjective about allowing unprivileged to do things that previously only root could do? I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible install packages would be on that list, it's possible not. That way packages could ask themselves does this break the policy? If it doesn't, great. If it does, time for a bug report. There have been bug reports, but they get closed by the maintainers as NOTABUG, so that procedure is obviously not working. This conclusion doesn't make a whole lot of sense. There's no guideline in place, so package maintainers aren't given the guidance Mike's suggesting. Without that guidance, closed-NOTABUG is not an indication of whether this process works, because there's no process being followed. To be perfectly frank, any packager has the power to change behavior is exactly how it should be. Right now developers using PK are basically deciding policy on their own, with no guidance as to the grander plan, and people are evaluating the quality of these decisions without a real, tangible reference point. There does need to be a way for a developer or packager to know if or how they /should/ be changing security-relevant behaviors, and for others to evaluate if the change is good or bad. Mike's suggestion of a distro-wide policy is one way to do that, and on it's face, it's certainly a lot more practical than a distro wide change control board auditing for security relevant changes, or even sillier, expecting package maintainers to identify when a change has security implications and come asking what they should do. A command infrastructure does not fit Fedora or Linux very well. I think the policy should be in two parts, though. Mike's suggestion is good; we need general guidelines as to what roles which classes of users are expected to fulfill. We probably also need some packaging policy for applications providing escalated privileges via policy kit, like we already have for setuid utilities. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/19/2009 02:49 PM, Colin Walters wrote: * Do we have a fedora-default-policykit-policy? Sounds like the right way to go. * How do we get this installed on upgrades? Code in preupgrade? code in preupgrade seems like a very *bad* way. Maybe Provides: system-policykit-policy on each of them and then make policykit itself require that, and only include one of them when doing a pungi run? I.e. the same way we do fedora-logos. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/19/2009 03:37 PM, Jeff Garzik wrote: On 11/19/2009 12:16 PM, Simon Andrews wrote: Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. PackageKit has only ever been included in destkop package groups. While these groups are enabled by default, they are with the caveat of: The default installation of Fedora includes a set of software applicable for general internet usage. I've just been and checked on our servers, which were installed with minimal packages and never used for desktop activities and found two of them with PackageKit installed. Looking at the dependencies there is nothing on those machines which currently requires PackageKit so it could be cleanly removed, but something has pulled this in as a dependency in the past. Both of these machines have been through sequential upgrades from around FC3. Changing the behaviour of PackageKit would certainly affect me and I've never explicity installed it. Indeed. This issue is giving Fedora a major black eye in security. And this major security issue -- where admins upgrade into insecurity -- is just hand-waved away even though it applies to a lot of situations. Seriously, quit spreading this it's hand-waved away FUD. Elsewhere in the thread, notably without your participation, people have started discussing both guidelines for how polkit policy should work and also mentioned that they're going to bring this specific case up at the next FESCo meeting and try to deal with it. So seriously, quit pontificating about how your opinion is the truth, the way, and the light, and start reading what others are saying. It's not as you seem to think is is. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/19/2009 04:13 PM, Casey Dahlin wrote: On 11/18/2009 09:23 PM, King InuYasha wrote: On Wed, Nov 18, 2009 at 8:18 PM, Ikem Krueger 1: Date/Time stamp, Unix time doesn't work in 32-bit past 2038 (not really affecting us much, most of us will replace our PCs long before then) I believe even 32-bit kernels now keep the time in a 64-bit integer. This shouldn't apply any more. Sure it does -- time_t in userland is 32-bit, and that's what applications are using, and what the system call interface supports. -- Peter Any connection between your reality and mine is purely coincidental. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:52 PM, nodata wrote: Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. Please do try and stay on topic. This is an entirely unrelated problem which has been resolved. -- Peter Any connection between your reality and mine is purely coincidental. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:24 PM, nodata wrote: Am 2009-11-18 21:02, schrieb Peter Jones: On 11/18/2009 01:52 PM, nodata wrote: Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.comwrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. Please do try and stay on topic. This is an entirely unrelated problem which has been resolved. It's related because it's the same problem. In both cases functionality was missing before a suitable replacement was available. Related to the topic is not the same as on topic. -- Peter Any connection between your reality and mine is purely coincidental. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:10 PM, Casey Dahlin wrote: On 11/18/2009 03:06 PM, Peter Jones wrote: On 11/18/2009 02:35 PM, Casey Dahlin wrote: On 11/18/2009 02:32 PM, Casey Dahlin wrote: On 11/18/2009 01:19 PM, Konstantin Ryabitsev wrote: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. --CJD Addendum: Why do you think sudo would ask an already-logged-in user for his password? Because the config file says to. Good sort of answer when speaking about chickens and roads. A bit too existential for system administration though. You've sortof missed my point here, which isn't a big surprise since I left a lot of space to figure it out in. root added your name to /etc/sudoers. She might have put: cjd ALL=(ALL) NOPASSWD:ALL but apparently instead she put: cjd ALL=(ALL) ALL If sudo is asking you for a password, it's because somebody intentionally made a choice for it to do so, in the config file. It's not some kind of accident. It's not some global policy because of a universal truth, as you seem to think. It's a choice somebody made when they put your name in there. (Read what you will as to how this is relevant to our current predicament.) -- Peter Computers don't make errors. What they do, they do on purpose. -- Dale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 02:48 AM, Jeff Garzik wrote: On 11/17/2009 02:43 AM, nodata wrote: Am 2009-11-17 01:55, schrieb Chris Ball: Hi, I've written up a draft of an F13 filesystem rollback feature using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is the right idea, and how exactly the UI interaction should work, before submitting this formally. Thanks! - Chris. So this will confuse things a lot if the user doesn't have only rpm stuff on one partition, and everything else on another. This is potentially a major risk. How would that be handled? Mr. nodata, As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. A bloody awful solution, especially when you consider that btrfs' maintainer Chris Mason is adding support for real userland transactions (via some additional ioctls). Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. If they do, that'd be really interesting for upgrades. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. Yes, that's why I included the extra words. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On 11/17/2009 02:15 PM, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:09 PM, Peter Jones pjo...@redhat.com wrote: On 11/17/2009 11:48 AM, Tom Lane wrote: Peter Jones pjo...@redhat.com writes: Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be. Rollback *after* commit? This must be some other usage of the term commit than is standard to database people. So, I guess I should expand some more on what I'm saying. The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit. Or, put another way, what you basically want is: 1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as: 1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point. It doesn't. Userspace transactions are _only_ to make sure that a set of operations go to disk at the same time. The original reason this was implemented was for ceph, a distributed filesystem that has a client that runs in userspace and needs to write to an inode and update an xattr on that inode at the same time in order to maintain filesystem consistency. Nowadays there is _no_ guarantee that the write to the inode and the write to the xattr will go into the same transaction, so the userspace transaction just makes sure that they do happen in the same transaction. It's not a snapshot or anything like that, its just a way to guarantee ordering. Thanks, Okay, so then I definitely don't see what jgarzik was getting at. -- Peter If you're not part of the solution, then you're part of the precipitate. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [SoaS] Booting Fedora live USB on MacBookPro
On 11/17/2009 04:17 PM, Stewart Adam wrote: On 2009/11/16 10:56 AM, Peter Jones wrote: On 11/11/2009 01:30 AM, Stewart Adam wrote: On 2009/11/10 5:41 PM, Peter Jones wrote: On 11/10/2009 05:37 PM, Caryl Bigenho wrote: Hi, My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. If the silver MBP is also a 4,1 model, there may be complications... There are some video initialization problems [1] when booting EFI kernels. Stewart [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 Yeah. If somebody had one of these machines at FudCon in Toronto, I could probably knock this out in relatively short time. I know that it can be harder to debug if you're not at the machine, but if I can provide you with any info I'll be happy to do so - just let me know what I need to do. There's nothing to /debug/. Somebody needs to figure out where the framebuffer is and what it's dimensions are, and then it needs to be added to the table. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [SoaS] Booting Fedora live USB on MacBookPro
On 11/11/2009 01:30 AM, Stewart Adam wrote: On 2009/11/10 5:41 PM, Peter Jones wrote: On 11/10/2009 05:37 PM, Caryl Bigenho wrote: Hi, My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. If the silver MBP is also a 4,1 model, there may be complications... There are some video initialization problems [1] when booting EFI kernels. Stewart [1] https://bugzilla.redhat.com/show_bug.cgi?id=496134 Yeah. If somebody had one of these machines at FudCon in Toronto, I could probably knock this out in relatively short time. -- Peter In computing, turning the obvious into the useful is a living definition of the word frustration -- Alan Perlis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: intent to retire: kudzu
On 11/11/2009 04:51 AM, Rahul Sundaram wrote: On 11/11/2009 12:07 PM, Stewart Adam wrote: I will update it eventually to DeviceKit, but I can't invest the time at the moment. Would it be possible to have it temporarily removed from the repos? If it works as it is, you can take over kudzu for the time being and continue with it till the time that you can move over to a replacement. Really, temporarily removing this is more desirable than merely passing maintainership of kudzu around. Kudzu needs to actually go away. -- Peter In computing, turning the obvious into the useful is a living definition of the word frustration -- Alan Perlis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Booting Fedora live USB on MacBookPro
On 11/10/2009 02:40 PM, Bernie Innocenti wrote: Hello, I'm creating an EFI bootable USB image on my rawhide system with this command-line: ./livecd-iso-to-disk.sh --format --efi --overlay-size-mb 400 \ --delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 The resulting USB stick boots fine on a black MacBook, but not on a silver MacBook Pro. The bootable stick does not even show up in the list of boot devices. Which generation of MBP and MBP, and are you using the i386 tree or the x86_64 tree? It sounds like the MacBook is a Santa Rosa (MacBook3,1) or later and the MacBook Pro is an earlier generation, and you're using x86_64. Or vice-versa regarding the ages, and you're using the i386 tree. This won't work, as pre-Santa Rosa mac will only boot 32-bit EFI images, and post-Santa Rosa macs will only boot 64-bit EFI images. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Booting Fedora live USB on MacBookPro
On 11/10/2009 03:49 PM, John Reiser wrote: pre-Santa Rosa mac will only boot 32-bit EFI images, and post-Santa Rosa macs will only boot 64-bit EFI images. Also, it is only recently that a Mac might boot from USB2.0 at all; Firewire (IEEE 1394) was required for most of Apple history. All EFI macs can do this. -- Peter RFC 882 put the dots in .com. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [SoaS] Booting Fedora live USB on MacBookPro
On 11/10/2009 05:37 PM, Caryl Bigenho wrote: Hi, My MacBook is a 4,1. Will it work on my machine? A 64-bit EFI image should work on a MacBook4,1 . A 32-bit EFI image won't. -- Peter RFC 882 put the dots in .com. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Interface Question
On 10/29/2009 01:17 PM, Martin Dubuc wrote: How is it possible to figure out what driver is associated with which interface. We used to have some of this information available in /sys/config/hwconf. I am especially interested to know details of Wi-Fi interfaces (for instance ath5k or iwlagn). lshal will show this info, among mountains of other data. -- Peter Teach a man to use food stamps, he'll eat for a day. Teach a man to *forge* food stamps, he'll eat for a lifetime. -- Dossy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On 10/27/2009 03:03 PM, Ola Thoresen wrote: On 27. okt. 2009 19:18, Tomasz Torcz wrote: You can install rfkill package and use same-named command: Nice app. Thanks for the tip. But does anyone have any idea about how to disable the hardware kill switch, when linux insists it is enabled no matter what position the switch is really set to: AIUI, this means there's a physical switch somewhere on the device. -- Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Wi-Fi Question
On 10/27/2009 03:49 PM, Martin Dubuc wrote: This is a very nice tool. Unfortunately, on my system running Fedora 11, I get the following erro: Can't open RFKILL control device: No such file or directory Using strace, I discovered that rfkill is trying to open path /dev/rfkill, but this path does not exist on my system. Instead, it should try to open path /sys/class/rfkill. Yep, that feature isn't in kernels that old. Martin On Tue, Oct 27, 2009 at 2:18 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Tue, Oct 27, 2009 at 12:24:10PM -0400, Martin Dubuc wrote: On most laptops, there is a way to disable Wi-Fi either through function keys or kill switch. I am wondering if there is a way programmatically speaking to figure out whether or not Wi-Fi is currently disabled because the user has pressed the Wi-Fi function key or turned Wi-Fi off with the kill switch. You can install rfkill package and use same-named command: % rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: yes Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Peter For some reason it has always seemed to me that the term software engineering contains some very optimistic assumptions about the nature of reality. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On 10/26/2009 10:51 AM, Adam Jackson wrote: On Mon, 2009-10-26 at 20:13 +0530, Rahul Sundaram wrote: On 10/26/2009 08:15 PM, Adam Jackson wrote: On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote: On 10/26/2009 07:03 PM, Adam Jackson wrote: On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote: I meant performance, primarily in terms of speed of compilation. Not the code itself. Suppose it's faster. Say even by a factor of 100. So what? What problem would that solve? The problem of slow compilation? :-) Which affects who? koji certainly seems to be keeping up with the load. What I'm trying to pry out of you is what you'd be hoping to accomplish by using it. The answer so far seems to be I'd spend less time building things, at the cost of some unknown amount of time invested in fixing everything to build again. That doesn't sound like progress. Well, that plus your already voiced complaint about its dwarf generation, which is to say that any fairly immediate adoption would also make normal development and debugging more painful. -- Peter Gravity is a habit that is hard to shake off. -- Pratchett -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On 10/26/2009 10:51 AM, Rahul Sundaram wrote: On 10/26/2009 08:21 PM, Adam Jackson wrote: Which affects who? koji certainly seems to be keeping up with the load. What I'm trying to pry out of you is what you'd be hoping to accomplish by using it. The answer so far seems to be I'd spend less time building things, at the cost of some unknown amount of time invested in fixing everything to build again. That doesn't sound like progress. Certainly status quo is easier. Less time building things is a obvious benefit. This is just myopia, though. In isolation, yes, faster builds are nice. But if the faster builds result in poorer quality, then no, they're not a benefit. We don't know the cost unless we try. Doing a scratch build similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing that we should never try at all doesn't seem appealing to me. Go ahead and set that up. Report the result back to us. -- Peter Gravity is a habit that is hard to shake off. -- Pratchett -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On 10/26/2009 11:22 AM, Rahul Sundaram wrote: On 10/26/2009 08:45 PM, Adam Jackson wrote: Please don't put words in my mouth, I did not say never try at all. I said that spending less time building things is only an obvious benefit if we don't lose real functionality, and don't waste time placating the compiler to get things to build. Yes, I understand that. Note that benefit is not just speed. From a earlier discussion, http://www.linux-archive.org/fedora-development/362915-clang-static-analyzer-use.html But hey, if you're volunteering to run the experiment, go wild. I am not volunteering. I just wanted to know if anyone else has already tried it. If you read my original post, that's what I asked. Well, why not? -- Peter Gravity is a habit that is hard to shake off. -- Pratchett -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
On 10/22/2009 10:22 PM, Kevin Kofler wrote: Sam Varshavchik wrote: 32 bits will be here for a long, long time, of course At most 29 years. 32-bit GNU/Linux doesn't support dates beyond 2038. This only actually means we've got 29 years to extend time_t . -- Peter All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On 09/10/2009 06:27 PM, Tom Lane wrote: Mark Wielaard m...@redhat.com writes: Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. ISTM the major argument in favor of letting this in now, namely better debuginfo data, is essentially moot because it missed the mass rebuild. The majority of packages are going to go out with old debuginfo. I'm not sure that's entirely true. Right now, a frequent debugging workflow for me is something like: 1) discover the problem I'm seeing is in $PACKAGE 2) check out $PACKAGE from cvs and make a test-srpm 3) build it without optimizations 4) wedge it into my test environment 5) debug! With better debuginfo generation in gcc, this workflow remains the same, but it's possible that a) I may not have to turn of optimizations in step #3, which can be a nontrivial difference depending on the package, and b) I may get better results with step #5 . So there is some advantage to doing this now, though it's not as great as it could be had it been done within Fedora's unrealistic schedule. -- Peter When in doubt, debug-on-entry the function you least suspect has anything to do with something. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/03/2009 12:29 PM, Bill Nottingham wrote: Hans de Goede (j.w.r.dego...@hhs.nl) said: It really is like having to support gentoo, versus having to support a distro using pre build packages. And I would really like to move to the having to support a pre-build package model for the initrd. The problem is this: The kernel binary RPM contains this pre-built initrd. The kernel source RPM does not contain the sources necessary to make this pre-built initrd. This makes me rather uncomfortable from a Licensing perspective. True, but we do provide SRPMS with the sources, if we include a list of the SRPMS with the sources, with full NEVR in the kernel rpm as doc, wouldn't that be sufficient? Not really. In the case of initrd-built-with-kernel, it could be packages in the buildroot that never leave koji for release/updates, and are then garbage collected. There's a related problem here - glibc32 . -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH 3/3] dracut has initrd-generic-version instead of initrd-version (#519185)
On 09/08/2009 12:04 PM, Tom spot Callaway wrote: On 09/08/2009 11:10 AM, Peter Jones wrote: There's a related problem here - glibc32 . I don't think we distribute glibc32. Hrm. Yeah, probably jumped the gun there. Just want to make sure we keep it in mind. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpqarrayd for fedora 11 and 12
On 08/27/2009 06:02 AM, Howard Wilkinson wrote: I have had to patch the code for cpqarrayd to get it working under Fedora 11. It was failing with a stack smashing exception. I have fixed this by replacing stack structures with dynamic allocation. Where should I send the patch ... the last development on this was in 2007 so it is probably not being maintained, although I will try to contact the author. Congrats, you get to be maintainer (and possibly the only remaining user) of cpqarrayd. -- Peter I hope you know that this will go down on your permanent record. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide LiveCD with EFI boot?
On 08/27/2009 12:21 PM, Peter Robinson wrote: Hi All, I have a little touch screen device that I'm playing around with. It has EFI and its easy enough to get it to boot something other than what its meant to. It seems the LiveCD doesn't have EFI support there. Any hints welcome. Right now, because of known problems with some older BIOSes, only the boot.iso contains multiple boot images. -- Peter Obviously, a major malfunction has occurred. -- Steve Nesbitt, voice of Mission Control, January 28, 1986 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On 07/01/2009 01:22 PM, Adam Jackson wrote: On Wed, 2009-07-01 at 11:51 -0400, Seth Vidal wrote: On Wed, 1 Jul 2009, Kevin Kofler wrote: Seth Vidal wrote: yum install system-autodeath That just turns off networking (so then how do you preupgrade from there? And it lets people keep running their obsolete stuff forever in their closet) and it has to be explicitly installed. yum install sense-of-humor He can't, KDE doesn't support that yet. Did you inform them that they needed to? -- Peter The trouble with the global village are all the global village idiots. -- Paul Ginsparg -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 12:05 PM, King InuYasha wrote: On Wed, Jun 10, 2009 at 3:43 AM, Christopher Brown snecklif...@gmail.comwrote: 2009/6/10 King InuYasha ngomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list While that is true, I have already seen two of my machines unable to boot through GRUB Legacy that could through GRUB 2. Bug numbers? -- Peter In the time of chimpanzees I was a monkey. -- Beck -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 05:17 PM, Jeremy Katz wrote: On Wednesday, June 10 2009, King InuYasha said: On Wed, Jun 10, 2009 at 11:36 AM, Adam Jackson a...@redhat.com wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. EFI support is not the same as fake-EFI. Erm, the EFI support in our grub today isn't fake-EFI. I think he's referring to a Chameleon feature. -- Peter Space, is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: de-modularising for the win!
Kyle McMartin wrote: On Fri, Oct 03, 2008 at 11:25:49AM -0400, Peter Jones wrote: Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100644 --- a/config-generic +++ b/config-generic @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set -CONFIG_DM_MIRROR=m +CONFIG_DM_MIRROR=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m CONFIG_DM_MULTIPATH_HP=m CONFIG_DM_MULTIPATH_RDAC=m -CONFIG_DM_SNAPSHOT=m +CONFIG_DM_SNAPSHOT=y CONFIG_DM_UEVENT=y -CONFIG_DM_ZERO=m +CONFIG_DM_ZERO=y Not that I object to this or anything of the sort, but it would be nice if when people were asking for things to be built-in, to see the size difference on vmlinux on a Fedora build with it enabled. Well, I haven't done a build (on a slow laptop right now) but these modules don't have anything funny going wrt compiling differently when modular. So that means: -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-mirror.ko -rwxr--r-- 1 root root 25K 2008-09-23 21:38 dm-snapshot.ko -rwxr--r-- 1 root root 7.0K 2008-09-23 21:38 dm-zero.ko 57kB or so max. But at the same time, these are loaded on nearly every Fedora system, and loaded as modules they're taking up at least 64kB . -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Bill Nottingham wrote: See various and sundry plumber's conf discussions. Comments? (The netfilter stuff needs further investigation.) Also, please add these, since they're nearly always loaded (patch is on top of yours): diff --git a/config-generic b/config-generic index 0f43c42..de33831 100644 --- a/config-generic +++ b/config-generic @@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_DM_DEBUG=y # CONFIG_DM_DELAY is not set -CONFIG_DM_MIRROR=m +CONFIG_DM_MIRROR=y CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m CONFIG_DM_MULTIPATH_HP=m CONFIG_DM_MULTIPATH_RDAC=m -CONFIG_DM_SNAPSHOT=m +CONFIG_DM_SNAPSHOT=y CONFIG_DM_UEVENT=y -CONFIG_DM_ZERO=m +CONFIG_DM_ZERO=y # # Fusion MPT device support ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] make sr_mod report more accurate drive status after closing the tray.
James Bottomley wrote:
On Thu, 2008-07-10 at 17:24 -0400, Peter Jones wrote:
Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl,
there's no way to differentiate between when you've just closed the
drive tray, but the media is not yet loaded, and when there's no media.
This seems to be accidental.
Here's a patch that seems to fix this behaviour:
I'm very wary of doing something like this because it took us months to
fix up all the breakage the last time ...
That's certainly understandable. What I'm hitting is that I can't tell
the difference any more between not having media and it simply not being
ready yet. And the amount of time it takes to become ready seems to
vary wildly (1s on one drive I've got here, ~20s on another fairly new
drive), so a timeout isn't even a very effective kludge.
Signed-off-by: Peter Jones [EMAIL PROTECTED]
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index ae87d08..43a084b 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi,
int slot)
/* we have no changer support */
return -EINVAL;
}
- if (0 == sr_test_unit_ready(cd-device, sshdr))
- return CDS_DISC_OK;
-
- if (!cdrom_get_media_event(cdi, med)) {
+ if (0 == sr_test_unit_ready(cd-device, sshdr)
+sshdr.sense_key == 0
This can't be right; if the return is zero, the sense_key must also be
zero (as in to have valid sense, it must have returned with at least
DRIVER_SENSE)
+!cdrom_get_media_event(cdi, med)) {
And this really doesn't look right either. Now you're only calling the
media event if the test unit ready succeeded. A drive can be open (thus
returning not ready and hence non zero) and still give you a valid media
event.
Ok, that's a fair point. That part I'm really trying to avoid here is
returning the CDS_NO_DSIC case when the sense key says we don't yet know
(NOT_READY). So probably that case simply shouldn't be returned until
after we do the SK/ASC/ASCQ check.
if (med.media_present)
return CDS_DISC_OK;
else if (med.door_open)
@@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi,
int slot)
}
/*
-* 0x04 is format in progress .. but there must be a disc present!
+* ASC: 0x04: logical unit is not ready
+* ASCQ: 0x01: cause not reportable
+* 0x02: in process of becoming ready
+* 0x03: initializing command required
+* 0x04: format in progress .. but there must be a disc present!
+* 0x07: operation in progress
+* 0x08: long write in progress
*/
- if (sshdr.sense_key == NOT_READY sshdr.asc == 0x04)
- return CDS_DISC_OK;
This seems to be a nasty historical lie. It seems to play into the new
media changed stuff by stalling the change until the media is ready.
Convince me that if we actually tell the truth here we're not going to
fire a slew of spurious events at hal.
Would you be ok with a more minimal approach, where I only change the
behaviour of NOT_READY/4/4 ? I understand if you still want more study
of the effects WRT udev/hal.
+ if (sshdr.sense_key == NOT_READY sshdr.asc == 0x04) {
+ switch (sshdr.ascq) {
+ case 0x01:
+ case 0x02:
+ return CDS_DRIVE_NOT_READY;
+ case 0x03:
+ return CDS_TRAY_OPEN;
That's a stretch ... the initialising command can be start motor, but
the tray can be closed just fine.
Yes, it definitely is. I don't feel strongly about this particular
case, but the rationale was that as long as we're not handling that in
the driver, then this case essentially means user intervention is
required (though there's really no way for the user to know what that
would be). CDS_TRAY_OPEN is, AFAICT, the only return value that means
that in other cases (i.e., on slot-loaders). This part isn't critical
to the functionality I need; it just seemed wrong when I was reading it.
--
Peter
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] make sr_mod report more accurate drive status after closing the tray.
Right now, when using sr_mod and issuing the CDROM_DRIVE_STATUS ioctl,
there's no way to differentiate between when you've just closed the
drive tray, but the media is not yet loaded, and when there's no media.
This seems to be accidental.
Here's a patch that seems to fix this behaviour:
Signed-off-by: Peter Jones [EMAIL PROTECTED]
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index ae87d08..43a084b 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -306,10 +306,9 @@ int sr_drive_status(struct cdrom_device_info *cdi,
int slot)
/* we have no changer support */
return -EINVAL;
}
- if (0 == sr_test_unit_ready(cd-device, sshdr))
- return CDS_DISC_OK;
-
- if (!cdrom_get_media_event(cdi, med)) {
+ if (0 == sr_test_unit_ready(cd-device, sshdr)
+sshdr.sense_key == 0
+!cdrom_get_media_event(cdi, med)) {
if (med.media_present)
return CDS_DISC_OK;
else if (med.door_open)
@@ -319,10 +318,27 @@ int sr_drive_status(struct cdrom_device_info *cdi,
int slot)
}
/*
-* 0x04 is format in progress .. but there must be a disc present!
+* ASC: 0x04: logical unit is not ready
+* ASCQ: 0x01: cause not reportable
+* 0x02: in process of becoming ready
+* 0x03: initializing command required
+* 0x04: format in progress .. but there must be a disc present!
+* 0x07: operation in progress
+* 0x08: long write in progress
*/
- if (sshdr.sense_key == NOT_READY sshdr.asc == 0x04)
- return CDS_DISC_OK;
+ if (sshdr.sense_key == NOT_READY sshdr.asc == 0x04) {
+ switch (sshdr.ascq) {
+ case 0x01:
+ case 0x02:
+ return CDS_DRIVE_NOT_READY;
+ case 0x03:
+ return CDS_TRAY_OPEN;
+ case 0x04:
+ case 0x07:
+ case 0x08:
+ return CDS_DRIVE_NOT_READY;
+ }
+ }
/*
* If not using Mt Fuji extended media tray reports,
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Patch to arch/x86/mm/init_32.c causes EFI-32 machines to reboot early in startup
Hugh Dickins wrote: On Wed, 2 Jul 2008, Peter Jones wrote: The inline patch works, thanks! Oh, that's good news, thank you! I'll write a better description and send it off to Linus and Ingo for 2.6.26 now. I'll say Fedora reports... and say Tested-by: Peter Jones [EMAIL PROTECTED], would that be appropriate? That's fine by me, though TBF I don't think any /users/ have actually reported it, not counting myself. -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: revisit: turning some of the always used modules to built-in
Dave Jones wrote: On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote: Category 1: Always loaded anyway Rationale: Since we load these always anyway, why bother making it modules - ata_generic, pata_acpi These ones make me hrmm a bit. I'd like to know that our initrd isn't going to do something silly before we change these. Peter ? We probably need to do a little bit of mkinitrd work to make sure this works, but not much. That being said, don't we need to install e.g. ahci _before_ ata_generic on most systems to get the right behavior? Also, how does ata_generic interact with ata_piix? I know changing the install order of ahci vs ata_piix causes major flux in behavior... - libata Sure. Done in CVS. - sg, sd_mod Ditto. sr_mod and cdrom? They're not strictly required, but it's really, really common. It's 60k of bloat, which isn't great, but I think it also makes booting incrementally quicker (because hal won't need to load the modules.) , scsi_mod This one is tricky. It seems to become modular because it's dependant upon the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK, like the fibrechannel stuff. I'm not convinced we want to build all that stuff in. Then we need to make sure that there's a dep chain that shows up with modprobe --show-depends. - ext3, jbd, mbcache I'm torn on these. Mostly for the reasons both Eric and Matt suggested. The flipside being that Eric knows how to build his own kernels, and can do so, but at the same time, if it means he spends less time fixing ext bugs each day and more time staring at compiler output, I'm not sure it's a net win. Matts argument, whilst RHEL specific, does have an element of validity for Fedora too. We always push the 'Fedora isn't a test vehicle for RHEL' angle, but at the same time, there's no denying that doing something completely different does take away a certain amount of 'in the field' testing. (In this case, I'm primarily thinking about the knock-on effects changes like this have on the kernel periphery packages like mkinitrd/anaconda which now have to support two separate cases). Actually, I don't think these three change mkinitrd/anaconda much at all; we always pull these three modules in as dependencies, never manually. Category 2: Always loaded in default install [...] - dm_mod Yeah, I guess. This will require minor changes to mkinitrd, but I'm for it. Also, dm_snapshot, since we also always load it (there's no way to tell if it's necessary ahead of time :/ ) Also, though not strictly _required_, dm_zero, and dm_mirror would be nice -- you always get them loaded, and there aren't any module deps on them. (Though arguably this is a deficiency in lvm2) - ahci (default storage for all new systems; means that there the system always has the / device driver) Same thing as above. The mkinitrd logic surrounding ordering of storage modules is fragile at best.. I think this will break some ICH[789] boxes, won't it? I've seen this cause ata_piix badly misbehave if this is already loaded when it loads on systems configured in legacy mode in the BIOS (which is often not exposed as an option to the user AT ALL) - ehci_hcd (means you have a USB keyboard early) ISTR there was some issue with this. I'm sure we even tried it once in the FC2 era. Lets give it a shot, and see what happens. I think this should work these days... if not, we should really just sit down and fix it. There's some mkinitrd work here, but it's mostly just code removal, and you should get a working initrd even before we do it. Also this is required to do usb-serial console (though that's still pretty broken itself ATM), which could eventually be really useful for debugging. I think we also want uhci_hcd here; if you've got EHCI you'll wind up loading it anyway, and if you don't, then you'll probably want it loaded. -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] Merge the IMAC mode code with efifb and remove imacfb entirely.
This mail contains a patch which merges the IMAC mode code into the efifb
driver and removes the imacfb driver entirely. There are also a couple of
minor bug fixes. Any comments before I start bothering the upstream
maintainers with it?
---
drivers/video/Kconfig | 15 +--
drivers/video/Makefile |1 -
drivers/video/efifb.c | 170 --
drivers/video/imacfb.c | 376
4 files changed, 162 insertions(+), 400 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1bd5fb3..474c375 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -656,23 +656,14 @@ config FB_VESA
config FB_EFI
bool EFI-based Framebuffer Support
- depends on (FB = y) X86
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- help
- This is the EFI frame buffer device driver. If the firmware on
- your platform is UEFI2.0, select Y to add support for
- Graphics Output Protocol for early console messages to appear.
-
-config FB_IMAC
- bool Intel-based Macintosh Framebuffer Support
depends on (FB = y) X86 EFI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
help
- This is the frame buffer device driver for the Intel-based Macintosh
+ This is the EFI frame buffer device driver. If the firmware on
+ your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
+ using the EFI framebuffer as your console.
config FB_HECUBA
tristate Hecuba board support
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 11c0e5e..c789b01 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -118,7 +118,6 @@ obj-$(CONFIG_FB_OMAP) += omap/
# Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA)+= uvesafb.o
obj-$(CONFIG_FB_VESA) += vesafb.o
-obj-$(CONFIG_FB_IMAC) += imacfb.o
obj-$(CONFIG_FB_EFI) += efifb.o
obj-$(CONFIG_FB_VGA16)+= vga16fb.o
obj-$(CONFIG_FB_OF) += offb.o
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index bd779ae..cd962d0 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -12,9 +12,20 @@
#include linux/fb.h
#include linux/platform_device.h
#include linux/screen_info.h
+#include linux/dmi.h
#include video/vga.h
+typedef enum _MAC_TYPE {
+ M_I17,
+ M_I20,
+ M_MINI,
+ M_MACBOOK,
+ M_UNKNOWN
+} MAC_TYPE;
+
+/* - */
+
static struct fb_var_screeninfo efifb_defined __initdata = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -33,6 +44,37 @@ static struct fb_fix_screeninfo efifb_fix __initdata = {
.visual = FB_VISUAL_TRUECOLOR,
};
+static int inverse;
+static int model = M_UNKNOWN;
+static int manual_height;
+static int manual_width;
+
+static int set_system(const struct dmi_system_id *id)
+{
+ printk(KERN_INFO efifb: %s detected - set system to %ld\n,
+ id-ident, (long)id-driver_data);
+
+ model = (long)id-driver_data;
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata dmi_system_table[] = {
+ { set_system, iMac4,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,iMac4,1) }, (void*)M_I17},
+ { set_system, MacBookPro1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,MacBookPro1,1) }, (void*)M_I17},
+ { set_system, MacBook1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,MacBook1,1)}, (void *)M_MACBOOK},
+ { set_system, Macmini1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,Macmini1,1)}, (void *)M_MINI},
+ {},
+};
+
static int efifb_setcolreg(unsigned regno, unsigned red, unsigned green,
unsigned blue, unsigned transp,
struct fb_info *info)
@@ -67,6 +109,34 @@ static struct fb_ops efifb_ops = {
.fb_imageblit = cfb_imageblit,
};
+static int __init efifb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((this_opt = strsep(options, ,)) != NULL) {
+ if (!*this_opt) continue;
+
+ if (!strcmp(this_opt, inverse))
+ inverse = 1;
+ else if (!strcmp(this_opt, i17))
+ model = M_I17;
+ else if (!strcmp(this_opt, i20))
+ model = M_I20;
+ else if (!strcmp(this_opt, mini))
+ model = M_MINI;
+ else if (!strcmp(this_opt, macbook))
+
Re: kernel posttrans and preun hooks for other packages
Peter Jones wrote: (Adding Panu to the Cc) Jason L Tibbitts III wrote: MD == Matt Domsch [EMAIL PROTECTED] writes: MD [...] there's no ordering guarantee between the two such that we MD know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do. Actually, I guess that's not the only way -- there is %posttrans . It has some obvious downsides though, not least of which being if the transaction fails it'll never get run, it doesn't show up in any progress information, and AFAIK it's generally just not well tested. -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
(Adding Panu to the Cc) Jason L Tibbitts III wrote: MD == Matt Domsch [EMAIL PROTECTED] writes: MD [...] there's no ordering guarantee between the two such that we MD know kernel-devel is always installed before kernel. It should be possible to have kernel-devel have Requires(post): kernel or use some other type of fine-grained dependency to guarantee some sort of ordering. That doesn't guarantee the right thing -- it's inverted. It makes it so that before kernel-devel's %post runs, kernel must be installed. What Matt needs is a guarantee that kernel-devel is installed (if it will be installed at all) before kernel's %post runs. Right now the only way to do that is for kernel to require(post): kernel-devel, which is obviously not something we want to do. We've definitely mentioned that non-dependency ordering tags are an rpm wishlist item in the past. Maybe Panu has some thoughts on this? -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernels won't boot
David Zeuthen wrote: On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: On Saturday 22 December 2007 07:16:32 Build System wrote: kernel-2.6.24-0.123.rc6.fc9 --- * Fri Dec 21 2007 David Woodhouse [EMAIL PROTECTED] - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing * Fri Dec 21 2007 John W. Linville [EMAIL PROTECTED] - Yet another round of wireless updates... * Thu Dec 20 2007 Kyle McMartin [EMAIL PROTECTED] - 2.6.24-rc6 After build 81, I have not been able to boot any of the x86_64 rawhide kernels. They all end with: Trying to resume from /sys/block/sda/sda3 Unable to access resume device (/sys/block/sda/sda3) Creating root device Mounting root filesystem mount: could not find '/dev/root' Setting up other filesystems Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Booting has failed. Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other people running into this? I'm still seeing this too on all my x86 and x86_64 boxes with all kernels including todays update. Peter, Dave, any clue? Can you show me more of the log? -- Peter ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Linus and Fedora
On Fri, 2006-05-26 at 12:09 -0400, Alex Maier wrote: Hey, mind posting this on the Media Coverage page? http://fedoraproject.org/wiki/Marketing/PressArchive We probably shouldn't -- it's nice to have him as a user, but he doesn't really announce when he's changed his mind on which distro he's using, so it's _really_ easy to be citing old data. (to wit, he mailed me yesterday to say that he's using Ubuntu on his Mac Mini Core Duo box until I fix a grub bug he's hitting...) -- Peter -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
CD verify on FC5 disc 5.
On Tue, 2006-03-21 at 22:35 +1100, Russell Coker wrote: I burned a copy of CD 5 with 800 blank sectors at the end and it worked perfectly. I also noticed that CD 2 has the problem (although I hadn't noticed it before), CDs 3 and 4 don't have a problem (I still have to repeat tests on CD 1). I guess that I can work around this problem by specifying a padsize of something between 81 and 800 sectors (if some more friends want copies of FC5 then I'll find out soon). Ok, so... what CD drive do you have, what type of bus is it on, and what controller is in use? -- Peter
Re: Grub Fallback -- Is it for real?
On Mon, 2006-03-13 at 18:36 -0500, Janina Sajka wrote: Warren Togami writes: Janina Sajka wrote: Should I expect this to work? Is there some other mechanism to boot a different kernel just once--on the next boot? http://togami.com/~warren/guides/remoteraidcrazies/ My guide here has an example of using grub's savedefault --default X --once directives in order to specify a kernel to boot next. It tries to boot that kernel. If you reboot again, it falls back to the first listed kernel in grub.conf. Hmmm, this syntax looks different from that in the grub docs on gnu.org. Thanks for forwarding this. I will study and see what I can do with it. I am precisely in the position of needing to manage a server which I cannot get to physically. Janina It is -- we've got a patch that implements this functionality, and we've had it since before upstream had the ability to do this. Nobody's filed any bugs requesting the new way, and there's code using it, so we just haven't migrated to the new way yet. -- Peter
Re: FC5 Final Release
On Wed, 2006-03-08 at 03:04 -0500, Ivan Gyurdiev wrote: Then there's the minor inconvenience of gnome-netstatus being broken with my atheros chip: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179406 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181861 We don't ship an Atheros driver. -- Peter
Re: FC5 Final Release
On Wed, 2006-03-08 at 22:26 -0700, Stanton Finley wrote: And these: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178143 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182147 Almost certainly a BIOS bug in both cases. -- Peter
Re: FC5 Final Release
On Wed, 2006-03-08 at 23:39 -0700, Stanton Finley wrote: This then begs the question why do the FC2, FC3, and FC4 installation media boot and install on the same machine without incident? What's different about the FC5 installation image kernel and can it be fixed? Because the behavior of the int13h hook in your BIOS's CD reading code depends not only on the inputs that it's supposed to depend on, but also on some other factor, be it previous calls or some incorrect dependence on another register's value. If you really want this to work, you're either going to have to debug it, or get a machine to somebody who can. I can't really just guess what your BIOS is doing. -- Peter
Re: Meeting minutes - 16/09/2005
On Fri, 2005-09-16 at 02:01 +1000, Colin Charles wrote: * Logo - First round at: http://www.capstrat.com/development/fedora/. Infinite freedom isn't decided as the slogan, but the general consensus is that the logo is loved. Concentrate on logo feedback today. Color can be fixed later (like Legacy or something) Is the 'f' too subtle? Do we need a name? Somebody suggested I should comment on the list, so here goes ;) On the whole, I like the infinite freedom concept, and I like the f-infinity teardrop logo. It also makes a great icon. I don't like the 'f' in the wordmark; it seems that it should be more similar to the logo. I also don't like the 'a'; it doesn't really resemble the logo (as the intent is noted to be), and the wide circular style makes the wordmark feel asymetric. But that's just nit-picking. The real feedback I have is regarding the logo placement with respect to the text. There's a big field of heavy, dark color in the logo, and placing it caddy-corner to the right the text creates a lot of negative space around it. The combination of the two draws the eye away from the text very, very strongly. This is obviously why the subproject logos all have the text on the right side rather than the left, but it's still very, very strongly weighted to the top and right. Also, it kindof looks like a cartoon thought-balloon with that placement. -- Peter -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-marketing-list
