Am Dienstag 08 Dezember 2009 08:41:15 schrieb David C. Rankin:
> Anybody else seeing a slow down in kmail?
Well the initial access to a folder (after kmail install) takes a few seconds,
but after that it's usually fast.
I just counted and I have about 51k mails.
You should note that this also r
Guys,
Quick request for confirmation. I generally have used tbird in the past but
when doing the kde4.3beta tests, I resolved to use kmail and I have pretty much
stuck with it since May. The issue I am seeing is a slowdown in kmail that I
guess is 4.3.4 related.
Specifically I see a slowdown w
Guys,
Testing xf86-video-ati-6.12.99.git20091207
libdrm-2.4.16-1-x86_64.pkg.tar.gz I noticed that the plasma-panel has lost
transparency in kde4 when compiz is enabled. It's not uncommon for me to need
to restart plasma-desktop to regain transparency, but with these two packages
insta
On Tue, 2009-12-08 at 07:13 +0100, Thomas Bächler wrote:
> Ng Oon-Ee schrieb:
> > Hi all, I've been holding the mkinitcpio package due to
> > http://bugs.archlinux.org/task/15240
> >
> > A quick look into testing shows that I won't be able to update the
> > 2.6.32 kernel due to dependencies on kli
On Thursday 03 December 2009 12:19:58 and regarding:
> On 03/12/09 18:14, Arvid Picciani wrote:
> [...]
> > I'll add some additional points:
> > - it's implementation is large broken.
> how so?
> > - most software depending on it, will crash when dbus
> file bug reports and get developers to write
Ng Oon-Ee schrieb:
Hi all, I've been holding the mkinitcpio package due to
http://bugs.archlinux.org/task/15240
A quick look into testing shows that I won't be able to update the
2.6.32 kernel due to dependencies on klib invalidating my 'old'
mkinitcpio package. Unfortunately I'm stuck here, sin
On Tuesday 01 December 2009 17:34:42 and regarding:
> Did you reboot during this time frame? Perhaps the alsa modules were
> loaded, and when you finally rebooted (on the 20th?), they weren't
> there to be re-loaded.
Oh, yes, sorry for not including that. This is on my laptop so it get booted at
On Monday 07 December 2009 09:05:18 and regarding:
> I'm confirming this as well. Mine fails at radeon/R200_cp.bin, though.
> Loading in rc.conf works alright but the GPU appears to get very hot. I
> have no diode on it but it just tries to burn a hole through my laptop.
> Again, KMS performance is
On Tue, 2009-12-08 at 06:39 +0200, Christos Nouskas wrote:
> Ng Oon-Ee wrote:
> > > I know, but why would anyone in their right mind put some tro^Wguy's
> > > custom repo _before_ the official ones, especially when the provided
> > > packages are not the nightly builds of but ones
> > > like xorg-
Ng Oon-Ee wrote:
> > I know, but why would anyone in their right mind put some tro^Wguy's
> > custom repo _before_ the official ones, especially when the provided
> > packages are not the nightly builds of but ones
> > like xorg-server?
>
> In the preceding conversations some have said they would
On Tue, Dec 8, 2009 at 5:02 AM, Daenyth Blank wrote:
> On Mon, Dec 7, 2009 at 17:01, Thomas Bächler wrote:
>> This is on the intel-gfx list and has been replied to by one of the devs.
>>
>>
>
> Sweet :D
>
actually, the thread is dead silent since my
melt-your-cpu-git-bisecting result but I keep
On Tue, 2009-12-08 at 04:57 +0100, Sven-Hendrik Haase wrote:
> On 08.12.2009 04:54, Ng Oon-Ee wrote:
> > Hi all, I've been holding the mkinitcpio package due to
> > http://bugs.archlinux.org/task/15240
> >
> > A quick look into testing shows that I won't be able to update the
> > 2.6.32 kernel due
On 08.12.2009 04:54, Ng Oon-Ee wrote:
> Hi all, I've been holding the mkinitcpio package due to
> http://bugs.archlinux.org/task/15240
>
> A quick look into testing shows that I won't be able to update the
> 2.6.32 kernel due to dependencies on klib invalidating my 'old'
> mkinitcpio package. Unfor
Hi all, I've been holding the mkinitcpio package due to
http://bugs.archlinux.org/task/15240
A quick look into testing shows that I won't be able to update the
2.6.32 kernel due to dependencies on klib invalidating my 'old'
mkinitcpio package. Unfortunately I'm stuck here, since without this
'old'
On Tue, 2009-12-08 at 05:29 +0200, Christos Nouskas wrote:
> Ray Kohler wrote:
> > > Suggestions:
> > >
> > > 1. Rename all your packages appropriately (e.g. append -heresy or
> > > -nodbus or -whatever). This way your packages won't get unistalled if
> > > they lag behind the official ones.
> >
>
Ray Kohler wrote:
> > Suggestions:
> >
> > 1. Rename all your packages appropriately (e.g. append -heresy or
> > -nodbus or -whatever). This way your packages won't get unistalled if
> > they lag behind the official ones.
>
> No, this isn't how pacman works. If his repo comes before the official
>
Guys,
With a number of arch boxes now, I routinely rsync the package cache from box
to box for updates, etc. Today what started out as a "1-liner" to show what
scripts in /var/cache/pacman/pkg were installed, uninstalled (what I called
orphaned) and then to create summary files and create a scr
On Mon, Dec 7, 2009 at 17:01, Thomas Bächler wrote:
> This is on the intel-gfx list and has been replied to by one of the devs.
>
>
Sweet :D
Daenyth Blank schrieb:
On Mon, Dec 7, 2009 at 08:42, Emmanuel Benisty wrote:
Just FTR, I have bisected the issue and found out this commit was to blame:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154
I've reverted it and reb
On Mon, Dec 7, 2009 at 08:42, Emmanuel Benisty wrote:
> Just FTR, I have bisected the issue and found out this commit was to blame:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154
>
> I've reverted it and rebuilt 2.6.32. Issue
Am Montag 07 Dezember 2009 schrieb Tom K:
> Tom K wrote:
> > Thomas Bächler wrote:
> >> Gabriel Morrison Lima Dantas schrieb:
> >>> Removing radeon from initramfs and putting it in MODULES section of
> >>> rc.conf
> >>> solves the problem.
> >>
> >> Hm, I hope you are happy this way until we know w
Tom K schrieb:
The requirement here is that firmware-dependent modules are loaded after
the udev hook has been run i.e. after udevd starts. A simple solution,
based on the one in the forum thread, would be a hook called e.g.
fwmodules, where modules with this requirement are specified.
Alterna
Tom K wrote:
Thomas Bächler wrote:
Gabriel Morrison Lima Dantas schrieb:
Removing radeon from initramfs and putting it in MODULES section of
rc.conf
solves the problem.
Hm, I hope you are happy this way until we know what's going on ...
the problem is certainly not that the firmware is not
On Mon, Dec 7, 2009 at 12:55 PM, Christos Nouskas wrote:
> Arvid Picciani wrote:
>> http://heresy.asgaartech.com/
>>
>> Let me know if this solution works for everyone
>> and/or if anyone is offended by anything on that
>> site or the fact that it exists
>> and/or if anything should be add
Arvid Picciani wrote:
> http://heresy.asgaartech.com/
>
> Let me know if this solution works for everyone
> and/or if anyone is offended by anything on that
> site or the fact that it exists
> and/or if anything should be added to it.
>
> Contributors very welcome :)
Suggestions:
1. R
On 07.12.2009 05:54, David C. Rankin wrote:
> On Saturday 05 December 2009 08:51:23 and regarding:
>
>> Hi, I installed kernel26 and kernel26-firmware from testing, and I'm
>> experiencing some problems with KMS. During system initialization, the
>> system requests the firmware radeon/R300_cp.bi
So, any news on this?
I 'fixed' it by removing radeon from initramfs, but as has been pointed
out, thats not really a solution!?
Hello All,
I got a new computer and installed arch on it. I have restored my home
directory from other machine, which has lived thr. kde3 -> kde4 transition and
isn't exactly prestine.
This is core2duo machine and the soundcard is 82801G HDA, as reported by
lspci. I don't have pulseaudio insta
On Sun, Dec 6, 2009 at 7:12 AM, Allan McRae wrote:
> Roman Kyrylych wrote:
>>
>> On Sat, Dec 5, 2009 at 18:29, Emmanuel Benisty
>> wrote:
>>>
>>> On Sat, Dec 5, 2009 at 11:24 PM, Thomas Bächler
>>> wrote:
What's your chipset? Allan's chipset? No such issues here on 945GM.
>>>
>>> Integ
2009/12/7 大熊 :
> I need en_US.UTf-8 under console and zn_CN.UTF-8 under X
>
> So rc.conf:
>
> LOCALE="en_US.UTF-8"
>
> and ~/.xprofile:
>
> exprot LANG=zh_CN.UTF-8
sorry for typo :)
export LANG=zh_CN.UTF-8
>
> But after I login, the desktop is still en_US, Why?
>
--
不是所有的特仑苏都是牛奶
I need en_US.UTf-8 under console and zn_CN.UTF-8 under X
So rc.conf:
LOCALE="en_US.UTF-8"
and ~/.xprofile:
exprot LANG=zh_CN.UTF-8
But after I login, the desktop is still en_US, Why?
On 12/07/2009 01:26 PM, Abdourazak Osmanov wrote:
2009/12/7 Allan McRae
Two things:
1) bugs.archlinux.org is the place to file bugs
2) does rebuilding actually fix that issue?
1. Thanks for the info, I forgot about it.
2. Friday Gajim worked normally.
maybe report that upstream.
http://tr
2009/12/7 Allan McRae
> Two things:
> 1) bugs.archlinux.org is the place to file bugs
> 2) does rebuilding actually fix that issue?
>
1. Thanks for the info, I forgot about it.
2. Friday Gajim worked normally.
Abdourazak Osmanov wrote:
Hi!
I refreshed my Arch today, and found that the file ~/.xsession-errors grows
to infinity with messages:
13:45:13 (W) gajim.c.x.transports_nb: calling send on empty buffer and queue
13:45:13 (W) gajim.c.x.transports_nb: calling send on empty buffer and queue
13:45:13
Hi!
I refreshed my Arch today, and found that the file ~/.xsession-errors grows
to infinity with messages:
13:45:13 (W) gajim.c.x.transports_nb: calling send on empty buffer and queue
13:45:13 (W) gajim.c.x.transports_nb: calling send on empty buffer and queue
13:45:13 (W) gajim.c.x.transports_nb
is it just me or did the lastsync format change?
IIRC the lastsync file was 1 file in the root of the repo, with the
date in it in string format.
now the lastsync files are like so:
/{core,extra,testing,...}/os/{i686,x86_64}/lastsync
each containing a unix timestamp.
note: no lastsyncfile for any
36 matches
Mail list logo
