- Arch-general - lists.archlinux.org

[arch-general] xorg-server 1.6.0 in testing
by Jan de Groot 06 Mar '09

06 Mar '09

The upcoming version of xorg-server will have a lot of workarounds and patches removed. Doing so, the package becomes easier to understand, as even its maintainer has no idea what is happening anymore. When upgrading to xorg-server-1.6, you will see these file conflicts on most systems: error: failed to prepare transaction (conflicting files) xorg-server: /usr/lib/xorg/modules/extensions/libdri.so exists in filesystem xorg-server: /usr/lib/xorg/modules/libwfb.so exists in filesystem It's safe and advised to overwrite these files. The symlinks were previously created from post_install by the xorg-server and nvidia-utils packages. It is advised to install xorg-server first by using "pacman -Sf xorg-server", after which you can upgrade the rest of your system. This release of xorg-server requires a rebuild of all video and input drivers. Older drivers will fail to load with an ABI mismatch. Drivers in our repositories will receive an update to match the xorg-server ABI. Nvidia has updated their latest drivers with support for this version of xorg-server. AMD does not support xorg-server-1.6 yet in their Catalyst drivers. AMD users are advised to switch to the xf86-video-ati or xf86-video-radeonhd drivers instead, or keep any X.Org related updates on hold via IgnorePkg in pacman.conf. This can be done by putting xorg-server in IgnorePkg in pacman.conf. All other updates should have conflicts set, so it will be clear which additional packages should be added to the IgnorePkg list on your system. Note that there will be no support for older versions of xorg-server when this version moves to extra.

10 19

Re: [arch-general] [arch-announce] Newsletter for March, 2009
by Aaron Griffin 06 Mar '09

06 Mar '09

On Thu, Mar 5, 2009 at 9:54 PM, BinkyTheClown <binky(a)archlinux.us> wrote: > 2009/3/5 Recent News Updates <announce(a)archlinux.org> > >> The Arch Linux Newsletter team is proud to announce the <a href=" >> http://www.archlinux.org/static/newsletters/newsletter-2009-mar.html">Newsletter >> for February 2009</a>. To discuss this newsletter, <a href=" >> http://bbs.archlinux.org/viewtopic.php?id=510237">click here</a>. To read >> past issues of the Arch Linux Newsletter, <a href=" >> http://www.archlinux.org/static/newsletters/">here they are</a>. >> >> URL: http://www.archlinux.org/news/437/ >> _______________________________________________ >> arch-announce mailing list >> arch-announce(a)archlinux.org >> http://www.archlinux.org/mailman/listinfo/arch-announce >> > Am I the only one that is receiving ugly html tags in the newsletter? Moving to the arch-general list. No, you are not. The front-page news contains HTML tags, but rss2email doesn't seem to strip them out. I'm open to ideas as to how to fix this.

3 3

[arch-general] Nouveau sources not on the ftp
by Chris Bannister 06 Mar '09

06 Mar '09

Hi, im trying to rebuild nouveau for zen kernel but the source isnt on the FTP [1], does anyone have it? Or shall i just build from git. Thanks, Chris [1] ftp://archlinux.org/other/nouveau-drm/mesa-drm-20090303.tar.bz2

2 2

[arch-general] weird thing with X and nvidia driver
by Eric Wong 06 Mar '09

06 Mar '09

Hi, I run Arch linux with KDE 4.2 on a machine with a Geforce 6200 LE card. But recently I have been experiencing some weird things. At the begining I was running KDE 4.2.0 with a nvidia-180.22 driver and the X process consumes lots of memory graduately, even to 200+ MB some times. Then I updated to KDE4.2.1 and the problem disappeared. But today, after I update the video driver to nvidia-180.29 it is here again. I have no idea which component cause it. KDE, nvidia dirver or xorg? Another weird thing is with the nvidia driver. Before updating to 188.29, glxgear had about 1060 FPS. After update and I restarted the KDE. Then glxgear told me the nvidia api dismatch, that is, the kernel module is still 180.22 but other parts of the driver is 180.29, and it has 1300+ FPS, then I remove the old module and modprobe the new one so it runs 180.29 now, but it is 1060FPS again. There's no improvement over 180.22! What's the problem?

1 0

[arch-general] smtp daemon
by Baho Utot 04 Mar '09

04 Mar '09

I need a small smtp daemon for use as an MTA to move mail from a desktop to a mail server I could use sendmail or something like it but I am looking for something smaller. Any suggestions?

6 11

[arch-general] Problems with Acer Aspire One and Arch installer
by Henri Häkkinen 04 Mar '09

04 Mar '09

