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
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
