Re: X on UEFI systems.
On Thu, 2009-12-10 at 07:32 +0300, Vasily Levchenko wrote: Hi, folks. Currently at Virtualbox has introduced UEFI support in 3.1 release. But there is one issue with X server. When trying configure X with -configure. Resulted xorg.conf.new looks right except missed Modes. Observing code I've supposed that missed information should be somehow fetched from screen info (prepared by EFIFB) via ioctl(..,FBIOGET_FSCREENINFO,...), but for some reasons it isn't called and doing strace of X -configure the /dev/fb0 is open and than immediately closed ([pastebin.org]). So the question is what should be added in VirtualBox/UEFI firmware to get full xorg.conf? Does it not work without an xorg.conf, that would be the first goal. Dave. -- 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 Tue, 2009-12-08 at 01:50 -0800, Dan Williams wrote: On Tue, 2009-12-08 at 10:33 +0200, Pekka Savola wrote: Hi, On my laptop, after F12 updates-testing update today, after reboot F logo shows but then the screen goes dark and starts flickering between various shades of dark (changing modes?) with intel graphics chipset (GM965/GL960). I'm only using 1024x768 resolution. Nomodeset or using a previous kernel didn't help. Booting to runlevel 3 and running system-config-display (--reconfig) resulted in the same. I've worked around the issue by yum history undo 1 which rolled back a couple of hundred packages. Any idea which package could be the culprit and I should file a bug against or to isolate it? Somehow I don't think this is necessarily an Xorg base or driver issue. I'd start with xorg-x11-drv-intel. Update to the package set that caused the problem, then for the bug report attach the output of 'dmesg', your entire /var/log/Xorg.0.log file, and the output of 'lspci -nv'. Also indicate your kernel version, the version of xorg-x11-server-Xorg, and the version of xorg-x11-drv-intel. kernel is probably first up nowadays to blame for GPU bugs. File bugs against the X drivers generally though is easier for us to find them, kernel bug triage can be a long process. Dave. -- 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 ?
Which are the best Bugzilla components to register bugs against: X11 driver ATI: xorg-x11-drv-ati 3D driver: mesa DRM: kernel ??? Cheers Terry Where is the location of the DRM kernel module master git tree now ? It used to be at: http://cgit.freedesktop.org/mesa/drm/linux-core Is it now worked on directly withing the kernel source trees ? Its developed in-kernel now, like any sane driver. Dave. -- 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 13:17 +0200, Pekka Savola wrote: On Fri, 27 Nov 2009, Dave Airlie wrote: Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk. Well, a couple of Fedoras back, X didn't work except with radeonhd, but now radeon appears to support this one as well; I switched to it, and the CPU issue is gone even with KMS. Now fonts (esp small ones) look very smudgy though. But I suppose there are already bug(s) open on this. I'm guessing with radeonhd you did something to increase or decrease your font size in some dialog box, they had different ideas on DPI to the rest of the world. Try with a test user, though it might just be DPI changes. Dave. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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 07:18 +, Alex Hudson wrote: On 27/11/09 06:08, Dave Airlie wrote: Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. If you do this, please consider having a radeonhd-radeon testing day for people like myself - radeonhd works for me where radeon doesn't: If the radeonhd maintainer would even add kms detection and refuse to start it would help, the fact that with kms loaded, radeonhd cannot work doesn't seem to have made it back into the Fedora package. https://bugzilla.redhat.com/show_bug.cgi?id=492723 (I haven't yet tested with F12 final, it's on my to-do list - but the various alphas/betas didn't improve matters) I would have thought that the radeon driver capabilities should be very close to radeonhd, some of these bugs should be easy to squash (he says ;). Not at all, radeonhd has no kernel modesetting support and does a lot of stuff in its own unique way. Please test an F12 LiveCD or something as soon as you can and we'll figure this out. Anyone using radeonhd is only causing themselves long term problems and I encourage them to switch to radeon if they want any support going forward. Dave. -- 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 10:02 +0100, Jaroslav Reznik wrote: On Thursday 26 November 2009 23:14:09 Dave Airlie wrote: On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote: On Thu, 2009-11-26 at 20:16 +, Terry Barnaby wrote: On 11/26/2009 07:46 PM, Bruno Wolff III wrote: On Thu, Nov 26, 2009 at 17:09:14 +, Terry Barnabyter...@beam.ltd.uk wrote: I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :) I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine. Hi, I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention Airlie has continued development in the f12 branch. If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time. So is blender working the only thing you consider as working? The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense. Current priorities are: 0) you aren't running a binary driver - if so no priority for you. a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run? I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it. Hi, how could we (we = KDE SIG people) help with e) - serious question - not KDE over Gnome flame or blaming ;-) - to make it better? From Red Hat's POV, KDE should be at least partially supported by X team as it's official and supported component of RHEL - but this goes together with Fedora. Find a GPU developer who runs KDE ;-) and feed him treats. Though seriously its not really a major bias, like I have things on my list priority (a) but I still end up doing (e)(f) tasks occasionally for my own sanity and to take a break from staring at register dumps. Like a bug KDE finds in the driver is still a bug, it just means I have to go install KDE on my test machines again and that is where I generally lag and take a few days longer. I think the main thing non-GNOME users can do is stay on top of packages in updates-testing and stuff as I rarely get time to regression test on non-GNOME desktops. Dave. -- 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 13:42 -0600, Bruno Wolff III wrote: On Fri, Nov 27, 2009 at 08:12:05 +1000, Dave Airlie airl...@redhat.com wrote: Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point. I think one thing that is changing expectations is ATI providing documentation again. I was expecting significant improvements for F12, but near the end I had mostly given up on them. Then between the beta and the release some updates fixed some issues for me and in the end things are pretty much what I expected for radeon support. The documentation is great, but it doesn't answer every question, its a guide how a driver for an idealised version of a radeon would look, you then spend most of the time working in the grey undocumented area between the ideal GPU the hw guys wanted to produce and the piece of silicon they ended up shipping. Also areas like ACPI interaction, suspend/resume, etc are all generally OEM level things so AMD have nothing to do with it, and really can't document it. The nouveau guys actually did better than I expected since they aren't getting any help from nVidia. Its a double edged sword, knowing you won't get any help, means you rarely have to wait for anyones help, so you can just do it (though its really really hard to do), I keep the poor AMD open-source guys under a heavy snow of information enquiries. Dave. -- 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... 3D driver for r600 is 35,000 lines just the chipset specific code, Another 150,000 lines for the mesa core it uses. Now the hard part with OpenGL or and 3D interface is its massive, we probably need to write another few thousand lines of code to get a decent r600 3D driver that can do GL2.0. Now gnome-shell use of GL is a very known quantity same for compiz, we also have the g-s authors on hand to tell us what is happening. So debugging g-s or compiz is insanely easy compared to say blender or wine games. We (Red Hat or Fedora) currently don't have access to any sort of conformance suite for our GL though Intel and VMware have started at least doing more and more regression test work lately so less and less crap is making it way into the mainline and thus to users. So hopefully things get better as we move forward and more companies invest time in the 3D driver stack. Dave. -- 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 02:11 +0530, Rahul Sundaram wrote: On 11/28/2009 02:13 AM, Dave Airlie wrote: We (Red Hat or Fedora) currently don't have access to any sort of conformance suite for our GL though Intel and VMware have started at least doing more and more regression test work lately so less and less crap is making it way into the mainline and thus to users. Have we tried asking Intel or VMWare for access to their tests? We all use piglit from an open source point of view and they both add tests to that quite regularly. we also run some wine dx9 tests. The main non-open conformance tests suites are the OpenGL suite from Khronos now, and the DX test suite from Microsoft. VMware generally run XP inside a VMware session and run the DX test suite on their virtual GPU which finds a crap load of bugs in the host 3D drivers. Neither of these are really good solutions for us (though I think an interested user could reproduce the VMware system). Dave. -- 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 17:02 -0600, Sir Gallantmon wrote: On Fri, Nov 27, 2009 at 4:01 PM, Rahul Sundaram sunda...@fedoraproject.org wrote: On 11/28/2009 03:26 AM, Felix Miata wrote: 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce. I don't expect that to change, and even if it does, using more than necessary will remain a wasteful allocation of quickly diminishing global resources. Consequently, enabled by default will be ecologically irresponsible if it does come to pass. Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch. Rahul I actually would be surprised if we had a composited desktop in Fedora by default in a year. Maybe if the radical changes going on in Mesa's master tree weren't going on, that wouldn't be surprising. However, with the Gallium work, I seriously doubt that we will have composited desktop by default next year. Also, it would be nice if in a repo with experimental graphics drivers, the gallium drivers could be made available. Gallium will soon be the way that VMware offers accelerated 3D for Linux guests since they contributed a gallium driver. Given that, I think it should get some exposure to the rest of the Fedora community to get stuff tested. Gallium isn't totally broken, last I heard. In fact, I think the ATi gallium driver is supposed to be at least partially working. Packaging gallium drivers doesn't give us anything useful at the moment. Everything else required to run them is in the distro, the overhead of git cloning mesa and following instructions to get a gallium driver is the least of using those drivers worries. The problem with packaging anything like the current gallium drivers is the rate of change is too high, that by the time you've built the package in koji, its already out of date and possibly useless. It would require someone staying on top of it full time for little benefit to Fedora or to the gallium driver writers who would need you to have the git tree so you could test patches etc. Dave. -- 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 Thu, 2009-11-26 at 20:16 +, Terry Barnaby wrote: On 11/26/2009 07:46 PM, Bruno Wolff III wrote: On Thu, Nov 26, 2009 at 17:09:14 +, Terry Barnabyter...@beam.ltd.uk wrote: I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :) I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine. Hi, I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention Airlie has continued development in the f12 branch. If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time. So is blender working the only thing you consider as working? The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense. Current priorities are: 0) you aren't running a binary driver - if so no priority for you. a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run? So yes I'm sorry 3D generally does end up at the end of the list, but if everything else on your desktops work except that, then I suggest you try and lead some sort of 3D testing group and maybe feedback upstream when your favourite apps breaks. The big mesa problem for F11 was we pushed one mesa update to fix some r300 bugs, and it broke some Intel, we just cannot get the regression testing necessary with the current Fedora updates/updates-testing system, we are hoping per-user repos stuff will solve some of that. Dave. -- 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 ?
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software. Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point. GPUs have gotten more and more complex every 6 months for about 8 years now. A current radeonhd 4000 series bears little resemblence to the radeon r100 that was out then. The newer GPUs require a full complier to be written for an instruction set more complex than x86 in some places. The newer GPUs get more and more varied modesetting combos that all require supporting. Now I'd would guess (educated slightly) that the amount of code required to write a full driver stack for a modern GPU has probably gone up 40-50x what used to be required, whereas the number of open source community developers has probably doubled since 2001. Also newer GPU designs have forced us to redesign the Linux GPU architecture, this had to happen in parallel with all the other stuff, again with similiar number of developers. So yes it sucks but it should point out why there is no reason why 3D should really be working on all cards. Dave. -- 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 07:23 +1000, Dave Airlie wrote: On Thu, 2009-11-26 at 20:16 +, Terry Barnaby wrote: On 11/26/2009 07:46 PM, Bruno Wolff III wrote: On Thu, Nov 26, 2009 at 17:09:14 +, Terry Barnabyter...@beam.ltd.uk wrote: I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :) I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine. Hi, I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention Airlie has continued development in the f12 branch. If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time. So is blender working the only thing you consider as working? The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense. Current priorities are: 0) you aren't running a binary driver - if so no priority for you. a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run? I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it. Having some sort of repos where we can publish a new kernel/libdrm/mesa/intel/ati/nouveau package in one block for people to test and find regression that isn't rawhide and isn't updates-testing (since it would be abusing that) would be an excellent place to start. Dave. -- 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 08:07 +0200, Pekka Savola wrote: On Thu, 26 Nov 2009, Rahul Sundaram wrote: I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway. Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help. Well, here's one graphics regression: https://bugzilla.redhat.com/show_bug.cgi?id=540476 radeon.modeset=0 worked around the problem. (I'm not sure if it's filed against the right component.) Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk. So you've proven you can break your own machine that is all. Dave. -- 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 13:03 -0800, Adam Williamson wrote: 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? -145 should fix this, a patch went in upstream that we didn't want in F-12, I had to remember to revert it. I should push out a new mesa before we can ship that fix. Dave. -- 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 22:29 +1100, Bojan Smojver wrote: On Thu, 2009-11-19 at 16:25 +0530, Rahul Sundaram wrote: Not true. I just want to avoid repetition and if the points you wanted to make have already been made clearly here and elsewhere, just be patient till the decision is made. In other words, cool off. You really don't get it. 1. Telling people to cool off is patronising, especially when they are not upset. 2. Whether I repeated someone else's point or not is irrelevant. The only relevant thing is that I added my voice. Now, till the decision is made is what I'm trying to get at here. I'm adding my voice so that the _right_ decision (in my opinion) is made. Look put this simple, if you are not signal you are noise. At this point you are noise, please stop. Your point was made, you may as well just write +1 as repeat the point, now if you write +1 you realise how dumb this is. So cool off. Dave. -- 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 23:02 +, Bojan Smojver wrote: Adam Williamson awilliam at redhat.com writes: 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? RH folks in charge of this package (or packages) should tell everyone that their concerns have been listened to and that the _default_ will be corrected really soon (e.g. by pointing to a Koji build). It's a bug after all, isn't it? What has this got to do with Red Hat? you seem to be seriously concerned that people with Red Hat email addresses haven't just fixed this problem. This is a Fedora issue and its up to the Fedora maintainers (regardless of company) to fix this. Dave. -- 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 23:24 -0500, Mail Llists wrote: Jeff et al are 100% correct - why this is even debated is unfathomable to me. Surely it is completely obvious that the default should be off. (as it was and will be in f13+). Why have we not got a revert fix to turn this back off in updates-testing ? Please fix it now - then discuss how to improve the desktop experiance for Aunt tilly. But first put the security back to what it was, should be and presumably will be again anyway. If people need it, add a button to the PK gui config tool. (WHat is it called anyway?) - I cant seem to find a [gui] config tool of any kind - maybe that should be built too before futzing with insecurity policies? Why do you assume anyone here on this thread can fix this? Its up to the package maintainer to take a fix and ensure its well tested, pointless fire-drill exercises might make you feel better, but they don't help the distro. Really all this bullshit in this thread, and not one patch? I think ppl prefer hearing themselves spout than actually supply a fix. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, 2009-10-15 at 17:27 +0200, Kevin Kofler wrote: Michael Schwendt wrote: If you know that you would _never_ be happy with a test-update becoming a stable update, then either don't push such a test-update or unpush it (manually or by relying on karma automatism). That was my point! However, it could be that you would need to offer a test-update for two or more months before you would get essential feedback that helps with deciding whether it's safe to mark it stable or not. So we only disagree about the timelines. IMHO 2 or more months is way too long. You should not need that much time to know whether the update is broken or not! The big problem is that many months is almost indistinguishible from never for all practical purposes. If you enabled updates from testing, you're still stuck with no upgrade path unless you stick with testing forever. The main advantage of putting strong time limits on testing is to provide an upgrade path for one-time testers back to the stable stream. 2 months is too long for user apps maybe, for X.org or Mesa from what I can see for ever probably isn't long enough, its not a matter of how much time something spends in updates-testing its a matter of how many people run what is in there and report on it. We get a lot of QA from the community on the run-in from Beta to GA, however we get nothing at all even close post-GA, so finding regressions post-GA is close to impossible without it hitting updates. you can get lots of +1s easily finding the -1 that matters is hard. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
intel/nouveau kms users avoid kernel 2.6.31.1-46
KMS won't init on this kernel, -48 is building now. I untagged -46 but it'll probably still end up in rawhide last night. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
On Sun, 2009-09-13 at 19:43 +0300, Jonathan Dieter wrote: Deltarpm seems to be unable to generate correct rpms for deltarpms generated from noarch rpms. The uncompressed payload is correct, but the compressed xz payload is different. To test, using Rawhide's deltarpm, try running applydeltarpm -r anjuta-doc-2.27.3.0-3.fc12.noarch.rpm anjuta-doc-2.27.3.0-3.fc12_2.27.92.0-1.fc12.noarch.drpm test.rpm. You should end up with an md5 mismatch. If you rpm2cpio test.rpm, you'll find that the uncompressed cpio archive is identical to that of anjuta-doc-2.27.92.0-1.fc12.noarch.rpm. As I understand it, noarch rpms are generated on PPC builders. I suspect this problem is because of one of two reasons: 1. The version of xz on the PPC builders is a different version than that on the other builders? 2. xz generates different compressed files when run on different architectures If it is #2, this is a major problem (at least for yum-presto) because the whole purpose of deltarpm is to regenerate the original (compressed) rpm, given an older version and a deltarpm. If we can't do that, the regenerated package won't pass the signature check and will be re-downloaded in full. I have access to i586 and x86_64 systems, but no PPC systems. Could someone either give me access to a PPC system or verify themselves whether xz generates different files on different architectures (all other things being equal). It doesn't. [airl...@pegasus ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airl...@pegasus ~]$ xz -z -c lm93_busted.o | md5sum 86dbb83fea5f4e2f77396b3f491a0cc1 - [airl...@ppcg5 ~]$ md5sum lm93_busted.o d7174fc439c4678927725d06de4f18a2 lm93_busted.o [airl...@ppcg5 ~]$ xz -z -c lm93_busted.o | md5sum acf84a6c173b040f6cf8ea96c7daa513 - thats just a random file I had on my machine here, first is x86 32-bit, second is ppc. xz-4.999.9-0.1.beta.fc12 on both. Dave. Jonathan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, 2009-09-10 at 21:27 +, Mark Wielaard wrote: Jesse Keating jkeating at redhat.com writes: This is my issue too. There is claim that it was tested, yet it wasn't tested in the same place we require every other feature to be tested, that being rawhide. Although it obviously would have been far nicer to have had this all in before the mass rebuild, there were multiple test builds against rawhide packages. I did a build of the rawhide kernel package using jakub's gcc-vta and lxo used that to post results of testing to the gcc list, which helped get it accepted upstream, which is a requirement for it to make it into fedora, etc. Sorry, this wasn't more visible. Wierdly the first package that broke when this was pushed was the kernel ;-) Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On Fri, 2009-08-07 at 16:42 -0400, Casey Dahlin wrote: On 08/06/2009 01:26 AM, Dave Airlie wrote: On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? non-root X is a big security hole at the moment, and until we get revoke() support in the kernel, we can probably move X to running as a special user, and maybe once we get revoke to running as the real user. However it doesn't solve the issue how we know we need or don't need root since X only figures out what graphics drivers are needed after starting, so if you needed a non-kms gpu driver we wouldn't know until after we'd started as non-root. Dave. Why can't we just start as root or with the setuid bit, and use the standard set*uid() calls to drop what we don't need once we know what we're doing? We have to undo some stuff when X exits. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On Thu, 2009-08-06 at 01:36 -0400, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? non-root X is a big security hole at the moment, and until we get revoke() support in the kernel, we can probably move X to running as a special user, and maybe once we get revoke to running as the real user. However it doesn't solve the issue how we know we need or don't need root since X only figures out what graphics drivers are needed after starting, so if you needed a non-kms gpu driver we wouldn't know until after we'd started as non-root. Dave. Could permissions be raised temporarily? PolicyKit with (defaulted) auto-approve to load an appropriate driver? Maybe we could do something with SELinux, but I don't think we can do anything without getting revoke. or maybe some process capabilties if such things worked. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: non root X
On Mon, 2009-08-03 at 15:08 +0530, Rahul Sundaram wrote: Hi A few days back I ran into http://lists.x.org/archives/xorg-devel/2009-July/001293.html I am wondering, since we are already using KMS in most places in Fedora, how far are we from achieving this by default in a Fedora release? non-root X is a big security hole at the moment, and until we get revoke() support in the kernel, we can probably move X to running as a special user, and maybe once we get revoke to running as the real user. However it doesn't solve the issue how we know we need or don't need root since X only figures out what graphics drivers are needed after starting, so if you needed a non-kms gpu driver we wouldn't know until after we'd started as non-root. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Any asciidoc users?
On Wed, 2009-07-15 at 10:01 -0400, Todd Zullinger wrote: I'm not sure how widely used asciidoc is around here. Both git and tig use it to build their documentation and have been hit by bug 506953¹. I think this bug may hit many other users of asciidoc as well, making our current packages a bit annoying to use for many projects. If any other asciidoc users have run into spurious 'unsafe: include file' errors since asciidoc was updated to 8.4.5 (F-11 and devel), your help confirming that the patch I posted to the bug report helps and doesn't hurt would be most welcome. (Even if you haven't hit the 'unsafe: include file' errors, your testing would be great.) ¹ https://bugzilla.redhat.com/506953 just apply the --unsafe as default patch I suppose, I'm not sure its actually a useful feature, Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-06-26
On Sun, 2009-06-28 at 20:20 +0200, Kevin Kofler wrote: Seth Vidal wrote: I think we have a handful of vocal opponents. Where have you seen a hand with thousands of fingers? ;-) luckily we don't have to implement every whim that the majority or a vocal group yells about. If you go against the wishes of the majority, that's per definition undemocratic. If we were being democratic, i.e. proper majority rule, we'd kick KDE out of the distro as its definitely not 50% of developers or users. Maybe we should have Survivor: Desktop, where we can vote KDE off the island. Dave. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