Hello I'm having some troubles with installing Arch on my Acer Aspire One (this is the version with Linpus Linux). I have downloaded the installer FTP-USB image from the web site and copied the image to my 256 MB USB stick as usual with dd. However, when I try to boot my AA1 machine from it, it halts to the place where it gives "GRUB loading, please wait..." and nothing shows up. Any ideas? Thanks. -- Henri Häkkinen

2 1

Re: [arch-general] Keyboad in KDE locks up
by Jan de Groot 04 Mar '09

04 Mar '09

On Wed, 2009-03-04 at 07:21 +0100, Dan Vratil wrote: > Hi, > this happens to me sometimes too. I found out, that I just have to > switch > to console, restart HAL daemon and it works again, so I'd say it could > be > problem in Xserver, but I'm really not sure about it. > > Dan Could be a problem with the evdev driver that freaks out on your keyboard. Restarting hal generates a load of new hotplug events for Xorg, so your keyboard gets removed from Xorg and hotplugged again, after which it is reinitialized. Is the keyboard you use PS2 or USB?

3 3

[arch-general] xf86-video-nouveau/nouveau-drm in testing
by Andreas Radke 03 Mar '09

03 Mar '09

I've added xf86-video-nouveau + nouveau-drm to testing. Together with Xorg 7.5 this is a nice replacement for the binary crap when you don't need 3D stuff. 2D works well accelerated. 3D will follow later with gallium 3d. For more read: http://nouveau.freedesktop.org/wiki/ I run a DualHead setup on my desktop. This is my full xorg.conf for example: # the right one Section "Monitor" Identifier "NEC" Option "PreferredMode" "1280x1024_60.00" EndSection # the left one Section "Monitor" Identifier "FUS" Option "PreferredMode" "1280x1024_60.00" Option "LeftOf" "NEC" EndSection Section "Device" Identifier "nvidia card" BoardName "nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] rev 161" Driver "nouveau" Option "Monitor-DVI-I-0" "NEC" Option "Monitor-DVI-I-1" "FUS" EndSection Section "Screen" Identifier "screen1" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 2560 1024 EndSubSection Device "nvidia card" EndSection Section "ServerLayout" Identifier "layout1" Screen "screen1" # will be replaced by gallium 3D Option "AIGLX" "false" EndSection Have fun getting rid off nvidia binary blobs. -Andy

1 0

Re: [arch-general] [arch-dev-public] mailman hiccup
by RedShift 03 Mar '09

03 Mar '09

