Re: Our static Libraries packaging guidelines once more
On Wed, 2010-01-06 at 17:38 +0100, Michael Schwendt wrote: The only problem with that is that just about every packaging guideline has _some_ valid exceptions (that's why they're all guidelines...) and it's rather hard to build exceptions into an automatic testing system in a way which doesn't get horribly crufty in a hurry. If exceptions become a problem because they are applied to many packages, it would still be possible to adjust the guidelines or mark the packages with special metadata comments in their .spec files. Then packagers would need to make use of an exception _explicitly_, showing that what they do is intentional. Yup, indeed - this is the approach MDV uses for its rpmlint checks (you can code an exception into the spec file if it's justified). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ABRT considered painful
On Fri, 2010-01-01 at 16:45 +0100, drago01 wrote: Also some duplicate detection wouldn't hurt ... (I get new bug reports everyday just to notice that almost all of them are duplicates). abrt already does duplicate detection, but it's hardly a straightforward thing to do. Jiri and the rest of the team are always happy to work with anyone who has ideas on how to improve abrt's duplicate detection. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: BZ 523646 - F13Blocker?
On Tue, 2009-12-29 at 23:38 +, Paul wrote: Hi, I originally reported this bug in September 2009 when f12 was rawhide. It was fixed but has recently resurfaced for both F12 and rawhide users leaving anyone with an intel chipset for video with unusable systems. Are you sure this is the case? There are a wide variety of intel graphics chipsets and not all behave the same. If they were all broken - especially in F12 - I would have expected to hear a much larger stink by now. Given that this kills quite a few laptop users, can this be escalated to F13Blocker? It is already listed as high for both priority and severity. We always encourage people to nominate any bug they think may be a blocker. Basically any time you ask yourself the question - 'hmm, maybe this should be a blocker' - PLEASE just put it on the list, there's no need to post to a list to ask people's opinions. We have the blocker review process to downgrade bugs we eventually decide don't really need to be blockers, so please do err on the side of adding bugs, rather than leaving them off. I've not tried booting a live distro that is not a fedora one as to be honest, I'd rather not sully my machines! However, I've not heard of anyone using Ubuntu with the same kernel and xorg-x11-drv-intel version having the same problems. The 'same versions' means very little, really. The graphics stuff in Fedora's '2.6.31' kernel bears little resemblance to what's in upstream's '2.6.31' kernel, or what's in Ubuntu's. Fedora's kernel drm bits are much newer. Ditto, to a slightly less extent, for the 'intel' driver: Fedora's tends to include newer patches than indicated by the banner version number. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: need help in contributing to se-linux policy development
On Sun, 2010-01-03 at 13:52 +, Jonathan Underwood wrote: 2010/1/3 sai ganesh gane...@fedoraproject.org: hi, my name is sai. i am a fedora-ambassador.i want to contribute to the development of se-linux policies.i am a Redhat certified se-linux policy administrator.i am well versed in development of se-linux policies.how can i contribute ? whom should i contact? i have already tried contacting the owners of the se-linux packages.i didn't get any response. Perhaps you'd be better off sending a mail to the fedora-selinux-list: https://www.redhat.com/mailman/listinfo/fedora-selinux-list Additionally, Dan Walsh - the SELinux maintainer - is usually very responsive. It would be unusual for him not to respond to such a query. However, most Red Hat offices and employees shut down for the holiday period (around 25th December to 2nd Jan) and we all take a break, which may well explain the lack of a response. Sai may well get a response soon now the holiday is over. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-12-18 at 04:11 -0600, Otto Haliburton wrote: you don't follow the list very well, and obviously didn't read the post that this replies to so don't go around calling people inconsistent. Windows forces you to reboot and there is no mandatory reboots in Linux and windows does force you to restart, don't restart when it ask you and see what happens, it will not continue without insisting that you restart. Where do you get this crap? With windows you cannot avoid a restart. And there is no auto-restart in windows it is auto-update and with auto-update you have no choice it will restart for you. Try it then tell me about it. You're arguing from different starting points, and there's no need to be uncivil about it. Shmuel's point is that you can disable automatic updates on Windows (which is quite true), and hence you won't then be forced to restart until you manually choose to install the updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about a lib requires
On Fri, 2009-12-18 at 19:11 +0200, Jussi Lehtola wrote: Is there a way to include these requires properly ? (like adding directly /usr/bin/jpegtran and /usr/bin/tiffinfo in Requires). Yes. Requires: /usr/bin/jpegtran Requires: /usr/bin/tiffinfo Does it really just need the binaries and not the libs, just that rpm would auto-Require the libjpeg and libtiff RPMs? And if it actually needs the binaries, then you can just put in Requires: libjpeg, libtiff and safely ignore the rpmlint warning. AFAIK resolving file dependencies is a lot slower than resolving explicit dependencies. +1: just requiring the library packages and ignoring the rpmlint warning seems correct here, to me. You are smarter than rpmlint, after all. rpmlint is just considering the case where you're adding a library dependency, not realizing it will be automatically generated. It is not considering the case where the library package includes a binary that you need to depend on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-12-17 at 10:51 -0500, James Antill wrote: The UI isn't very pretty at the moment (it just fails with an update error) but I'll work on something a little bit more user friendly. How do you plan on restarting firefox? Or you just planning to kill() and get the user to restart? If we're just talking about Firefox (i.e. not the general case), then it has its own 'restart Firefox' hook you might be able to access. It's used, for instance, when you enable or disable an extension. I'm not sure if you can poke it from an external app easily, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-12-17 at 22:08 +0100, nodata wrote: Here is my point: Windows requires a reboot less often than Linux. Argue all you want, it's true. It's entirely false, because Linux *never* requires a reboot. Fedora (not Linux, you are generalizing too far) *advises* reboots, it never requires them. Windows forces you to reboot - literally, you cannot prevent it from rebooting when it decides you have to. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FUDConF13 videos
On Tue, 2009-12-15 at 09:31 -0600, Matt Domsch wrote: 2) The last 20 minutes of the Fedora Infrastructure: Sysadmins vs. Developers love-in. I'm grateful to whoever shot this, but I've complete blanked on who it was now. I'll be glad to give you attribution, please remind me! http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF13/fudconf13-infrastructure-roundtable.ogg If anyone else has video or audio from this or other Fedora events you'd care to share, please contact me and I'll help you get it into proper ogg format, tagged, and posted to Fedora Infrastructure servers for distribution. That was me. :) I actually think Remy DeCausemaker was sitting in that talk with his little recorder box - I don't know if it's only a voice recorder, or also video. But he may have the whole thing. Have you contacted him? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Wed, 2009-12-16 at 10:42 -0500, Simo Sorce wrote: But for anyone that does not using master as the default branch will be a problem. If you never used git you have to learn a lot of things anyway. I would hope you don't have to. To be a Fedora maintainer you hardly have to know a thing about CVS, after all - you can do all common operations via the Makefiles. I would hope the fpkg (or whatever) tool will do the same for the git-based system; if not, I'd consider that a significant regression. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Mon, 2009-12-14 at 23:22 +0100, Kevin Kofler wrote: Adam Williamson wrote: I actually dropped gst-mixer with F12, as we planned all along. So that one's not an option for F12. Someone could unorphan it, or use the F11 package. (BTW, I don't see why you retired it as it was clearly still useful to some users and it can't hurt to have it in the repository.) Because I don't see a substantial enough need to keep maintaining it now gnome-volume-control has most of the features most users need. If someone wants to maintain it I'm happy to pass it off to them, though I'd now agree with Lennart and the desktop team that it should not be in the default installed package sets (comps) any more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Sun, 2009-12-13 at 10:49 +0300, Vasily Levchenko wrote: Right, we still in progress (e.g. VBox 3.1 is failing to load FC12 with ACPI, and it can't load Windows Vista and 7/EFI) but with VBox 3.1 with manually edited config runs FC11(i386/x86_64) fine. From what I saw in the thread, the bug seems to be that X is assuming the presence of a VGA BIOS, which would seem to be a fairly generic problem that would hit any EFI setup. I guess real EFI systems has proprietary drivers + corresponding drivers, e.g. nvidia, and there're no serious reasons to use vga bios. Fedora never assumes the presence of proprietary drivers. When we say we want EFI to work, we mean with the drivers included in Fedora. AIUI anyway. See Vasily's message of a couple of days ago. But I could be wrong, and also I'm not sure why he's testing with F11 rather than F12 or Rawhide. About rawhide, could you please give me some pointers on ISO images, instructions for kernel compilations (looks like it bit different from compilation of vanilla kernels)? Live images go up nightly here: http://alt.fedoraproject.org/pub/alt/nightly-composes/ building kernels - well, approaches differ. Personally I tend to grab the latest .src.rpm, make the changes I want in the spec, build it back into a .src.rpm and compile with mock. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
On Fri, 2009-12-11 at 10:53 -0500, James Laska wrote: Not sure if this has been raised yet, but are we specifying when in the release that packages should be signed with a valid signature? I believe packages are signed at all release milestones, but I'd like to clear up that assumption. Do you think that's a criteria issue, i.e. something to which there's an innate correct answer which can be defined and which shouldn't change? I'd think of it more as a process issue, but IMBW. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Tue, 2009-12-08 at 14:05 -0500, Jon Masters wrote: On Tue, 2009-12-08 at 12:59 +0100, Tomasz Torcz wrote: On Tue, Dec 08, 2009 at 09:51:55AM -0200, Paulo Cavalcanti wrote: I did a clean install of Fedora 12 and realized that pavucontrol was not installed by default. I have two sound cards and I only got sound when I manually installed pavucontrol and used it. Any reason? pavucontrol is regarded as advance tool, but also partly obsolete. Current gnome-volume-control superseded most of its functionality: controlling different streams volume, switching profile, outputs, fallback devices. The new gnome-volume-control is so cut-down it's not useful to me. In the quest to be more Mac-like in removing mixer controls (and not even having any obvious advanced mode), I now have a choice of no audio or having full volume LFE output *and* whatever mixer level I have set for the master output. alsamixer works fine, but then I can't use the volume sliders on my desktop and it gets rather awkward. pauvucontrol is no different in that respect. If gnome-volume-control / pavucontrol do not correctly control your volume, please file an appropriate bug report: https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Tue, 2009-12-08 at 21:45 +, Bastien Nocera wrote: You can still do all the heavy lifting you want. Install the old gst-mixer, I actually dropped gst-mixer with F12, as we planned all along. So that one's not an option for F12. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Wed, 2009-12-09 at 13:40 -0500, Jon Masters wrote: I couldn't disagree more strongly. As a Linux user, I want the show me everything option. I don't care if I have to check a box to do it, but I want to see all the knobs and dials. And I at least expect not to have what I'm doing with alsamixer interfered with by the other tools. It's quite difficult for any given mixer not to 'interfere' with any other, given that, in the end, they're all poking the same underlying dials. We're always going to provide alsamixer for anyone who needs access to all the controls, it's not going anywhere. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why pavucontrol is not installed by default?
On Wed, 2009-12-09 at 13:46 -0500, Jon Masters wrote: All paranoia and ranting aside, there is some truth to this. There is a definite trend in the Linux community to want to cater to the lowest common denominator by being more Mac/Windows-esque. I put up with it because I can usually ignore it (I refuse on principal to use a GUI to copy a file, for example, but that's just me being weird), but I don't see the harm in hiding the advanced stuff under a checkbox - the advanced mixer stuff is still there underneath after all. That kind of 'split' interface - with the advanced stuff 'hidden away' - has several significant problems. It's much more difficult to support when you have to consider the possibility of there being two different interfaces the user could be using to the program. It's also been quite solidly documented in usability studies that just about everyone tends to consider themselves an expert and hence hit the 'advanced' button, even when they don't actually have a freaking clue what they're doing. It also encourages lazy interface design - the designer can always think 'well, I'll just make this a checkbox under 'advanced' somewhere', rather than considering how to properly design a single configuration interface. There are probably still cases where it makes sense, but it's not an unproblematic design, and I'm not sure I'd agree it's a sensible model for the default volume control. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, 2009-12-09 at 12:38 -0900, Jeff Spaleta wrote: On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote: Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. Other than revelation(which essentially has a dead upstream)...Istanbul is probably the most in need of more development love. This made me prick up my ears, as I keep my entire gigantic password database in revelation. What kind of development does it actually need? Dead upstream or not, it seems to work fine. Is it in imminent danger of dying? I can't help, not being a coder, but I'd like to know what's going on in case I have to change my workflow :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
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 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: new webkitgtk incremental release for F12
On Fri, 2009-12-11 at 12:38 -0600, Adam Miller wrote: There is currently a new incremental release to webkitgtk (the current release in F12 is 1.1.15-3, latest is 1.1.15-4) and I wanted to shoot out to the list to find out if there is anything that would need a new build against webkitgtk if I were to build the latest as a potential stable update for F12 (possibly pywebkitgtk and/or $other?). I've done a scratch build and tested with Midori which has been a positive experience so far, so if there are any other alternative web browsers that use webkitgtk they should work as well against the new build, but testing is always best. Isn't the Epiphany in F12 the webkit version? I think kazehakase may use it too, but not 100% sure. And I think quite a lot of bits of GNOME use webkit for HTML rendering these days. A quick-n-dirty check gives: [ad...@adam Download]$ repoquery --whatrequires libwebkit-1.0.so.2()(64bit) gimp-help-browser-2:2.6.7-2.fc12.x86_64 evolution-rss-0:0.1.4-12.fc12.x86_64 epiphany-extensions-0:2.28.1-2.fc12.x86_64 awn-extras-applets-0:0.3.2.1-8.fc11.x86_64 libproxy-webkit-0:0.2.3-12.fc12.x86_64 kazehakase-webkit-0:0.5.8-3.fc12.x86_64 gimp-help-browser-2:2.6.7-3.fc12.x86_64 devhelp-0:2.28.1-1.fc12.x86_64 empathy-libs-0:2.28.1.1-3.fc12.x86_64 gmpc-0:0.18.0-1.fc12.x86_64 empathy-0:2.28.1.2-1.fc12.x86_64 epiphany-0:2.28.1-1.fc12.x86_64 anjuta-1:2.28.1.0-2.fc12.x86_64 kazehakase-webkit-0:0.5.8-2.fc12.x86_64 solang-0:0.3-2.fc12.x86_64 evolution-rss-0:0.1.4-5.fc12.x86_64 webkitgtk-devel-0:1.1.15.3-1.fc12.x86_64 empathy-libs-0:2.28.1.2-1.fc12.x86_64 empathy-0:2.28.1.1-3.fc12.x86_64 claws-mail-plugins-fancy-0:3.7.3-1.fc12.x86_64 midori-0:0.2.0-1.fc12.x86_64 webkitgtk-0:1.1.15.3-1.fc12.x86_64 cairo-dock-plug-ins-webkit-0:2.1.1.2-1.fc12.x86_64 liferea-1:1.6.0-1.fc12.x86_64 anjal-0:0.1.0-1.fc12.x86_64 pywebkitgtk-0:1.1.6-2.fc12.x86_64 devhelp-0:2.28.1-2.fc12.x86_64 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Fri, 2009-12-11 at 11:12 -0900, Jeff Spaleta wrote: It's making use of some deprecated functionality for example gnomevfs which really should be ported to the newer gvfs stuff. There are probably some pygtk/gtk-isms which need to be updated. I'm willing to carry this as downstream patches if I have to but I really don't want to do that. Thanks. Less critically for basic operation... the export functionality needs love. I'm not willing to carry this as downstream patches as I view the export functionality as a nice-to-have feature and not critical. I'm more inclined to just patch it to keep export from crashing on error than actually fix the export to work as a downstream only patch. Well, I suppose a little ironically, if revelation were to die, the 'export' functionality would likely be the _most_ critical bit :) There's some subtle problems with language support... which I'm personally ill-equipped to work through as a US English speaker (and barely at that). Crasher bug and something I'm willing to hold as downstream only patches if needed. Haven't ever seen it crash. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X on UEFI systems.
On Fri, 2009-12-11 at 17:14 -0500, Peter Jones wrote: 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? From what I saw in the thread, the bug seems to be that X is assuming the presence of a VGA BIOS, which would seem to be a fairly generic problem that would hit any EFI setup. AIUI anyway. See Vasily's message of a couple of days ago. But I could be wrong, and also I'm not sure why he's testing with F11 rather than F12 or Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 updates-testing issue: X flickers and fails to start
On Wed, 2009-12-09 at 12:20 -0700, Linuxguy123 wrote: On Wed, 2009-12-09 at 18:36 +0100, Kevin Kofler wrote: Linuxguy123 wrote: I have logged 2 bugs that are possibly related to this. https://bugzilla.redhat.com/show_bug.cgi?id=528188 https://bugzilla.redhat.com/show_bug.cgi?id=525767 Huh? One of these is a Nouveau bug, the other is a bug in the proprietary nvidia driver, both of them already happened with F12 as released, so these have absolutely nothing to do with this thread. That is what you say. How exactly did you determine that ? OR are you guessing ? The fact that it only broke for the reporter with an update from three days ago, but you had those problems in September and October. Seems pretty clear. It's not even the same problem description. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
On Tue, 2009-12-08 at 09:19 -0500, Colin Walters wrote: Hi Adam, Looks really great in general! Thanks! One specific comment, for Final 9; I think we need a more specific definition of and subsequent login. Does that mean that you just type your username/password and look at the default desktop? This is what it was intended to mean, actually running apps I would have defined as 'login and use'. How would you suggest wording a clarification? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora release criteria completely revised
On Wed, 2009-12-09 at 14:54 +0100, Dominik 'Rathann' Mierzejewski wrote: On Monday, 07 December 2009 at 23:55, Adam Williamson wrote: [...] https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria 16. Automatic mounting on insertion of removable media must work It should be clarified with ... after GUI login, because it sure never worked before a user is logged in. Also it never worked when user was logged in via text console, did it? Good point - changed. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora release criteria completely revised
During FUDCon, we've been working on revising the Fedora release criteria. John Poelstra had already fleshed out a structure and much of the final content, and we've been revising and tweaking it in conjunction with QA (myself, Will Woods and James Laska), release engineering (Jesse Keating), anaconda team (especially Denise Dumas and Peter Jones) and desktop team (Christopher Aillon and Matthias Clasen, who provided suggestions at an earlier stage). The new structure is based around a general page and specific pages for the Fedora 13 Alpha, Beta and Final releases (which have been written generically so they can easily be converted into pages for F14 and all future releases just by copying and pasting). You can find the criteria here: https://fedoraproject.org/wiki/Fedora_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria they should contain everything you need to know. We based most of the criteria around testing that was already being carried out but with no formal policy basis, with additional suggestions from the anaconda and desktop teams. We will follow these criteria for the Fedora 13 release process. So if you can see any problems or potential trouble with any of this, please do reply and let us know! Desktop team - can you please let us know of any additional things that you would expect to be working at each point during the release cycle? Note that only things that *must* be working at each point should be listed on these pages, not nice-to-haves. You must be able to commit to the idea that, if any criterion on the page is not met, we would slip the release in question. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-12-03 at 08:20 -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. I'm not saying I support the proposal, I don't, I think it's a waste of effort for no benefit. I was just clarifying the initial characterization. Actually I think the initial proposer _was_ expecting to remove initial packages when updates become available, because they keep saying stuff like 'only historians are interested in the GA packages'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird crashing while trying to send e-mail (apparently trouble while composing message)
On Thu, 2009-12-03 at 13:40 +0100, Michal Schmidt wrote: But it appears in bugzilla as a low priority medium severity problem. Priority has no standardized meaning. Most maintainers do not use this field at all. Policy on this is: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity as Michal said, there is no official definition of Priority, and the only group entitled to set it is the maintainer(s) of the affected component; maintainers can choose to use it however they like, or not at all. Most maintainers don't use it at present. Severity can be set by initial reporter, triager, or maintainer. It didn't get set when you reported it because abrt doesn't set this field. It hasn't been set by a triager yet, because it hasn't been triaged (thunderbird isn't actually on our priority triage components list; I don't think anyone's working on triaging tbird bugs at present). And it hasn't been set by the maintainer because they haven't looked at it yet (and they may not really care about severity settings either). Also, as Michal pointed out, you didn't provide any explanation in the report of when the crash actually happened, or explain that it crashes every time you send a mail. Even if a triager were to look at it, it would be impossible to judge a severity based on the information you provided in the report. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote: I suspect that most commercial and government customers will be interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology base on which future Red Hat Enterprise Linux releases are built. The better Fedora is, the more confidence customers will have the the Red Hat product. I agree. What I'm really worried about here, ultimately, is PolicyKit, and the way it permits a lot more grey areas than have been possible before. If you look at previous privilege escalation mechanisms, they're simplistic; whether you're using sudo or consolehelper or whatever, ultimately you either have a process run as root or as user. And it's pretty obvious what should run as root and what shouldn't; I don't remember there being any real serious debates about that, everyone pretty much reaches the same conclusions independently. The authentication question is equally simple: basically either the process just runs as root automatically (which everyone agrees should happen for as few processes as possible), or you have to authenticate each time - for Fedora, basically you have to type the root password, since we never really used sudo. Things like 'well, we can perform this one specific type of operation with this one specific type of authentication' just weren't possible. Now they are, so stuff like the PackageKit issue was bound to start happening. The things PolicyKit make possible really need some kind of coherent oversight, I think, and that is indeed something Red Hat Enterprise Linux will also need to address, so obviously from an RH perspective, it helps RH if Fedora develops some kind of policy for this. But I think it's necessary for Fedora anyway, regardless of RH. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
On Fri, 2009-11-27 at 23:49 -0500, Orcan Ogetbil wrote: On Fri, Nov 27, 2009 at 11:19 PM, Braden McDaniel wrote: I'm an emacs user who's nearly completely useless in vi. But, really... it just doesn't matter if emacs isn't installed by default. If you want it, you know how to get it. And let's be frank: emacs is not something that a user who is unaware of it might stumble into and suddenly find himself blindingly productive. (Nor, for that matter, is vi.) I agree. My problem is not that emacs is missing in development stack. My problem is when there is something wrong with the computer and I have to boot in the rescue mode, I can't rescue anything because emacs is not there. I wrote on a piece of paper how I would save and exit in vi, or exit without saving in vi, but that paper is gone now. I wish vi had some tutorial the way emacs does, so one don't get lost in it. I'd recommend you use nano instead (which is, I believe, installed by default for just this purpose). It has the main keyboard shortcuts permanently displayed on screen, so you can't lose 'em. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Sun, 2009-11-29 at 09:23 +, Terry Barnaby wrote: That doesn't scale. There's lots of useful pages in the Wiki. We can't link to all of them from the front page. I was thinking of this more as a special Graphics debug push :) Special cases are never a good idea. and add some search terms such as Graphics Problems, 3D problems etc. I'm not sure you can add search terms to Wiki pages, but if you can, then sure. I would have thought that simply adding the text for these in the page would have helped searching ? It would be rather ugly, though? It's a decent idea, the problem I have with it is you wind up with a forest of little scripts with no decent maintenance strategy. I'd rather have a more integrated and properly maintained tool, it may grow out of abrt in future. Yes, but that the moment the Graphics bugs seem to have random user inputs of information. I would have thought that a simple script to help with just Graphics bugs would help just now. (I am hoping all of the graphics problems will have gone away by next year :) ) This is never a good way of thinking. The more experience you get with working on an ongoing project like a Linux distribution, the more you want to do _everything_ in a properly planned and sustainable framework, because you find that the things you think will just be temporary hacks never ever wind up that way. They just get built into the plumbing and make people's lives miserable forever :) Hoping all graphics problems will go away in a year is definitely not a good way to plan. :) We don't do this except for extreme major brokenness which we somehow missed during testing, it's not worth the effort involved. Fedora Unity does updated re-spins, however they haven't got anything out for F11 yet due to some problems, I believe they're looking for extra volunteers. You say that producing a Fedora 12.1 release is not worth the effort involved. Is that truly the case ? Certainly that is what I always do here. Normally the initial Fedora releases contain quite a few issues and there are a flurry of updates. So I use pungi to create my own updated release that I use to install on further systems. There is very little effort in this and, I would have thought, not to much further testing effort needed. It is a problem that anaconda updates aren't released however. Certainly from the users front I would have thought that this is worth the effort. It allows them to install a Fedora system with the core bugs that users have found fixed in one pass. Building a spin isn't that much work. Validating it (yes, QA would not want to release any image which hadn't been through full installation validation testing) and doing all the other release gubbins which happens as _well_ as just spinning an image is a lot more work. Not doing .1 releases has been the releng's team position for a long time. I'm not in the releng team so I'm not going to argue their position for them, but it is a properly argued one. Jesse can give you full set of reasons if you like, and if he feels like rehashing them :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Sun, 2009-11-29 at 20:03 +, Ikem Krueger wrote: The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of. I'd like to help. But the wikipage for testing Xorg issues* is a way to much to read, given the case you follow all the links on the site and you need to do so to get an overview. :S To much confusing for a newb. A real howto with goal, what you need, small steps, final step, conclusion and how it change things would be nice. :) *https://fedoraproject.org/wiki/How_to_debug_Xorg_problems If you'd like to mock up such a page as a draft and submit it to test-list, that'd be fine. But I'm not sure it's actually possible to make the existing page any _smaller_ without losing valuable information. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Mon, 2009-11-30 at 10:28 -0900, Jeff Spaleta wrote: On Mon, Nov 30, 2009 at 10:16 AM, Haïkel Guémar karlthe...@gmail.com wrote: Instead of whining, he should ask his employer to hire more X hackers, one guy is obviously not *enough*. This has nothing to do with our issue and Fedora at all. What is your definition of hacker? Is he contributing to X.org upstream development or is he just pulling patchsets to be applied to distribution specific packages? Just as interesting. he's spent most of his time between UDS and that post trying to address nvidia regressions Fwiw, I pretty much ended up spending 100% of my time between release and UDS on SRU bugs (mainly for -nvidia) Yippie for prioritizing regressions in proprietary code! Nope, Bryce doesn't get to work on upstream in any significant way as part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.) As others have said, this post doesn't really teach Fedora any lessons. It could more accurately have been titled 'Why Having Exactly One X Developer Is A Really Bad Idea For A Major Distribution'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Sat, 2009-11-28 at 07:31 +, Terry Barnaby wrote:
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily
find it from the main wiki home page however. Maybe a link to this page
marked
Graphics issues could be made on the front page (focus users on improving
the
graphics) ?
That doesn't scale. There's lots of useful pages in the Wiki. We can't
link to all of them from the front page.
There's a link on the front page which says 'Report a new bug', with the
word 'bug' a link to
https://fedoraproject.org/wiki/BugsAndFeatureRequests . The X page is
linked from that page in the 'Information required for bugs in specific
components' section. That's two steps from the front page.
Could improve the title Graphics problems and bug reporting ?
We have multiple pages of this type, all named
How_to_debug_foobar_problems . We found that the best generic naming
scheme for all such pages.
and add some search terms such as Graphics Problems, 3D problems etc.
I'm not sure you can add search terms to Wiki pages, but if you can,
then sure.
Add some info on what to set for Bugzilla fields ?
That's not appropriate for subject-specific pages; it's discussed in the
main 'how to report bugs' page,
https://fedoraproject.org/wiki/BugsAndFeatureRequests .
Maybe the bug reports should include the package version numbers ?
That might be useful in some cases, yeah.
Maybe some simple user tools could be generated to ease and make bug
reporting
more useful. Something simple like the following might be useful:
#!/bin/sh
date bug1
lspci | grep VGA bug1
(echo -n kernel: ; uname -r) bug1
rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}\n xorg-x11-server-Xorg bug1
rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}\n xorg-x11-drv-ati bug1
rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}\n mesa-dri-drivers bug1
glxinfo | grep OpenGL renderer string bug1
It's a decent idea, the problem I have with it is you wind up with a
forest of little scripts with no decent maintenance strategy. I'd rather
have a more integrated and properly maintained tool, it may grow out of
abrt in future.
It might be worth including info on how to update from fedora-testing just
graphics related packages. Ie add something like:
includepkgs=kernel* xorg-x11-* mesa*
to the updates-testing section of fedora-updates-testing.repo and
enable the repo ? Also how to revert. Should it state that all tests
should be done with fedora-updates-testing packages ?
The automated systems for handling updates usually handle this (when an
update is submitted to updates-testing that's marked by the maintainer
as fixing a particular bug, an automatic comment is added to the bug
with a note that an update is in updates-testing to be tried).
I notice there is a new xorg-x11-drv-ati. It does look like things are moving
:)
All we need now is 2 months down the line for Fedora 12.1 to be released with
updated anaconda and all updated packages in ISO form so that
Joe public can easily install a good working Fedora release ...
We don't do this except for extreme major brokenness which we somehow
missed during testing, it's not worth the effort involved. Fedora Unity
does updated re-spins, however they haven't got anything out for F11 yet
due to some problems, I believe they're looking for extra volunteers.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
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 Fri, 2009-11-27 at 09:35 +, Terry Barnaby wrote: Also mentioned then I thought it would be good to have a basic, and simple for users, graphics testing system to easily allow users to test and feedback issues. Even if this is simply a short list of 2D/3D applications and a list of operations to try. Would a graphics testing day on F12 with the special graphics repo and some basic list of tests be useful to the developers ? You mean, just like the three F12 graphics test days, with basic lists of tests and special live spins, which we already did? :) https://fedoraproject.org/wiki/Test_Day:2009-09-09_Radeon https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau https://fedoraproject.org/wiki/Test_Day:2009-09-11_Intel So, here's my general take on this. First, as has been pointed out, several of your issues were encountered when running the NVIDIA proprietary driver. There is no way we can sensibly do any work on NVIDIA driver issues as we have no source for the driver. There's no way we can tell what's going wrong or fix it. It's just a complete non-starter. And no, we can't even forward the bugs to NVIDIA, because they don't have a bug tracking system. What they have is a guy who reads the Linux / NVIDIA forums at nvnews.net and Phoronix, and that's it. All we can really do is advise you to post your problem there. Second, I do understand your frustration, really I do. I do quite a lot of X triage, and it is noticeable that issues are often not fixed in the release against which they're reported. However, there are really genuinely good reasons for this. Mainly, as Dave noted, it's very hard to implement fixes in X for stable releases and be sure they don't cause regressions; again as he noted, we're hoping to work on a system to make this a bit more possible. But also importantly, the 'upstream / downstream divide' that's being discussed in this thread isn't so simple, for Fedora. To a large extent, Fedora is _part_ of upstream, for X server, radeon and nouveau especially. The people who package and develop X in Fedora are also major upstream developers, and the work they do tends to be genuine development work rather than integration / fix backporting. Dave and Jerome are major contributors to radeon driver development, Ben is a major contributor to nouveau driver development, and all of them along with Adam contribute to X server development. So, a lot of what our X team is doing is actually driving the major forward progress of these components - not just fixing specific bugs but working on support for new hardware, and new features / architecture like KMS and DRI2 and GEM. So they tend to work by pulling fixes into new development. A lot of issues reported in, say, 10 and 11 actually got noticed by the developers and worked on, but they were worked on in such a way that the fix isn't a minimal band-aid that it's trivially simple to backport to that release. The fix got incorporated into significant development work which would not be straightforward to backport without the possibility of causing a regression. It would, of course, be theoretically possible for Fedora's X team to spend less time working on important new driver development and more time working on minimal-impact fixes for the existing releases, but that's not the same as saying it would be _desirable_. In the long run, getting the major development done really needs to happen. As Dave has implied several times in the thread, there are several openings here for community involvement, and that would be great. It would be entirely possible for volunteers to get involved both in testing and development work, especially in building and testing update packages for stable releases. But it's not something that we could simply redirect existing development towards without suffering significant consequences in other areas. The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of. https://fedoraproject.org/wiki/BugZappers/Joining -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug triage: further change upcoming
On Fri, 2009-11-27 at 11:08 +0100, Matěj Cepl wrote: Dne 24.11.2009 18:02, Adam Williamson napsal(a): So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. If anyone can see why this may present a big problem, please let us know; we're holding off on the change for a day or so just in case. Adam, do you think it was presented here long enough, so we could just go ahead with this plan? yeah, I was about to poke you and suggest the same thing :) I think we can go ahead with it now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-11-27 at 20:04 +, Terry Barnaby wrote: Hi, I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this. Right...that is mainly a product of what Dave mentioned, that general 3D functionality is unfortunately right at the bottom of the priority list, at least until we have drivers that work really solidly for basic desktop functionality. But I'd be happy to have more extensive 3D tests in the list for future test days, please do feel free to submit some. But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part. It's not a bad idea, for sure. I'm not sure _I'd_ do it, though, it's enough work organizing the test days for the upcoming release without doing ones for the last release too. :) However, we do have a process for allowing anyone to organize a Test Day. You can propose one just by mailing test-list or filing a ticket in QA trac, and we have an SOP for the whole process of actually hosting one: https://fedoraproject.org/wiki/QA/SOP_Test_Day_management so it'd be perfectly feasible for a community member to organize post-release graphics test events for the stable release. I'd be happy to work those into the upcoming test day schedule if you'd be interested in doing it. Actually it was not me with NVIDIA. I don't have any systems using this chipset. sorry, yes, mistaken identity :) Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway. We do have a page on reporting X.org bugs: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems which should cover the major points, and which we try to direct people to wherever we can. Do you think there's anything missing from that? Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see. Thanks a lot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-11-27 at 21:24 +0100, stefan riemens wrote: Not that i'm unhappy about the way things are going forward (my intel gfx are working great!), but gnome 3 isn't going to be much useful without 3d support... Note that gnome-shell working was quite high in Dave's priority list (within the range of 'things RH staff get paid for'). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-26 at 11:32 +0100, Karel Klic wrote: On 11/25/2009 06:54 PM, Adam Williamson wrote: What do you think of the idea of running the improved duplicate detection logic over existing abrt bug reports in Bugzilla? Would that be feasible, perhaps with some help from the Bugzilla maintainer? Thanks! Many backtraces currently stored in bugzilla are damaged (truncated) by a bug (in Linux kernel?). That bug has been fixed, but the backtraces already uploaded with that bug are not parsable by current backtrace parser. I haven't figured out how to tweak the parser to handle the damaged backtraces yet. However, I'd like to focus on the new duplication detection mechanism for now, because it is more important from my point of view. Sure, I agree that would take priority for now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-25 at 10:20 +0100, Karel Klic 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. The algorithm for duplicate detection in the currently released version of ABRT is very rudimentary: it removes only the most obvious duplicates in simple programs. As far as I know it does not work for applications with variable number of threads (e.g. Firefox). Fortunately now we have a new algorithm for duplicate detection which handles all the cases in a significantly better way. Most of the code is written, but it needs some testing before releasing. I guess it will take two weeks or so to finish it, and to make sure it works well. An important attribute of the new algorithm is that it errs on the side of false duplicates. So it will much more often say some bug is a duplicate of another bug, even if sometimes it is not the case. It should make abrt bug flow sustainable, and than we can slowly improve the detection mechanism to be more accurate. Second, we wondered if abrt team might be able to assist in running any improved duplicate detection mechanisms over already-reported bugs in Bugzilla retrospectively. We will follow up with them about that. When the duplicate detection works, it would be a loss to not have the crashes directly in Bugzilla. I often see that the crashes reported by ABRT are located in the code and fixed. If we fail to deliver better detection, then some intermediate site is certainly better target for thousands of duplicates than Bugzilla. I would propose to create some intermediate site as a target for users who are not experienced enough to create an account in Bugzilla and to respond to questions, or they simply do not care. Then, it would be possible for them to report almost automatically, and we could get a lot of backtraces and support data that is currently lost. However, this must be thought out (security issue with backtraces). Thanks, Karel. If you think you'll be able to manage a level of duplicate detection which keeps things workable for triaging, that's great news and would certainly make the whole situation simpler :). I think we'd be willing to wait on that and see how it goes. I was working from Matej's suggestion in the meeting that he'd talked to you (abrt team) already and was sure that a high enough level of duplicate detection was hard/impossible; if that's not the case, obviously it changes things. What do you think of the idea of running the improved duplicate detection logic over existing abrt bug reports in Bugzilla? Would that be feasible, perhaps with some help from the Bugzilla maintainer? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 13:13 -0500, Jud Craft wrote: Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. The very first time I booted my laptop with this (800x600) projector, it defaulted to clone mode in session. I left the room and restarted my laptop. When I returned, plugging the monitor in live resulted in an extended desktop (very cool). I then restarted my laptop and let it boot fresh with the monitor plugged in. The desktop session started in clone mode again. I have a completely-different-in-every-way giant widescreen monitor at home, so I don't think Display Settings is mixing up the external display configurations. Did you read Bastien's suggestion about the BIOS? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, 2009-11-25 at 14:28 -0500, Jud Craft wrote: Please pardon my answering everyone in one email. To Adam: I have not used my BIOS. The Intel 965 card on my Toshiba laptop has no BIOS options. I can't even change the default scaling from full-panel to off. It's really sad. so, um, you didn't read it, then. =) he simply suggested connecting the external monitor at grub stage rather than having it plugged in at BIOS stage, to see if that made a difference. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: review request - rasmol, Molecular Graphics Visualization Tool
On Wed, 2009-11-25 at 12:04 -0800, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
the short version is that at a minimum you should stick an icon with
the
same name as the binary, extension / file format .png,
in /usr/share/icons/hicolor/48x48/apps .
That did not work for me, but if I put the converted .png icon in
/usr/share/icons it works nicely.
That's the 'old' system and really shouldn't be used. What you probably
missed is the bit I missed from my original email - when using the new
system you need to add these snippets:
%post
touch --no-create %{_datadir}/icons/hicolor /dev/null || :
%postun
if [ $1 -eq 0 ] ; then
touch --no-create %{_datadir}/icons/hicolor /dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor /dev/null || :
fi
%posttrans
gtk-update-icon-cache %{_datadir}/icons/hicolor /dev/null || :
to the spec. Otherwise the icon cache doesn't get updated so the icon
won't be available.
...that sounds like you shouldn't ship a menu entry at all, to me. As
you say, it would be rather pointless. But I dunno if there's a policy
requirement that you should anyway.
It turns out to be trivial to have the desktop file launch the program
from within a gnome-terminal
Terminal=true
which does exactly what I want.
ah, I see. I misunderstood you as suggesting that you need to pipe data
to rasmol at startup to make it useful, obviously that's not the case :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
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 Mon, 2009-11-23 at 19:01 -0500, 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. 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? If I am not misunderstand, can you point me to the real reason that this feature was removed? Your understanding is not correct. The 'feature that was removed' is retention of authorizations (for more than a very short period). PolicyKit 0.x had keep_always policies, which asked a user to authenticate for an operation just once and then kept that authorization indefinitely. These are what were removed in PolicyKit 1.x, leaving only the keep policies, which retain authorization for just a few minutes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug triage: further change upcoming
Hi, guys. Just a quick note - Matej Cepl pointed out that the already-agreed BugZappers plan to switch to using the Triaged keyword only for Fedora 13 and later presents problems. Most significantly, it's impossible to reliably construct a Bugzilla search which will find bugs that have been triaged under *both* the F13+ and F12- methods. So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. No other change will be made to the bugs (they won't, for instance, be changed back to NEW). This will be done without generating any email notifications, so there won't be an email flood. We can't think of any problems this could cause; some bugs that haven't actually gone through the triage process may get marked as 'Triaged', but that won't have any negative effects. All we really use the flag for is searching to find which bugs need triage and which don't. If anyone can see why this may present a big problem, please let us know; we're holding off on the change for a day or so just in case. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug triage: further change upcoming
On Tue, 2009-11-24 at 22:35 +0530, Rahul Sundaram wrote: On 11/24/2009 10:32 PM, Adam Williamson wrote: Hi, guys. Just a quick note - Matej Cepl pointed out that the already-agreed BugZappers plan to switch to using the Triaged keyword only for Fedora 13 and later presents problems. Most significantly, it's impossible to reliably construct a Bugzilla search which will find bugs that have been triaged under *both* the F13+ and F12- methods. So, we've come up with a plan. With the help of David Lawrence we propose to add the Triaged keyword to all existing F10-F12 bugs that are in ASSIGNED state, with the exception of anaconda bugs, PackageReview bugs and FutureFeature bugs. Why the exception for Anaconda? at present anaconda is in a state of having opted-out from the typical triage process, so we generally leave them out of things like this and let them handle their own bugs. in practice this change was actually partly designed to bring the bugzappers practice and anaconda practice closer together, and in future this may well change, but for now we're leaving it out just to be consistent with the current official status of anaconda wrt bugzappers. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Tue, 2009-11-24 at 20:47 +0530, Rahul Sundaram wrote: We are not discarding CD images all together. If you feel there is a compelling reason to continue with a Live CD, I am afraid you will have to step up and do it. The tools are easy enough to learn and I am willing to help you or anyone else interested. I'm not sure that's entirely true. To my knowledge, only the desktop team is considering making this change. I haven't heard that the KDE, LXDE and Xfce spins are all moving to 1GB images. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 13:28 -0500, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 install stops at screen switch (language select)
On Tue, 2009-11-24 at 19:28 +0100, Jos Vos wrote: On Tue, Nov 24, 2009 at 06:00:20PM +, Jóhann B. Guðmundsson wrote: Try adding the kernel parameters nomodeset and xdriver=vesa or xdriver=intel and vga=ask and select any of the 24 bit values offered.. If install is successful then boot into run level 3 and run Xorg -configure and adapt accordingly something like.. BTW it looks like the nomodeset parameter is missing in the list of boot options at these two places: http://docs.fedoraproject.org/install-guide/f12/en-US/html/sn-bootoptions-hardware.html http://fedoraproject.org/wiki/Anaconda/Options I checked these lists to find a usable option first, but couldn't find it. it is documented in the Common Bugs: https://fedoraproject.org/wiki/Common_F12_bugs#intel-misc-gfx it could stand to be in the install guide, I guess, but it will likely go away in future - the UMS (userland mode setting) code path is going away. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 10:44 -0800, Adam Williamson wrote: As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. or, I suppose more trivially, a PackageKit policy for the ability to install PolicyKit policy packages. heh, now that's a bizarre sentence. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 x86 DVD images
On Tue, 2009-11-24 at 10:54 -0800, Jesse Keating wrote: On Tue, 2009-11-24 at 12:24 -0600, Sir Gallantmon wrote: Why not label it x86_32 instead of i386? That is far less confusing and illustrates that it is 32-bit on the x86 architecture, since x86_64 says it is 64-bit on x86 architecture. Because that's not what uname says. Change that, and then we'll talk. it doesn't change the fact that, logically speaking, either the DVD or CD images is wrong. Or at least, less right. I can see no sustainable argument that they should be different. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Sun, 2009-11-22 at 19:21 +0100, Martin Sourada wrote: So, since I've already received 3 separate bug reports caused by BadIDChoice X Error in subtitleeditor [1][2][3] (haven't had enough time to debug and try to fix it yet though) by abrt, I wonder if there is any room for duplicity detection improvement in these cases, or if we are doomed to zillions of duplicates in rhbz? (btw. otherwise abrt is awesome, IMHO the bugreports from abrt are much more useful than before :-) We discussed this issue at the Bugzappers meeting today. BZ would like to register that the high level of duplicates reported by abrt is a significant issue for triage work. We're not sure we can sustainably triage some major components (e.g. Firefox) if the current situation continues. 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. Second, we wondered if abrt team might be able to assist in running any improved duplicate detection mechanisms over already-reported bugs in Bugzilla retrospectively. We will follow up with them about that. Third, we agreed to look at methods used in GNOME and other Bugzillas to cope with high levels of duplicate reporting from automated tools, such as extracting significant sections of tracebacks as bug comments to make manual duplicate detection faster and easier. Finally, we considered - and rather approved of - the proposal that's been floated on this list (and was floating in the meeting by Will Woods) to consider using the mechanism used by the kernel developers for kernel oopses: instead of being reported direct to Bugzilla, these are reported to an intermediate site (kerneloops.org) and can be promoted from there to Bugzilla if appropriate. Will is planning to work on this idea after finishing up some AutoQA work, and will talk to abrt team about it and see if they are interested in helping. He would welcome contact from anyone else who's interested in helping with that, too. That's all, really - I just took an action item to pass on our thoughts about this :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 15:34 -0500, Bill Nottingham wrote: Chris Ball (c...@laptop.org) said: If some some spin decided to make every user run as root, ship with no firewalling, have password-less accounts, or have insecure services enabled by default, etc. You mean Sugar as configured on the XO? (It has passwordless user, who can su without a password.) It's true, but note that the XO software is technically a Remix rather than a Spin, so there aren't any technical requirements on it to satisfy the use of the Fedora mark. (I think I'd agree with Greg's point regarding official Fedora spins.) But if it was such a concern with respect to the Fedora brand and image, I would think the same argument would apply, even if it was just branded as a 'Fedora remix'. SoaS is not Fedora-branded in any way, AFAIK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Tue, 2009-11-24 at 16:21 -0500, Peter Jones wrote: 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. Matej? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Tue, 2009-11-24 at 16:38 -0500, Peter Jones 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. it ought to be *somewhere* in http://svn.mandriva.com/cgi-bin/viewvc.cgi/ , but I dunno where exactly. I'll try and find out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: review request - rasmol, Molecular Graphics Visualization Tool
On Tue, 2009-11-24 at 15:05 -0800, Carl Byington wrote: 1) There were some menu icon references to files that are no longer in the package, but there is a rasmol_48x48.xpm image. What is the preferred mechanism to create menu icons, where do they go, etc? Follow the fd.o icon theme specification: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html the short version is that at a minimum you should stick an icon with the same name as the binary, extension / file format .png, in /usr/share/icons/hicolor/48x48/apps . If upstream provides icons in any other resolution, include those in the appropriate directory; if upstream provides an SVG, include it in /usr/share/icons/hicolor/scalable/apps . The .desktop file should list the icon as simply the main part of the filename, with no extension (so if the icon is rasmol.png , the .desktop file should state Icon=rasmol ). However, see below... 2) There does not seem to be much point in creating gui icons for this, since it seems to be intended to run from a command prompt in a terminal. The program uses stdin to read commands, and the data is then displayed in a graphic window. Unless there is an easy way to create an icon that launches a gnome-terminal which in turn runs the rasmol binary, and allows the user to then type commands into that terminal session. ...that sounds like you shouldn't ship a menu entry at all, to me. As you say, it would be rather pointless. But I dunno if there's a policy requirement that you should anyway. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 13:28 -0500, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 2009-11-24 at 10:44 -0800, Adam Williamson wrote: As I noted somewhat flippantly in another thread, this comes with the problem that, theoretically, a user who has the privileges to install packages at a relaxed security level could arbitrarily raise the security level of the system to a much higher level, against the wishes of the administrator. perhaps something akin to system-config-selinux would be needed to guard against this? I'm not sure how it could work in the PolicyKit framework, though. or, I suppose more trivially, a PackageKit policy for the ability to install PolicyKit policy packages. heh, now that's a bizarre sentence. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
On Mon, 2009-11-23 at 12:44 +0100, Andreas Tunek wrote: I seem to get crashes when I sometimes close tabs in Epiphany of Firefox. I have a ATI Mobile 340 (based on the R100 series I think). I do not get the same error on my other computer with intel gfx. That has absolutely nothing to do with what Liang posted, but please do file a separate bug report for it: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
On Mon, 2009-11-23 at 17:31 +0800, Liang Suilong wrote: After updating the package, compiz crashed and glxgears can not run. However, KMS and plymouth can still run well. Here is dmesg message that I grabbed: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! But I reboot with kernel-2.6.31.5-127. All the thing return to normal. My desktop is running on Fedora 12 x86_64. My graphic card is HD3650. can you check if this is still the case with 145, and make sure you're also running updated mesa packages from koji? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Mon, 2009-11-23 at 07:37 -0600, Otto Haliburton wrote: well, abrt just pops up and sends a report without user control, the user um, no it doesn't. it never sends a report unless you explicitly agree to do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
On Mon, 2009-11-23 at 22:29 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 13:13 -0800, Adam Williamson a écrit : On Mon, 2009-11-23 at 19:48 +0100, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Maintainers do not equal developers. I am a package maintainer, yet my coding skills extend to copying and pasting things from Google results. usually incorrectly. You cannot assume that all the people to whom you are sending these mails have the capability to fix code problems, that is not a valid assumption. I don't assume they have the capability to fix code problems. I assume they're ready to do their maintainer work and nag upstream till it does. Or are ready to drop the package if it costs them more than it's worth. He already said that he had talked to his upstreams and they had said they would not adjust their code. In that case, he really has done everything he possibly can in his position as maintainer, and sending him further nag emails is achieving nothing constructive and serving only to annoy him. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Security testing: need for a security policy, and a security-critical package process
Hi, everyone. I'm sending this email as a result of a discussion in the Fedora QA meeting this morning. You can find a log of the meeting here: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-23/fedora-meeting.2009-11-23-16.00.log.html the discussion takes place from 16:14:09 onwards. We discussed the recent PackageKit kerfuffle from a QA perspective, which means we talked about how we could have meaningful security testing. We came to some basic conclusions about this which require co-ordination with the security and development groups. We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground. So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change. It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try. Focussing on the relatively simple issues for now, we believe it would be reasonably simple to generate a list of all packages in the distribution that attempt privilege escalation. We believe this would be a list of packages that contain suid binaries, that invoke su, sudo or consolehelper, or that contain PolicyKit policies. This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. Will Woods has indicated he is prepared to help work on the tools necessary to generate the security-sensitive package list. The QA group as a whole is happy to contribute what input we can to any discussion of a general security policy. Mostly, we wanted to make it clear that we believe security testing would be of benefit to the distribution, but these things need to be in place before any meaningful such testing could be done. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 14:33 -0800, Jesse Keating wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software. yeah, sorry - I was thinking along the same lines, having a script to generate the list. I thought that was kind of implied in what I wrote but I guess not :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 18:16 -0600, Chris Adams wrote: Once upon a time, Adam Williamson awill...@redhat.com said: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. IMHO that's a backwards way of approaching security. You will never be able to define everything somebody should _not_ be able to do. You should always take the approach of defining what somebody _should_ be able to do. But think from a QA perspective. However the policy is phrased, we have to test the negatives. If we just tested that all the 'could' things on the list were OK, we would happily approve a release that gave everyone root privileges. After all, everyone would be able to do all the things they were supposed to do. it'd be a 100% pass. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote: How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work. The important part is that we QA the combination, not just the strict defaults. Right. If the Grand Plan is to go down this path, then what I've been referring to as 'the security policy' would include the policies defined for each spin, and hence any testing QA did for any given spin would involve the policy defined for that spin. Having said that - is everyone agreeing that it's fine for each spin SIG to be entirely in charge of defining and implementing security policy for each spin? At the very least, that would possibly be problematic given the known border issues between 'the desktop spin' and 'Fedora'. Just another issue contributing to why we would need to settle that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
On Mon, 2009-11-23 at 16:52 -0600, Otto Haliburton wrote: - Original Message - From: Adam Williamson awill...@redhat.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Sent: Monday, November 23, 2009 3:03 PM Subject: Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM On Mon, 2009-11-23 at 12:44 +0100, Andreas Tunek wrote: I seem to get crashes when I sometimes close tabs in Epiphany of Firefox. I have a ATI Mobile 340 (based on the R100 series I think). I do not get the same error on my other computer with intel gfx. That has absolutely nothing to do with what Liang posted, but please do file a separate bug report for it: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems thanks! again criticizing the reporter for reporting his case. That was what he was Um, where did I criticize anyone? I just told the reporter it wasn't the same bug. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Security testing: need for a security policy, and a security-critical package process
Hi, everyone. I'm sending this email as a result of a discussion in the Fedora QA meeting this morning. You can find a log of the meeting here: http://meetbot.fedoraproject.org/fedora-meeting/2009-11-23/fedora-meeting.2009-11-23-16.00.log.html the discussion takes place from 16:14:09 onwards. We discussed the recent PackageKit kerfuffle from a QA perspective, which means we talked about how we could have meaningful security testing. We came to some basic conclusions about this which require co-ordination with the security and development groups. We can't do any meaningful security testing without knowing exactly what we should be testing for, in which packages. I believe Seth Vidal's upcoming proposal for covering 'major changes' may touch on this, but I doubt they'll cover exactly the same ground. So, if we are to have meaningful security testing in future releases - which QA believes would be a good thing - we need the project to define a security policy. We believe there's a genuine need for this anyway, as the introduction and widespread adoption of PolicyKit will likely lead to much more complex and significant potential changes in security posture than any previous change. It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. The second thing QA would require, aside from a policy with concrete and testable requirements, is a list of security-sensitive components to test. Obviously we couldn't test every package in the entire distribution for compliance with even such a simple list as spot's, and it would be a waste of time to try. Focussing on the relatively simple issues for now, we believe it would be reasonably simple to generate a list of all packages in the distribution that attempt privilege escalation. We believe this would be a list of packages that contain suid binaries, that invoke su, sudo or consolehelper, or that contain PolicyKit policies. This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. Will Woods has indicated he is prepared to help work on the tools necessary to generate the security-sensitive package list. The QA group as a whole is happy to contribute what input we can to any discussion of a general security policy. Mostly, we wanted to make it clear that we believe security testing would be of benefit to the distribution, but these things need to be in place before any meaningful such testing could be done. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 14:33 -0800, Jesse Keating wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: This list of packages would be what the QA team would test with regard to the security policy. We also believe there ought to be a process for maintaining this list, and additions to the packaging guidelines for any new package which would be on this list or any existing package for which a proposed change would add it to this list. We could also hook AutoQA into this process, to run additional tests on security-sensitive packages or alert us when a package change was submitted which added security-sensitive elements to an existing package. I would warn against trying to have a manual static list of packages here, same as crit-path. These packages need to be discoverable via software. yeah, sorry - I was thinking along the same lines, having a script to generate the list. I thought that was kind of implied in what I wrote but I guess not :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote: How that translates in packages and defaults is not really the most important part, but the plan is to have strict package defaults + a policy package that makes things work. The important part is that we QA the combination, not just the strict defaults. Right. If the Grand Plan is to go down this path, then what I've been referring to as 'the security policy' would include the policies defined for each spin, and hence any testing QA did for any given spin would involve the policy defined for that spin. Having said that - is everyone agreeing that it's fine for each spin SIG to be entirely in charge of defining and implementing security policy for each spin? At the very least, that would possibly be problematic given the known border issues between 'the desktop spin' and 'Fedora'. Just another issue contributing to why we would need to settle that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: PackageKit policy: background and plans
On Fri, 2009-11-20 at 21:28 -0500, Jeff Garzik wrote: On 11/20/2009 09:19 PM, James Morris wrote: Are we moving toward a model where the user and the administrator are no longer really separated? Things seem to be regressing according to whatever use-case some desktop developer thinks is important at the time. Agreed. Speaking even more generally, it seems we have abandoned the default to secure principle. just keep echoing back and forth like that and you'll be firmly convinced the world is ending tomorrow. the thesis seems quite comprehensively destroyed by, uh, the fact that we changed the policy. if no-one cared about the default to secure principle, why would we have changed anything? please don't extrapolate to absurdity, here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 09:43 -0600, Mike McGrath wrote: We should just use release epochs, people might hate them for whatever reasons, but they would easily prevent such issues from happing. Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. Really don't want to see that upgrade happen. Epochs are nasty. Can anyone think of any other mechanism they could use with rpm? I'm not talking about what rpm can do today, but any other mechanism we could make rpm do tomorrow that could replace epoch? I was going to suggest what seems an obvious alternative way to do what Christian wants, without changing anything in rpm. Instead of: foobar-1.0-1.fc12.x86-64 have: foobar-fc12-1.0-1.x86-64 it has the problem that we'd have to do something horrible one time to switch to that system, of course, but that seems the 'cleanest' way to do it. I'm still not sure it's necessary. I think as Jesse does - any time this is broken indicates maintainer error, our work should focus on helping maintainers not make errors. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Improve the way rpm decides what is newer
On Sat, 2009-11-21 at 18:07 +0100, Michael Schwendt wrote: On Sat, 21 Nov 2009 08:16:39 -0800, Adam wrote: I was going to suggest what seems an obvious alternative way to do what Christian wants, without changing anything in rpm. Instead of: foobar-1.0-1.fc12.x86-64 have: foobar-fc12-1.0-1.x86-64 Insufficient. Making %dist most-significant is only sufficient for ordinary %dist upgrades, but doesn't replace everything %epoch is needed for: fixing issues with upstream versioning schemes, reverting accidental upgrades, resetting %version as a result of software project splits. I didn't mean it as a replacement for epoch, I meant it as a way of handling the initial problem. Of course, it has problems in that regard too, which is why I don't actually support doing anything like this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt and bugzilla
On Fri, 2009-11-20 at 11:24 +, Matthew Booth wrote: Firstly, I'd like to say I think abrt is fantastic. Call what follows a nit-pick. It's just a pretty in-your-face nit. After installing F12, after a short while I got presented with a couple of SELinux errors. This is nothing unusual in a new Fedora release, but this time it asked me for my bugzilla login details and offered to submit the bug automatically for me. Fantastic! The lazy person in me who wants to do the right thing truly appreciates this. Turns out I wasn't the first person report them, so it added me to the CC list. If these were selinux reports, you were not actually using abrt. You were using the enhanced features of setroubleshoot, which can now submit problems to Bugzilla. All your points happen to be valid, however, and applicable to both. Which is handy =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-11-20 at 10:50 -0500, Bill Nottingham wrote: Benny Amorsen (benny+use...@amorsen.dk) said: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. Is there a blanket prohibition on daemons defaulting to ON or are some (presumably considered vital) daemons exempt? I ask because cronie defaults to ON. It's not a blanket prohibition. (See also opensshd, rsyslog, etc.) Additionally, I believe it applies only to daemons which are configured to be remote-accessible by default. I don't believe cronie is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 09:02 -0800, Jesse Keating wrote: On Thu, 2009-11-19 at 10:32 -0600, Chris Adams wrote: Once upon a time, Jesse Keating jkeat...@redhat.com said: That is incorrect, unless somehow your ssh tunneled VNC registers as local console login, which I doubt. In your case, none of your users would be allowed to install software/updates. VNC looks like a local console login. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. Not according to what I'm being told by the Desktop folks, at least as far as PolicyKit and ConsoleKit are concerned. Oxf13 hrm, in the world of PolicyKit and ConsoleKit, does a VNC login look like a console login for the sake of policy? hughsie Oxf13: no hughsie if you log in, then start remote desktop, and then allow other users to connect then it does hughsie if you're just using vnc to create a virtual desktop for users then it's not on_console, so to speak however, see: https://bugzilla.redhat.com/show_bug.cgi?id=534047#c179 which points out that one could use x11vnc to exploit this method. As x11vnc's page says: x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. certainly seems to fit the bill. the bugzilla comment notes that a remote user could install a copy of x11vnc in his home directory and use it to gain 'local console' access, there is no need to install it systemwide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 13:38 +, Richard Hughes wrote: 2009/11/19 Paul W. Frields sticks...@gmail.com: It makes sense to me for the upstream defaults to be fairly restrictive, with changes being made downstream in distros (and their remixes/spins) to loosen those up as needed. In other words, our desktop package group would include whatever was needed to induce the desired behavior in the Desktop spin. A good bit of this issue would need to be addressed upstream though. (Maybe I just repeated what you said, not sure if I caught the nuance.) Yes, this makes a lot of sense, and if I was to redo the F12 experience again this is what I would have done. At the moment we're asking the server spin to essentially close the door, when maybe we should start with a closed door, and be asking the desktop spin to open it up a little more. It's a point I've made elsewhere, but I'm not sure it's perfectly okay to keep talking about 'the desktop spin'. First of all, this does not only affect the desktop live image: it also affects a default install from either the DVD image or a network install. PackageKit is installed by default in both those cases. (I wouldn't be surprised if it's also on the Xfce and LXDE spins too, btw). Second of all, the general perception of 'the desktop spin' is not 'the desktop spin'. The general perception, helped by how our download page set up, is that 'the desktop spin' is Fedora, or at least the three methods mentioned above - desktop spin, DVD, network install - are Fedora. Most people who are not quite active Fedora project members, and probably even a lot of those, see the desktop spin as 'default Fedora', not as a special-interest spin like the KDE or XFCE spins. Whether that's right or not is a question to be looked at, but we have to take into account that that's how things are generally seen at present. Third of all, though this has been implied already, it's worth explicitly stating: the policy change was not made in 'the desktop spin'. It wasn't even made in Fedora's PackageKit package. It was made upstream. Upstream PackageKit comes configured to allow trusted package installation without authentication. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 08:48 -0800, Jesse Keating wrote: On Thu, 2009-11-19 at 09:14 -0500, Owen Taylor wrote: It doesn't work practically: configuration for packages needs to live with the package. Putting gigantic amounts of configuration into the %post of a kickstart file quickly becomes unmanageable. And the idea that we make configuration changes in the %post of the kickstart really falls part badly once people start upgrading their install to the next version of Fedora. Which is why you do it with specifically selected policy packages, and not trying to write out files in %post. Create a set of policy packages that define certain user cases, and pick from those as you construct a spin. I can't resist pointing out the irony that the currently-under-discussion issue would precisely allow an unprivileged user to torpedo such a system of enforcement, if we were using one already =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 13:34 -0800, Adam Williamson wrote: On Wed, 2009-11-18 at 19:47 -0600, King InuYasha wrote: Netbooks are entirely 32-bit currently, and a majority of low end desktops are still 32-bit only. I don't think your second assertion is true. I'm not aware of any currently-sold desktop processor, no matter how low end, which is not x86-64 capable. The very cheapest processor you can buy from my friendly local dealer is a 'Celeron 430', which is x86-64 capable. The last processor Intel released which was not x86-64 capable, so far as I can figure out, was the Celeron D 310, released December 2005. The last non-x86-64-capable chip AMD released was the 'Paris' Sempron family, which came in July 2004. The subsequent 'Palermo' Sempron family, released February 2005, had x86-64 support. If you're talking about already-existing systems rather than newly sold ones, there's more of a case there, but even so we've been in a 64-bit-capable world aside from netbook Atom CPUs for over four years now. oh, damn. Forgot the first Intel Core mobile families. Core Solo and Core Duo are 32-bit only. The last of those showed up in January 2007, so quite a bit more recent. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 gold. Well, not so golden
On Thu, 2009-11-19 at 11:51 -0200, Casimiro de Almeida Barreto wrote: Problems updating from F11 - F12 1st: graphics interface (X) didn't work. Hardware NVIDIA 5500 + LG 710E CRT. After update: /etc/X11/xorg.conf was altered: Section Device Driver sis # Driver nv ... I guess that install is detecting motherboard's Sis chip (but it is disabled)... Current auto-detection methods don't rely on doing _anything_ to xorg.conf. The only thing I can think of that would poke it is livna-config-display , which comes from RPM Fusion. Do you have that installed? LG 710E is also source of problems since correct definition is: Section Monitor Identifier Monitor0 VendorName LG ModelName710E HorizSync30.0 - 71.0 VertRefresh 50.0 - 160.0 OptionDPMS EndSection There's not enough detail here. Did something create an incorrect monitor section? Was there no monitor section and that didn't work? What goes wrong exactly? Basically, it'd be interesting if you completely remove (rename) xorg.conf and try starting X. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: where did window properties go?
On Thu, 2009-11-19 at 11:52 -0500, Bill Nottingham wrote: Andre Robatino (an...@bwh.harvard.edu) said: If control-center-extra goes away, then install gconf-editor, then under apps-metacity-general, set focus_mode to sloppy. (Thanks to Adam Williamson for pointing this out.) You can do this with gconftool-2, without the need for gconf-editor. I'm a sucky pointy-clicky user bum, not a l33t gconftool-using cool ninja. sorry. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FC11 packages 'newer' than FC12
On Thu, 2009-11-19 at 13:19 -0500, James Antill wrote: On Thu, 2009-11-19 at 13:03 -0500, Przemek Klosowski wrote: I originally reported this through bugzilla, but at Rahul's suggestion, I am posting this to the fedora-devel. Some Fedora 12 packages have versions that do not supersede the versions of Fedora 11 packages, preventing a complete upgrade to FC12. A partial list is: [...] For example, 'yum update iw' does nothing; 'yum install iw' results in an error message Transaction Check Error: package iw-0.9.17-3.fc11.i586 (which is newer than iw-0.9.17-2.fc12.i686) is already installed This is due to the .i586 = .i686 change, probably worth a BZ against yum. downgrade also has problems ... of course this should really be the last time now, so adding any more hacks is going to be a low priority. Er? No, it isn't, it's because -3.fc11 is bigger than -2.fc12. the arch is irrelevant. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 16:38 -0500, Casey Dahlin wrote: The netbook-grade Atoms mentioned a few times in this thread are certainly newer than that. I did specifically say 'aside from those', since they're already clearly under consideration. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote: Once upon a time, Adam Williamson awill...@redhat.com said: The last processor Intel released which was not x86-64 capable, so far as I can figure out, was the Celeron D 310, released December 2005. The last non-x86-64-capable chip AMD released was the 'Paris' Sempron family, which came in July 2004. The subsequent 'Palermo' Sempron family, released February 2005, had x86-64 support. Don't just go by release date, go by end-of-sale date. When did Intel and AMD _stop_ selling CPUs that did not have 64 bit support? That's what really matters. Usually fairly soon after, CPUs have pretty short shelf-lives these days. I have a Thinkpad from early 2006 that is 32 bit only for example. It works perfectly fine, so I am in no hurry to replace it just because it is only 32 bit. see my 'oops' follow-up - I forgot to consider the first rev of the Core architecture, which was 32-bit only and current until Jan 2007. The follow-up 'Core 2' architecture was x86-64 capable. You probably have a Core Duo or Core Solo CPU in that thing. (Core 2 CPUs replaced Core CPUs in shipping models very quickly after Core 2 was released, which kinda supports my first point of this mail). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 16:19 -0500, Casey Dahlin wrote: Why put the users most likely to dislike us (low-computer-literacy newbies using old computers) through such a hassle? And here the Board's hard work comes into play. Reference, the current state of the discussion on Fedora's target audience: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00350.html We found four defining characteristics that we believe best describe the Fedora distribution's target audience: Someone who (1) is voluntarily switching to Linux, (2) is familiar with computers, but is not necessarily a hacker or developer, (3) is likely to collaborate in some fashion when something's wrong with Fedora, and (4) wants to use Fedora for general productivity, either using desktop applications or a Web browser. as per that, 'low-computer-literacy newbies' are not the user group towards which Fedora is primarily targeted, hence their needs should not be a high priority in designing the download page. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 16:14 -0600, Chris Adams wrote: Once upon a time, Adam Williamson awill...@redhat.com said: On Thu, 2009-11-19 at 15:54 -0600, Chris Adams wrote: I have a Thinkpad from early 2006 that is 32 bit only for example. It works perfectly fine, so I am in no hurry to replace it just because it is only 32 bit. see my 'oops' follow-up - I forgot to consider the first rev of the Core architecture, which was 32-bit only and current until Jan 2007. The follow-up 'Core 2' architecture was x86-64 capable. You probably have a Core Duo or Core Solo CPU in that thing. I just checked, and it is actually a Pentium M (Dothan core). damn, my psychic powers stink lately. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-11-20 at 09:25 +1100, Bojan Smojver wrote: On Fri, 2009-11-20 at 03:00 +0530, Rahul Sundaram wrote: I would have thought, it should have actually convinced you to not indulge in same thing but apparently not. I will lower my expectations. You don't seem to realise that right now you have a protest staged outside your office. Your response appears to be all you stupid people go home and wait for a decision. No-one's calling anyone stupid. What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened? The only alternative is for someone to abuse Red Hat chains of command to force some kind of change in this policy, which is exactly the kind of thing that should _not_ happen in Fedora. The current process appears to precisely the correct one, so far as I can see. The issue will be considered in very timely fashion by the appropriately-constituted (and majority-elected!) authority, which will decide what the appropriate response will be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Thu, 2009-11-19 at 18:07 -0500, Paul W. Frields wrote: No-one's calling anyone stupid. What would you suggest would be better than escalating the issue at the first available opportunity to the appropriate authority - FESco - which is exactly what's happened? The only alternative is for someone to abuse Red Hat chains of command to force some kind of change in this policy, which is exactly the kind of thing that should _not_ happen in Fedora. The current process appears to precisely the correct one, so far as I can see. The issue will be considered in very timely fashion by the appropriately-constituted (and majority-elected!) authority, which will decide what the appropriate response will be. Those aren't the only alternatives. There's also the alternative of the maintainers voluntarily making a change to accommodate feedback. A situation where we have one part of the Fedora community giving unwanted marching orders to the other parts of the Fedora community is not an optimal result. (Where that's happened before on rare occasions, it's never been a good thing.) I'm not saying that FESCo shouldn't have purview over the issue, just that you're really drawing a black and white picture where there's clearly some in-between. Sorry, you're quite right, I shouldn't have omitted that bit. I should've explicitly clarified that the above was working from the basis that the maintainer has already said he's not just going to go ahead and change this. It's also worth noting that there's obviously issues for FESco to discuss here even if the maintainer had decided to go ahead and revert the change, and FESco is the appropriate venue for those wider discussions. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Fri, 2009-11-20 at 01:01 +0100, Kevin Kofler wrote: I think what we have in F12 is much more usable, perhaps trading off with the perceived loss of control. I think you just picked the easy way out without realizing the consequences and are now spitting out bullsh*t to make us believe that decision made sense. Before this bit gets any nastier it's worth pointing out the initial discussion of this change: http://thread.gmane.org/gmane.comp.freedesktop.packagekit/2611 (this is what Richard was thinking of with his passing reference to having discussed it publicly over 9 months ago. which turns out to be an underestimate :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Thu, 2009-11-19 at 22:30 -0500, Josh Boyer wrote: On Thu, Nov 19, 2009 at 10:01:54PM -0500, Orcan Ogetbil wrote: Is RPM so hard to hack to work this around? There's many things that need to be changed in rpm but IMHO this isn't one of them. RPM produces predictable versioning. Hacking it up with special cases will lead nowhere but pain. Suppose we hack the RPM, such that right before RPM does the EVR check when updating a package, it will take the Release string and does a 's...@.fc\([0-9]\)@.f\1@' for both the old and the new package? Can you give me an example where this might lead to a problem? Yes. The part where you said hack the RPM. Carrying a Fedora specific hack like that in our RPM package for _no_ good reason seems pretty silly. also, QA and release engineering can provide an entertaining little talk on what can go wrong with changes where 'nothing can possibly go wrong' (aka, in this case, 'Can you give me an example where this might lead to a problem?'). Warning: talk contains loud, expressive lamentations and erratic hurling of empty liquor bottles. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote: On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't. I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-18 at 20:00 +, Richard W.M. Jones wrote: They can install lots of packages are fill up all the disk space? Has someone checked yet whether this is actually possible? There are nuances here. It depends whether PackageKit is capable of using up the space reserved for root when installing packages or not. Even if it's operating 'as root', it doesn't necessarily follow that it can, as I understand it. Please check this before asserting it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-18 at 17:54 -0500, Eric Christensen wrote: I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others. Anyone requested that CVE yet? That's a different point, and specifically _not_ the point I was addressing. You don't need to point it out as it's already been pointed out about five times earlier in the thread. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug zapper clears NEEDINFO
On Wed, 2009-11-18 at 22:03 +0100, Matěj Cepl wrote: Dne 18.11.2009 21:07, Jeff Spaleta napsal(a): On Wed, Nov 18, 2009 at 11:03 AM, Jerry James loganje...@gmail.com wrote: Should the NEEDINFO flag be cleared by adding such a comment? I didn't expect that. when you set the needinfo flag did you set it such that anyone could clear it or did you specifically require that the original reporter needed to reply in the bugzilla interface? But to be fait. Bugzappers should be conscious of this and careful not to liquidate needinfo by mistake, even when it was set incorrectly. To be clear (we went over this on IRC :) the initial message talking about 'Bug Zapper' is talking about the automated F10 EOL bug housekeeping. Since that added a comment on each bug, if those bugs were in 'needinfo anyone' state, they're now not in it any more. =) there's not much we can do about that. but indeed, everyone should be careful to use needinfo appropriately. generally it's a bad idea to use the 'needinfo from anyone' flag as it will be cleared incorrectly far too often. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Thu, 2009-11-19 at 04:48 +0530, Rahul Sundaram wrote: On 11/19/2009 04:31 AM, Jesse Keating wrote: On Wed, 2009-11-18 at 22:37 +0100, Michael Schwendt wrote: If there were an automated sanity check somewhere as part of the pkg release procedure, that might help. It would enforce proper %release bumps. That is coming with AutoQA and it will certainly be able to find upgrade-path issues. A lot of questions seem to be getting this answer but how close are we to AutoQA doing all this? Are we going to start running it and reporting bugs in Rawhide soon? There's a weekly update on AutoQA in the QA group meetings, the summaries and logs of which you can find linked here: http://fedoraproject.org/wiki/QA/Meetings I also summarize the weekly update in the QA section in every FWN issue. I'm not working on autoqa myself, but we're actually already running several autoqa tests - the results go to the autoqa-results mailing list at present, https://fedorahosted.org/mailman/listinfo/autoqa-results , until we have things in more 'final' form - and I would guess we will be running tests of the kind discussed above, oh, during the F13 cycle. Will could be more precise. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-18 at 19:34 -0500, Jeff Garzik wrote: IFF this feature was listed as a question in firstboot, This is generally considered to be a bad way of organizing things. Asking people vague questions about the intended role of the system or the intended nature of a given user account is a great way to confuse them into making the wrong choice, especially since it wouldn't be at all obvious what the actual impact of each choice would be. I don't think that's the answer here. (frankly I'm a bit dubious about the plan to introduce a simplistic 'user / administrator' paradigm, but that's a wider topic). and IFF this feature was explained in detail in release notes, then there would have been no problem at all... it is now :) http://docs.fedoraproject.org/release-notes/f12/en-US/html/sect-Release_Notes-Security.html (but yes, obviously this should have happened way before release) You also omitted the case where admins of servers upgrade into a less secure policy. PackageKit presence does not imply desktop user. i'm really not losing any sleep about that vector. if your server allows untrusted people to have local login access it is a badly configured server and you probably have more severe problems to worry about. the impact on _non_-server machines is more significant, to my mind. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- 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 Wed, 2009-11-18 at 16:04 -0900, Jeff Spaleta wrote: And I think you missed my point. As we are learning..the hard way... sysadmins and spin developers can and should be encouraged to generate site specific policykit rules as part of hardening/softening ALL policykit enabled applications. You we really won't be able to rip out all the stuff using policykit. We're gonna have to digest the fact that policykit is there and start dealing with it in our setups and we are going to need some hand holding so we can do it effectively. PackageKit's policy is just the beginning of the learning curve here. It may not be server relevant as an application.. but the underlying issue about checking and configuring PolicyKit settings will be server relevant and unavoidable at some point. I agree, but I also agree with those who said that this issue makes it very clear we need to have some kind of process for setting a general, project-wide policy for what kind of policies packages should set via PolicyKit; this needs to be handled in a joined-up way and with the involvement of the appropriate people (i.e. the security group), not just on an ad hoc level by individual package maintainers. This should be something the FESCo discussion should cover, I think. We need to have a proper definition of our desired default security posture, and proper oversight of the implementation of this. Especially now PolicyKit usage is becoming (rightly!) widespread. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
