[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Beginner's Documentation Scarcity



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 redhat com
> Subject: fedora-test-list Digest, Vol 60, Issue 99
> To: fedora-test-list redhat com
> Date: Tue, 24 Feb 2009 20:39:12 -0500
>
> Send fedora-test-list mailing list submissions to
> fedora-test-list 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 redhat com
>
> You can reach the person managing the list at
> fedora-test-list-owner 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 redhat com>
> Subject: RE: BugZappers
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <1235513717 4829 44 camel 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 redhat com>
> Subject: Fedora Bug Triage Meeting Recap 2009-02-24
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <49A47189 6050708 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 alum mit edu>
> Subject: Re: Fedora Bug Triage Meeting Recap 2009-02-24
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <1235514603 6772 17 camel 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 gmail com>
> Subject: f11 g++ behaviour
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID:
> <b79371120902241432o639271beteaafdabafd6ce86b 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 gmail com>
> Subject: Re: clock riddle
> To: fedora-test-list redhat com
> Message-ID: <1235515770 18118 137 camel 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 yahoo ca>
> Subject: Re: f11 g++ behaviour
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <908375 44107 qm web52301 mail re2 yahoo com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
>
> --- On Tue, 2/24/09, David L <idht4n gmail com> wrote:
>
> > From: David L <idht4n gmail com>
> > Subject: f11 g++ behaviour
> > To: "For testers of Fedora Core development releases" <fedora-test-list 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 gmail com>
> Subject: Re: f11 g++ behaviour
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID:
> <f224c6140902241549jcd8228fm2aee390ab97c54b6 mail gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Feb 24, 2009 at 6:01 PM, Deji Akingunola <deji_aking 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 cs indiana edu
> Fedora • salimma fedoraproject org
> MacPorts • hircus macports org
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 24 Feb 2009 18:53:46 -0500
> From: Michel Salim <michel sylvan gmail com>
> Subject: Re: Circular dependency Rawhide glibc and glibc-common
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID:
> <f224c6140902241553r351ee399oe298015a5464d843 mail gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Feb 23, 2009 at 12:15 PM, Per Bothner <per 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 cs indiana edu
> Fedora • salimma fedoraproject org
> MacPorts • hircus macports org
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 24 Feb 2009 19:04:23 -0500
> From: Michel Salim <michel sylvan gmail com>
> Subject: Re: Circular dependency Rawhide glibc and glibc-common
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID:
> <f224c6140902241604s78236a22jf5877695a43b8a7 mail gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Feb 24, 2009 at 6:53 PM, Michel Salim <michel sylvan gmail com> wrote:
> > On Mon, Feb 23, 2009 at 12:15 PM, Per Bothner <per 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 cs indiana edu
> Fedora • salimma fedoraproject org
> MacPorts • hircus macports org
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 24 Feb 2009 19:06:19 -0500
> From: Michel Salim <michel sylvan gmail com>
> Subject: Re: Fedora 11 Alpha in VirtualBox
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID:
> <f224c6140902241606r21f17c03s291bd5d3057e8e91 mail gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Feb 23, 2009 at 2:05 PM, Michel Salim <michel sylvan gmail com> wrote:
> > On Thu, Feb 12, 2009 at 5:51 PM, Adam Williamson <awilliam 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 cs indiana edu
> Fedora • salimma fedoraproject org
> MacPorts • hircus macports org
>
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 24 Feb 2009 19:10:23 -0500
> From: sean darcy <seandarcy2 gmail com>
> Subject: Re: F11: X starts at wrong resolution
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <49A48C6F 9050900 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 gmail com>
> Subject: Re: F11: X starts at wrong resolution
> To: fedora-test-list redhat com
> Message-ID: <49A48C6F 9050900 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 redhat com>
> Subject: Re: Triage goals
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <49A491F4 30107 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 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 redhat com>
> Message-ID: <49A49AF7 30304 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 bothner com>
> Subject: Re: Circular dependency Rawhide glibc and glibc-common
> To: For testers of Fedora Core development releases
> <fedora-test-list redhat com>
> Message-ID: <49A4A11F 8010203 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 bothner com http://per.bothner.com/
>
>
>
> ------------------------------
>
> --
> fedora-test-list mailing list
> fedora-test-list 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]