Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On 11/28/2009 10:26 PM, Adam Williamson wrote:
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.
I was thinking of this more as a special Graphics debug push :)
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.
I would have thought that simply adding the text for these in the page would
have helped searching ?
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.
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 :) )
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.
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.
--
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
2009/11/29 Gregory Hosler ghos...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rahul Sundaram wrote: On 11/28/2009 02:32 AM, Debayan Banerjee wrote: 2009/11/28 Rahul Sundaram Why? It's just shows your personal preference for a editor. Emacs is certainly not needed for software development. Well one does need an editor for development. Assuming vim and emacs have roughly equal user bases, chosing emacs over vim for the distribution shows Fedora packagers' personal preference too. I guess both vim and emacs should be available. First of all, I don't think we have enough data to determine which editor is being used by developers. How did you come up with the roughly 50/50 estimate? I am sure we need a editor for development but I might be using Eclipse or even Anjuta? IMO, it can be listed as a optional package in the group and not more than that. Um... emacs is more than just an editor. Advanced users of emacs use emacs as a shell from which they - edit the source - invoke the compile/make process from WITHIN emacs - run the application from WITHIN emacs - if the application crashes, then the debugger comes up WITHIN emacs, and allows them to debug the application, look at the source code, etc. All from within emacs. While I readily admit that most emacs users probably don't use these advanced features of emacs, I would argue that emacs DOES belong in the development group. Those that leave it out of that group are simply unaware of what emcas can and does do... From my point of view, a development tool is something like make, or a compiler. Just because your editor can interface with it, that doesn't make it defacto a development tool. From that perspective, emacs should not be in a development category. It should be in a Kitchen Sink category. The real truth is that this is just semantics, and i'd rather see labelling and tags over predefined groups. But show me a real usability study that shows that this group division is causing trouble to users and that they are having trouble getting their work done. Then show me that the one time effort of installing a package on a fresh system is so important compared to daily activity that we really need to bother with this. Then we can discuss which category emacs should be in. Our personal intuitions won't give us the right answer. -Yaakov signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091129 changes
Compose started at Sun Nov 29 08:15:13 UTC 2009 Broken deps for i386 -- anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 blacs-mpich2-1.1-33.fc12.i686 requires libmpich.so.1.1 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 dx-4.4.4-11.fc12.2.i686 requires libnetcdf.so.4 dx-libs-4.4.4-11.fc12.2.i686 requires libnetcdf.so.4 evolution-exchange-2.28.0-1.fc12.i686 requires libexchange-storage-1.2.so.3 frei0r-plugins-1.1.22-3.fc12.i686 requires libcvaux.so.2 frei0r-plugins-1.1.22-3.fc12.i686 requires libml.so.2 frei0r-plugins-1.1.22-3.fc12.i686 requires libcv.so.2 frei0r-plugins-1.1.22-3.fc12.i686 requires libcxcore.so.2 frei0r-plugins-1.1.22-3.fc12.i686 requires libhighgui.so.2 galeon-2.0.7-19.fc13.i686 requires gecko-libs = 0:1.9.1.5 gcstar-1.5.0-1.fc13.noarch requires perl(GCItemsLists::GCImageLists) gcstar-1.5.0-1.fc13.noarch requires perl(GCItemsLists::GCTextLists) hulahop-0.6.0-2.fc12.i686 requires xulrunner-python hulahop-0.6.0-2.fc12.i686 requires libpyxpcom.so ifstat-1.1-12.fc12.i686 requires libnetsnmp.so.15 inksmoto-0.7.0-1.rc1.fc13.noarch requires /bin/python jaxodraw-latex-2.0.1-3.fc13.noarch requires tex(texmf) kipi-plugins-0.8.0-3.fc13.i686 requires libcxcore.so.2 kipi-plugins-0.8.0-3.fc13.i686 requires libcvaux.so.2 kipi-plugins-0.8.0-3.fc13.i686 requires libcv.so.2 kipi-plugins-0.8.0-3.fc13.i686 requires libhighgui.so.2 kst-fits-1.8.0-3.fc12.i686 requires cfitsio = 0:3.140 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf.so.4 kst-netcdf-1.8.0-3.fc12.i686 requires libnetcdf_c++.so.4 maniadrive-1.2-18.fc12.i686 requires libphp5-5.3.0.so maniadrive-track-editor-1.2-18.fc12.i686 requires libphp5-5.3.0.so monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 mrpt-apps-0.7.1-0.1.20090818svn1148.fc12.i686 requires libcv.so.2 mrpt-apps-0.7.1-0.1.20090818svn1148.fc12.i686 requires libcxcore.so.2 mrpt-apps-0.7.1-0.1.20090818svn1148.fc12.i686 requires libhighgui.so.2 mrpt-core-0.7.1-0.1.20090818svn1148.fc12.i686 requires libcv.so.2 mrpt-core-0.7.1-0.1.20090818svn1148.fc12.i686 requires libcxcore.so.2 mrpt-core-0.7.1-0.1.20090818svn1148.fc12.i686 requires libhighgui.so.2 nagios-plugins-snmp-disk-proc-1.2-6.fc12.i686 requires libnetsnmp.so.15 ncview-1.93c-6.fc12.i686 requires libnetcdf.so.4 php-facedetect-1.0.0-2.fc12.i686 requires libcv.so.2 php-facedetect-1.0.0-2.fc12.i686 requires libcvaux.so.2 php-facedetect-1.0.0-2.fc12.i686 requires libcxcore.so.2 php-facedetect-1.0.0-2.fc12.i686 requires libhighgui.so.2 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(zend-abi) = 0:20060613 php-pecl-gmagick-1.0.2b1-3.fc11.i586 requires php(api) = 0:20041225 player-2.1.1-13.fc12.i686 requires libml.so.2 player-2.1.1-13.fc12.i686 requires libcvaux.so.2 player-2.1.1-13.fc12.i686 requires libcv.so.2 player-2.1.1-13.fc12.i686 requires libcxcore.so.2 player-2.1.1-13.fc12.i686 requires libhighgui.so.2 raydium-1.2-18.fc12.i686 requires libphp5-5.3.0.so rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext_activerecord) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(gettext) = 0:2.0.4 rubygem-activeldap-1.2.0-3.fc12.noarch requires rubygem(locale) = 0:2.0.4 scalapack-mpich2-1.7.5-7.fc12.i686 requires libmpich.so.1.1 Broken deps for x86_64 -- anjal-0.1.0-1.fc13.x86_64 requires libevolution-mail-shared.so.0()(64bit) anjal-0.1.0-1.fc13.x86_64 requires libefilterbar.so.0()(64bit) blacs-mpich2-1.1-33.fc12.x86_64 requires libmpich.so.1.1()(64bit) cluster-snmp-0.16.1-2.fc12.x86_64 requires libnetsnmp.so.15()(64bit) dx-4.4.4-11.fc12.2.x86_64 requires libnetcdf.so.4()(64bit) dx-libs-4.4.4-11.fc12.2.i686 requires libnetcdf.so.4 dx-libs-4.4.4-11.fc12.2.x86_64 requires libnetcdf.so.4()(64bit) evolution-exchange-2.28.0-1.fc12.x86_64 requires libexchange-storage-1.2.so.3()(64bit) frei0r-plugins-1.1.22-3.fc12.x86_64 requires libml.so.2()(64bit) frei0r-plugins-1.1.22-3.fc12.x86_64 requires libcv.so.2()(64bit) frei0r-plugins-1.1.22-3.fc12.x86_64 requires libcxcore.so.2()(64bit) frei0r-plugins-1.1.22-3.fc12.x86_64 requires libcvaux.so.2()(64bit)
orphaning dblatex
I no longer wish to maintain dblatex. Any takers? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Pulseaudio in F12
Hi, I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess. But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... Is this a kind of new feature? Is it configurable? -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Sun, Nov 29, 2009 at 3:58 PM, Paulo Cavalcanti pro...@gmail.com wrote: Hi, I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess. This is a feature, not a bug. But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... This sounds like a bug (works for me though) -- 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
Rahul Sundaram wrote: On 11/28/2009 02:32 AM, Debayan Banerjee wrote: 2009/11/28 Rahul Sundaram Why? It's just shows your personal preference for a editor. Emacs is certainly not needed for software development. Well one does need an editor for development. Assuming vim and emacs have roughly equal user bases, chosing emacs over vim for the distribution shows Fedora packagers' personal preference too. I guess both vim and emacs should be available. First of all, I don't think we have enough data to determine which editor is being used by developers. How did you come up with the roughly 50/50 estimate? I am sure we need a editor for development but I might be using Eclipse or even Anjuta? IMO, it can be listed as a optional package in the group and not more than that. Um... emacs is more than just an editor. Advanced users of emacs use emacs as a shell from which they - edit the source - invoke the compile/make process from WITHIN emacs - run the application from WITHIN emacs - if the application crashes, then the debugger comes up WITHIN emacs, and allows them to debug the application, look at the source code, etc. All from within emacs. While I readily admit that most emacs users probably don't use these advanced features of emacs, I would argue that emacs DOES belong in the development group. Those that leave it out of that group are simply unaware of what emcas can and does do... I completely agree with you ONLY if you agree that kdevelop, qt-creator, anjuta, eclipse, netbeans, monodevelop and etc. should be added to the group because all of them can do what you have described. It will be a funny group - usable for everyone ??? I doubt it. Alex All the best, -Greg -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
mono and snk key files
Hello, I'm writing this to fedora-devel list and also cross-posting to fedora-mono, as the latter seems rather dead but might be useful for archiving purposes. I am not very familiar with Mono and .NET technology, so if I get something wrong, please correct me. I'm also neither nant's nor log4net's maintainer; I just saw that a large part of Mono is currently broken in rawhide and tried to figure out the root cause. Mono assemblies that get installed into GAC need to be strongname-signed. The resulting public key token gets placed into the assembly (DLL), and uniquely identifies a series of assembly releases that are all API/ABI compatible. When the assembly manufacturer releases an API-compatible updated version, they would strongname-sign the update with the same snk key as the previous release. This is supposed to prevent DLL hell: applications reference the public key token, and if there's an updated DLL with the same public key available, then applications are automatically redirected to the new version. There are several Mono source packages in Fedora that don't ship an .snk key file. The reason why the file sometimes isn't shipped with the source is probably this: upstream developers want to be able to create binary releases which are guaranteed to be API compatible, and don't want anyone else to sign non-compatible versions with the same key. However, since assemblies installed into the GAC need to be signed, several Fedora packages generate the public key files during build time. With this approach every single build gets signed with a DIFFERENT snk file, making every new build incompatible with the previous one. Right now nant is broken [1] in Fedora because someone rebuilt log4net. During the rebuild a new strong name key was generated, and log4net was signed with the new key. However, since nant was built against the previous log4net build, it is no longer able to find the rebuilt log4net assembly which is signed with a new key. Result: nant breaks, and with that also log4net breaks [2], because it uses nant for building itself. This situation not only applies for log4net, but for many different Mono libraries. Historically nant appears to have been fixed with bootstrapping [3]. Nant's source distribution contains a bunch of binary dll files. Someone has to flip a switch in the spec file so that nant uses those binary files to build itself. After that bootstrapping is disabled and nant is rebuilt against the assemblies from the system. However, this approach doesn't scale if every single update / rebuild needs to have nant manually bootstrapped/debootstrapped. I'd suggest to fix this changing the way snk files are generated. Instead of automatically generating a new key at build time, it should instead be generated once, and stored in cvs / lookaside cache. It would then be at a package maintainer's discretion to regenerate the snk file whenever an API incompatible update is made. However, casual rebuilds would be done with the same strongname key, making sure that everything depending on the assembly doesn't get automatically broken with each rebuild. Comments? [1] https://bugzilla.redhat.com/show_bug.cgi?id=538908 [2] https://bugzilla.redhat.com/show_bug.cgi?id=539189 [3] https://www.redhat.com/archives/fedora-devel-list/2009-October/msg01399.html -- Kalev -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
On Sun, Nov 29, 2009 at 1:01 PM, drago01 drag...@gmail.com wrote: On Sun, Nov 29, 2009 at 3:58 PM, Paulo Cavalcanti pro...@gmail.com wrote: Hi, I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess. This is a feature, not a bug. But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... This sounds like a bug (works for me though) I have two sound cards installed: one onboard and another PCI. The PCI, the one I do no use very much, works fine. The onboard is the one which does not save the volumes. Every time I call an application its master and pcm volume go to the maximum (I see the sliders going to the top in alsamixer). -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
The packages that run sn -k from .spec file and thus affected by the problem are: mono-sharpcvslib mono-cecil-flowanalysis mono-ndoc mono-nunit22 log4net -- Kalev -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
I have two sound cards installed: one onboard and another PCI. The PCI, the one I do no use very much, works fine. The onboard is the one which does not save the volumes. Every time I call an application its master and pcm volume go to the maximum (I see the sliders going to the top in alsamixer). This has been addressed by the PulseAudio creator. You can read more about it here, see the PCM is always 100%: http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes In my lay explanation, Pulse manages the application volumes behind the scenes. It still remembers their values, but it doesn't use Alsamixer to set them. It tries to use the full volume range of the hardware (for better volume scaling), so it keeps every other software linux volume control at full volume, and scales itself internally. Otherwise, ALSA would say you can only use the lower 50% of the sound range of this device. (PCM at 50%). Now Pulse decides internally what volume level is best. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
2009/11/29 Kalev Lember ka...@smartlink.ee: Hello, snip Comments? I'm the maintainer for log4net but unfortunately not for nant. I've finally gotten around to looking at this. Debian have a policy[1] of using a standard mono.snk which is provided by a package (I guess we just then BuildRequires this) and I think this seems like a good solution but have no experience of this. Paul Johnson looks after a good deal of the mono stuff so happy to be guided by him really. I imagine Spot will want to have a say as it looks like he has been doing the heavy-lifting when each rebuild takes place and this is clearly a pain[2]: Thanks for raising this Kalev! Cheers -- Christopher Brown [1] http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-signing [2] https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00122.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio in F12
Paulo Cavalcanti wrote: But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ... Looks like the flat volumes feature: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01810.html Kevin Kofler -- 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 ?
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 -- 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: Emacs is not for software development
On Sat, Nov 28, 2009 at 6:23 AM, Kevin Kofler kevin.kof...@chello.at wrote: Both vim and Emacs are obsolescent and hard to use. Kate FTW! Hmm, at this point I would have thought nano would be the editor with one of the lowest learning curve in those very pleasant moments when an inexperienced admin needs to edit a system config file manually from runlevel 1 or similar heart stopping panicy recovery situations. Do we have nano in by default or just vi? I mean vi is fine and all.. so is emacs... both are pretty useful development tools with there own style. but both can be frustrating to use out of the gate and your in a situation where you really really need to fix something _now_. Nano isn't particularly powerful, but its pretty clear how to edit and to save and to exit from looking at the default interface...without much head scratching or heartburn. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora Project Board FESCo Schedule for Election Town Hall Meetings
Town hall meetings have now been scheduled for the Fedora Project Board and FESCo. The first Board meeting will be on Tuesday, December 1 at 0300 UTC. Please note that in North America this will be on the evening of Monday, November 30 at 10:00pm eastern. The second Board meeting will be Wednesday, December 2 at 1500 UTC. FESCo will have their town hall meetings on Tuesday, December 1 at 2200 UTC and Thursday, December 3 at 1800 UTC. Full details about the elections including town hall scheduling are available at http://fedoraproject.org/wiki/Elections To participate in any of the town hall meetings please join #fedora-townhall and #fedora-townhall-public on freenode at the scheduled time. Questions may be posed in the #fedora-townhall-public channel and the candidates will discuss your questions in #fedora-townhall. Hope to see many of you there. John -- 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 ?
Rudolf Kastl che666 at gmail.com writes: intel (i965) works fine... You are lucky. Major regressions there in F-12. On my hardware, this used to work when nomodeset was passed to kernel. Now, it doesn't any more. With KMS, on the other hand, hibernate/thaw or suspend/resume causes the whole system to go berserk after a few cycles. So, I'm back to metacity and 2D. Bugs filed, of course, etc. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On 11/30/2009 01:33 AM, 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 Get a Fedora account and create a new page under your username and show it to the QA team get some consensus. Rahul -- 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, 29 Nov 2009, Dave Airlie wrote: 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. Thanks for input. Neither a test user or rolling back to radeonhd helped; maybe something changed between F11 and F12. I filed a PR: https://bugzilla.redhat.com/show_bug.cgi?id=542398 -- 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
