- Arch-general - lists.archlinux.org

[arch-general] [signoff] madwifi/madwifi-utils 0.9.4.3382
by Tobias Powalowski 13 Mar '08

13 Mar '08

Hi bump of madwifi drivers, back to trunk version please signoff both arches also users can signoff, no respond from any dev greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-general] udev-118-5 udev.rules.pacsave
by Neil Darlow 13 Mar '08

13 Mar '08

Hi, Is it safe to delete /etc/udev/rules.d/udev.rules.pacsave following the update? Regards, Neil Darlow

2 1

[arch-general] [signoff] madwifi/madwifi-utils 0.9.4
by Tobias Powalowski 13 Mar '08

13 Mar '08

Hi small bump of madwifi drivers please signoff both arches also users can signoff, no respond from any dev greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-general] Dangerous dbus update for testing
by Jan de Groot 12 Mar '08

12 Mar '08

There's a dangerous dbus update coming up for the testing repository. The package itself isn't so special, as it works fine, but the fact that every dbus-daemon process on your system will crash during the upgrade can lead to unpleasant surprises. Testing users: please be aware of this and run your upcoming upgrades from a plain text console instead of from X. One of the unpleasant surprises is that xorg-server in testing goes down with dbus while it's upgrading, leading to loss of important work or an interrupted package upgrade process.

1 0

Re: [arch-general] [arch-dev-public] ISO 2008.03 release status update
by Grigorios Bouzakis 12 Mar '08

12 Mar '08

On Wed, Mar 12, 2008 at 08:10:22PM +0100, Tobias Powalowski wrote: > Hey guys keep cool, > following packages i would like to see in core: > > pending signoffs and move to base: > pmciautils, just a small udev.rules fix waiting for signoff. > cryptsetup -->waiting on response > > klibc > klibc-extras > klibc-module-init-tools > --> seems to be solid and movable, would you move in Thomas? > > vi > --> seems to be signed off, could Eric or Tobias this move in or should i move > it? > > klibc-udev? > the one from testing works fine, we can use this 116-3 > instead of 118 which is not buildable here. > --> move in klibc-udev-116-3, would you move in Thomas? > > initscripts? > bump to 2008.03 with the last changes from git > aaron and roman will add the final changes and then release a new version. > > mkinitcpio? > do we need a new version to get init= syntax back? > if yes we could fix this bug also: > http://bugs.archlinux.org/task/9433 > --> Aaron said doesn't seem to be an issue > problem because of missing /dev/mem? > http://bugs.archlinux.org/task/9813 > Thomas is this a showstopper? > > pending signoffs and move to support: > rp-pppoe --> waiting for response > tiacx --> will go to core now > tiacx-firmware --> will go to core now > > wpasupplicant? > Thomas movable? > > fuse? > Thomas is there an issue atm? > movable? > > kbd? > Roman wanted to add some changes and additions to it, > this is not critical we could live with the old version too. > Roman just tell me, if we should wait for your work or not. > > madwifi/madwifi-utils? > I don't have the hardware and cannot test it at all. > I am so undecided, Andy has issues with both the one in core and the one from > testing. > Varun reported this bug on his macbook: > http://bugs.archlinux.org/task/9802 > Others have no issues and gave signoff on general ml. > We could move in the so called stable version or leave it with the snapshot we > already have in core.(I hate buggy modules:( ) > > delayed package moves due to rebuilds and issues: > gcc > build-toolchain > libtool > perl > > any other comments? > > greetings > tpowa May i add xorg-server to the above packages too? I know its not part of core, let alone base, but its a very important package in extra. Current xorg-server in testing comes with HAL enabled. Reference: http://bugs.archlinux.org/task/9563 Is that gonna be the default now? Users probably havent reported back on this, but many had problems with it. On the other hand others didnt. Its already a month in testing, but no decision has been made up yet. Should this be reviewed later? What do devs think about this change? Greg

3 2

[arch-general] [OT] i'm giving away textbooks
by Petar Bogdanovic 12 Mar '08

12 Mar '08

Hi, I'm aware of this being off-topic but since no profit is going to be made, I dare to post the [1]offer here. The books are in excellent condition and shape. You only have to accept the shipping [2]costs. Thanks, Petar [1] http://smokva.net/lib/ [2] The books are in Switzerland, Europe.

2 1

[arch-general] xf86-video-i810 obsolete?
by David Rosenstrauch 11 Mar '08

11 Mar '08

After tracking down an issue I was having, I finally realized the cause was that I was using an outdated version of my X video driver. It looks like xf86-video-i810 (unbeknownst to me) has been renamed to xf86-video-intel, and that new development is continuing there. If that's the case, then shouldn't we decommission the xf86-video-i810 package? Is there any reason to keep it around? DR

6 5

[arch-general] [signoff] tiacx tiacx-firmware
by Tobias Powalowski 11 Mar '08

11 Mar '08

Hi new package for core repository please signoff both arches also users can signoff greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] [signoff] udev 118-4
by Michal Soltys 10 Mar '08

10 Mar '08

You can block frambuffer in udev, but you have to block the driver by its modalias or other attributes (similary as if you tried to block sound through udev). For example, following rule would do the thing in my case, on one of my machines (that has some old ati card): SUBSYSTEM=="pci", ATTR{vendor}=="0x1002", ATTR{device}=="0x5446", OPTIONS="ignore_device" Or you could just use modalias. For example - provide auto generated 03-fb-block.rules by PKGBUILD in form similar to: ACTION!="add", GOTO="fb_block_end" DRIVER=="?*", GOTO="fb_block_end" ENV{MODALIAS}!="?*", GOTO="fb_block_end" ENV{MODALIAS}=="modaliases #1", OPTION="ignore_device" ENV{MODALIAS}=="modaliases #2", OPTION="ignore_device" ..... LABEL="fb_block_end" This should be blazing fast, without any need for extra logic in module loading scripts you call from udev. Moreover - if users don't want it - they can simply mv or rm that file. However you name the file, make sure it's parsed before big compound udev.rules you use. Btw - is there any reason why fbcon is built into kernel, instead of being left as a module (also, fbcon never loads automatically) ? Consoles are not taken until fbcon is activated - so maybe it would solve the issue with binary blobs having problems with active framebuffer driver. Just a thought (although as per fbcon documentation, depending on how well the framebuffer driver is written, consoles might end with garbaged screen w/o fbcon ; they shouldn't though). cheers Michal

3 4

[arch-general] compiz-fusion with gnome
by Verner Jänes 10 Mar '08

10 Mar '08

Hi. I installed compiz-fusion to my gnome desktop and now I have two problems with it. First: no shadows around windows or panels (tweaked the window manager section under compiz control panel, but it didn't work). Secondly, the performance is very bad although games (e.g. urban terror) run fairly good. Also it seems that there is no option to use metacity styles (under ubuntu you can still use the same themes if I'm not mistaken). Just to mention, few days ago I had problems with compositing and openGL (I wrote a letter to the mailinglist), but after reinstalling and using nvidia-xconfig --composite option (no --add-argb-visuals any more on newer nvidia cards), the problem got fixed. So anyone having the same problem or know how to help, please let me know. Verner

3 4