Geoffroy Carrier wrote: > On Tue, Jan 20, 2009 at 09:10, RedShift <redshift(a)pandora.be> wrote: >> I've been working on my own mailing list manager, it's completely written in >> PHP and uses SQL as a backend, but at this point a bit specific to our >> setup. Because our company is all about open source I intend on releasing it >> as such. It's in need of an overhaul anyway, I'll get hacking at it again >> ASAP. > > I'd love to be an early adopter :) > > Plus I'd be happy to contribute... > > Ok so here's what I've got so far: When I was designing my anti-SPAM filter, I noticed you're just running a series of code after each other. To keep everything nice and tidy I split up the various routines into small pieces of code designed to do one thing and then pass on to the next filter. My project has the codename "redsky". Yes, it's cliché but I couldn't think of anything else. By itself, redsky is pretty useless. It's only capable of running a series of filters after each other. The real power is in the filters itself. The 3 filters that come shipped with redsky are designed to interface with another piece of software called proxsmtpd (but can be used in other ways as well, they just use STDIN and STDOUT), but there's no reasons you could write your own input/output filters and make redsky a mini-SMTP server. Here are the packages that are of interest: * phpemailtoolbox (http://aur.archlinux.org/packages.php?ID=22237) This is a small set of email related functions and classes. It is required by redsky. * redsky (http://aur.archlinux.org/packages.php?ID=22261) This is the main redsky code. It contains three filters: * redsky_read: this reads the email in question from STDIN. It is designed for interfacing with proxsmtpd, but can be used in a generic manner as well. * redsky_discard: when the discard flag is set on an email, this filter will log this event. * redsky_out: this outputs the email to STDOUT, again designed to interface with proxsmtpd but is suitable for general purpose as well. In the mailinglist * redsky-filters (http://aur.archlinux.org/packages.php?ID=24393) This is a set of complementary filters for redsky, it has for example SMTP blacklist checking, whitelisting, autoreplies, etc... They are mainly designed to use in a postfix content scanner context. Only the redsky_sqlconn filter is required for mailinglist manager. * mlm-filters (http://aur.archlinux.org/packages.php?ID=24399) This is the most interesting set of filters. Mlm stands for Mailing List Manager. There's a queueing part and a sending part. For the queueing part: * mlm_getinfo: Fetch information for a certain list using SQL * mlm_loopdetect: Check if a message is looping or not * mlm_bouncehandler: If the message received was sent to a bounce address, store it in an SQL table * mlm_getsubscribers: Get the subscribers from SQL for the current list * mlm_access: Determine if a sender has access to the list. It currently supports 4 methods: use an ACL, only allow subscribers, require a passphrase or no limitations * mlm_subjecttag: Tag the subject if the mailinglist is configured for that * mlm_addfooter: Add a footer to the emails if the mailinglist is configured for that * mlm_queuer: Write a spoolfile and put all the recipients into an SQL table For the sending part: * mlm_singleinstance: Only allow a single instance of redsky to be run * mlm_queuebuilder: Build a queue of messages to be sent and their respective recipients * mlm_queuerunner: Process the earlier built queue using sendmail to send messages redsky is written to support multiple configurations. In the MLM case, you would have two configuration files (examples are shipped with mlm-filters), one for the queuer and one for the sender. The queuer would be called by the MTA while to sender could be executing with a cronjob. Use -c to supply an alternate config, for example: redsky -c /etc/redsky.queuerunner.config.php You will notice that the redsky-filters and mlm-filters come shipped with example configuration files. You will find them in /usr/share/php/redsky/. Some filters depend on each other, so it is important in which order they are executed. For example, the mlm_access cannot determine if the sender is a subscriber when mlm_getsubscribers hasn't run first, because it uses the information from mlm_getsubscribers for this. Now maybe the hardest part, integration with an email server. I'll only handle postfix. Our entire infrastructure is based on MySQL, however all redsky code is written to use PDO, so it should be compatible with any databaseserver that PDO supports. You can get our database schema from http://projects.webmind.be/redsky/mail.sql In postfix terms, you would add entries to your alias table to send certain addresses to the "mlm". The examples below are made to work with the database schema above, but all queries can be modified in the configuration files. virtual_alias_maps = mysql:/etc/postfix/mysql/lists.cf lists.cf: user = USER password = PASSWORD hosts = HOST dbname = MAILDB query = SELECT 'mlm' AS goto FROM lists LEFT JOIN domains ON domains.domain_id = lists.domain_id WHERE (lists.list_post_address = '%u' OR lists.list_bounce_address = '%u') AND domains.domain_name = '%d' AND domains.domain_type = 'virtual' AND domains.domain_enable_email = 'yes' The above will send all mail sent to a mailing list address to 'mlm'. Now postfix knows it needs to send any list emails to mlm. Now we need to tell postfix that all email sent to the local 'mlm' address to be piped to our mlm program. For this we create a transport table, that has 'mlm(a)localhost.localdomain' transported to the 'mlm' destination. Now we have to define what the mlm destination is. Open up master.cf and add: mlm unix - n n - - pipe user=nobody flags=O argv=/usr/bin/redsky -c /etc/redsky.queuer.config.php Note the O flag, this will add an X-Original-To header, which is required to identify wich original address the message was sent to. To allow the messages to be distributed, just call /usr/bin/redsky -c /etc/redsky.runner.config.php Ok, all this information was probably hard to swallow. I will try to answer any questions you have regarding the implementation. If you want to ask me a direct question you can find me on IRC, freenode with the nick RedShift. I am in #archlinux. It's also easier if you start by testing it out directly from the shell instead of immediatly integrating it into your MTA. Best regards, Glenn

1 0

[arch-general] netcfg testing and git packages
by James Rayner 02 Mar '09

02 Mar '09

Hi The release beta cycle wasn't working well for netcfg. Small changes, bugs and many FR's got held up far too long while other work happened. To try and help get netcfg development going smoothly again I've uploaded some netcfg git PKGBUILDs to the AUR to use instead of -beta releases. This way I can make those small changes, push it to git, and it can be tested immediately, while larger things can be safely done in another branch locally. When it's ready, rc's will be released. http://aur.archlinux.org/packages.php?ID=23953 http://aur.archlinux.org/packages.php?ID=23954 There's some fairly substantial changes in this release. - Moving from net-tools to iproute - iproute is the way forward. net-tools is long unmaintained, nor as capable. - Moving from wireless_tools to pure wpa_supplicant - More reliable, less quirks required. Hopefully more stable. - As part of this, wireless moves into netcfg-wireless (dependency issues) Both of these require config changes. Once they're both stabilised I can release 2.2.x to give people time to migrate, and eventually 2.5 which will use them by default. There are example configs included. More details on the wiki: http://wiki.archlinux.org/index.php/Network_Profiles_development The wpa_supplicant move needs a significant amount of testing. I havn't tested WEP (testing hardware is gone), and net-auto may not work presently. WPA and custom WPA configs work in my testing. If there's any criticisms or comments about the way this is going, the code, netcfg, etc, please let me know. I'd like to make 2.2 a good release and I think these changes are important. I'm hoping they'll make netcfg simpler and more reliable. Cheers, James

4 3