- Arch-announce - lists.archlinux.org

[arch-announce] netcfg v2 has replaced netcfg from initscripts
by Recent News Updates 24 Mar '08

24 Mar '08

netcfg v2 is a complete rewrite of the netcfg that was previously included within 'initscripts'. netcfg v2 has been moved into a different package 'netcfg'. netcfg v2 is feature compatible, but not configuration compatible. Configurations need to be rewritten for netcfg v2, and examples are included in /etc/network.d/examples. For more information on transitioning to netcfg v2, please check the wiki: http://wiki.archlinux.org/index.php/Network_Profiles URL: http://archlinux.org/news/387/

1 0

[arch-announce] Perl 5.10.0 moved to core
by Recent News Updates 23 Mar '08

23 Mar '08

The latest release of perl 5.10.0 has been moved to core. This package is built following the Perl Policy document found on the wiki. Pay attention to the upgrade notes because some things have changed and may require some action. URL: http://archlinux.org/news/386/

1 0

[arch-announce] Kernel 2.6.24.1 in Core
by Roman Kyrylych 10 Feb '08

10 Feb '08

After a testing phase kernel 2.6.24.1 has been moved to Core where it replaces version 2.6.23.14. Some of the most visible changes for users include: * more mac80211-based wireless drivers added * tickless support for x86_64 * uvesafb; support for ATI Xpress 200M and Mac framebuffers * ACPI usage in libata * SATA port multipliers support * NCQ support on MCP51/MCP55/MCP61 chipsets (add 'swncq=1' to the kernel boot commandline) * SDIO support * ability to use any kernel version to resume a hibernated system * read-only --bind mounts * tons of bugfixes and improvements A detailed human-readable changelog is available at KernelNewbies Wiki: http://kernelnewbies.org/Linux_2_6_24 Attention! The kernel26-2.6.24.1-2 package includes an important security fix (local user privilege escalation). Everyone is encouraged to upgrade, especially on a system with ssh accounts. -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-announce] [draft] QT-4 and QT3 moved to [extra]
by Pierre Schmitz 20 Jan '08

20 Jan '08

As announced last year* and after a longer period of testing, QT versions 3 and 4 have now been moved to [extra]. At least until the final release of KDE4 there are plenty of packages which still use version 3 of QT. Therefore a new package called qt3 was introduced. The dependencies of all packages are updated according to this change. The update should be quite smooth. Pacman only notifies about replacing qt by qt3 and qt4 by qt. If you don't want to have QT version 4 installed just remove it with "pacman -Rc qt" after the update. If you are using any third party repositories like KDEmod please wait until they have updated their packages, too. Do not force any updates! If there are still any issues, please report them at http://bugs.archlinux.org. Community packages may not be updated with the new versioning scheme of QT, so give your TUs some time to make the required changes. *) http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html -- http://www.archlinux.de

1 0

[arch-announce] Status Report: 2008-01-07
by Aaron Griffin 10 Jan '08

10 Jan '08

