[arch-dev-public] Status Report: 2007-11-05

Thu Nov 8 20:49:13 EST 2007

On Mon, 2007-11-05 at 18:51 -0600, Aaron Griffin wrote:
> ArchLinux Status Report, 2007-11-05
> ===================================
>    Aaron Griffin (Reviewed by Travis Willard)
> 
> So, some of you may have noticed there was no Status Report last week. Well,
> see, I got busy. No one to blame but myself. I _was_ going to get it out on
> Tuesday, but decided to "roll with it", as it were.
> 
> So, before we get started, I wanted to get some honest opinions - does doing
> this every 2 weeks make you guys feel less pestered?
> 
> One important thing to note: for anyone looking for "something to do", the
> reason I list a lot of thing here is that I feel we should get them done. If
> you're looking for things to do, I'd appreciate it if you took a look at this
> list to see if there's something you can tackle.
> 
> 
> == Newsworthy Items ==
> 
> * New Logo Competition has begun!
> 
> The competition for the new Arch logo, spearheaded by Travis, has begun. Full
> details can be found in this news item:
> 
> http://archlinux.org/news/359/
> 
> * New Newsletter Format
> 
> Eduardo Romero (kensai) has taken over doing our newsletter, and has changed the
> format and content. Take a look, and let him know what you think - I, for one,
> think it's great. Thanks a lot for all the effort Eduardo, and congrats on
> making a great new new style and layout!
> 
> 
> == Completed Tasks ==
> 
> * Latest ISO Testing
> 
> The upcoming 2007.11 ISOs have been in testing for some time now.
> 
> ftp://ftp.archlinux.org/other/rc-iso/2007.11/
> 
> No new show-stoppers have been reported, so I believe we should have new ISOs
> when Tobias returns from his exams. Yay!
> 
> * New devtools release
> 
> This is for all the developers and TUs. We've included a few new features, and
> two new scripts, in the latest devtools release. Please report any problems or
> feature requests on the bug tracker.
> 
> * Xorg 7.3 out of testing
> 
> Xorg 7.3 has been in testing for about a month now. It's time to move it out
> there.
> 
> http://archlinux.org/news/363/
> 
> Thanks go out, of course, to Alex for making this happen.
> 
> * Code projects moved to git
> 
> All our code projects have officially been moved to our git repos, located at
> 
> http://projects.archlinux.org/git/
> 
> Special thanks to Dan, Simo, and Eliott for carving up CVS and SVN
> repos to create nice
> little subsets for specific projects.
> 
> * cvsup is dead. Long live csup.
> 
> We've officially replaced cvsup (used by ABS) with csup. There are a handful of
> reasons, but the biggest one is that cvsup does not compile on x86_64.
> 
> Thanks to Dan for actually making the move and testing it.
> 
> * slocate has been replaced by mlocate
> 
> This has been a long time coming. mlocate is a locate/updatedb implementation
> that uses a different method of updating the locate database, making it much
> faster on successive runs. This means your machine isn't going to grind to a
> halt every night at around midnight, heh.
> 
> Thanks goes out to James for pushing this one through here, good job.
> 
> 
> == Pending Tasks, Short Term ==
> 
> * QT4 Move
> 
> Pierre has proposed a migration plan for moving to QT4.
> 
> http://archlinux.org/pipermail/arch-dev-public/2007-November/002910.html
> 
> This appears to be straightforward, so we should get to this soon! Hooray for
> progress!
> 
> * Killing off of /opt
> 
> According to Jan, the last remaining apps we have in /opt (KDE, OpenOffice, and
> Mozilla/Firefox) can be safely moved out of /opt and into the /usr tree like
> everything else.
> 
> Moving binaries and things out of /opt is going to remove a lot of headache
> we've had in the past. So for anyone who maintains a package that installs to
> /opt, see if you can get it to install in /usr instead.
> 
> * Core rebuild
> 
> Our core rebuild, due to toolchain changes, is currently waiting for testing to
> empty. For those developers that have packages sitting in testing, please either
> try to push them up to the real repo, or remove them from testing if they are
> old.
> 
> Andy has started cleanup threads for most of these packages. Please check here
> to see if you own any of these packages:
> 
> http://archlinux.org/pipermail/arch-dev-public/2007-November/002855.html
> http://archlinux.org/pipermail/arch-dev-public/2007-November/002856.html
> 
> * License Updates
> 
> Travis has created us a _HUGE_ todolist of packages with broken licenses. Please
> take a look at it and see if you can close out any packages you currently own.
> 
> http://archlinux.org/todo/43/
> 
> Keep in mind that this list contains ONLY packages in the [extra] repo. This
> means it will not affect the core repo rebuild, but may be affected by the
> Package Cleanup.
> 
> * The dividing line: extra and community
> 
> Another discussion that has gone by the wayside.  I'll try to summarize here to
> see if we can a better idea.
> 
> The question: when does a package belong in extra?
> 
> We all agree that we need some sort of "rule" for this. There seems to be two
> big ideas on how to "answer" this question:
> 
> a) Split extra into "mantle" and "crust". Mantle contains packages "important to
> the distro" to be agreed upon by the developers, and crust contains anything
> else a developer wants to maintain.
> 
> b) The idea above remains the same, BUT extra is not split at all. The "mantle"
> packages go to extra, and "crust" packages go to community.
> 
> So, what do you guys think? Should we vote on these two to get things moving?
> 
> * Package and Orphan Cleanup
> 
> Eric has done an amazing job of cleaning up a big wave of packages from extra.
> All things considered, this is fairly important task, as is affects the
> "Dividing line" question above, as well as lightening our workload.
> 
> Eric, what is the next step here - how can we help?
> 
> * DVD and Additional Package ISO Lists
> 
> Still not even a peep from people. This is the last time I'm going to include
> this item on the list. If we don't get any sort of activity or discussion on
> this, I am going to consider the matter closed.
> 
> The question: do we want to distribute additional DVDs/CDs full of packages? If
> so, how do we define what packages are on these things?
> 
> * Unified chroot build tools
> 
> The new devtools release has pushed two of these tools out there: mkarchroot,
> for creating ArchLinux based chroots, and makechrootpkg, for running makepkg
> inside one of these chroots.
> 
> Currently, there are a few little bugs floating around, but feel free to report
> more.
> 
> The next step is to move to official usage here, so for you developers out
> there, PLEASE contact me if you have any problems - we should all be building
> packages in clean chroots to make sure hidden dependencies do not sneak into the
> packages, and I want to make these tools as easy to use as possible.
> 
> * DB Scripts Code to git
> 
> With our SCM backend changing, the DB Scripts rewrite task is no
> longer a big deal.
> What we _do need_, however, is our existing code moved out of CVS (and into git,
> in an ideal world). This way we can use these as examples as we create new
> scripts for working with our new SCM layout.
> 
> 
> == Pending Tasks, Long Term ==
> 
> * Perl policy
> 
> I've moved this one to the long-term section
> 
> http://bugs.archlinux.org/task/8374
> 
> Apparently, perl isn't very widely cared about, so this is mostly all up to me,
> and we all know my freetime is hard to find these days. So, this is on the "hey
> this is important" list, but there is no rush.

I mentioned that I was working on it :) and I'm pretty much done the
perl package.  I have three different versions of Sys:Syslog: the one
included with perl, a separate pkg for testing, and a manual CPAN one.
They co-exist nicely.  Thanks to Charles Mauch for the initial footwork.
I didn't include one patch (enc2xs) since I didn't really know what it
was for but I'm sure it'll come up in testing.  Older perl pkgs such as
Zim still work fine.

I'm waiting for perl 5.8.8-9 to go out before I put it in testing.  Then
the remaining packages can be converted to go in vendor dirs.

> * Getting rid of CVS
> 
> Last time we visted this, we had two potential implementations. The complexity
> here has to do with representing one package in many repos at the same time.
> _This_ is the problem that is solved by CVS tags that we need to redefine
> elsewhere.
> 
> Jason gave us an example svn implementation that used the following structure:
> 
>     package-name/
>         PKGBUILD
>         repos/
>             core/
>             testing/
>             blahblah/
> 
> Where each directory under repos/ is a new repository that contains a PKGBUILD
> and all supplemental files that are routinely "synced" with the master files (in
> the top level directory).
> 
> Dan gave us a git implementation that uses a similar structure, but uses git's
> "lightweight branches" in place of the repos/ directory. This also allows us to
> create rebuild branches and the like very easily. Here is a usage example:
> 
>     git checkout -b foo_rebuild
>     $EDITOR foo/PKGBUILD
>     $EDITOR pkg1/PKGBUILD
>     $EDITOR pkg2/PKGBUILD
>     git commit -a
> 
> or
> 
>     git checkout -b testing
>     $EDITOR foobar/PKGBUILD
>     git commit -a
> 
> The branch names above indicate a new repo, which contain only packages that are
> changed in the new branch.
> 
> So, I leave the floor open here - what do you guys think? Which is a better
> solution? I want to open this up to opinion and vote _real_ soon, as this is
> something we've talked about for so long it's becoming near mythical.
> 
> * Pacman 3.1 Release
> 
> http://bugs.archlinux.org/task/8109
> 
> Ah, another stagnating task. We've gotten some great patch contributions from
> the community, and Dan has been rocking with the pacman changes.
> 
> We'd love to see more testers out there testing the version from git, and
> possibly confirming some of the "Requires Testing" bugs on the above, so we can
> close them out.
> 
> * Official pacbuild usage
> 
> We have an official git repo for pacbuild sitting here:
> http://projects.archlinux.org/git/?p=pacbuild.git;a=summary
> 
> The news here is small, again. Last I heard, Jason is planning on incorporating
> the new 'mkarchroot' tool from devtools into pacbuild. Anything else, I am
> unsure of.
> 
> Jason, would you mind informing us on what needs to be done to get pacbuild
> running somewhere? I'd like to do _something_ here before this becomes
> vaporware.
> 
> * Modernize our Dashboard
> 
> Ok, we've made some steps. We now have our web code up here:
> http://projects.archlinux.org/git/?p=archweb.git;a=summary
> 
> I plan on filling out the README as far as running your own instance goes.
> 
> >From there, I'd like people to add any and all dashboard related requests to the
> "Internal Dev" bug tracker, so we can begin closing them out.
> 
> 
> * Architecture Independent Repos
> 
> Roman has provided us patches for makepkg on the pacman-dev list. That's step
> one. The next step is to modify our DB scripts to check for the proper suffix,
> and run itself for both the i686 and x86_64 repos.
> 
> This one is a rather small change, is anyone interested in doing this? Thomas?
> 
> * ArchCon 2009: Big Baaad Idea
> 
> http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html
> 
> ArchCon is still floating here at the bottom of the list...but it looks like no
> one is interested anymore. That's sad. No one wants to come visit lil ol' me?
> 
> _______________________________________________
> arch-dev-public mailing list
> arch-dev-public at archlinux.org
> http://archlinux.org/mailman/listinfo/arch-dev-public
-- 
K. Piche <kpiche at rogers.com>