Beginner's Documentation Scarcity
Patrick Gunsolley
vansolrick at earthlink.net
Fri Feb 27 07:53:09 UTC 2009
Hi Danny and everyone,
I can somewhat agree with you. IMO, what we really need is more
organization for the pages that we already have. There are lots of pages
of information to go thru for beginning zappers/triagers/testers.
I'm already beginning a project in localizing some user docs for Ubuntu
to target new users and/or testers. I'm considering doing the same for
Fedora. Simplicity in documentation and references is key.
Patrick Van Gunsolley
On Fri, 2009-02-27 at 01:17 -0600, Hunter Bukowski wrote:
> Hi all,
>
> I'm trying to get a beginners' training going. I e-mailed Adam
> about it. I know some about Fedora Linux but the previously titled
> "sketchy" documentation for beginning bug-zappers left me clueless, to
> be perfectly honest. Once I know enough, if people give the time to
> teach me, I'm perfectly willing and capable of revamping the
> beginners' documentation. Ideas or offerings are welcomed.
>
> Danny
>
> > From: fedora-test-list-request at redhat.com
> > Subject: fedora-test-list Digest, Vol 60, Issue 99
> > To: fedora-test-list at redhat.com
> > Date: Tue, 24 Feb 2009 20:39:12 -0500
> >
> > Send fedora-test-list mailing list submissions to
> > fedora-test-list at redhat.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://www.redhat.com/mailman/listinfo/fedora-test-list
> > or, via email, send a message with subject or body 'help' to
> > fedora-test-list-request at redhat.com
> >
> > You can reach the person managing the list at
> > fedora-test-list-owner at redhat.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of fedora-test-list digest..."
> >
> >
> > Today's Topics:
> >
> > 1. RE: BugZappers (Adam Williamson)
> > 2. Fedora Bug Triage Meeting Recap 2009-02-24 (John Poelstra)
> > 3. Re: Fedora Bug Triage Meeting Recap 2009-02-24
> > (Christopher Beland)
> > 4. f11 g++ behaviour (David L)
> > 5. Re: clock riddle (Patrick O'Callaghan)
> > 6. Re: f11 g++ behaviour (Deji Akingunola)
> > 7. Re: f11 g++ behaviour (Michel Salim)
> > 8. Re: Circular dependency Rawhide glibc and glibc-common
> > (Michel Salim)
> > 9. Re: Circular dependency Rawhide glibc and glibc-common
> > (Michel Salim)
> > 10. Re: Fedora 11 Alpha in VirtualBox (Michel Salim)
> > 11. Re: F11: X starts at wrong resolution (sean darcy)
> > 12. Re: F11: X starts at wrong resolution (sean darcy)
> > 13. Re: Triage goals (John Poelstra)
> > 14. 0xFFFF getting bug reports just because it's the 1st
> > component in the list. (Lex Hider)
> > 15. Re: Circular dependency Rawhide glibc and glibc-common
> > (Per Bothner)
> >
> >
> >
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 24 Feb 2009 14:15:17 -0800
> > From: Adam Williamson <awilliam at redhat.com>
> > Subject: RE: BugZappers
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <1235513717.4829.44.camel at adam.local.net>
> > Content-Type: text/plain
> >
> > On Tue, 2009-02-24 at 20:10 +0000, Lalit Dhiri wrote:
> >
> > > > There is a summary of the meeting sent to the list after it
> takes place
> > > > every week, yes. Expect it to be sent soon. Are you never able
> to attend
> > > > at the time when the meeting currently takes place, or was that
> just
> > > > this week?
> > > >
> > >
> > > Assuming all meetings are weekly at 15:00 UTC it will be a problem
> as
> > > I am in the UK therefore will be working :=(
> >
> > Well, we can always re-consider the meeting times if they're
> > inconvenient for active triagers.
> >
> > (The fact that the current time works out to 7 a.m. for me has
> NOTHING
> > TO DO WITH THIS AT ALL. I am entirely impartial. ;>)
> >
> > > > Tips for starters - we don't have anything great yet. What we
> have is:
> > > >
> > > > https://fedoraproject.org/wiki/BugZappers/GettingStarted
> > > > https://fedoraproject.org/wiki/BugZappers/TakingAction
> > > >
> > > > which is fairly...sketchy :). I would like to have something
> similar to
> > > > what I wrote for Mandriva previously:
> > > >
> > > > http://wiki.mandriva.com/en/Projects/Bugs/Triage_guide
> >
> > > I won't mention too much about Mandriva and triage; I did not have
> a
> > > good exp when I tried Mandriva again a few years ago... :=(
> >
> > 'A few years ago' is probably before the triage team existed :). At
> that
> > point, no-one was doing any kind of triage at all, so I'm not
> surprised
> > you had a bad experience...
> >
> > > May be I and others new to triage could join in on eg brain storm
> > > sessions which help develop a better intro site?
> >
> > Yep, that would be great - please do post any feedback you have on
> > information you found was missing or hard to find on the existing
> site,
> > for instance.
> > --
> > Adam Williamson
> > Fedora QA Community Monkey
> > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> > http://www.happyassassin.net
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 24 Feb 2009 14:15:37 -0800
> > From: John Poelstra <poelstra at redhat.com>
> > Subject: Fedora Bug Triage Meeting Recap 2009-02-24
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <49A47189.6050708 at redhat.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Recap and full IRC transcript found here:
> >
> https://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Feb-24
> >
> > Please make corrections and clarifications to the wiki page.
> >
> > == Attendees ==
> > * comphappy
> > * poelcat
> > * tk009
> > * John5342
> > * mcepl
> > * bigdufstuff
> > * adamw
> > * beland
> >
> > == Meeting Summary & Action Items ==
> > * We are officially done setting goals for Fedora 11
> > ** Goal will be triaging bugs for key components
> > ** https://fedoraproject.org/wiki/BugZappers/components
> > ** For Fedora 12 maybe we can create goals that are more
> ''measurable''
> > * mcepl will create queries and RSS feeds for key components to be
> triaged
> > * comphappy will:
> > ** have metrics reporting working by this weekend
> > ** merge greasemonkey script created by mcepl to create ''triager
> > signature'' into main Fedora triage greasemonkey script
> > ** make sure download link for greasemonkey script is working and
> accessible
> > * adamw will arrange and coordinate the first bug triage day
> >
> > == IRC Transcript ==
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 24 Feb 2009 17:30:03 -0500
> > From: Christopher Beland <beland at alum.mit.edu>
> > Subject: Re: Fedora Bug Triage Meeting Recap 2009-02-24
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <1235514603.6772.17.camel at diet-anarchy.localdomain>
> > Content-Type: text/plain
> >
> > > ** For Fedora 12 maybe we can create goals that are more
> ''measurable''
> >
> > I thought the goal was to keep the number of NEW bugs for the key
> > components from getting any higher? That seems very quantifiable to
> me,
> > if not terribly ambitious.
> >
> > -B.
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 24 Feb 2009 14:32:08 -0800
> > From: David L <idht4n at gmail.com>
> > Subject: f11 g++ behaviour
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID:
> > <b79371120902241432o639271beteaafdabafd6ce86b at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > This is a bit off topic, but it's something I noticed
> > when logged into my f11 partition. An application
> > fails to compile that used to compile with f10.
> > I've condensed the problem to this:
> >
> > #include <stdio.h>
> > #include <string.h>
> > int main(int argc, char *argv[])
> > {
> > char *gr;
> > const char *pl="BlahHello world!";
> > const char *gt="Hell";
> > gr = strstr(pl, gt);
> > printf("%s\n", gr);
> > return 0;
> > }
> >
> > In f10, this compiles with g++. In f11, it compiles
> > with gcc, but not with g++. It fails with this error:
> >
> > test.cpp:8: error: invalid conversion from 'const char*' to 'char*'
> >
> >
> > It seems a little odd that it fails since the man page
> > for strstr shows this signature:
> >
> > char *strstr(const char *haystack, const char *needle);
> >
> > I guess strstr is returning a pointer to a const char *,
> > so this error kind of makes sense. But I'm
> > not sure what's supposed to happen. Is this the
> > correct behaviour for g++ to fail and gcc to work
> > for this code?
> >
> > Thanks,
> >
> > David
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Tue, 24 Feb 2009 18:19:30 -0430
> > From: "Patrick O'Callaghan" <pocallaghan at gmail.com>
> > Subject: Re: clock riddle
> > To: fedora-test-list at redhat.com
> > Message-ID: <1235515770.18118.137.camel at bree.homelinux.com>
> > Content-Type: text/plain
> >
> > On Tue, 2009-02-24 at 11:38 -0700, Michal Jaegermann wrote:
> > > On Tue, Feb 24, 2009 at 10:48:12AM -0430, Patrick O'Callaghan
> wrote:
> > > > On Mon, 2009-02-23 at 15:25 -0700, Michal Jaegermann wrote:
> > > > > [...]> The KDE
> > > > > > clock applet doesn't allow you to change the time (just the
> timezone)
> > > > >
> > > > > If that is a global change, and not how time is displayed on
> this
> > > > > specific desktop, that this is bad enough.
> > > >
> > > > It isn't. It affects the displayed time on the desktop. The
> system's
> > > > view of the timezone does not change.
> > >
> > > Yes, I was quite sure this only this could and should happen if
> you
> > > will switch timezone in clockapplet (a very poor cousin of that
> > > would a modification only for a time displayed by _that_ clock). I
> > > was quite surprised when I found out that /etc/localtime changed.
> >
> > Once again, under KDE it doesn't. I now understand your point, that
> PK
> > is wrong and should be fixed. What confused me is that you started
> this
> > whole thread without saying that the vulnerability manifests through
> > Gnome.
> >
> > > > AFAIK you can only change the system timezone via the root
> password.
> > >
> > > Not quite if you can start on your system a Gnome desktop session
> > > and you have 'gnome-panel' package installed. That provides
> > > /usr/libexec/clock-applet. Log out from a KDE session, change a
> > > session type, login into a Gnome desktop, proceed like above ...
> >
> > See above.
> >
> > poc
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Tue, 24 Feb 2009 15:01:30 -0800 (PST)
> > From: Deji Akingunola <deji_aking at yahoo.ca>
> > Subject: Re: f11 g++ behaviour
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <908375.44107.qm at web52301.mail.re2.yahoo.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> > --- On Tue, 2/24/09, David L <idht4n at gmail.com> wrote:
> >
> > > From: David L <idht4n at gmail.com>
> > > Subject: f11 g++ behaviour
> > > To: "For testers of Fedora Core development releases"
> <fedora-test-list at redhat.com>
> > > Received: Tuesday, February 24, 2009, 5:32 PM
> > > This is a bit off topic, but it's something I noticed
> > > when logged into my f11 partition. An application
> > > fails to compile that used to compile with f10.
> > > I've condensed the problem to this:
> > >
> > > #include <stdio.h>
> > > #include <string.h>
> > > int main(int argc, char *argv[])
> > > {
> > > char *gr;
> > > const char *pl="BlahHello world!";
> > > const char *gt="Hell";
> > > gr = strstr(pl, gt);
> > > printf("%s\n", gr);
> > > return 0;
> > > }
> > >
> > > In f10, this compiles with g++. In f11, it compiles
> > > with gcc, but not with g++. It fails with this error:
> > >
> > > test.cpp:8: error: invalid conversion from 'const
> > > char*' to 'char*'
> > >
> > See
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02248.html and https://www.redhat.com/archives/fedora-devel-list/2009-February/msg01576.html announcement and comment concerning this new behaviour.
> >
> >
> > Deji
> >
> >
> >
> > __________________________________________________________________
> > Instant Messaging, free SMS, sharing photos and more... Try the new
> Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/
> >
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Tue, 24 Feb 2009 18:49:54 -0500
> > From: Michel Salim <michel.sylvan at gmail.com>
> > Subject: Re: f11 g++ behaviour
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID:
> > <f224c6140902241549jcd8228fm2aee390ab97c54b6 at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Tue, Feb 24, 2009 at 6:01 PM, Deji Akingunola
> <deji_aking at yahoo.ca> wrote:
> > >
> > >> #include <stdio.h>
> > >> #include <string.h>
> > >> int main(int argc, char *argv[])
> > >> {
> > >> Â char *gr;
> > >> Â const char *pl="BlahHello world!";
> > >> Â const char *gt="Hell";
> > >> Â gr = strstr(pl, gt);
> > >> Â printf("%s\n", gr);
> > >> Â return 0;
> > >> }
> > >>
> > >> In f10, this compiles with g++. Â In f11, it compiles
> > >> with gcc, but not with g++. Â It fails with this error:
> > >>
> > >> test.cpp:8: error: invalid conversion from 'const
> > >> char*' to 'char*'
> > >>
> > > See
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02248.html and https://www.redhat.com/archives/fedora-devel-list/2009-February/msg01576.html announcement and comment concerning this new behaviour.
> > >
> > Type-safety bugs are one class of problems that are easier to fix in
> > C++ than in C. Bless polymorphic type signatures.
> >
> > Regards,
> >
> > --
> > miʃel salim • http://hircus.jaiku.com/
> > IUCS • msalim at cs.indiana.edu
> > Fedora • salimma at fedoraproject.org
> > MacPorts • hircus at macports.org
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Tue, 24 Feb 2009 18:53:46 -0500
> > From: Michel Salim <michel.sylvan at gmail.com>
> > Subject: Re: Circular dependency Rawhide glibc and glibc-common
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID:
> > <f224c6140902241553r351ee399oe298015a5464d843 at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Mon, Feb 23, 2009 at 12:15 PM, Per Bothner <per at bothner.com>
> wrote:
> > > Will Woods wrote:
> > >>
> > >> Here's the error from my (32-bit) system, which has *only* i386
> > >> glibc{,-devel,-common,-headers} installed:
> > >>
> > >> Error: Missing Dependency: glibc-common = 2.9.90-3 is needed by
> package
> > >> glibc-2.9.90-3.i386 (installed)
> > >>
> > >> It looks like yum isn't considering glibc-common-2.9.90-7.i586 as
> a
> > >> potential provider of glibc-common for the upgrade transaction..
> or
> > >> something? Depsolving makes my head hurt. Full log is attached.
> > >
> > > So what is the recommended fix for this? Â Manually install
> > > the two rpms with rpm --nodeps?
> > >
> > There ought to be a way to upgrade using Yum. For x86_64 users it's
> > bad enough -- worse come to worst you can still wipe the 32-bit
> stack
> > and start again -- but the same problem is present on a 32-bit
> > install.
> >
> > glibc-2.9.20-2.i386 from installed has depsolving problems
> > --> Missing dependency: glibc-common = 2.9.90-2 ...
> >
> > Regards,
> >
> > --
> > miʃel salim • http://hircus.jaiku.com/
> > IUCS • msalim at cs.indiana.edu
> > Fedora • salimma at fedoraproject.org
> > MacPorts • hircus at macports.org
> >
> >
> >
> > ------------------------------
> >
> > Message: 9
> > Date: Tue, 24 Feb 2009 19:04:23 -0500
> > From: Michel Salim <michel.sylvan at gmail.com>
> > Subject: Re: Circular dependency Rawhide glibc and glibc-common
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID:
> > <f224c6140902241604s78236a22jf5877695a43b8a7 at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Tue, Feb 24, 2009 at 6:53 PM, Michel Salim
> <michel.sylvan at gmail.com> wrote:
> > > On Mon, Feb 23, 2009 at 12:15 PM, Per Bothner <per at bothner.com>
> wrote:
> > >> Will Woods wrote:
> > >>>
> > >>> Here's the error from my (32-bit) system, which has *only* i386
> > >>> glibc{,-devel,-common,-headers} installed:
> > >>>
> > >>> Error: Missing Dependency: glibc-common = 2.9.90-3 is needed by
> package
> > >>> glibc-2.9.90-3.i386 (installed)
> > >>>
> > >>> It looks like yum isn't considering glibc-common-2.9.90-7.i586
> as a
> > >>> potential provider of glibc-common for the upgrade transaction..
> or
> > >>> something? Depsolving makes my head hurt. Full log is attached.
> > >>
> > >> So what is the recommended fix for this? Â Manually install
> > >> the two rpms with rpm --nodeps?
> > >>
> > > There ought to be a way to upgrade using Yum. For x86_64 users
> it's
> > > bad enough -- worse come to worst you can still wipe the 32-bit
> stack
> > > and start again -- but the same problem is present on a 32-bit
> > > install.
> > >
> > > glibc-2.9.20-2.i386 from installed has depsolving problems
> > > Â --> Missing dependency: glibc-common = 2.9.90-2 ...
> > >
> >
> > Happily, this is a yum problem only; RPM itself is fine. I installed
> > glibc-common.i586 and glibc.i686 by hand and it does not need the
> > --nodeps flag.
> >
> > x86_64 users can do the same, but they'd have to download manually
> > glibc.x86_64 and glibc-common.x86_64 as well.
> >
> > Regards,
> >
> > --
> > miʃel salim • http://hircus.jaiku.com/
> > IUCS • msalim at cs.indiana.edu
> > Fedora • salimma at fedoraproject.org
> > MacPorts • hircus at macports.org
> >
> >
> >
> > ------------------------------
> >
> > Message: 10
> > Date: Tue, 24 Feb 2009 19:06:19 -0500
> > From: Michel Salim <michel.sylvan at gmail.com>
> > Subject: Re: Fedora 11 Alpha in VirtualBox
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID:
> > <f224c6140902241606r21f17c03s291bd5d3057e8e91 at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Mon, Feb 23, 2009 at 2:05 PM, Michel Salim
> <michel.sylvan at gmail.com> wrote:
> > > On Thu, Feb 12, 2009 at 5:51 PM, Adam Williamson
> <awilliam at redhat.com> wrote:
> > >
> > >> At a guess, is it using the vesa driver and might be sped up by
> using
> > >> the 'native' X.org driver for virtualbox instead?
> > >
> > >
> > > It is, yes, but F-10 and other Linux distributions are usable even
> > > before the VirtualBox Additions are installed anyway. Presumably
> some
> > > debugging features in F-11 is hitting VirtualBox particularly
> hard.
> > >
> > Performance is now decent, though the upgrade experience (400
> > packages!) was not pleasant given how sluggish Rawhide-on-VBox was.
> >
> > --
> > miʃel salim • http://hircus.jaiku.com/
> > IUCS • msalim at cs.indiana.edu
> > Fedora • salimma at fedoraproject.org
> > MacPorts • hircus at macports.org
> >
> >
> >
> > ------------------------------
> >
> > Message: 11
> > Date: Tue, 24 Feb 2009 19:10:23 -0500
> > From: sean darcy <seandarcy2 at gmail.com>
> > Subject: Re: F11: X starts at wrong resolution
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <49A48C6F.9050900 at gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Adam Jackson wrote:
> > > On Mon, 2009-02-23 at 18:32 -0500, sean darcy wrote:
> > >> Just installed i386 F11 from alpha .iso on hp laptop, then did
> yum upgrade.
> > >>
> > >> Each time X starts at 800x600. xrandr shows the preferred
> resolution as
> > >> 1280x800.
> > >>
> > >> I use xrandr to change to preferred, but how can I set X to start
> at
> > >> 1280 x 800? does this require a modeline after all these years?
> > >
> > > I'm not a mind reader, so I don't know what your X log contains or
> what
> > > xrandr reports. But I suspect it's detecting a TV connected that
> isn't
> > > really there. And since the default placement policy is clone
> (because
> > > we suck), we'll try to set things up so all outputs have the same
> mode.
> > >
> > > If you want to disable an output at configure time, see the
> dualhead
> > > setup instructions here:
> > >
> > > http://intellinuxgraphics.org/dualhead.html
> > >
> > > Particularly the bit about Option "Ignore".
> > >
> > > If you'd set the resolution with gnome-display-properties this
> would get
> > > remembered for you when you log in. gdm would still be wrong
> though.
> > >
> > > - ajax
> > >
> >
> > No xorg.conf, but yes X log finds a TV out:
> >
> > (II) intel(0): EDID for output TV1
> > (II) intel(0): Output VGA1 disconnected
> > (II) intel(0): Output LVDS1 connected
> > (II) intel(0): Output DVI1 disconnected
> > (II) intel(0): Output DVI2 connected
> > (II) intel(0): Output TV1 disconnected
> > (II) intel(0): Using fuzzy aspect match for initial modes
> > (II) intel(0): Output LVDS1 using initial mode 1024x768
> > (II) intel(0): Output DVI2 using initial mode 1024x768
> >
> > not clear why it settled on 800x600, but...
> >
> > I used gnome-display-properties as you suggested. That worked.
> Thanks.
> >
> > This new laptop, an hp g50, has an intel gm45 chipset:
> >
> > (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel®
> GM45
> > Express
> > Chipset
> > (--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset"
> >
> > with an hdmi port. Using the F11 series intel drivers ( now
> > xorg-x11-drv-i810-2.6.0-6.fc11.i586 ) is it possible to actually use
> the
> > hdmi port to drive an 1080p or 1080i projector?
> >
> > I remember posts that hdmi for the intel driver was a Work In
> Progress.
> > Still? Any ETA?
> >
> > sean
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 12
> > Date: Tue, 24 Feb 2009 19:10:23 -0500
> > From: sean darcy <seandarcy2 at gmail.com>
> > Subject: Re: F11: X starts at wrong resolution
> > To: fedora-test-list at redhat.com
> > Message-ID: <49A48C6F.9050900 at gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Adam Jackson wrote:
> > > On Mon, 2009-02-23 at 18:32 -0500, sean darcy wrote:
> > >> Just installed i386 F11 from alpha .iso on hp laptop, then did
> yum upgrade.
> > >>
> > >> Each time X starts at 800x600. xrandr shows the preferred
> resolution as
> > >> 1280x800.
> > >>
> > >> I use xrandr to change to preferred, but how can I set X to start
> at
> > >> 1280 x 800? does this require a modeline after all these years?
> > >
> > > I'm not a mind reader, so I don't know what your X log contains or
> what
> > > xrandr reports. But I suspect it's detecting a TV connected that
> isn't
> > > really there. And since the default placement policy is clone
> (because
> > > we suck), we'll try to set things up so all outputs have the same
> mode.
> > >
> > > If you want to disable an output at configure time, see the
> dualhead
> > > setup instructions here:
> > >
> > > http://intellinuxgraphics.org/dualhead.html
> > >
> > > Particularly the bit about Option "Ignore".
> > >
> > > If you'd set the resolution with gnome-display-properties this
> would get
> > > remembered for you when you log in. gdm would still be wrong
> though.
> > >
> > > - ajax
> > >
> >
> > No xorg.conf, but yes X log finds a TV out:
> >
> > (II) intel(0): EDID for output TV1
> > (II) intel(0): Output VGA1 disconnected
> > (II) intel(0): Output LVDS1 connected
> > (II) intel(0): Output DVI1 disconnected
> > (II) intel(0): Output DVI2 connected
> > (II) intel(0): Output TV1 disconnected
> > (II) intel(0): Using fuzzy aspect match for initial modes
> > (II) intel(0): Output LVDS1 using initial mode 1024x768
> > (II) intel(0): Output DVI2 using initial mode 1024x768
> >
> > not clear why it settled on 800x600, but...
> >
> > I used gnome-display-properties as you suggested. That worked.
> Thanks.
> >
> > This new laptop, an hp g50, has an intel gm45 chipset:
> >
> > (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel®
> GM45
> > Express
> > Chipset
> > (--) intel(0): Chipset: "Mobile Intel® GM45 Express Chipset"
> >
> > with an hdmi port. Using the F11 series intel drivers ( now
> > xorg-x11-drv-i810-2.6.0-6.fc11.i586 ) is it possible to actually use
> the
> > hdmi port to drive an 1080p or 1080i projector?
> >
> > I remember posts that hdmi for the intel driver was a Work In
> Progress.
> > Still? Any ETA?
> >
> > sean
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 13
> > Date: Tue, 24 Feb 2009 16:33:56 -0800
> > From: John Poelstra <poelstra at redhat.com>
> > Subject: Re: Triage goals
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <49A491F4.30107 at redhat.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Christopher Beland said the following on 02/24/2009 09:42 AM Pacific
> Time:
> > > After discussion at today's meeting, I have redirected
> > > [[BugZappers/Goals]] to:
> > > https://fedoraproject.org/wiki/BugZappers/components
> > >
> > > The official goal is now to stabilize the number of NEW bugs for
> each
> > > key component. Counts from today have been copied into that page
> on
> > > the wiki, and there's a preformatted query from which you can get
> the
> > > current count.
> > >
> > > I also threw in "all NEW bugs filed against EOL versions should be
> > > closed" as a complementary goal, with a pre-formatted query for
> that
> > > as well.
> > >
> > > -B.
> > >
> > >
> >
> > We were not explicit about the version, but I was assuming and think
> we
> > only have a chance at making it if it is only the 'rawhide' the
> version.
> >
> > What do others think?
> >
> > John
> >
> >
> >
> > ------------------------------
> >
> > Message: 14
> > Date: Wed, 25 Feb 2009 12:12:23 +1100
> > From: Lex Hider <floss at lex.hider.name>
> > Subject: 0xFFFF getting bug reports just because it's the 1st
> > component in the list.
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <49A49AF7.30304 at lex.hider.name>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Hi,
> >
> > Because 0xFFFF is alphabetically 1st component we have, it gets
> bugs
> > filed against it because people don't know what to file against.
> >
> >
> https://bugzilla.redhat.com/buglist.cgi?component=0xFFFF&product=Fedora
> >
> > * I've tried to reassign to correct components, but I am unsure
> with
> > some bugs. Please see if we can get them all fixed because I don't
> think
> > any of the NEW bugs are actually about 0xFFFF
> >
> > * Should we consider creating a component especially to catch this
> > situation, and owned by the bug zappers.
> > e.g. component 000-Not-Sure-What-Component-To-File-Against.
> >
> > Thanks,
> >
> > Lex.
> >
> >
> >
> > ------------------------------
> >
> > Message: 15
> > Date: Tue, 24 Feb 2009 17:38:39 -0800
> > From: Per Bothner <per at bothner.com>
> > Subject: Re: Circular dependency Rawhide glibc and glibc-common
> > To: For testers of Fedora Core development releases
> > <fedora-test-list at redhat.com>
> > Message-ID: <49A4A11F.8010203 at bothner.com>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Michel Salim wrote:
> > > Happily, this is a yum problem only; RPM itself is fine. I
> installed
> > > glibc-common.i586 and glibc.i686 by hand and it does not need the
> > > --nodeps flag.
> >
> > Thanks - that worked!
> >
> > I'm now up-to-date, except for an annoying conflict with
> kipi-plugins:
> >
> > $ sudo yum install kipi-plugins
> > Loaded plugins: dellsysidplugin2, refresh-packagekit
> > Setting up Install Process
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package kipi-plugins.i386 0:0.2.0-0.14.rc1.fc11 set to be
> updated
> > --> Processing Dependency: libgpod.so.3 for package: kipi-plugins
> > --> Finished Dependency Resolution
> > kipi-plugins-0.2.0-0.14.rc1.fc11.i386 from rawhide has depsolving
> problems
> > --> Missing Dependency: libgpod.so.3 is needed by package
> > kipi-plugins-0.2.0-0.14.rc1.fc11.i386 (rawhide)
> > Error: Missing Dependency: libgpod.so.3 is needed by package
> > kipi-plugins-0.2.0-0.14.rc1.fc11.i386 (rawhide)
> >
> > Also, vlc complains about missing dejavu-fonts-sans.
> >
> > Neither of these are critical - I'm assuming they'll be
> > fixed by an update soon.
> > --
> > --Per Bothner
> > per at bothner.com http://per.bothner.com/
> >
> >
> >
> > ------------------------------
> >
> > --
> > fedora-test-list mailing list
> > fedora-test-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-test-list
> >
> > End of fedora-test-list Digest, Vol 60, Issue 99
> > ************************************************
>
>
> ______________________________________________________________________
> Windows Live™ Hotmail®:…more than just e-mail. Check it out.
> --
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list
More information about the fedora-test-list
mailing list