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:
path/{core,extra,testing,...}/os/{i686,x86_64}/lastsync
each containing a unix timestamp.
note: no lastsyncfile
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)
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
2009/12/7 Allan McRae al...@archlinux.org
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.
On 12/07/2009 01:26 PM, Abdourazak Osmanov wrote:
2009/12/7 Allan McRaeal...@archlinux.org
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
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?
2009/12/7 大熊 bearspr...@gmail.com:
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?
--
不是所有的特仑苏都是牛奶
On Sun, Dec 6, 2009 at 7:12 AM, Allan McRae al...@archlinux.org wrote:
Roman Kyrylych wrote:
On Sat, Dec 5, 2009 at 18:29, Emmanuel Benisty benist...@gmail.com
wrote:
On Sat, Dec 5, 2009 at 11:24 PM, Thomas Bächler tho...@archlinux.org
wrote:
What's your chipset? Allan's chipset? No such
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
So, any news on this?
I 'fixed' it by removing radeon from initramfs, but as has been pointed
out, thats not really a solution!?
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.bin,
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. Rename
On Mon, Dec 7, 2009 at 12:55 PM, Christos Nouskas n...@archlinux.us 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
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.
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 what's going on ...
On Mon, Dec 7, 2009 at 08:42, Emmanuel Benisty benist...@gmail.com 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
Daenyth Blank schrieb:
On Mon, Dec 7, 2009 at 08:42, Emmanuel Benisty benist...@gmail.com 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
On Mon, Dec 7, 2009 at 17:01, Thomas Bächler tho...@archlinux.org wrote:
This is on the intel-gfx list and has been replied to by one of the devs.
Sweet :D
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
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.
No, this isn't
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
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.
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 to
On Tue, Dec 8, 2009 at 5:02 AM, Daenyth Blank daenyth+a...@gmail.com wrote:
On Mon, Dec 7, 2009 at 17:01, Thomas Bächler tho...@archlinux.org 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
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 insert_your_fav_app but ones
like xorg-server?
In the preceding conversations some have said
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 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
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,
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 proper
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 klib
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
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
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
33 matches
Mail list logo