ArchLinux Status Report, 2008-01-07
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:
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
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:
* 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.
* 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:
* 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
It's great to see work on the community tools again. Thanks a lot to everyone
== 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:
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
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
- 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.
01-08-2008, 04:33 AM
Status Report: 2008-01-07
On Jan 7, 2008 11:39 PM, Aaron Griffin <firstname.lastname@example.org> wrote:
> * 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.
Chicago sounds good to me.
01-09-2008, 09:02 PM
Status Report: 2008-01-07
On Jan 7, 2008 10:39 PM, Aaron Griffin <email@example.com> wrote:
> * 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
> Is anyone willing to take up the pacbuild charge here? Give it some new life?
An addendum here. Jason gave us a status report of pacbuild last time.
I lost it in the shuffle when writing up the report, so forgot that it
The full text is here:
So there are a few pending changes, the following will NOT block a release:
Better logging in Apple and Strawberry
Automatic chroot rebuilding
Usage of the chroot tools from devtools
And the following are considered "blocking"
Ability to 'cancel' a package not currently being built
Include packages depends/makedepends
Addition of 'depwait' status for when a dependency has not been
Git tree for progress:
So, if we take a look at the last three items that block this release,
we can actually get this up and running without those features.
So, next steps. I'm going to setup my x86_64 build machine as a
pacbuild build machine to start testing things out. Anyone willing to
setup some build machine instances for me? This way we can get it
working and debugging.
See here for more: