Spamassassin [Fwd: 3.0.0 schedule]
by Warren Togami
FYI. Rawhide now contains a snapshot of spamassassin-3.0.0, which will
be updated next week when the official pre-release happens. I encourage
all spamassassin users to rebuild the rawhide spamassassin SRPM for use
on FC1 or FC2 in order to provide production testing, and report bugs in
upstream Bugzilla. I personally have been using 3.0.0 svn snapshots on
my personal server for a few weeks now, and it has been much better than
spamassassin-2.63 for me.
Warren Togami
wtogami(a)redhat.com
-------- Original Message --------
Subject: 3.0.0 schedule
Date: 28 May 2004 17:41:24 -0700
From: Daniel Quinlan <quinlan(a)pathname.com>
Reply-To: quinlan(a)pathname.com
To: spamassassin-dev(a)incubator.apache.org
So, here's the new schedule, based on Theo's last schedule:
(a) bug squashing is not part of schedule; this can and should be
scheduled independently
(b) there is no concept of "all bugs" any more, only "critical bugs"
(c) warning people about mass-check runs is also decoupled as that can
be done independently -- we can warn people now, even
(d) critical bugs had better darn well show up in red in my bugzilla
screen (that is, "Severity" field set to "critical") or the bug
doesn't count as critical.
feature freeze:
05/31: feature freeze, enter Review-then-Commit mode at 0900 UTC to
enforce feature freeze
pre-release cycle:
06/03: first pre-release
do {
3 to 7 days of testing of pre-release
issue new pre-release
} while (critical bugs found in testing)
mass-check cycle:
day 0: announce mass-check run 1 (sets 0 and 1), run 7 days
day +7: generate scores, etc.
day +9: new pre-release with new scores, announce mass-check run 2
(sets 2 and 3), run 7 days
day +11: generate scores, etc.
release-candidate cycle:
day 0: release 3.0.0-rc1
do {
3 to 7 days of testing of release candidate
issue new release candidate
} while (critical bugs found in testing)
day ?: issue 3.0.0-final
------------------------------------------------------------------------
RATIONALE:
First, we need R-T-C to have the feature freeze. Second, my experience
is that we actually move faster once we enter R-T-C mode because
everyone is following development closer.
We should not try to get everything done or close every bug before
moving forward with pre-releases (which must precede the mass-checks to
get the bugs out) because we'll always have bugs being added. 2.63 is
not as good as 3.0, so let's release and help out our users.
So, no more bug squashing events, no more delays, let's enter R-T-C mode
on Monday and do a pre-release next week. WE ARE READY.
Also, if someone wants to replace the scores, then you have a week.
Open a bug. ;-)
I believe tying everything together in the schedule is adding delays and
making it easier to slip more and more stuff into the release. We never
had to lock-step things before, we just reviewed the open bugs at each
stage of the simple schedule and decided whether or not we were ready to
proceed to the next step or if we had to cut a new pre/rc release. It's
how most open source projects work. Assigning dates far out in the
future is pretty pointless and just makes things frustrating.
As you can see, I've attempted to streamline the schedule, for example,
by allowing for as little as 3 days of testing (if a bug can be verified
as fixed quickly) so we can plow through rather than stay stuck in the
mud. I limited things to 3 days, though, so we don't issue new releases
every day or every other day.
Finally, since we're not in R-T-C mode yet, I'm calling this the 3.0.0
schedule. If you want to veto...
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
19 years, 11 months
3ware 9500
by Peter Maas
Dear Sirs:
3ware had released new drivers for there 9500S series ide raid cards under
the GNU GPL, the current kernel drivers support up to the 8500 Series. What
is necessary to have to have these drivers added to the redhat
kernel(hopefully linus's kernel also)? I have the source that is shipped
with the card if needed.
Thank You
Peter Maas
fedora(a)rooker.dyndns.org
19 years, 11 months
systematic Kerberization
by Havoc Pennington
Hi,
Something we've wanted to do for a long time is create a matrix of
programs that should support Kerberos authentication, and start checking
them off. I guess this includes both client-side and server-side.
Does anyone have a good start on this?
Any real-world experience/scenarios where Kerberos support was needed
and not available? (Which things should be Kerberized first?)
Havoc
19 years, 11 months
building packages for FC2 for external kernel modules
by Thomas Vander Stichele
Hi all,
I'd like to spark some discussion on how to properly package kernel
modules for FC2. I have personally packaged a few kernel module
packages for FC1 for fedora.us (see
http://thomas.apestaart.org/download/pkg/fedora-1-i386-fedora-stable/),
and Ville Skytta has packaged some others using a different technique.
I have spent some time this week getting more familiar with the linux
2.6 buildsystem, and have come up with a similar system to what I had
for 2.4. I'd like to explain the various parts of the problem and
solution and get some feedback so I can fix the procedure and propose it
to fedora.us
First of all, a few things are different with 2.6 and FC2:
- you cannot use kernel-source anymore to build for all archs (i586,
i686 - athlon is dropped) and types (regular and -smp) This is because
you need a bunch of different headers and built files
- these built files are packaged in the kernel rpm and install in
/lib/modules/`uname -r`/build which is now no longer a symlink to
/usr/src/linux-(rel) but a real directory. This effectively prevents
you from building kernel modules for more than one arch at the same time
on your system, since there's no way to install the same kernel rpm for
different archs.
- afaict the FC2 kernel no longer uses symbol versioning (MODVERSIONS
not defined, and Module.symvers only contains "0" versions. I have no
idea why this change has been made.
- 2.6 has a new kbuild system that makes it possible to build
out-of-source kernel modules more reliably/easily
So, how does the current procedure work ?
- I wrote a script (http://thomas.apestaart.org/download/tmp/kmd.py)
which takes a set of kernel rpms for the same-version release, but
different arch/types, extracts them, then creates a symlink/copy forest
that produces a tree of dirs with the same contents as each of the four
rpms
(http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kern...)
The reason for doing this is so that modules for each arch/target combo
can again be built on one kernel, and the resulting rpm is smaller than
four copies of the other rpms.
Currently, this rpm puts files in
/usr/share/kernel-module-devel-2.6.5-1.358 :
common kernel-smp-2.6.5-1.358.i586.rpm
kernel-2.6.5-1.358.i586.rpm kernel-smp-2.6.5-1.358.i686.rpm
kernel-2.6.5-1.358.i686.rpm
common is a symlink to /lib/modules/`uname -r` (which can be regular or
smp, and is symlinked at %post time by the rpm).
the four other directories are named exactly like the rpm they were part
of, and contains a tree of files that are different to the others, and
symlinks to the common directory.
- In the autostars project, we have come up with a set of scripts and a
sample project to package kernel modules and build them reliably and
reproducably against any kernel build tree
(http://cvs.sourceforge.net/viewcvs.py/autostars/autostars/linux/)
This has been updated with a full set of procedures to build for 2.6 as
well. Given only the argument
--with-linuxdir=/usr/share/kernel-module-devel-(ver-rel)/(rpm dir), it
can build the correct kernel module. (This same project can still be
used to build 2.4 modules correctly as well, including redhat's special
defines for boot,enterprise,smp,bigmem from /boot/kernel.h)
For 2.6, it includes a libtool-like script that takes care of installing
modules and taking into account symbol versions.
- like before, I have created patches to hostap and ipw2100 drivers to
autotoolize them using this setup. This only takes ten minutes if
you're used to autotools, and ten more if you want it to work out of the
box for both 2.4 and 2.6 (assuming the source allows this).
- Since ipw2100 needs symbol versions and include files from hostap,
I've made the hostap rpm install these files as part of a
kernel-module-devel-hostap-(ver-rel) rpm, in the same tree as the
original kernel-module-devel rpm. all hostap*.symvers files end up in
e.g.
/usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm
(which is where Modules.symvers lives).
The .h files I have for now put in
/usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm/include/modules/hostap
- the spec files for ipw2100 and hostap need some small tweaks to build
both on pre-fc2 (with 2.4) and post-fc2. It mainly consists of the
first buildrequire'ing kernel-source and kernel, and the second
buildrequiring kernel-module-devel-(ver-rel). For hostap, depending on
2.4 or 2.6, different symbol versioning files are installed
(builddir/include/linux/modules/*.ver versus builddir/*.symvers)
Currently the configure invocation is slightly different too, but this
could be fixed.
The resulting rpms are up at
http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kern...
and
http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kern...
and are of course built with mach.
I'd appreciate it if some other people (particularly on smp, though I
don't even know if there are people with an ipw2100 AND dual cpu's) try
them out and let me know if it works.
I'll work on some other kernel module projects as well (I've done the
qc-usb module too, but the resulting module doesn't seem to work
correctly. The original upstream build against my /lib/modules tree
doesn't work either, so I'm sure it's not my changes that break it :))
Here is a list of things I still need to decide or fix and would like to
have input on:
- the devel rpm containst the kernel's version and release as part of
the name, in accordance with fedora.us's policy for actual kernel
modules. It's not possible to have a "-" in the version number, so I
can't put kernel ver/rel in that, and I don't want to stick it in the
release tag since then it's impossible to buildrequire: it properly
since on fedora.us the resulting rpm gets a 0.fdr.2 appended to the
release tag. Is this ok ?
- the devel rpm currently stores its files in
/usr/share/kernel-module-devel-(ver-rel)
Would it be more appropriate to put stuff in
/usr/lib/kernel-module-devel-(ver-rel) instead ?
- the devel rpm is currently set with arch i386. I've considered making
it noarch, since it contains files for more than one arch. But I assume
it's not possible anyway to easily build for x86, ppc and ia64 on the
same machine (though the -devel rpm could still be created for all of
them since it just unpacks rpms and compares files). Which of the two
would be preferable in this case ?
- the hostap rpm does the following:
- when built with --target i386, it does the build for the four
arch/type combos and packages only the devel files (symbol versions +
headers), installing them in the same dir as the kernel-module-devel
rpm.
- when built with --target i586 or i686, it does only one build for
the given 'kernel' uname -r define, and removes the devel files.
This would be an argument in favour of having the -devel packages be
i386; I don't think it's possible to build a -devel rpm for ppc, x86 and
ia64 at the same time if you have to actually build the files.
- currently, .symvers files are installed in the root of the builddir,
and include files are installed in builddir/include/modules/(basename of
module). For the .symvers, I think this is an ok location. For the
headers, I'm not sure yet. Of course, this needs to be a location we
need to agree on so interdependent modules can be built correctly.
For building ipw2100, an extra include directive is given in the
Makefile.am patch that points to builddir/include/modules/hostap
Any suggestions on standardizing this or is this ok ? What would
projects like these be expected to install them to normally ?
- the module spec files could be made to work with fc2 and pre-fc2. I
normally use a check to scan /etc/fedora-release and build a conditional
based on that. Maybe it should check for the kernel version instead ?
If so, can that be done reliably without invoking rpm as part of the
check ? Is it worth it to try and integrate, or would it make more sense
to just do 2.4 and 2.6 spec files separately ?
- I cannot test the smp versions because my machine cannot boot the smp
kernel. For all 2.4 kernels this worked fine. Has it become impossible
to run smp kernels on up machines ? Does anyone know more about this ?
- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account
correctly if it were turned on.
- any other suggestions/questions/objections ?
Thanks,
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
yes i am
a long way
from home
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
19 years, 11 months
Self-Introduction: Alex Perez
by Alex Perez
[If you get this twice, my sincere apologies.]
Hi there, my name is Alexander Joseph Perez, and I'm a co-maintainer of
the GNUstep.org website and have been using GNUstep.org for several
years. I'm from Santa Rosa, California, in the USA, am a full time
anthropology student at Santa Rosa Junior College and work part time as
a lowly help desk technician for the City of Santa Rosa, California.
I'm writing this e-mail because I've recently noticed that the most
recent release of Fedora Core (2) does not contain any GNUstep packages,
and as I've just installed it after getting sick and tired of Debian,
I'd like to change that. I am intimately famaliar with the build
process, and have a significant amount of personal contact online with
the GNUstep core development team on a daily basis. I'd be willing to do
QA on my packages as long as the requirements were reasonable. In short,
I'd like to expose GNUstep to a wider audience now that it is ready for
such exposure. GNUstep has been a long-lived project, and "we're not
dead yet" seems to have become our mantra. GNUstep is not dead. In fact
it's alive and well, and with the inclusion of GNUstep packages into
Fedora Core, one of the more popular distributions of Linux, we will
gain the potential to expose many more people to GNUstep and its offerings.
As I said previously, I'm a current GNUstep.org website maintainer, and
am working on unifying the disparate GNUstep-related documentation
sources which are/have been strewn across the expanse of the Internet
until recently (much of it still is). I love the simplicity and true
Object-Oriented nature of the Objective-C programming language, which
GNUstep is based on. My associate, Andrew Pinski, is the GCC libobjc
(GCC Objective-C runtime) maintainer and works periodically for apple as
his college career permits. I recently worked with him to make sure that
some of the patches to the Objective-C runtime were integrated into
libobjc head.
If anyone here has any questions, please feel free to contact me at
aperezATstudentDOTsantarosaDOTedu as I'd be glad to answer or clarify
any points I've made here. I am not subscribed to the fedora-devel
mailing list and do not wish to be unless I am "accepted" and allowed to
create and provide GNUstep packages to Fedora.
My GPG fingerprint is 2F36 2A89 14B4 B58F 176B 1B26 5E4D 5FCA 9190 2041
and this has been uploaded to pgp.mit.edu
Cheers,
Alex Perez
--
pub 1024D/91902041 2004-05-31 Alex Perez (MrBIOS)
<aperez(a)student.santarosa.edu>
Key fingerprint = 2F36 2A89 14B4 B58F 176B 1B26 5E4D 5FCA 9190 2041
sub 2048g/380DB427 2004-05-31
19 years, 11 months
Re: Why are there only i686 and i586 Version of glibc and kernel?
by Bryan Smith
Alan Cox wrote:
> Likewise my own testing has always found that the Athlon really
> doesn't care much how you order instructions. If you think about it
> AMD have spent years dealing with everyone optimising for random intel
> processor of the year and adapted appropriately.
I have to agree with Alan on this. Having assembled Athlon-based
clusters from Athlon's introduction until a year ago, the i686 (Pentium
Pro) optimizations get you very close, like within 5%, of ideal on
Athlon32.
> Except on things like 3dnow and prefetch stuff the AMD really doesn't
> seem to care.
Plus any floating point.
Athlon32/Athlon64/Opteron has 3 FPUs, two complex and one simple.
Pentium II to Pentium IV has 2 FPUs, of which you can only do either
one complex (while one is idle) or two simple.
While the Athlon does a lot of run-time optimization via out-of-order
execution and register renaming, the compile-time optimizations can
affect things upto 40%.
But that's more of an application thing -- maybe only a few GLibC calls
(?).
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Not sure where to post this message
by Joseph Hurst
Hello,
I'm not exactly sure where to post this message. So I thought that since this is a developers group that it might be a decent place to start.
I'm wanting to find information about a newsletter for Fedora Core if there is one or not. I would like to help work on it if there is or if there isn't, I'd like to help get it started. I'm also considering making a fedora core website. Not an official fedora website but a site that has documents and downloads and such.
If there is anyone out there that can give me the information that I need please email me.
Best Regards,
Joseph Hurst
19 years, 11 months
submount?
by Neal Becker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I discovered submount when testing suse-9.1. First, let me say, that
something like this is really needed for a non-geek desktop linux system.
Users expect that when they insert a CD it will be mounted, and that this
would work "out of the box".
I don't know if submount is the "best" way to make this happen or not,
although I think maybe it is.
I'd like to start a discussion on this topic.
http://submount.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAskNtMDqogpR5tkMRAhVaAJ4n4WhKc5hmxRFiQgd3I6h6Joat4gCdHGVC
A1hPMAS34m3WckdOmq5AdB0=
=a060
-----END PGP SIGNATURE-----
19 years, 11 months
Re: The Fedora Hardware Project
by Chan Min Wai
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Max K-A 提到:
>> How is this hardware Project working? any plane?
>
>
> Hey. I never had a chance to actually *work* on the Fedora Hardware
> Project. If somebody wants to take it over, using that specification,
> that's fine with me. :-)
>
> -Max
I do really hope that I'm capable and possible to help these development
as it is really a obstruction when People asking if what hardware is
supported.
I do actually suggest we do it the simple way, When time go by, let
people rewrite it somehow.
At lease we got something running. (Isn't that nice)
Maybe you think that my idea is too myopia but at least we get something
running and will not stop the people enjoying linux.
My idea is simple.
Just a Web Page with DB that can be short by Brand, Chipset, Disto and
kernel version. And add or a view.
I'm not sure...
Thank You
Chan Min Wai
P.s I don't think that I can help much there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFArje5V0p9slMZLW4RAgroAJ9hsJAJclPFzNFJ5ih2YpFKFg7H8QCggNJh
HmTdxzpgXCp/D0CumPCz/y0=
=iEHn
-----END PGP SIGNATURE-----
19 years, 11 months
