Re: [arch-general] A little weirdness at boot time
Heiko Baums wrote: But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time. Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa. Here is my /etc/conf.d/lircd - maybe it helps in your case too (: ## Configuration for Technisat USB remote TTS35AI LIRC_DRIVER="devinput" ## Using dev/input device by name (description) ## because event device node my change. ## To get the 'name' for your USB device ## look at dmesg|tail after pluging it in for a line like: ## input: USB IR Receiver USB IR Receiver as ## /devices/pci:00/:00:10.0/usb1/1-2/1-2:1.0/input/input8 ## or use cat /proc/bus/input/devices ## Make shure you have -d "$LIRC_DEVICE" (with quotes !) in your ## init script because of blanks! LIRC_DEVICE="name=USB IR Receiver USB IR Receiver" LIRC_EXTRAOPTS="" LIRC_CONFIGFILE=""
Re: [arch-general] since the fglrx legacy driver is now static - any will to make a run at getting it to work?
David C. Rankin schrieb: Now with the driver static, I wonder if it might not be worth looking into to see if it is even feasable to try and make it work with the current arch setup. That doesn't change anything. The driver is incompatible with the current Xorg ABI - and if it isn't, be sure it'll be incompatible with the next version for at least half a year. It is also incompatible with the latest kernel - if not, it will be with the next version. ATI completely fails to keep up with Xorg and kernel development and simply sticks to what Ubuntu releases. Nobody in the Arch team will put that kind of effort in a piece of binary-blob software whose upstream maintainer doesn't even care. signature.asc Description: OpenPGP digital signature
Re: [arch-general] An evil idea --- use Git to manage the repositories
On Wed, Sep 2, 2009 at 10:35 AM, wrote: > Is it possible? > > advantage: > 1 The mirrors do not need download the total new pkgs if it just > updated several files. > 2 old versions of package can be retrived. > 3 GIT is fast. > 4 It seems cool! > > dis-advantage: > 1 It is a torture of GIT > 2 Huge of works to be done. > Without mentioning that any scm would probably explode handling such big amount of binary files, did this idea only concern the mirror synchronization part ? who would choose to retrieve an older version of a package ? and how would you do that ? (anyway the first point makes any discussion worthless).
Re: [arch-general] An evil idea --- use Git to manage the repositories
goodme...@gmail.com schrieb: Is it possible? advantage: 1 The mirrors do not need download the total new pkgs if it just updated several files. 2 old versions of package can be retrived. 3 GIT is fast. 4 It seems cool! dis-advantage: 1 It is a torture of GIT 2 Huge of works to be done. I don't think git is suitable for maintaining large amounts of binary files. The diffs probably won't be very efficient, so storage size will explode. And - all mirrors use rsync (they also mirror other stuff besides Arch), we can't just tell them all to do it differently. signature.asc Description: OpenPGP digital signature
Re: [arch-general] since the fglrx legacy driver is now static - any will to make a run at getting it to work?
On Wed, Sep 2, 2009 at 01:22, Rogutės Sparnuotos wrote: >> Now with the driver static, I wonder if it might not be worth looking >> into to >> see if it is even feasable to try and make it work with the current arch >> setup. ( I know I'm not smart enough in this area to be of any use. ) The >> reason I bring this up I running arch on one drive I have for my laptop, and >> I'm limited to the radeonhd driver. It's getting better, but it has two >> achiles heels: (1) performance, and (2) heat (lots of it). Ultimately, the >> radeonhd driver will crack the black box and have a great driver, but >> currently, the combination of the issues is bad enough, I keep an old copy of >> suse 11 on another driver for use in my laptop, for no other reason than it >> has the working fglrx driver and I can work with my laptop without the fan >> noise and heat under my left palm caused by the lack of >> downclocking/powerdown >> of the unused gpu circuitry experienced with the radeonhd driver. > > Even if catalyst-9.3 would work with the newly proposed kernel26-lts, it > wouldn't work with xorg-server-1.6, and there's no source code for that > part of the driver. The only way to use the driver would be to downgrade > to xorg-server-1.5 (along with its dependencies, of which there might be > a handful). kernel26-lts is not supposed to work for any external modules, so this is not relevant here at all. -- Roman Kyrylych (Роман Кирилич)
Re: [arch-general] Howto adjust font scaling in Arch? All fonts look a bit big and fat?
On Wednesday 26 August 2009 07:40:15 am Nicolas Bigaouette wrote: > Just append "-X" to your ssh command for X forwarding. You can add "-C" for > compression too. > Now isn't that the coolest thing since sliced bread -- thanks. I can't believe I've nearly mastered vim over the past 10 years when all I really needed to do was ssh "-X" hostname and then type "kwrite". Think of all the empty space and all those uncluttered brain cells I would still have available for something else today ;-) Live and learn... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] An evil idea --- use Git to manage the repositories
On Wed, 2 Sep 2009 16:35:12 +0800 goodme...@gmail.com wrote: > Is it possible? > > advantage: >1 The mirrors do not need download the total new pkgs if it just > updated several files. rsync does this too >2 old versions of package can be retrived. YAGNI >3 GIT is fast. rsync is too >4 It seems cool! rsync is more suited for the job > > dis-advantage: >1 It is a torture of GIT >2 Huge of works to be done. I think a big improvemt will be when we fix it so that if we move packages from testing to extra/core, mirrors will not see as a "file remove and a new file", which causes a lot of unneeded traffic. if we make this system use symlinks or whatever this can be handled much better. but other then that, I think the current syncing system is fine. (the "getting" part is something different. see tiered setup,mirrorbrain etc. discussions) Dieter
[arch-general] An evil idea --- use Git to manage the repositories
Is it possible? advantage: 1 The mirrors do not need download the total new pkgs if it just updated several files. 2 old versions of package can be retrived. 3 GIT is fast. 4 It seems cool! dis-advantage: 1 It is a torture of GIT 2 Huge of works to be done.
