Arch Linux Status Report, 2009-10-05 =================================== Aaron Griffin Yes, a new status report. I haven't put one of these out in some time, and a lot has happened since the last one, so bear with me here. There is a lot being left out from this, because there's simply to much to cover. We've had a lot of changes - repository oopses, server reinstalls, and things of that nature - that I simply won't be able to cover without writing a novel. == Newsworthy Items == * Bug Squashing Day We had our first bug squashing day in a long time. Thanks to everyone who helped, it makes everything so much easier. Andreas and Paul, many thanks for organizing this. More details can be found here: http://www.deelab.org/bash/2009/10/bug-squashing-day-results/ * kernel.org Tier 1 mirror I just now setup a mirror for kernel.org. The use geo dns re-routing, so it should work safely and quickly for any country. Additionally, this will get us images on boot.kernel.org eventually, which is impressive. Additionally, they have volunteered to be a tier 1 mirror so that others can rsync from them. == Completed Tasks == * Far too many to list As stated above, a lot has happened since I last wrote one of these. We've had numerous package rebuild frenzies, server reinstalls, code fixes, support for architecture independent packages, and so many more things. So, rather than try to cover all that, I just want to give my personal thanks out to all the developers and TUs. You guys are the ones who keep Arch going strong, and I appreciate all the hard work. It's amazing to see how much people actually care about a lil' ol' Linux distro like this :) == Pending Tasks, Short Term == * Web Server Hiccup Seems like we had our web domU hang on us the other night. This is the second time it has happened, and signs seem to point to it being Xen related. I would like anyone with knowledge or experience here to see if you can find anything. * Mirror Tiering Handling proper mirror tiering will give us a few benefits, the first of which being the fact that it will help us get rid of some of the "mirror not fully synced" issues. It will also help minimize our bandwidth. With the addition of the kernel.org mirror, and mirror.archlinux.no offering to be a tier 1 mirror, I think we can safely send out an email to the mirror admins, requesting a few more tier 1 mirrors. I'd say we shoot for around 5, just to pick a number. With these in place, we can begin the switch over. To do this, we'll simply: * Email all the mirror admins a list of the tier 1 mirrors * Have mirror admins chose a tier 1 mirror * Reply to us when changes are made * Remove their IPs from the DB * After a month or so, remove all IPs still pending (and keep a list of these offenders) * Replacing cron with fcron This was brought up on the ML a bit ago. It appears that most of us are in favor of using fcron to replace our existing dcron. I would like someone to spearhead this move. Any volunteers? * Ensuring Package Quality We run into package quality issues every so often. No, I'm not pointing fingers or anything, I'm guilty of this as well. I'd like to institute some way to ensure that our packages are of the proper quality before they hit the repos. Ideas are welcome. Currently, I had the following ideas in my head: * Add some token to the PKGINFO indicating that makechrootpkg was used This has the con of requiring this tool, when people may be using their own chroots or tools for this. * Make db-scripts check packages with namcap, and reject them on errors This has the con of making the db-scripts slower. * Combine the above: Add a PKGINFO token from namcap We should all be running namcap anyway * Support for community <-> extra moves I would like to get db-script support that allows developers to move packages across svn repos. This is actually fairly involved and should _try_ to include history. This should require ssh connections to each machine for a little boost of added security. Implementation details beyond this have not been thought of. * IRC Developer Meetings We used to have regularly monthly meetings in IRC, where we'd all get together and discuss things. We haven't done this in a while, and some of us have begun to feel like we don't really know each other to well. Well, let's try to change this. I'd like to schedule a developer's meeting for some time in October. I'd like to tentatively suggest Saturday the 24th. We'd all join #archlinux-dev and discuss things on the current status report at that time, and cover any other itches we have that need scratching. Please suggest times, or alternate days if needed. == Pending Tasks, Long Term == * Early-userspace in uClibc klibc has a slow development model, and it doesn't suit us too well anymore. Initially there was promise, but things have come to a near halt. As such, Thomas has proposed we switch from klibc to uClibc for our early-userspace. This is a great idea. This change should be near seamless to the users, but will require much work and testing on our part. I'm sure Thomas could use some help if anyone is interested. I believe all the packages needed are checked into the repos, but mkinitcpio needs changing and fixing. Thomas, would you mind pushing your changes to a branch somewhere? Or even to master if you're satisfied with them so far? This way we can all give you a hand. * Project TODO lists This was brought up a while ago, but I don't see a lot of follow through. For all our internal projects, I'd like to see some sort of public TODO list somewhere. If you'd like to use the bug tracker, that's fine, just add a link to the wiki page. In the Internal Projects wiki page located at: http://wiki.archlinux.org/index.php/DeveloperWiki:Internal_Projects we have lists of all the funny little things we maintain for our daily lives. I'd like to see, on this page, some indication of direction for these projects. This has already begun for the developer tools list. Pacman is most likely exempt as it is much more public and active than the other projects, unless Dan or Xavier feels like maintaining a list there :) It seems tedious, but this will actually give us something to point at when people say "How Can I Help?(TM)". * Repo symlinking This idea was put out by Jan a while ago, and I like it. It goes like this: When we put a package in the repos, we stick it in some master directory - we'll call it "packages" for now. Then a symlink is created, linking the "packages" instance of the package to an architecture specific dir. When and if this package moves repositories, the symlink is simply moved. What does this give us? The ability to easily move things from testing to core/extra without overwhelming our server during mirror sync (as mirrors will already have the packages). I think this is a great idea, and would require two things: db-scripts patches, and a script to convert our existing repo.