ArchLinux Status Report, 2008-01-07 =================================== Aaron Griffin Ah, it's been so long since I had to shuffle through all these old emails and pump one of these reports out. With Christmas, New Years, and all that time off, I nearly forgot! That means one thing: I might forget some important things here. If I do, I will add an additional mail with additional items. We *do* have about 4 weeks to cover here, don't we? Happy Festivus to you all! == Newsworthy Items == * Ion 3 Removed from the repos Due to licensing concerns, we have removed Ion3 from the repos, as it is no longer "freely distributable" and puts unwanted constraints on the developers. * Logo Contest completion We've chosen a winner in the logo contest. The winner is Thayer Williams' Archer logo, available for your viewing pleasure in submission form here: http://dev.archlinux.org/~travis/logo-contest/thayer/1-archer.png Hooray, and congrats! We're currently going over the integration with the main site, so it may be a small amount of time before we get the changes in, but it *IS* being worked on. == Completed Tasks == * Dev/public site split Eliott has split the arch website into two distinct applications - the public site which everyone sees, and the developer site which we use to do our day-to-day tasks. This allows us to make changes to the dev site without interrupting everyone else's usage, AND allows us to increase performance on the public site through aggressive caching and other fancy terms like that. * Mozilla move to /usr All of the Mozilla related packages have been moved out of /opt and into the /usr tree. Currently these packages are still in [testing] but should reach [extra] soon. Special thanks to Alex and Jan for doing all the hard work here. == Pending Tasks, Short Term == * New initscripts and netcfg There are a handful of minor changes to the initscripts package, coming down the pipeline, but the most important one is the dropping of 'netcfg' from the package. netcfg has been completely rewritten by James, with many additional features and improvements, and should be used for any more complex networking needs beyond the simple networking in the default initscripts. More details here: http://wiki.archlinux.org/index.php/Network_Scripts * License Updates License updates are long and tedious, and they're still there. So every so often, if you can, please make sure and take a peek. See if you can fix some of your packages, and see if you've fixed any of them. It's a big list. http://archlinux.org/todo/43/ * ABS Redux ABS has been split from the pacman development tree in preparation for the pacman 3.1 release. This means that ABS can be developed and changed at a different pace than pacman, and pacman is more distro agnostic. The next big step will be getting rid of cvsup/csup and replacing it with an rsync-based system. Travis will be taking over the reins here, and this feature is currently being looked at / worked on. * Replacing CVS with SVN We've talked about this replacement for way too long, with no direct work beyond Jason's original proposal, so I am going to run with this. The proposal is to replace our CVS repos with an SVN implementation, and also restructure the layout just a bit. Jason has provided all the tools he has used to create these repos to me, and I am currently looking into the changes needed, mainly to our repo generation scripts. Once we can get these changes done, we can make the switch over to the new repo layout. * New devtools release I've been putting this one off for way too long. There are a large amount of changes we need to get into a new devtools package, including some newer scripts to aid packagers, and the chroot build tool updates. I'd like to push a release out the door soon, so if you have something you'd like included, please either email me, or add it to the Internal Dev section of the bug tracker. * Pacman 3.1 Release We're getting ever closer to a 3.1 release here (note the move from Long Term to Short Term, here). Dan and the crew are real close to getting 3.1.0 out. And it should be hitting [testing] real soon. So cross your fingers. You can see the full status here: http://archlinux.org/pipermail/pacman-dev/2008-January/010700.html * FHS Man Page support For as long as I've used arch, we've always put man pages in /usr/man. I never questioned it, and assumed it was on purpose. It turns out this is wrong, and in violation of the FHS. So we're working to fix this. Man pages *should* be installed to /usr/share/man from here on out. The new makepkg (3.1) will no longer move man pages to /usr/man. This will begin our slow-but-steady phase in of FHS compliant man pages. Users are encouraged to report packages which EXPLICITLY use /usr/man in the PKGBUILD (perhaps through a configure option) via the bug tracker. * 'codecs' Package Removal The codecs package has long been a bit of a thorn in our sides. While it adds support for some interesting formats, it also has questionable licensing issues. That said, mplayer and xine can both OPTIONALLY use the codecs package, and the dep has been removed (in [testing]). In the future, we will most likely be moving 'codecs' to [unsupported] due to the fact that it IS optional, has questionable license issues, and most video players can play a majority of formats WITHOUT the need for this package. * AUR Development Work Simo, our resident AUR pro, has been away for the holidays, and Eliott has been handling AUR development and progress. I want to point this out here because we've apparently had a resurgence of outside interest, and a lot of patches coming from Callan Barrett. Thanks a lot, Callan. Additionally, it appears that a few people are hard at work on an AUR successor, so if you're interested in starting from scratch, there is that as well. It's great to see work on the community tools again. Thanks a lot to everyone involved. == Pending Tasks, Long Term == * Perl policy implementation Kevin has been doing a great job implementing our fancy new "Perl Policy". You can see a full bug collector here: http://bugs.archlinux.org/task/8374 Apparently, one of the large leaps here is the removal of all the crazy symlinking we used to have to deal with. Cleaning this up, alone, helps us greatly with many perl related bugs and issues. * Official pacbuild usage This has gone more and more by the way side. With the advent of a manual machine to build packages on for non x86_64 devs, this is less and less of an issue. The major push for pacbuild was so that some devs could build on hardware they don't run. Is anyone willing to take up the pacbuild charge here? Give it some new life? * Modernize our Dashboard Eliott has made some great strides here. The split of public and dev websites give us a lot of flexibility and allow us to develop and make changes more rapidly. In case anyone is listening, I'd like to prioritize some changes here: - Multiple Architecture support: getting support for ALL our packages in the dashboard interface should be our first major milestone here. - Integration of Andy's 'difflist' functionality to show the differences between architectures. - Signoff functionality via the web interface. As it stands this is 90% Eliott doing all this work. If anyone would like to help out, I'm sure he'd appreciate it. * Architecture Independent Repos This will be made a reality AFTER pacman 3.1 is release. Support is already there for arch=(any) and we should start using this as soon as the DB scripts are updated to support this. Currently, this will most likely happen around the same time that the repos switch from CVS to SVN, but until then, this task is in holding. Anyone willing to help out, let me know. * ArchCon 2009: Big Baaad Idea This is staying right here until someone decides to come to Chicago to visit 8) No, the US is not dangerous! Hah.

