Thunderbird vs Evolution
by Stephen Smoogen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well I know this is probably noise, but I got tired of 20 second lockups
on my laptop while RHEL-3 version of evolution would do various lookups
of folders and such. I decided to try something different and got the
thunderbird from fedora.us and recompiled it (just in case). After
getting my email back on the server, and building all my filters back..
I havent really looked back at evolution. Thunderbird does not have all
the gizmos but it doesnt seem to freeze the entire system with I/O.
Having it look more like firefox also gives a cleaner desktop look. So
if there is ever a debate about which graphical mail client.. I like
thunderbird (and I really really like Enigmail).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBozlNgySQyi8l3URAgVNAJsGqyGZSqluOVknOg1tDrKmMU6XDgCeIDv9
MeZS0vQ17/mgaYpJlpaSi7w=
=1fVd
-----END PGP SIGNATURE-----
19 years, 10 months
Thoughts on managing C++ ABI breaks
by Mike Hearn
Hi guys,
This is a proposal for a way to handle backwards compatibility in the
face of continuing C++ compiler ABI breaks. Rationale:
- The GCC team have an explicit policy of preferring standards compliance
to ABI stability. I think there is no 100% perfect test suite for this
standard, and even if there was, it's unlikely that such a complicated
document is never open to interpretation. Likewise the C++ spec itself
evolves with time.
Consequently, it's possible (probable?) that we will be dealing with ABI
breaks into the medium term future. These need to be managed.
- It is desireable to have binary compatibility and to manage interface
breaks. This is what ELF soname versioning is all about, but in the face
of compiler breaks as opposed to library breaks, soname versioning is not
enough. A library libqt.so.3 compiled with one compiler may not export the
same interface as libqt.so.3 compiled with another, yet the user may wish
to run binaries compiled with the gcc 3.3 ABI on a 3.4 compiled system.
One of my assumptions is that the C++ standard library is parallel
installable and has a different soname for each ABI. From what I've read
about g++ ABI policy this assumption seems to be correct, please let me
know if it is not.
The proposal is to modify the dynamic linker so that when a
library which depends on a symbol version of CXXABI_X.Y is loaded, each
element in the library search path is tested once with $dirname/cxxabi-X.Y
and once with $dirname. So, if you have a version of Qt compiled with abi
1.2 (gcc 3.2,3.3), that can be placed in /usr/lib/cxxabi-1.2/libqt.so.3
and then the version compiled with the "native" ABI can be placed in
/usr/lib as per normal.
A similar technique has been used before with the LD_ASSUME_KERNEL
environment variable switching between /lib, /lib/i686, /lib/tls and so
on. This mechanism would be similar, except triggered by the CXXABI symbol
version rather than an environment variable.
This allows C++ binaries built for older versions of the system to operate
correctly on newer systems when the right compat-* packages are installed.
I propose this here as there are a good set of distro, glibc
and gcc developers working for Red Hat, so it seemed like a good place to
find people to shoot it down :)
What are peoples thoughts on this mechanism? Using CXXABI_ is somewhat
inelegant but this has the advantage that it works with the toolchains
already deployed.
thanks -mike
19 years, 10 months
Problem with HPT370/372 and kernel 2.6.6-1.435.2.3
by ra993482＠ic.unicamp.br
Hi,
I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid
controller. The problem is that booting kernel 2.6.6-1.435.2.3 always
ends up with an oops in init_setup_hpt366().
CPU: 0
EIP: 0060:[<0232d6eb>] Not tainted
EFLAGS: 00010246 (2.6.6-1.435.2.3)
EIP is at init_setup_hpt366+0x61/0x139
eax: 00000006 ebx: 21e52800 ecx: 01040006 edx: 21f06f6c
esi: 00000000 edi: 022a7cab ebp: 022e0b00 esp: 21f06f84
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=21f06000 task=21ebf630)
Stack: 00000000 000000d0 00000006 022a7cab 022a7cab 022a8021 022a8028
022a802f
022a8037 00000000 00000000 022e0ce0 21e52800 00000000 00000000
021ec295
0232fe52 21e52800 00000000 0232fe8f 0233bcf4 0232fdc1 0232fe0f
0231c576
Call Trace:
[<021ec295>] hpt366_init_one+0xf/0x12
[<0232fe52>] ide_scan_pcidev+0x31/0x54
[<0232fe8f>] ide_scan_pcibus+0x1a/0x85
[<0232fdc1>] probe_for_hwifs+0xa/0x14
[<0232fe0f>] ide_init+0x44/0x56
[<0231c576>] do_initcalls+0x49/0x97
[<0210037d>] init+0x0/0xe7
[<021003a4>] init+0x27/0xe7
[<021041d9>] kernel_thread_helper+0x5/0xb
Code: ac aa 84 c0 75 fa 8b 44 24 08 83 e8 03 83 f8 02 0f 86 b1 00
I can boot with kernel 2.6.5-1.358, but the file /proc/ide/hpt366 shows
garbage in the place of the chipset and the output of the hpt366
initialization code in dmesg is all messed up. I've already booted with
'pci=noacpi', 'noapic' and 'acpi=off', but had the same results with
both kernels. Any ideas?
Regards,
-- Ulisses
19 years, 10 months
open office
by John Mizell
Where can I find the equivalent to
OpenOffice1.2.0/share/uno_packages? I want to install
the postgresql-sdbc-driver. Did the openoffice get
slit out to different directories? Are different
database connection drives going to be considered for
inclusion.
Thanx,
John Mizell
19 years, 10 months
Schedule change proposal
by Bill Nottingham
Strawman proposal: move the schedule out one week.
This moves all the dates starting with the 25 Aug freeze
for test 2.
Opinions?
Bill
19 years, 10 months
The gnome MIME mess
by Denis Leroy
I would like to know what is currently the "official" way for a
packager to add new MIME types and the correct corresponding
application bindings to Gnome in general, and Nautilus in particular. I
thought it was just a matter of dropping the right foo.keys and
foo.mime files into /usr/share/mime-info, but it turns out this has
pretty much zero effect on anything. Instead one has to edit the
somewhat obscure /usr/share/mime/packages/freedesktop.org.xml file and
call the update-mime-database command.
I understand this is being worked on in the next version of Gnome, but
for the time being, how is one supposed to do this from an RPM spec
file ?
-denis
http://cdrdao.sf.net/
http://www.poolshark.org/
19 years, 10 months
openoffice 1.1.2 requires KDE (and a bunch more)
by Pete Zaitcev
[root@lembas o]# rpm -U openoffice.org-1.1.2-1.i386.rpm openoffice.org-libs-1.1.2-1.i386.rpm openoffice.org-i18n-1.1.2-1.i386.rpm
error: Failed dependencies:
libkdeui.so.4 is needed by openoffice.org-1.1.2-1
libebook.so.8 is needed by openoffice.org-libs-1.1.2-1
libedataserver.so.3 is needed by openoffice.org-libs-1.1.2-1
[root@lembas o]#
Why is it needed? Just curious.
The primary reason I'm asking is that I'm afraid to install kdelibs
from Rawhide. They require new libstdc++, which might not be terribly
compatible with my FC2 system.
-- Pete
19 years, 10 months
way bigger NR_GROUPS
by Florian La Roche
People should be aware of a way bigger NR_GROUPS for a current
kernel if compiled against a current glibc-kernheaders.
greetings,
Florian La Roche
* Fri Jul 30 2004 Arjan van de Ven <arjanv(a)redhat.com>
- update limits.h to reflect NR_GROUPS change
19 years, 10 months
Open Office Bug, quick fix
by Trever L. Adams
There is a bug in the latest OO packages. In /usr/lib/ooo-
1.1/program/setup lines 158 and 160, I believe, are commented out. This
makes the script barf because there is nothing between then and else and
else and fi. Removing the comments seems to work just fine. So why not
file a bug? Because it is too simple of a fix.
Trever
--
If it's there and you can see it, it's REAL If it's there and you can't
see it, it's TRANSPARENT If it's not there and you can see it, it's
VIRTUAL If it's not there and you can't see it, it's GONE! -- Unknown
19 years, 10 months
Re: i686 build of Fedora Core
by Pete Zaitcev
On Wed, 28 Jul 2004 15:08:16 -0500
David T Farning <dfarning(a)sbcglobal.net> wrote:
> > >So they run on i386 and are .i386.rpm but i686 optimised. The packages in
> > >.i686 form are packages containing functionality that won't run on i386
> > >and are carefully chosen because it matters in those packages alone that
> > >i686 instructions can be used.
> > >
> > Sure, but what can do optimization without using the *hardcoded* cpu
> > instructions inserted in the architecture ?
> >
> > BTW when i've some spare time, i'll try compiling an optimized version
> > of some meaningful packages and will post here the results.
> Isn't arguing with Alan Cox about kernel hacking like []
We are not arguing the kernel here, mind. It's the userland which is
built without additional instructions.
Let's see if Angelo comes with actual numbers. Various people did
benchmarks before, and it appears that the speedup is very hard to
discern among the noise. Basically, using different DIMMs gives you
more variation... But I would not be surprised if he finds an application
which does see a benefit.
-- Pete
19 years, 10 months
