Due to high demand we have created a separate project on our bugtracker named "Community Packages". All bug reports and feature requests related to packages from the [community] repository should now be reported there. Please do not report them to "Arch Linux" or "Arch User Repository (AUR)" projects. Instead use the "Switch" button at the upper left of Flyspray's page to choose the correct project. In addition to this do not report bugs for packages which are in [unsupported]. Just put a comment on the package's page on AUR instead.

After a testing period for over one month we made the decision to move X.org 7.3 to our stable package repositories. Thanks to all the testers and reporters who enabled us to wipe out most of the major issues. Please note that libgl-dri has been renamed to libgl since the deprecation of libgl-mesa happened a long time ago already. That means people packaging for the AUR should finally get rid of any hard dependencies on libgl-dri or else their packages will be left broken.

netcfg2 aims to be a refined network profile system for Arch Linux, replacing the current implementation. Through this, it has also gained various features and improvements which are listed on the development wiki page Before it can replace the current profiles, netcfg2 needs testers of various wireless hardware and configuration to try the scripts and report back on the wiki page testing section. Bugs can be filed at the bug tracker. Documentation for netcfg2 is located in the netcfg manpage, detailed examples in /etc/network.d/examples, and the wiki

Current: http://archlinux.org/static/newsletters/newsletter-2007-Nov-05.html Archive: http://archlinux.org/static/newsletters/

mlocate has replaced slocate as the default locate implementation after a short period in [testing], and an even longer one in [extra]. This was requested on the bug tracker a while back as FS4490 mlocate is used by Fedora at least and unlike slocate, no longer has the well known midnight updatedb crawl. In all other aspects it's compatible with and identical to slocate. AndyRTR posted some performance measurements on the mailing list. As described by the README: mlocate is a locate/updatedb implementation. The 'm' stands for "merging": updatedb reuses the existing database to avoid rereading most of the file system, which makes updatedb faster and does not trash the system caches as much. The locate(1) utility is intended to be completely compatible to slocate. It also attempts to be compatible to GNU locate, when it does not conflict with slocate compatibility.

Hello everyone! As you may have heard, the Arch logo as we know it is going the way of the dodo! We are refreshing our graphical identity, and in that spirit we're having a logo competition, open to the entire Arch community! We want to know what you think of when you think Arch Linux - what logo do you think would best suit the distribution we've all come to love? Submission guidelines are as follows: . Anyone can submit as many logo concepts as they wish . Entry is freeform, with no need to base it on current logo. Be creative! . For the sake of moving the competition along, artists will maintain the rights to their works until the completion of the competition, when we've decided what to do with license issues. Per submission, you will need: . SVG sources for logo preferred. If you don't know how to make SVG logos, but have a great idea, visit this thread; foxbunny has graciously stepped up to help with logo concepts. . Fill out the following on this submission sheet (courtesy of foxbunny) .. Name (or alias) .. Main logo areas (white/black/neutral BG) .. 2-colour or Black version .. 128x128px and 16x16px icon version .. Colour palette used All other fields are optional - you do not need them to create a submission, and omission of those options will not count negatively against you. Submit completed submission sheet attached in an email to travis AT archlinux.org. They will be posted in this thread; two weeks after the date of this post, we will collect all submissions in that thread and judge. Judging will be the job of the Developers, and will proceed as follows: All submissions will be posted to the [arch-dev] private mailing list, and developers will give their +1 to those logos they like. They may add a +1 to more than one submission - once all developers are accounted for, the logo with the most +1 votes will win. Should multiple logo submissions tie for first place, those entries will be announced to the community, and we will have a community vote on the forums. The logo voted highest in this case will be the winner. Additionally, we'll want to use the logo for additional media - CD labels or wallpapers, for example. If the winning author hasn't provided any, they will be given a chance after the competition is over to create this artwork, if they want. Basically, no need to get it done before the judging, if you want to do it, so don't worry! :) Please note: there are also threads for logo concept discussion and for showing off possible concepts, without entering them into the competition. Feel free to make use of them. Good luck to all participants, and have fun! NOTE: There has been some recent concern about entries by developers, since it is the developers themselves voting. This was never forbidden at the beginning of the contest, and so the rules will not be modified for this halfway through; developer entries are allowed, and will be treated on exactly equal merit as any other entry. Rest-assured, there is no reason for favouritism in this contest - if we wanted an explicitly developer-made logo, we would have simply done so, so there's no reason to choose a dev's submission simply because they are a dev. :)

Current: http://archlinux.org/static/newsletters/newsletter-2007-Oct-22.html Archive: http://archlinux.org/static/newsletters/

We've added a new mailing list for special announcements in the same vein as front page news and forum announcements. http://archlinux.org/mailman/listinfo/arch-announce This should be useful for anyone who doesn't frequent the forums or front page daily. In addition, I will be CC-ing devland status reports to the list every Monday, for those of you interested in the developer happenings. Thanks, Aaron

Another late newsletter. This time it's only a day late though, not 4 months... Current: http://archlinux.org/static/newsletters/newsletter-2007-Oct-15.html Archive: http://archlinux.org/static/newsletters/

After several days of trying to get tuxonice running stable, I give up. I have no effort anymore to get this kernel running. No other developer wants to maintain it. I have also asked on the TU mailinglist, but no answer so far. That means, that kernel26suspend will die shortly and will be deleted from the official repo. If anyone from the community want to "maintain" it further, feel free to download the PKGBUILD and patches of the kernel26suspend and corresponding modules from CVS and put it to AUR. My suggestion to everyone who is using kernel26suspend2, look at the package "suspend" in AUR. It does nearly the same as kernel26suspend2, but without the need of an extra kernel. Sorry for the bad news, but that is the farewell to the officially supported kernel26suspend2/tuxonice package and modules. Daniel