3 3

[arch-announce] Holiday Status
by Aaron Griffin 21 Dec '07

21 Dec '07

Hello Everyone, I wanted to let you know that I'm not going to be around all that much for the next few days. With Holiday parties at the office, and visiting family, I probably won't be sitting down at a computer until Wed. This means, sadly, I won't have the time to write up a big long status report. :( BUT, the good news is that I am on vacation until the next Wed. So with 7 days with nothing to do but Arch, I should be able to get a lot of ground covered. I'm sure other developers are in the same boat. This is on the announce list. Feel free to reply to this thread and let us know what you're up to - we can make it an impromptu mini-status report Me, personally, over the next week or so, I plan on getting a new initscripts release out the door, beginning work on the DB scripts revamp, and helping finalize everything that needs to be done for pacman 3.1. After all that is done, I want to take a look at Jason's svn repo implementation and begin making that switch over as part of the db script changes. Anyone else want to add anything?

1 0

[arch-announce] Status Report: 2007-12-11
by Aaron Griffin 13 Dec '07

13 Dec '07

ArchLinux Status Report, 2007-12-11 =================================== Aaron Griffin I apologize for the delay here - yesterday was a long day for me, and I didn't have the time to sit down and write this out (it is a tad time consuming, as you can probably tell). == Newsworthy Items == * TLLTS Interview I hate self-promotion as much as the next guy, but TLLTS wants to do an interview about me tomorrow at 20:30 EST. Some of you may be interested. It'll be freeform, so I don't know what we'll talk about, but it will probably be related to where we're going in the near future. More here: http://www.tllts.org/ == Completed Tasks == * Developer signoff clarification When I originally initiated the "signoff" buffer for core packages, I had intended that the developer requesting the signoff count as one of the "two required" signoffs per architecture, as it is assumed a given developer tested a package before uploading and is also responsible. To clarify: We need two developers responsible for each physical package - two for each architecture. These two can include the original uploader. These people are responsible for any issues caused by this release of the package. They're also the people we have to point fingers at 8) * Mailing list rename We've renamed two of our most important mailing lists, just for a change in nomenclature. There's not much to say on this topic that wasn't covered in the front page news: http://archlinux.org/news/368/ * New netcfg scripts _still_ in [testing] I want to poke this item here. I'd like to get some yays/nays here. I dropped the ball on including the patches into an initscripts package in [testing] which replaces the current netcfg scripts. It's on my list - high priority. More details here: http://archlinux.org/news/362/ * Packages in [extra] I attempted to get some discussion here a few times, and not much came of it. As such, here's the criteria for what goes in extra, and what goes in community. * Packages in [extra] define us as a distro and should not include packages for personal use. If something is personal and/or only used by small amounts of people, it should go to community. Not only does this help us with our vision, it also helps out our mirrors (not all mirrors mirror the community repo). * Devs should inform everyone if they're putting a new package into extra, just in case another dev has an issue with it, to prevent silly bloat from too many personal packages. If someone has a problem with a package going into extra, a simple vote should suffice (no need to discuss it to death) * We should be prepared to remove contentious packages at any time. If someone claims "package foo doesn't belong in extra" and enough developers agree, we should simple move it to community and maintain it there. * Unified chroot build tools These chroot building tools have gone through some changes, and are in successful use on my "micro build machine": http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003130.html This machine is being used to cover developers and TUs who do not have x86_64 hardware and still would like to build the packages. This way, we can help out the x86_64 guys immensely. Future plans involve setting up a 32bit chroot on the same machine for the converse of the above. == Pending Tasks, Short Term == * Logo contest delay We've hit a few snags trying to figure out issues with regard to setting up a trademark for our new logo. Suffice to say that we HAVE chosen the top 5 logos. And ARE moving forward with this. Travis, could you provide us with a follow up email with all the fun details here? * Bug tracker cleanup This weekend Roman is planning to do a big bug tracker overhaul and attempt to cleanup and consolidate our open bugs. Any help from the developers would be appreciated. I'd like to especially thank Allan McRae here too - I keep seeing him suggesting bugs be closed, and he's been helping Roman out here too. Thanks for the hard work. I'm very grateful. * Bug Squashing Day revamp We used to do official Bug Squashing days near the end of every month (second to last Sunday, or something to that effect), but these have fallen by the wayside due to Roman's awesome work. Even so, I'd like to get back in the swing of doing this, as it will help keep us all on track. Roman, would you like to help organize this? I will try to keep track of the dates and everything, but it'd be nice if you could spearhead the initiative. * Getting rid of /opt We officially have a todo list here. Actually, we have two: General packages: https://archlinux.org/todo/45/ (Thanks Jeff) Mozilla specific: https://archlinux.org/todo/44/ (Thanks Alex) It seems we haven't done a whole lot with this, though Paul's moved Eclipse out of /opt (yay!). It'd be nice if we can get to these at some point - they're not very taxing to change for the most part. Anyone willing to devote a night to knocking out the easy ones? * License Updates This one is not easy or pretty - every so often, please take a look at the items in the list and try to correct your licenses if they are wrong. https://archlinux.org/todo/43/ * ABS Redux This task has been partially done/discussed around the water cooler. http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html The plan? To create a static directory which we can use to rsync ABS instead of using cvsup. Dan has already sent some patches around. I will dig them up after I send this out. The easiest step here is to break ABS out from the pacman package - Dan, is is possible for us to do this as part of the 3.1 release? After that we can make ABS changes independent of pacman (and ABS is really an Arch specific tool, while pacman/makepkg are not) * Getting rid of CVS Last status report, I pointed this guy out. Roman responded with a vote for Jason's SVN proposal. In summary: * Jason has provided us with an svn solution, where sub-directories control the location of the package (i.e. package-name/repos/extra/PKGBUILD will place the package into extra) * Dan has provided us with a git solution that uses named branches to control the location (i.e. a branch named "testing" has changes to PKGBUILDs present only in the testing repo) I'm going to put my weight behind Jason's SVN proposal too, for the following reasons: * There is no reason to manage our packages in a distributed manner * SVN will be an easier transition for some users and developers unfamiliar with the esoteric commands of git. * It has a real implementation * One can use the git-svn porcelain on top of this, to still get the full power if git if they so wish. So, the next steps: Jason, can you provide us with some more details on your implementation, or perhaps something on gerolde as a preliminary system? I'd like to setup something side-by-side for people to use and to play with a bit. This way we can easily flesh out the hairier details. Paul, you did some similar work with repoman, yes? Do you have anything to add to this topic? == Pending Tasks, Long Term == * Perl policy implementation Kevin has been taking some of these on, and helping implement the perl policy. It's a big task, and any help from perl gurus around would be appretiated. http://bugs.archlinux.org/task/8374 * Pacman 3.1 Release We're still cranking away here. Big thanks go out to Chantry Xavier, Allan McRae, Nagy Gabor, and Nathan Jones for all the hard work. And thanks to all the translators too: Giovanni Scafora, Jeff Bailes, and anyone else I missed. Dan DOES have a pacman repo here with the latest and greatest pacman-git package for those of you wanting to live on the edge: http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html Pending bugs for the release are listed here: http://bugs.archlinux.org/task/8109 * Official pacbuild usage This apparently has gone farther by the wayside with the machine I put out there for non-x86_64 devs to build packages, taking some of the load off of the guys who were waiting for pacbuild. I'm not even sure of the state here anymore - Simo, Jason, any news? Would you guys like root access to the build machine so as to have a place to RUN pacbuild? Last I checked I did install it, but it isn't configured or the most recent version. * Modernize our Dashboard Eliott has broken out our public and private sites, allowing us to, in the future, mess with our internal tools without disrupting the external site, in addition to applying improvements with regard to caching and all that fun stuff on the public site. The testing site URL should, for the time being, remain private - his original email was sent to the private ML. Please test it and give us a thumbs up/down if you have the time. You should be able to use it for all your normal public site access, if you'd like to give it a thorough testing. In order to garner more interest here, I'd like to get some docs or a script setup in the git repo that would allow one to run a quick local instance with a small test DB. Eliott, is this doable? * Architecture Independent Repos We have pacman support (for the 3.1 release) done thanks to Roman. We now have an idea of where we want the new SCM changes to go. This means some rewriting of the DB scripts are in order here. So, with this in mind, we should be able to create these architecture independent repos as part of the same push. Don't you love it when things fall into place like that? Here's the internal (private) task for anyone interested in this: http://bugs.archlinux.org/task/8555 * ArchCon 2009: Big Baaad Idea More details. Tom has suggested some dates for this. What do you guys think? http://archlinux.org/pipermail/arch-dev-public/2007-November/003310.html Pierre brought up a valid idea - we plan this around another convention that we have a presence at. Doing this at Froscon would cover our German/European contingent well, but we also have a chunk of developers on this side of the pond. It'd be nice if we could give an island somewhere in the middle of the Atlantic, but without massive volcanic activity, we're stuck with one side or the other. How to the Europeans feel about coming over here? And vice versa? Let's assume, for the sake of argument, that money isn't the issue here. Opinions? What about Canada? Birthplace of Arch AND it's not as dangerous as the US (hah!).

