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
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
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 (Роман Кирилич)
---------- Forwarded message ----------
From: James Rayner <iphitus(a)gmail.com>
Date: 6 Лис 2007 00:38
Subject: [arch] netcfg2 is now in [testing]
To: arch(a)archlinux.org
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 (http://wiki.archlinux.org/index.php/Network_Scripts)
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
(http://wiki.archlinux.org/index.php/Network_Scripts#Testing). 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:
http://wiki.archlinux.org/index.php/Network_Profiles
--
Roman Kyrylych (Роман Кирилич)
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.htmlhttp://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.
* 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?
2007/11/5, James Rayner <iphitus(a)gmail.com>:
> 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[1].
>
> 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 [2].
>
> [1] http://bugs.archlinux.org/task/4490
> [2] http://archlinux.org/pipermail/arch-dev-public/2007-November/002870.html
>
> 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.
>
--
Roman Kyrylych (Роман Кирилич)