RE: RFC: fedora.us QA approval format
by Erik LaBianca
>
> enrico.scholz(a)informatik.tu-chemnitz.de (Enrico Scholz) writes:
>
> >> I know that bugzilla has the 80 charachter limit and have been a
> >> victimized more than once.
> >
> > My suggestion: use w3m which allows to configure an external
$EDITOR.
> This
> > makes it possible to bypass the 80 character limitation.
>
I do think that expecting newbies to understand the vagaries of gpg,
browser textarea line wrapping, cut 'n' paste and tab expansion is
probably going to cause us some pain in the long run.
Since it isn't required to sign the entire review, perhaps the better
way to handle it would be to ONLY sign the SRPM md5sum and (if
applicable) PUBLISH recommendation (at least in the automated tools)?
That way anything else can be included, but since it's not signed, it
can be formatted and pasted however is most appealing to the eye,
instead of worrying about 80 char lines etc.
This means we can easily include full source URL's that were verified,
etc.
Currently fedora-startqa is designed to be run from a qa account, which
shouldn't have your gpg signing key available to it. However, it would
be pretty simple to have a program to do the split signing from ones
regular account that digests the output from fedora-startqa (Toshio's
qa-assistant, perhaps?).
Thoughts?
--erik
20 years
Re: RFC: fedora.us QA approval format
by PLinnell
> ----------------------------------------------------------------
>
> Message: 1
> Date: Sat, 10 Apr 2004 14:04:27 +0200
> From: Aurelien Bompard <gauret(a)free.fr>
> Subject: Re: RFC: fedora.us QA approval format
> To: fedora-devel-list(a)redhat.com
> Message-ID: <c58ns1$k3r$1(a)sea.gmane.org>
> Content-Type: text/plain; charset=iso-8859-15
>
> Hi,
>
> Sorry to write back so late about that.
>
> Toshio wrote:
> > * I would get rid of the first line altogether. Because these reviews
> > are going into bugzilla, the package name is already available. And it
> > doesn't provide any information the build system needs. Alternately,
> > you could make the first line:
> > <HASH> <SRPM>
> > so that it's useful for the build system. (But see my next entry.)
> >
> > * I would change Files to MD5sums (or MD5SUMS) because at sometime in
> > the future the build system may support other hash types and it would be
> > good for it to be able to easily tell which is which one this is.
> >
> > * I would specify that the <SRPM> always comes first in the HASH
> > section. This makes it easier for the release managers and the
> > buildsystem to parse the HASH-SRPM pairing from the other files.
> > It could also be separated by a blank line or other visible
> > demarcation.
>
> OK. I've updated http://fedora.us/wiki/QAFormat. How do you like it now ?
>
> > * Regarding the Sources lines: I'd include the full URL for the
> > tarball and say it comes from a canonical source rather than simply
> > "is valid".
> > * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is
> > the canonical Source location
>
> Maybe the full URL is not necessary in the review, we could just add that
> canonicalness has been checked.
> I'm worried about the fact that bugzilla's mails are reformated to 80 (or
> some) characters columns, thus breaking GPG check. I try to avoid long
> lines, and an URL will probably be too long.
>
> > For the other source line, I'd want something like this:
> > * Sources: bash-completion.profile appears to be correct and proper
> >
> > My reasoning is that I don't care so much about whether I can download
> > the files off the internet (More precisely: I only care if I can't.)
> > I do want to know what works been done verifying the sources (which
> > canonicalness of source tarballs helps for the first one and looking
> > at the file helps for the second.)
>
<snip>
I know that bugzilla has the 80 charachter limit and have been a
victimized more than once. The key for me with any review is
repeatability. I like having the full source url to make it easy to wget
and unroll the package for inspection in two easy steps.
Most of my reviews are very similar to what you have outlined. Maybe a
bit more verbose, if only to enable a second reviewer to replicate what
I have done. Hence checking the checker, if needed.
The other issue which I see missed often in reviews is not just a clean
install/remove check, but also upgrades, which I test as much as
possible. I tend to review packages I have already installed and use
regularly. So many times I can make this check, but this is not 100% of
the time.
While I would not say it should be a hard and fast policy, upgrade
correctness is important, especially for stable repo packages.
I just had that case with one of my own packages and it was not easy to
figure out. That is one of the hold ups on GIMP 2.0 in Fedora extras..
but I now think I have that solved.
Great work and thanks for adding this.
Peter
20 years
Re: RFE (fedora 3? 2.1?)
by "Nils O. Selåsdal"
On Thu, 2004-04-08 at 03:00, Ricardo Gorosito wrote:
> I know that is to late for a feature request, but:
> - what about RHDB Administrator 2.0 (tcl?)
I'd advocate http://www.pgadmin.org/ rather.
Though, it uses wxWidgets, which isn't in FC.
--
Nils Olav Selåsdal
System Engineer
w w w . u t e l s y s t e m s . c o m
20 years
Future: fhs 2.3 compliance for fc3
by seth vidal
Hi all,
looking at fhs 2.3 and thinking about what needs to be done for fc3 -
just a few things that people could get working on early:
/srv - user data for services not owned by a single specific user there
ie:
/srv/www
/srv/vsftpd
/srv/postgresql ?
/srv/mysql ?
/srv/jabberd ?
/srv/bittorrent ?
/media - all the removable media and silliness there.
Thoughts on looking through the daemons and seeing what needs to be
fixed up to meet this?
-sv
20 years
kudzu hangs on latest kernel
by Jurgen Botz
On my desktop workstation (Asus A7V8X mb, Athlon XP 2500 CPU),
kudzu freezes the system when it runs at startup with kernel
2.6.5-1.315. This is a hard freeze, need to hit reset,
ctrl-alt-del doesn't, keyboard lights don't respond to capslock,
etc.
Anyone else seeing this?
:j
20 years
udev by default?
by Shahms King
Are there any particular reasons for not using udev by default these
days? It seems limiting the entries in /dev to existing devices is a
good idea (particularly given the number of devices currently listed...)
The only thing missing (IIRC) is autoloading of modules upon device
entry access, but that seems to be the job of hotplug anyway...
--
Shahms King <shahms(a)shahms.com>
20 years
RFC: fedora.us QA approval format
by Aurelien Bompard
Hi all,
Erik and myself have been working on a QA check script to automate the QA
process at fedora.us. The script is getting quite correct, and can even be
useful ;-)
At the end of the checks, the script outputs a QA approval report, which can
be edited, gpg-signed, and pasted into bugzilla. The question is: what
should a QA approval look like to have all the minimum QA requirements and
be as parseable as possible by a publishing script for the release manager.
Erik and I have different minds on what has to be in the review, so we
though we should discuss it here, especially with the release managers.
I have setup a wiki page with a primary format proposal, and I invite you to
have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat
If the script is to get into fedora-rpmdevtools, a complete newbie could
contribute meaningful QA's in a format which would be useful to the release
manager. This would lower the bar to QA, and standardize the process a
little bit more.
Please comment
Aurélien
--
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
If you wish to live wisely, ignore sayings -- including this one.
20 years
I was wondering why totem and anjuta aren't included in fc2
by lupus
totem will be in gnome 2.8 so why wait ;) It's a great mediaplayer that
can use gstreamer.
anjuta is interresting for C and C++ projects like gnome ;) it even
creates makefile.am automaticly.
And eclipse for java.
Talking about java. Is there an opensource java plugin for mozilla?
Lupus (Kristof Vansant Belgium)
20 years
Dependency hell
by Richard Hally
Please see the list of my attempts to update my system to rawhide.
The thing that seems most incorrect is that rpm or yum do not report
correctly the packages that need to be excluded. Since there always
seems to be some dependency problem (one gets fixed but another one
stops the update) it would seem that a reliable way to determine which
packages to exclude would be very helpful and save time that can be put
to better use. thanks for any help,
Richard Hally
> [root@localhost root]# yum upgrade
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Finding obsoleted packages
> Resolving dependencies
> ......Unable to satisfy dependencies
> Package pwlib needs libdv.so.2, this is not available.
> Package xemacs needs libRKC.so.1.2, this is not available.
> Package xemacs needs libcanna.so.1.2, this is not available.
> Package dvgrab needs libdv.so.2, this is not available.
> Package db4-java needs db4 = 4.1.25-14, this is not available.
Here is the second attempt with the packages that reported excluded
>
> [root@localhost root]# yum --exclude=pwlib --exclude=xemacs
> --exclude=dvgrab --exclude=db4-java upgrade
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1 - i386 - Rawhide
> Finding updated packages
> Downloading needed headers
> Finding obsoleted packages
> Resolving dependencies
> ......Unable to satisfy dependencies
> Package gnomemeeting needs libpt.so.1.6.3, this is not available.
> Package gnomemeeting needs pwlib >= 1.6.3, this is not available.
> Package xemacs-info needs xemacs = 21.4.15, this is not available.
> Package openh323 needs libpt.so.1.6.3, this is not available.
> Package openh323 needs pwlib >= 1.6.3, this is not available.
> Package xemacs-el needs xemacs = 21.4.15, this is not available.
> Package pwlib-devel needs libpt.so.1.6.3, this is not available.
> Package pwlib-devel needs pwlib = 1.6.3, this is not available.
> Package db4-java needs db4 = 4.1.25-14, this is not available.
> [root@localhost root]#
>
20 years
RE: Easter sermon: Of kernels and slocate [was: Slocate hates me (was:Prelink hates me)]
by Fred New
On April 11, 2004, at 00:52, Bryan O'Sullivan wrote:
>
> On Sat, 2004-04-10 at 13:03, Simon Perreault wrote:
> > Ok, I found out what the problem was. The culprit is not prelink. It
is
> > slocate.
<snip>
> Tools like "slocate" are pathological in their behaviour for caches.
> The cache is meant to help when you need to access the same data again
> and again, which is very common. However, slocate reads every single
> file in a filesystem once, so the caches balloon up in size with data
> that they don't need to contain.
<snip again>
We have a similar problem with databases: reports that need to scan an
entire database fill the database cache with unnecessary data, while
only a fraction of the database is usually active. In the database
package I am familiar with, you can set a parameter that limits how much
database cache the reports are allowed to use. It seems like a similar
parameter for file system cache could be created for programs like
slocate.
Fred
20 years