Bizzare FC2 test 1 networking issue
by Tim Hawkins
I have a DSL line terminated with a Netgear DG814 ADSL router/modem,
which is then connected to my internal network .
Im testing FC2 test1 on a Sharp PC-FS2518 laptop, that has a Socket
Compact Flash Network Card in it.
Everytime I boot the laptop, the Netgear router siezes up and stops
routing, requiring a hard reset, once reset it is fine, and does not
cause any problems, something during the FC2 boot is sending a network
packet that kills the Router, FC1 on the same hardware does not do the
same thing.
Anybody seen the same behaviour.
I have another FC1 box on the net, so if nobody has seen this before,
I'll see if I can capture an ethereal trace of the startup.
20 years, 2 months
Buglet list from FC2t1
by Peter Backlund
Hi.
Here's list of (mostly) minor issues I've encountered on FC2test1. I'm
not 100% rawhide yet, so some things may even be fixed right now.
Anyway, if there's anything here that's not known about or already
fixed, I'll add it to BZ.
- Rhythmbox opens mp3 by default, but has no license problem dialogue.
- GNOME Print Manager asks if you want to run printer config tool no
first run, and shows alternatives "OK/Cancel" instead of "Yes/No".
- system-settings:/// is empty.
- The icon for Computer (on the desktop) should be
/usr/share/icons/Bluecurve/48x48/apps/icon-computer.png
- gnome-terminal sometimes has the entire view "selected" (i.e. black
background) when opening a new tab, at least with ctrl-shit-t. ctrl-l
fixes that.
- The icon for opened folder in Nautilus is not from BC (I think)?
- Sometimes, when selecting icons on the desktop and the un-selecting
them, a small trace of the blue shade is left to the left of the text,
about 1 pixel wide and as high as the text. Reproducible at least on the
"Start here" icon.
- RFE: Metacity should focus on a window, if there is one, when
switching desktops. Right now, it focuses on the panel by default.
- If KDE is installed, the "Other" meny item (in GNOME) is waaaaaaaay to
crowded.
- GNOME control center has a launcher for itself (which it shouldn't),
and it doesn't even work :-)
- Opening a .spec file in Nautilus pops up the file association
question, but gnome-file-types-properties segfaults if you choose "yes".
Running g-f-t-p from the meny works fine.
- system-config-securitylevel does not strech very nicely, if the window
is resized vertically.
- The Mozilla Mail icon is horrible. Use the redhat-email icon instead,
and skip the "mozilla mail message" launcher altogether.
- OOo flickers a lot when resizing, especially the file dialogue
(upstream issue?).
- The panel sometimes stops responding to clicks on the main menu and
launcher icons, related to when a gnome app fails to launch (gpdf for
example). restarting the panel fixes the launcher icons, but not the
main menu. logging out and in again fixes the main menu.
And the some more serious issues:
=================================
- The directory /etc/lvm was not created by anaconda (I created one LVM
group on install), which b0rked the first boot completely. Running the
lvm2 part of rc.sysinit fixed that.
- s-c-display hides my mouse cursor after running it, even if no changes
were made. The mouse still works, but the pointer is invisible.
(geforce2, logitech usb mouse).
- s-c-soundcard fails with the following error message:
** (system-config-soundcard.py:28986): WARNING **: `GtkTextSearchFlags'
is not an enum type
Traceback (most recent call last):
File "/usr/share/system-config-soundcard/system-config-soundcard.py",
line 47, in ?
app = soundcard.childWindow()
File "/usr/share/system-config-soundcard/soundcard.py", line 160, in
__init__
self.primaryDeviceMenu.set_active(self.cardList.index(self.soundcardBackend.getDefaultCard()))
ValueError: list.index(x): x not in list
20 years, 2 months
RE: Prelink success story :)
by Erik LaBianca
> What would that change? We've talked about it, criticism has been
noted,
> and as I've tried to make clear, the checklist should not be
> misunderstood. There is no silver bullet. One could create a different
> checklist for every different type of package. The biggest hurdle to
QA is
> lack of common sense. I don't want to spend a lot of time editing
> documentation in the Wiki to please a single individual (read "you")
who
> runs his own independent repository and doesn't really care. I'd
rather
> like to know how to lower the hurdle for other people who would like
to
> help, but who still don't know where to start. And that would mean
that
> they start talking about any problems they see.
>
As a new-to-fedora.us prospective QA'er, I've been attempting to compose
an email on this very subject for the last several days, but haven't
managed to complete it. It's going to be long, so please forgive me
As a longtime redhat user (4+ yrs) and not-entirely-new rpm packager (2
yrs) and professional system administrator / software engineer, it took
me over 8 hours of work before I submitted my first QA review. This is
partially because I hadn't been using GPG, partially because I didn't
have a bugzilla account, partially due to general incompetence on my
part, and partially due to the amount of material in the QA checklist.
I'm happy to discuss this stuff in more detail, but I'm just going to
throw out some "newbie observations" for you all to think about. I do
think that the barrier for entry that I found was entirely too high. I'm
just now beginning to understand what is going on after getting some
feedback on some of my reviews.
1. Information how "how to do some useful qa" is scattered. Heres only
some of the url's I had to look at to figure out whats going. None of
them were complete in and of themselves, and my first two attempts at QA
were still sub-optimal.
http://www.fedora.us/wiki/PackageSubmissionQAPolicy
http://www.fedora.us/pipermail/fedora-devel/2003-March/000459.html
http://www.fedora.us/wiki/QAChecklist
http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires
I also got some good mileage out of one of Jef Spaleta's bug triage
messages to the list.
2. Too much detail. The QA checklist is great. However, as it turns out,
a lot of the stuff being checked there aren't really showstoppers. I
ended up turning it into a list
1. Does the package follow the Fedora Package Naming Guidelines?
2. Are the sources from upstream pristine and free from trojans?
3. Are the pre- and post(un)install scripts correct?
4. Epoch
5. Are there no missing BuildRequires?
6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS.
7. Are all paths within the .spec replaced with macros?
8. If the package has a DesktopEntry, are the VFolder categories ok?
9. Is the package free of any %{buildroot} macros?
10. Is the package free of unowned directories?
11. Is the License tag used rather than Copyright?
12. Is the package free of default passwords?
13. Are all daemon's which can be installed to run as non-root installed
as such?
14. Does the package handle a parallel build cleanly?
Now. Some of these items apparently are subject to contention. If
there's any chance that they aren't showstoppers, lets get them off that
list! There should be a template like I have above, that can be answered
with simple yes or no answers, that covers all the showstoppers. That
way a newbie can fill it in the blank with yes's or no's and no he's
done something useful. Since all the checklist items are there, answered
with yes or no questions, it's easy to know if they actually made a good
faith effort to check the package.
The non-showstoppers should be on a second list of "stuff to watch for".
This could be far more detailed than the actual QA checklist, and as a
newbie gets deeper into packaging lore, they would likely begin filling
out more of it.
Some critique of the list:
1. Does the package follow the Fedora Package Naming Guidelines?
This is pretty darn complicated for a newbie QA'er. They should be
allowed to opt out. A "senior developer" could look at the package in 10
seconds and understand whether or not the name is ok.
2. Are the sources from upstream pristine and free from trojans?
This is important, but exceedingly difficult to do "properly"... At what
point does this become a showstopper? At some point it becomes
impossible to verify the source without actually being the author of the
code and inspecting it line by line. For a newbie this is very
intimidating
My suggestion would be to have a set of no-fail, simple steps that
result in a concrete answer, like the following: "verify the source url
exists, and check to see that it is at the official distribution site
for the software. Compare the md5 sums of their posted souce tarball and
the one included in the SRPM. If it doesn't, please detail your
findings".
3. Are the pre- and post(un)install scripts correct?
Honestly. How the heck is a newbie supposed to know this? Again,
concrete steps would be better. I'd suggest something like "are all
pathnames in the pre/post(un) install scripts complete? Are macros used
for all package files? Are all operations backed out? Is ldconfig being
run if there are shared libraries installed? Maybe these should be a
series of questions
Also. Wheres the "does this package appear to work" line item? Do we QA
packages and not actually run them? It seems like this is pretty basic
criteria.
4. Epoch
This appear to be subject to debate, and isn't included in a lot of
upstream rpms. That being said it's easy to check so leave it in.
Couldn't / doesn't rpmlint check this?
5. Are there no missing BuildRequires?
This one took me a LONG time to check. The manual "remove all devel
rpms" method is apparently deprecated according to the url above,
however fedora.us doesn't even include a copy of mach. No less, mach is
pretty complicated and you've got to figure out how to create a
fedora.us enabled buildroot.
After all that mach works great, except for I found out that it doesn't
understand perl(Net::Lib) style depends, so it doesn't handle on
buildrequires.
There needs to be an official build environment. Mach works. Why not
spend the hour it takes to get a copy of mach in the repo, with
fc1+extras as the default buildroot? Then you can change this line to
"Does the package build under mach". And the "how to build using mach"
instructions can be
yum install mach
mach build mypackage.src.rpm
6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS.
Not sure if this is relevant to anything, but again, it's easy to check.
Couldn't rpmlint do this?
7. Are all paths within the .spec replaced with macros?
Relatively easy to check, but I'd had to be tasked with this without
having built a few rpms in the past. A howto for this process might be
nice.
8. If the package has a DesktopEntry, are the VFolder categories ok?
I don't have any idea what any of this stuff is. I don't build desktop
software. Some documentation about it might be good.
9. Is the package free of any %{buildroot} macros?
Apparently this is subject to debate. It's not a showstopper. Make it go
away.
10. Is the package free of unowned directories?
This is also very hard to check. You mean I have rpm -ivvh this package
and then scroll through a whole pile of cruft to see the unowned
directories? And then I have to know which ones it's "supposed" to own,
and which ones it's now?
The packages I checked didn't own /usr, /usr/lib, /usr/bin. I assume
they aren't supposed to?
This is a good thing to check, but theres gotta be a way to automate
this, and if nothing else, explain what paths are ALLOWED to be unowned.
11. Is the License tag used rather than Copyright?
Easy. Rpmlint should/can? Check this.
12. Is the package free of default passwords?
Not necessarily easy to check, but easy to understand, and important.
13. Are all daemon's which can be installed to run as non-root installed
as such?
Same as 12.
14. Does the package handle a parallel build cleanly?
Does this really matter? Seems like a nice thing to check but not a
showstopper. Make it go away.
Ok. So. Heres what I suggest to replace it all with
Showstoppers:
1. Are the sources from upstream pristine and free from trojans?
2. Does the package build clean under mach?
3. Does the package follow the Fedora Package Naming Guidelines?
4. Does the package appear to work?
5. Is the package free of default passwords?
6. Are all daemon's which can be installed to run as non-root installed
as such?
Additional Critiques:
7. Are all paths within the .spec replaced with macros?
8. If the package has a DesktopEntry, are the VFolder categories ok?
9. Is the package free of unowned directories? <-- at least explain this
10. Does the package handle a parallel build cleanly?
11. Does it pass rpmlint cleanly?
With good solid descriptions for 1-6 especially, I think it will become
much easier to get useful information from would-be QA'ers. I'd like to
see the how to help page say "Please do QA. Heres how"
1. Create bugzilla login
2. Follow this link to the list of packages needing QA.
3. Follow these instructions and fill out this checklist and post the
results in a comment.
Some additional notes:
1. Relax on the whole GPG thing. GPG is great. I figured it out. So can
anybody else. But don't make it a barrier for entry. For a newbie, it's
utterly unnecessary. The first thing you want people to do is to go
through the package, create a bugzilla login, and post a completed
checklist like I did above. When they first start, their input is going
to be suspect anyway, so why slow down the process by an hour by
figuring out how to use GPG? Bugzilla passwords aren't entirely
insecure...
2. Provide some feedback. I QA'd some packages. I waited. And waited. A
week later, AFTER I saw a discussion about bugzilla keywords and added
"NEEDSWORK" to the packages I had QA'd, I got my first piece of
feedback. This doesn't encourage repeat customers. It's a whole lot more
rewarding when you submit something, and an hour later you get a message
back from somebody saying "Hey, you messed up, but thanks for trying,
can you please check a, b, and c?".
I realize everybody's volunteering here, but there has GOT to be a way
to detect when somebody new has posted to bugzilla and go check out what
they did. If there were a "newbie comments" query available in bugzilla
it might help. It's a set the hook sort of thing.
3. Provide a way for people to QA packages which have already been QA'd,
so the 2 reviews happens. I think there has been some discussion about
this. A link to an appropriate bugzilla query from the "How do I get
started" page would be great.
I think it's imperative that packages make it through the QA process. It
doesn't do any good if packages never make it into the repo. Right now,
they appear to just sit there. Then the packager gets fed up, doesn't
respond if anybody checks his package, and starts a new repo. This is
not building community. This process has GOT to be fast enough that when
I submit a package for something that people actually use, it gets QA'd
SOON, before I've lost all interest in it.
In addition, there needs to be a way for a motivated packager to
convince people to QA his work. Is sending email to fedora-devel saying
"please QA my new widget package?" acceptable?
Maybe a mailing list that automatically gets CC'd all new Fedora Meta
New package Requests, NEEDSWORK, and REVIEWED keyword changes would
help? Or maybe they should just go to fedora-devel?
Anyway, just my $0.02. Hope you're still awake!
--erik
20 years, 2 months
latest update
by Richard Hally
what is the problem with the /development tree? see below:
[root@old1 root]# yum update
Gathering header information file(s) from server(s)
Server: Fedora Core 1.90 - i386 - Development
Finding updated packages
Downloading needed headers
Resolving dependencies
.Package gnome-applets needs libgtop-2.0.so.1, this is not available.
Package gnome-system-monitor needs libgtop-2.0.so.1, this is not
available.
Package gnome-applets needs libgtop_common-2.0.so.1, this is not
available.
Package gnome-system-monitor needs libgtop_common-2.0.so.1, this is not
available.
Package gnome-applets needs libgtop_sysdeps-2.0.so.1, this is not
available.
Package gnome-system-monitor needs libgtop_sysdeps-2.0.so.1, this is not
available.
[root@old1 root]#
thanks for the help
Richard Hally
20 years, 2 months
RE: Fedora.us QA (was: Re: Prelink success story :))
by Erik LaBianca
> -----Original Message-----
> From: fedora-devel-list-admin(a)redhat.com [mailto:fedora-devel-list-
> admin(a)redhat.com] On Behalf Of Michael Schwendt
> Sent: Thursday, February 26, 2004 7:15 PM
> To: fedora-devel-list(a)redhat.com
> Subject: Fedora.us QA (was: Re: Prelink success story :))
>
<snip>
>
> ... and, of course, because you've realized that you take a big
portion of
> responsibility with your approval of a package, so you wanted to aim
> at perfection, didn't you? ;) Yes, of course you wanted to avoid any
> mistakes. :)
You got me there :)
> > 1. Information how "how to do some useful qa" is scattered.
>
> Remains the question whether you could really instruct newbies without
the
> help of a book or a few courses.
A good question it is. My belief is that it must be possible. At least,
I like to think I made a useful contribution, and I read no books and
took no courses. They'll not be packaging guru's overnight, but they'll
be able to "get up to speed" doing something useful.
> I added an entry to the checklist yesterday. A show-stopper IMO.
> To check file permissions and ownership. Has happened several times,
> that a %defattr was missing or files/directories were inaccessible.
I agree on that one. File %defattr can make a nasty mess to be sure.
>
> > There should be a template like I have above, that can be answered
> > with simple yes or no answers, that covers all the showstoppers.
That
> > way a newbie can fill it in the blank with yes's or no's and no he's
> > done something useful.
>
> But would that be useful? Do you expect someone to go through the list
a
> newbie posted and check step by step whether he made a mistake? I
think
> the checklist is for personal use only and should not be attached to
> package requests as a Yes/No answered list. Approvals should be short
and
> to the point and concentrate on a few items. If I had to fill out a
list
> of what I check, that would slow me down a lot unless some special
> software would aid me upon maintaining the list.
Well, honestly, yes, I do expect someone to go over a newbies work.
That's what the "2 reviews" policy for, isn't it? For someone such as
yourself, who clearly knows what makes a good package at a much deeper
than just "did it pass the showstopper checklist", the need to fill out
the checklist becomes less if at all.
I don't know why it would take more than a few seconds to fill out a
basic showstopper checklist. Obviously, the more skilled the QA'er, the
more additional "value" they add beyond the checklist. But the checklist
makes a good start, and allows someone without that "common sense" you
referred to earlier today to make a meaningful contribution and get up
to speed.
Think of it as a pre-flight checklist. I think this sort of formalism is
one of the area's where fedora.us / extra's has a chance to improve upon
the single-maintainer policies, because theres a written down list of
"showstoppers" which aren't allowed to pass QA. And if they do, the
multiple reviews over time will eventually catch them.
>
> > Since all the checklist items are there, answered
> > with yes or no questions, it's easy to know if they actually made a
good
> > faith effort to check the package.
>
> Which increases the workload a lot, when many items are not needed
> for a particular package or when many more items are added to the list
> (because it isn't complete). Reviewers should develop a feeling for
> what is important and what is not.
>
How is a new reviewer supposed to develop that feeling? You've got to
have a place to start. I'm sure there are people out there who have
never seen a spec file before that would like to be able to help fedora.
These people should be recommended to read maximum rpm, and then start
qa'ing using the showstopper checklist. I'd say there shouldn't be more
than a dozen or so show stoppers, which could easily be included in the
preflight checklist.
> > Some critique of the list:
> >
> > 1. Does the package follow the Fedora Package Naming Guidelines?
> > This is pretty darn complicated for a newbie QA'er. They should be
> > allowed to opt out. A "senior developer" could look at the package
in 10
> > seconds and understand whether or not the name is ok.
>
> But package naming and versioning issues don't stop anyone from
reviewing
> the rest of a package, do they?
>
No they don't. However, as a newbie, my impression was that I was to
review ALL aspects on the checklist. After doing some QA and looking at
other peoples bugzilla reports I figured out that it would be ok if I
just downloaded the package and made some comments about what I didn't
like.
However, people just making comments about what they like doesn't
provide a deterministic path to REVIEWED status.
> > 2. Are the sources from upstream pristine and free from trojans?
> > This is important, but exceedingly difficult to do "properly"... At
what
> > point does this become a showstopper? At some point it becomes
> > impossible to verify the source without actually being the author of
the
> > code and inspecting it line by line. For a newbie this is very
> > intimidating
>
> Of course. Still, the least someone can do is compare the MD5
checksums
> and also check packages from other distributions (not because they are
> trusted ultimately, but to fetch the source from multiple locations)
and
> visit the home page (and e.g. directories like freshmeat.net) to check
> whether a release might be official.
>
> Asking upstream authors for MD5 checksums via e-mail doesn't work
> well. I've tried without luck to get some to post clearsigned
checksums in
> the download area.
I'd have been happier about this item if I'd known this was somewhat
optional, and not expected to be 100% possible. However, it needs to get
done at some point. If it's on the checklist, then you know it got done.
If I just make comments about broken things, and then submit an
approval, how do you know I verified md5sums?
> > I'd suggest something like "are all
> > pathnames in the pre/post(un) install scripts complete?
>
> What does that mean? Macros in scripts are okay and are expanded at
> build-time. Environment variables are not okay because they are
evaluated
> at run-time.
These are tough. I don't think you can expect a newbie to really
evaluate this very effectively. That being said, if they install the
package and it works, the scripts can't be TOO bad. They can be improved
later when somebody more knowledgeable looks at the code. Maybe this
item is pedantic and should be instead included under "does it work?".
>
> > Are macros used for all package files?
>
> Depends on whether it makes sense. If the source code has some paths
> hardcoded, it doesn't make much sense to use corresponding macros in
the
> spec file.
Ditto as above. It's a tough call, but not exactly a showstopper. People
will have differing opinions on it. If the package works, let it go or
argue about it, but don't stall it in QA over this.
>
> > Also. Wheres the "does this package appear to work" line item? Do we
QA
> > packages and not actually run them? It seems like this is pretty
basic
> > criteria.
>
> Are step by step items on "does it build?", "does it install?",
> "does it upgrade?", "does it erase?" really necessary?
I think so, to a degree. This list needs to be basic, so people can get
up to speed. Also, in the interests of formalism, knowing that the
package builds properly, and appears to work after installing is
important. Maybe the review just downloaded the srpm, made some
complaints about the spec file syntax ($RPM_BUILD_ROOT vs %{buildroot}
anyone) and moved on.
I'm seriously concerned that packages be able to move through fedora
quickly and efficiently, without compromising their quality. I'm not
convinced the current process is getting that job done.
> > 5. Are there no missing BuildRequires?
> >
> > This one took me a LONG time to check. The manual "remove all devel
> > rpms" method is apparently deprecated according to the url above,
> > however fedora.us doesn't even include a copy of mach. No less, mach
is
> > pretty complicated and you've got to figure out how to create a
> > fedora.us enabled buildroot.
>
> "mach" is not mandatory. I've tried it once, long ago. Use what works
for
> you. It can be embarrassing if an approved package fails in the build
> system.
Ok so it's not mandatory but it seems the sanest way to check
buildrequires. Is it used for the fedora.us buildsystem or not? It
doesn't make much sense to me for packages to pass QA that can't be
built properly on the build system.
>
> > 6. Is the Group tag an official one? See
/usr/share/doc/rpm-*/GROUPS.
> >
> > Not sure if this is relevant to anything, but again, it's easy to
check.
> > Couldn't rpmlint do this?
>
> AFAIK, rpmlint checks whether a group is known, but not whether
> a package is put into the proper category.
Point well made. I agree. A human will need to verify that the
categorization makes sense.
>
> > 10. Is the package free of unowned directories?
> >
> > This is also very hard to check. You mean I have rpm -ivvh this
package
> > and then scroll through a whole pile of cruft to see the unowned
> > directories? And then I have to know which ones it's "supposed" to
own,
> > and which ones it's now?
>
> You can also "rpm -qlv |less" the package and make sure that it owns
> its _own_ directories. ;)
>
<snip>
> This depends on a package's dependencies, e.g. whether the package
adds
> files to the directory of a package it depends on. In that case it
would
> not need to own the directory.
These are good tips. Lets get them into the docs somewhere, along with a
definition of "its own directories". This wasn't immediately obvious to
me, and I would hope to be able to have people be able to contribute
more easily than I did.
> > 14. Does the package handle a parallel build cleanly?
> >
> > Does this really matter? Seems like a nice thing to check but not a
> > showstopper. Make it go away.
>
> It is a showstopper, because a package which "make"s with %_smp_mflags
in
> the spec file might break badly in the build system. It is not always
> obvious whether such breakage is due to SMP make flags. Defining
> "%_smp_mflags -j3" in your local ~/.rpmmacros file also on UP machines
> can help detect breakage.
Ok. So we need everybody to put "%_smp_mflags -j3" in their
~/.rpmmacros, and then we can just ask them "does it build". Maybe what
I'm getting at here is that it would be really helpful to have an easily
duplicated (checked out from fedora.us!!), defined build environment...
>
> > 11. Does it pass rpmlint cleanly?
>
> Not always possible. :)
>
Ok true, but if it doesn't maybe that's time for a more knowledge person
to approve that which doesn't pass rpmlint?
> > With good solid descriptions for 1-6 especially, I think it will
become
> > much easier to get useful information from would-be QA'ers. I'd like
to
> > see the how to help page say "Please do QA. Heres how"
>
> And when issues not covered in the list come up, those people are fed
up.
> E.g. but not limited to:
>
> * build not accepting $RPM_OPT_FLAGS
> * build stripping binaries
> * bad -rpath found
> * archdependent files below %_datadir
> * not adhering to FHS
> * spec file sections in wrong order (e.g. builds in %install section)
> * libtool archives not deleted and not needed or wrong paths
> in libtool archives
> * *.so links in non-devel package and not needed there
> * python *.py{c,o} files not marked %ghost
> * perl modules installed into site location, not vendor location
> * macros in %changelog
I'm not sure I understand what you're saying here. Maybe I should have
said "heres how to start" instead?
I understand all those and many more can be possible problems, but
expecting packages to be perfect before they pass QA is going to stall
the process indefinitely. If those issues come up, the newbie may not be
able to detect them. They'll get noticed sometime, and should get fixed
then.
>
> > 2. Provide some feedback. I QA'd some packages. I waited. And
waited. A
> > week later, AFTER I saw a discussion about bugzilla keywords and
added
> > "NEEDSWORK" to the packages I had QA'd,
>
> NEEDSWORK is to move packages out of the QA queue, because they don't
> build or need more work before they are moved back into the QA queue.
> This can also be set by the packager if major changes are planned.
> REVIEWED is the new keyword to flag reviewed packages, so they are
> easy to locate.
>
OK. So at what point do I make the determination that the package has
passed QA? The stuff I marked as needs work ended up being due to some
stuff I saw on the "QA Checklist" which turns out not to really be a
showstopper, or is it?
With a showstopper checklist, I know that if there are no showstoppers
it's safe to approve. If there are it's not.
This way my likelihood of looking like an idiot is very low, if I
followed the instructions properly. Not feeling like an idiot is what
makes people come back and feel good about contributing.
> > I got my first piece of
> > feedback. This doesn't encourage repeat customers. It's a whole lot
more
> > rewarding when you submit something, and an hour later you get a
message
> > back from somebody saying "Hey, you messed up, but thanks for
trying,
> > can you please check a, b, and c?".
>
> Lack of man power. More reviewers are needed. Especially since we
don't
> know how/what official Fedora Extras will change.
Agreed. And understood. And I'm trying to help make it easier to get new
reviewers. I know several semi-serious linux users I might get QA some
packages, but until the process is streamlined enough I can point them
to a relatively straightforward set of tasks I'm very unlikely to get
them to actually do it.
> > I think it's imperative that packages make it through the QA
process. It
> > doesn't do any good if packages never make it into the repo. Right
now,
> > they appear to just sit there. Then the packager gets fed up,
doesn't
> > respond if anybody checks his package, and starts a new repo.
>
> Not every packager can work on his packages as soon as someone found
> issues. Sometimes you need to wait till the next weekend. If the
packager
> doesn't respond, simply move the request out of the package queue by
> deleting the QA keyword and setting the NEEDSWORK keyword.
OK, that's fine, but in all reality I'm uninterested in removing the
package from the QA queue. I want the package published! And now! At
what point is it ok for me to just post my own version of the SRPM?
Also, documentation of these keywords was not apparent to me in the web
of pages I looked at while trying to figure this process out.
> > This is
> > not building community. This process has GOT to be fast enough that
when
> > I submit a package for something that people actually use, it gets
QA'd
> > SOON, before I've lost all interest in it.
>
> If there are people with interest in a package, surely there should be
> two reviewers, too?
>
I'm sure they are out there, but we've got to make the process so darn
straightforward they can't help but succeed once they decide to help
out. I'm skeptical that it's that way now. I'm not sure if I succeeded
yet, and I can assure you I attacked it unsuccessfully a few times
before finally making it over the hump of actually posting a review
comment.
Just $0.02!
--erik
20 years, 2 months
Re: Fedora Core 2 Test 2 - delayed
by Jef Spaleta
James Harrison wrote:
> That dont cut it for me. Two distinct kernels one with SELinux
> and one without.
Then i suggest you build your own custom kernel 2.4.x kernel. The
momentum upstream is against you. I also suggest you become more
actively involved with following all relevant kernel development
communication channels while development decisions like this are
on-going...instead of trying to second guess them after the fact.
Oh and by the way...everyone is out to get you...don't doubt it for a
second.
-jef"is rotating jamming frequencies profiles on his rf spectrum
broadband whitenoise helmet based on a quantum interference
randomization algorithm to keep the thought control rays out"spaleta
20 years, 2 months
Announce: Updated Speedtouch rpm
by Leonard den Ottolander
Hi,
A new speedtouch rpm for use with Red Hat 9 and Fedora Core 1 is
available at
http://www.ottolander.nl/opensource/speedtouch/speedtouch.html . This
version is built from CVS (2004/02/20) and should work with the silver
330 rev.4 version of the modem.
Binaries are built on RH9 but should probably be usable on Fedora Core 1
as well. On FC1 you probably want to use the kernel mode driver anyway,
but you can probably use the modem_run binary from the RH9 rpm. If not,
rebuild from the source rpm (and notify me).
Please report any issues you are having to speedtouch(a)ml.free.fr
(subscribe via
http://speedtouch.sourceforge.net/index.php/contacts.html). Don't forget
to concatenate the two firmware parts when using this version.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
20 years, 2 months
rawhide report: 20040227 changes
by Build System
Updated Packages:
anaconda-9.91-0.20040226192747
------------------------------
* Thu Feb 26 2004 Anaconda team <bugzilla(a)redhat.com>
- built new version from CVS
* Tue Feb 24 2004 Jeremy Katz <katzj(a)redhat.com>
- buildrequire libselinux-devel
* Thu Nov 06 2003 Jeremy Katz <katzj(a)redhat.com>
- require booty (#109272)
at-spi-1.3.13-1
---------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 1.3.13-1
- update to 1.3.13
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
* Fri Jan 30 2004 Jonathan Blandford <jrb(a)redhat.com> 1.3.11-1
- new version
cyrus-imapd-2.2.3-5
-------------------
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com>
- Fix location of < /dev/null
gedit-2.5.90-1
--------------
* Wed Feb 25 2004 Dan Williams <dcbw(a)redhat.com> 1:2.5.90-1
- fix dumbness in the egg-recent file locking patch
- Remove the autotools-1.8 patch because it is no longer
needed
- Require gtksourceview-devel >= 0.9 due to update to 2.5.90
- Update to gedit-2.5.90
gnome-games-2.5.7-1
-------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 1:2.5.7-1
- update to 2.5.7
gnome-mag-0.10.7-1
------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 0.10.7-1
- update to 0.10.7
gnome-speech-0.3.1-1
--------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 0.3.1-1
- update to 0.3.1
gnome-system-monitor-2.5.3-1
----------------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 2.5.3-1
- update to 2.5.3
gnome-user-docs-2.5.0-1
-----------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 2.5.0-1
- update to 2.5.0
gnopernicus-0.7.5-1
-------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 0.7.5-1
- update to 0.7.5
gok-0.9.8-1
-----------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 0.9.8-1
- update to 0.9.8
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
* Tue Sep 09 2003 Jonathan Blandford <jrb(a)redhat.com>
- update for GNOME 2.4
gpm-1.20.1-43
-------------
* Thu Feb 26 2004 Adrian Havill <havill(a)redhat.com> 1.20.1-43
- add event device (for 2.6 kernel) superpatch-- includes all
patches up to release 38; thanks to Dmitry Torokhov
- change default mouse device over to /dev/input/mice
- set mouse type to Intellimouse Explorer (exps2), which is what
the 2.6 kernel exports by default
grep-2.5.1-26
-------------
* Thu Feb 26 2004 Tim Waugh <twaugh(a)redhat.com> 2.5.1-26
- Fix fgrep (bug #116909).
gstreamer-0.7.5-1
-----------------
* Tue Feb 24 2004 Alexander Larsson <alexl(a)redhat.com> 0.7.5-1
- update to 0.7.5
- clean up specfile some
- enable docs
htdig-3.2.0b5-6
---------------
* Thu Feb 26 2004 Phil Knirsch <pknirsch(a)redhat.com> 3.2.0b5-6
- Removed buildroot cruft from HtFileFype (#116442).
- Use mktemp in HtFileFype to create temporary file (#116443).
iiimf-le-inpinyin-0.2-3
-----------------------
* Thu Feb 26 2004 Yu Shao <yshao(a)redhat.com>
- to switch off lookup table when preedit string is empty
iiimf-le-xcin-0.1-5
-------------------
* Fri Feb 27 2004 Leon Ho <llch(a)redhat.com> 0.1-5
- rebuilt
* Thu Feb 26 2004 Leon Ho <llch(a)redhat.com> 0.1-4
- install cin2tab with 755 (#116892)
- install .so files with executable (#116554)
- fixed '0' commit to preedit problem
- added 'esc' clean preedit
- fixed candidates non-empty problems
iptables-1.2.9-2.3
------------------
* Thu Feb 26 2004 Thomas Woerner <twoerner(a)redhat.com> 1.2.9-2.3
- fixed iptables-restore -c fault if there are no counters (#116421)
kbd-1.12-1
----------
* Thu Feb 26 2004 Adrian Havill <havill(a)redhat.com>
- update to 1.12
kernel-2.6.3-1.110
------------------
* Thu Feb 26 2004 Dave Jones <davej(a)redhat.com>
- Fix unresolved smp_num_siblings symbol on x86-64
* Wed Feb 25 2004 Dave Jones <davej(a)redhat.com>
- Update to 2.6.3-bk7
- Change a slew of config options to match those in arjanv's kernel.
Lots of "surely no-one is using this anymore" options are now disabled,
along with lots of "this is broken anyway" options.
- Numerous fixes to various modules to fix panics on unload.
* Tue Feb 24 2004 Dave Jones <davej(a)redhat.com>
- Update to 2.6.3-bk6
- Enable lots of ISDN config options.
- Several E1000 net driver fixes.
- Disable ACARD SCSI driver. (It's very broken right now)
libpng-1.2.2-19
---------------
* Fri Feb 27 2004 Mark McLoughlin <markmc(a)redhat.com> 2:1.2.2-19
- rebuild with changed bits/setjmp.h on ppc
mdadm-1.5.0-2
-------------
* Thu Feb 26 2004 Doug Ledford <dledford(a)redhat.com> 1.5.0-2
- Add a default MAILADDR line to the mdadm.conf file installed by default
(Bugzilla #92447)
- Make it build with gcc-3.4
* Mon Feb 23 2004 Doug Ledford <dledford(a)redhat.com> 1.5.0-1
- Update to 1.5.0 (from Matthew J. Galgoci <mgalgoci(a)redhat.com>)
* Sun Nov 16 2003 Doug Ledford <dledford(a)redhat.com> 1.4.0-1
- fix problem with recovery thread sleeping in mdmpd
ncurses-5.4-4
-------------
* Thu Feb 26 2004 Adrian Havill <havill(a)redhat.com> 5.4-3
- xterm-color is wrong for rh; inverted bs/del (#115499)
openssh-3.6.1p2-31
------------------
* Thu Feb 26 2004 Daniel Walsh <dwalsh(a)redhat.com> 3.6.1p2-31
- Add restorecon to startup scripts
* Thu Feb 26 2004 Daniel Walsh <dwalsh(a)redhat.com> 3.6.1p2-30
- Add multiple qualified to openssh
patchutils-0.2.27-1
-------------------
* Thu Feb 26 2004 Tim Waugh <twaugh(a)redhat.com> 0.2.27-1
- 0.2.27.
policy-1.6-12
-------------
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-12
- Fix fd inheritance
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-11
- fix locate
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-10
- Add Russells latest
policycoreutils-1.6-4
---------------------
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-4
- exit out when selinux is not enabled
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-3
- Fix minor bugs in restorecon
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-2
- Add restorecon c program
rhpl-0.128-1
------------
* Thu Feb 26 2004 Brent Fox <bfox(a)redhat.com> 0.128-1
- add some hooks to xhwstate.py to get PCI bus ID info
rpmdb-fedora-1.90-0.20040227
----------------------------
20 years, 2 months
MrProject is now Planner
by Chuck Mead
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...and there has been an updated release! (.11)
Any chance we can see the updated release in FC2? It fixes a number of
outstanding bugs.
- --
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAPLC3Zfy0juH51WsRAnltAKCDa2MMdnA3bS7Uc0Qi1kplSmi60QCfXa4Q
QqVYo7/4sLIj2TecF8Dk0FY=
=ikP0
-----END PGP SIGNATURE-----
20 years, 2 months