3 4

[arch-announce] Mailing list rename
by Aaron Griffin 27 Nov '07

27 Nov '07

Hey guys, You may have noticed a new address up there in the From line (unless you got this via the announce list) The main mailing list has been renamed, from "arch" to "arch-general", and additionally "tur-users" has been renamed to "aur-general". The reason? The naming was unclear, especially on the tur-users list. So, please try to use this address when posting to the list (the old address will work fine for now, but I can't predict how long). Additionally, I have kept archive symlinks so that the following two are the same: http://archlinux.org/pipermail/arch-general/ http://archlinux.org/pipermail/arch/ Sorry for all of you that have to update your mail filter rules, but it's better this way - I promise 8) Thanks, Aaron

1 0

[arch-announce] Status Report 2007-11-20
by Aaron Griffin 27 Nov '07

27 Nov '07

ArchLinux Status Report, 2007-11-20 =================================== Aaron Griffin (Reviewed by Eliott) Another couple of weeks, another status report. Things have been calm around here, oddly enough. A lot of us are getting ready for the holidays, or exams, or both. Me? I'm just really busy with work these days. I want to let everyone know that you are always welcome to contact me over jabber or email for any questions or concerns. I seem to be getting a few emails recently with lines such as "sorry for emailing you" - I like email. Emails are fun. So don't be afraid ;) == Newsworthy Items == * New Logo Competition Voting All the submissions for the Logo Competition are in, and the developers are currently voting. Hold on to your seats, the final verdict will be incoming soon. http://bbs.archlinux.org/viewtopic.php?pid=298688 * Simo takes over AUR development Paul has taken a step back from being the lead on the AUR project, and Simo is taking his place. In Paul's own words: Thanks to all of you for making the AUR come alive over the last few years! It's been exciting to watch our creation really brought to life by this vibrant community. I'm excited about beginning a new chapter with Simo at the helm! * Bug Tracker open for [community] packages In the past, we've not allowed bug tracker items for community packages because it was difficult to manage the bugs. Now, we've created a section in our bug tracker for community package issues. http://archlinux.org/news/364/ == Completed Tasks == * Xorg 7.3 Brouhaha This update seems to have caused quite a ruckus among the users. For some people it worked fine, but others ended up with broken systems. Sadly, this is somewhat expected on large upgrades like this. I remember a day when we had breakages like this all the time. Arch has been running so smoothly recently that most people forget that software actually does break. http://archlinux.org/news/363/ * Package Cleanup An extraordinary amount of thanks goes to Eric here. This is a thankless job, but he has done the legwork and cleaned up a large amount of packages from extra. This makes everyone's job easier, and our repos cleaner. There's still more to come, so stay tuned: http://archlinux.org/pipermail/arch-dev-public/2007-November/003154.html * [core] repo rebuild Daniel did a huge amount of work here, rebuilding all of our core packages for the new gcc/glibc toolchain. This is a common rebuild that a lot of distros do, yet we typically do not do it that often. So hats-off to Daniel for doing the rebuild and package move, and special thanks to Tobias (tpowa), Andreas, Roman, and anyone else I missed for doing the cleanup work that enabled Daniel to do this. * New netcfg scripts in [testing] James has spent some time revamping our network profile support, and generally cleaning up our network scripts. His changes have been moved to testing now. Please try them out if you get a chance. http://archlinux.org/news/362/ * QT4 Move to [testing] Pierre and others have begun the move to Qt 4 based packages. This includes backwards compatible support for Qt 3 (in the form of a package named qt3). These packages should all be moved to testing now. Please try them out and report any problems you come across. http://archlinux.org/pipermail/arch-dev-public/2007-November/003242.html. * GPL License naming Just so we don't bollocks this up, the following naming scheme will be using for GPL licenses in PKGBUILDs: GPL means GPL2 or later GPL2 means GPL2 GPL3 means GPL3 or later Note: We have no GPL1 packages, and I doubt anyone could actually find one. == Pending Tasks, Short Term == * Getting rid of /opt Revisiting this from last time. It looks like we have a lot of packages which can move out of /opt when we have the time. The first step is to create a todolist in the dashboard for all packages which currently install to /opt. Would anyone be willing to create this list? * License Updates We still have a large TODO list sitting here, of packages that have broken licenses. Please take a look at these while packaging, to ensure we have licenses setup properly. http://archlinux.org/todo/43/ * ABS Redux This is actually a multi-part task here. The first part, involves replacing the cvs dependence in ABS with rsync. http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html This change will allow abs to be independent of the SCM backend we use, and perhaps more efficient in the long run. I think Dan and Eliott have done some work here in this regard. Step 2 is actually breaking abs out from the pacman package, as it's very ArchLinux specific, and pacman/makepkg are not. This can, and should, most likely be done around the same time as the pacman 3.1 release (see below). * The dividing line: extra and community Ah, waning discussion is always fun. I've tried to revitalize this a few times, but it seems discussion feel short. So here's a fun little ultimatum for ya: Since no one seems to care about this topic anymore, if we don't get a vote, or at least continued discussion here, I'm going to have to make an "executive decision". That decision will be as follows: * Packages in [extra] define us as a distro and should not include packages for personal use. If something is personal and/or only used by small amounts of people, it should go to community. Not only does this help us with our vision, it also helps out our mirrors (not all mirrors mirror the community repo). * People should inform everyone if they're putting a new package into extra, just in case someone has an issue with it, to prevent silly bloat from too many personal packages. If someone has a problem with a package going into extra, a simple vote should suffice (no need to discuss it to death) The other reigning idea seems to be Damir's idea of the mantle/crust repos. That is, the same idea as above, except there is another repo in between extra and community that serves as the developers' dumping grounds for these packages. So, take a look at your options, and decide what feels best to you - I'd like to close this task out soon, as there's no real work here - only process. * Unified chroot build tools The chroot tools I've put in devtools have gotten little response. Jason has made some changes, and Roman has provided some patches, if I remember correctly. I'd like to get more input here, suggestions of things like using linux32 and dchroot are great (both suggested by Thomas). So feel free to bring it up. * Getting rid of CVS Yep, this is moving up the chain from long-term to short-term. Before the next status report (2 weeks from now) I want to at least begin this task. In order to do this, we need to first make a decision on where we want to go. The root of the decision here is how we represent a given package being in multiple repos at one time. * Jason has provided us with an svn solution, where sub-directories control the location of the package (i.e. package-name/repos/extra/PKGBUILD will place the package into extra) * Dan has provided us with a git solution that uses named branches to control the location (i.e. a branch named "testing" has changes to PKGBUILDs present only in the testing repo) Both of the solutions above solve the issue. The real question is - what tool do YOU want to use? == Pending Tasks, Long Term == * Perl policy implementation Looks like some perl progress has been made. As said last time, there's not a HUGE amount of perl hubbub on Arch, so this isn't critical. It's important, sure, so lets keep this one in mind. http://bugs.archlinux.org/task/8374 * Pacman 3.1 Release Dan has been doing some amazing work closing out a lot of bugs for this release. In addition, he has a public repository which contains recent builds of pacman from git, that should help in testing in debugging. If you feel like helping out with testing, please use Dan's repo to install 'pacman-git'. More info here: http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html Pending bugs for the release are listed here: http://bugs.archlinux.org/task/8109 * Official pacbuild usage Another pipe-dreamy project. I'm not even sure of the state here anymore - Simo, Jason, any news? * Modernize our Dashboard Eliott has been pushing out some very nice changes to our web interface, so thanks goes out to him. For some of this stuff. I'd, of course, love to see more web-dev type people working on this. Take a look at our gitweb: http://projects.archlinux.org/git/?p=archweb.git;a=summary At some point, I want to add README text with information on how to run a local instance. * Architecture Independent Repos As stated last time, Roman sent us a patch for pacman 3.1 to incorporate the no-arch packages. This means that when the 3.1 release comes out, we should be ready to go here. So here's your deadline: let's try and get support into our DB scripts before the pacman 3.1 release. Who's interested? http://bugs.archlinux.org/task/8555 This one is a rather small change, is anyone interested in doing this? Thomas? * ArchCon 2009: Big Baaad Idea /me winks http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html

3 2

[arch-announce] Bugtracker is open for Community packages
by Roman Kyrylych 06 Nov '07

06 Nov '07

Due to high demand we have created a separate project on our bugtracker named "Community Packages" [1]. 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. [1] http://bugs.archlinux.org/index.php?project=5 -- Roman Kyrylych (Роман Кирилич)

1 0