Evolution crash on email search.
by Naoki
Search option set to "This account" immediately crashes the app after
pressing return.
Changed to "This folder", searched, it seemed ok, switched search option
to "This account" and it also crashed. I had it under 'gdb' at the time
but the output was pretty limited in it's usefulness.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912583570672 (LWP 6075)]
0x00002aaaadac5f80 in strlen () from /lib64/libc.so.6
Now I can't even start evo, it just hangs on "CalDAV Eplugin starting up
...", doing a --force-shutdown then "--disable-eplugin=caldav" didn't
help either. Debug output was blank.
Anybody have any tips? I've installed evolution-debuginfo but gdb still
isn't giving me anything useful because there is no output nor return to
prompt after "CalDAV Eplugin starting up ..."..
17 years, 9 months
Re: Fedora's Userfiendliness (was Re: Leaving?)
by seth vidal
On Wed, 2006-08-02 at 12:46 -0400, Sean wrote:
> On Wed, 02 Aug 2006 18:10:04 +0200
> Chris Chabot <chabotc(a)xs4all.nl> wrote:
>
> > An interesting editorial on this topic, that might sum up some of the
> > feelings that some people have been feeling:
> >
> > http://www.freesoftwaremagazine.com/articles/editorial_13
> >
> > Slashdot discussion on this:
> > http://linux.slashdot.org/article.pl?sid=06/08/02/0238233
> > Digg discussion:
> > http://digg.com/linux_unix/Why_Red_Hat_will_go_bust_because_of_Ubuntu
> >
> > All of this isn't necessarily to be taken as gospel, however it does
> > illustrate well the point some of 'us' have been trying to make .. lets
> > not forget about the users! :-)
>
> Agreed, let us not forget about the open source users. Let's not let the
> people who want to use binary-only proprietary extension spoil the
> distribution for those that don't. On top of which, the first article
> you cite seems to indicate that the niche you're worried about is
> already nicely filled by Ubuntu. There doesn't seem to be much
> reason for Fedora to become just another Ubuntu.
I know I'm not the typical user - but I got involved with fedora and
with linux in general b/c of open source.
I don't want to work on a distribution that isn't sticking to those
ideals.
The only two distros I can think of that follow that extremely closely
are fedora and debian.
ubuntu is definitely not one of them.
Thank you for making this point.
-sv
17 years, 9 months
sbin/weak-modules
by Erwin Rol
What does the following mean ?
Updating : selinux-policy-targeted ##################### [ 78/234]
Installing: kernel-PAE ##################### [ 79/234]
**** weak-modules did not process this kernel ****
weak-updates links not updated for 2.6.17-1.2488.fc6PAE
Please run /sbin/weak-modules --add-kernel `uname -r`
in order to update kernel module compatibility links.
Removing : nscd ##################### [ 80/234]
17 years, 9 months
Re: [Linux-ATM-General] OAM not support [SOLVED]
by Dario Lesca
Il giorno lun, 24/07/2006 alle 17.05 +0200, Sk3 Sk3 ha scritto:
> Dario Lesca escribió:
> Make this changes on usbatm.c likes this:
> http://zyxel630-11.cvs.sourceforge.net/zyxel630-11/amedyn2/module/usbatm....
>
> The patch are from Roman Kagan
>
> http://sourceforge.net/mailarchive/message.php?msg_id=11987440
Ok. now my ADSL Telecom(italy) work great with this patch !
I have use the last version of cxacru.c and usbatm.c modules, take from
last FC4 official kernel, I have arranged the zyxel patch and I have
produced this structure (see attach):
> usbatm-oam-support/
> usbatm-oam-support/usbatm.c
> usbatm-oam-support/usbatm.h
> usbatm-oam-support/Makefile
> usbatm-oam-support/cxacru.c
> usbatm-oam-support/usbatm.c.orig
> usbatm-oam-support/usbatm.h.orig
> usbatm-oam-support/usbatm-oam-support.patch
The OAM feature it is necessary with some ADSL therefore would be useful
that this patch comes introduced in ATM support of the kernel... or not?
How I can make this demand?
Where I must send the patch (of Roman Kagan) in order to demand to
insert it in the kernel?
Or I must always patch the standard kernel modules?
To this purpose, there is a method for automate the rebuild only the
driver after a standard update of the kernel (yum update kernel) without
patch and rebuild the kernel-src rpm?
Many thanks, and sorry, I am not a driver developer :-(
--
Dario Lesca <d.lesca(a)solinos.it>
17 years, 9 months
Re: Maintainer for nvidia-crap in lvn wanted (Re: Pull off AIGLX repoistory?)
by Horst H. von Brand
Arjan van de Ven <arjan(a)fenrus.demon.nl> wrote:
> On Sun, 2006-07-30 at 15:50 +0200, Denis Leroy wrote:
> > Peter Gordon wrote:
> > > Christian Fredrik Kalager Schaller wrote:
> > >
> > >> The Nvidia drivers (or ATI ones) are not 'illegal'. The slides you point
> > >> to doesn't even claim they are. [...]
> > >
> > >
> > > No disrespect intended, but did you even read those slides? The 13th
> > > slide that Greg KH has on his site explicitly states - in big bold red
> > > lettering: "Closed source Linux kernel modules are illegal."
> >
> > The problem is obviously that it's not up to him to decide.
> I think you're mistaken there. Since Greg is one of the authors of the
> kernel, to a large degree it IS up to him to decide under what terms
> people get to use the parts of the kernel he wrote. Now Greg is a nice
> guy and he makes them available under a restricted but open license
> (generally called "GPL version 2"), but still.
The point is that the kernel is available under GPLv2, and /that/ decides
what is (or isn't) allowed. Sure, any reasonable judge will take into
(some) account the wishes of the author(s) (in general, owners of the
relevant copyrights) where the license isn't crystal clear, but what those
areas are (and what the law/the judge says about them) isn't Greg's call.
The nVidia (et al) folks certainly did look into the matter, and I'd bet
their lawyers told them there was no (or just a very tiny) chance for them
doing wrong before they went ahead, so I'd guess Greg is mistaken. Also
remember that the code was written by a collection of thousands, it isn't
easy to ask all them (and then weigh their opinions according to some
"importance of contribution" measure...).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
17 years, 9 months
Re: Latest libtheora
by David Nielsen
tir, 01 08 2006 kl. 09:55 -0400, skrev Jason Apfelbeck:
> Any chance of getting this in to FC devel before the next test
> release.
>
>
>
> Jason
>
>
> On Mon, 2006-07-10 at 11:36 +0200, Matthias Saou wrote:
> > Hi,
> >
> > The latest libtheora (alpha7), now includes all the MMX optimisations
> > that were only available previously in the special MMX version of
> > alpha5 (which only worked on x86 AFAIK). So now it should also works
> > much faster on x86_64!
> >
> > FC devel is still at alpha5, so if anyone feels like bumping it to
> > alpha7 it would be great. I've already updated many FC5 systems I have,
> > encoding streams 24/7, and all works fine. I was using the MMX version
> > already, but still managed to see a 4% drop in CPU usage.
> >
> > The update is a no-brainer as the package contains zero patches...
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168773
> >
> > Matthias
Seeing as Theora and Vorbis are basically the only codec support we ship
it would be nice if they were at least up to date to give the best
possible impression of free codecs in Fedora.
- David Nielsen
17 years, 9 months
Latest libtheora
by Matthias Saou
Hi,
The latest libtheora (alpha7), now includes all the MMX optimisations
that were only available previously in the special MMX version of
alpha5 (which only worked on x86 AFAIK). So now it should also works
much faster on x86_64!
FC devel is still at alpha5, so if anyone feels like bumping it to
alpha7 it would be great. I've already updated many FC5 systems I have,
encoding streams 24/7, and all works fine. I was using the MMX version
already, but still managed to see a 4% drop in CPU usage.
The update is a no-brainer as the package contains zero patches...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168773
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2356.fc6
Load : 0.24 0.42 0.32
17 years, 9 months
