i want to upgrade these Packages:
I will also fix these Packages for amd64 Support.
URL : http://blog.stefan-betz.net | http://www.stefan-betz.net
GPG : E188 933B BC00 723A 9DB0 0CD3 1398 E68B 6F33 567E
In response to Louis objections about skipping the discussion period,
I'm posting the full text of the proposal below. It has been altered
from the original text
to incorporate Xynes idea of adding the 'last maintainer activity rule.
Sorry for making you guys vote twice.
This marks the beginning of the discussion period.
recently I had a look at the AUR db to see if we could do some mass cleanups
(see my mail at aur-general ).
Packages which are marked 'out of date' but the last package action
(submission or modification)
AND the maintainers last action (across all of his packages) are before
January 1st, 2009.
Out of date = TRUE
AND Last package action < 20090101
AND Last maintainer action < 20090101
(335 packages in the most recent DB dump - results may vary a little
when querying the actual db)
Valid objections in reply to  (and any other related threads) would
While many of these packages are probably candidates for deletion,
the only safe thing to do en masse is to orphan them.
Please vote 'yes' if you agree with orphaning these packages and 'no' if
Hi aur-general, my name is Kaiting Chen and Xyne has decided to sponsor me
for my TU application.
I'm twenty one years old and a senior at Duke University studying Biomedical
Engineering with a minor in Economics. I have also been a web developer and
systems administrator for about four years now and am currently working on a
rather long and protracted project for the university. I have been using
Linux on a daily basis for about seven years now starting with Red Hat
Linux, then Debian, Gentoo and finally Arch Linux for the last three years.
I have Arch installed on four servers in total as well as on one virtual
machine. I'm not ashamed to admit that I run a Windows 7 notebook as my only
physical computer; though it's only role these days is to not bother me
while I SSH into my Linux machines.
I maintain a small cluster running Arch where I hand out free shell accounts
to anyone who wants them. Currently this cluster has one hundred and twenty
five users though I am in the process of updating its infrastructure to
(hopefully) scale up to a couple thousand. The most important services on
this cluster are/were glusterfs, nfs, ntpd, httpd, vsftpd, postfix, dovecot,
postgresql, ejabberd, slapd, openvpn, memcached, pvpgn (this list is being
updated quite often).
I currently maintain thirty packages in the AUR, most of which I do not use
but would be unhappy in seeing them orphaned.
I would like to become a Trusted User simply because I would like to
maintain packages more effectively. Recently there's been a thread on
aur-general about the possible removal of hundreds of packages from
[community] which makes me very worried. Packages such as cacti, courier-*,
ejabberd, freeradius*, ipsec-tools, monit, roundcubemail, scilab, and *ircd
are very important to people who run Arch on the server such as myself. This
list evinces a fundamental problem however that there is simply not enough
manpower to maintain the current repositories. Because I am able (or
hopefully will be deemed so by the powers that be/grant TU priveleges) I
would like to help alleviate this condition. Arch allows me to focus on the
work that I do; it should be obvious that helping to ensure that Arch
functions smoothly and efficiently is a necessary task for anyone who has
made this distribution a valuable part of their workflow.
In more concrete terms of how I want to contribute, I would like to start by
adopting python-openbabel, freeimage, metakit, gen2shp, tdl, python-bsddb,
and other orphaned packages in [community] once I have the chance to take a
closer look at the orphan list. I'd also like to pull smalltalk, burp, bti,
liboauth, and vim-align into [community]. I would also like to work on
bringing some of the packages in [community] up to date such as rsyslog,
pyinotify, openntpd, and ngspice.
I would also like to work on maintain the Arch web presence. I think that a
separate login is needed for each part of the site is something that should
be fixed. The AUR is also somewhat outdated and I in large part agree with
the page here: http://wiki.archlinux.org/index.php/AUR_2.
That's about all I can think of for now. Please feel free to ask any
questions and thanks for taking the time to consider my application.
Kiwis and Limes: http://kaitocracy.blogspot.com/
I'll start this discussion with an example of the problem.
I notice that python-sqlalchemy is about to change in [community].
Most of the packages which depend on it will need to change their
dependency to python2-sqlalchemy. This is handled quite nicely for
packages in the binary repositories. If you do a package search on
www.archlinux.org, you'll see which packages require python-sqlalchemy.
Likewise, it is easy to get a list of [unsupported] packages which
require a given package from [unsupported]. However, I don't know of a
way to get a list of [unsupported] packages which require a given
package from the binary repositories. If it were possible to build such
lists, we could contact maintainers of [unsupported] packages, in order
to inform them of upcoming changes which require their attention.
Recently github switched over to using SSL for their entire website
. Currently wget does not accept the wildcard *.github.com in the
$ wget http://github.com/
--2010-11-06 15:45:12-- http://github.com/
Resolving github.com... 22.214.171.124
Connecting to github.com|126.96.36.199|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/ [following]
--2010-11-06 15:45:12-- https://github.com/
Connecting to github.com|188.8.131.52|:443... connected.
ERROR: certificate common name `*.github.com' doesn't match requested
host name `github.com'.
To connect to github.com insecurely, use `--no-check-certificate'.
This can be solved/worked around by passing --no-check-certificate to
wget, something that makepkg does by default (DLAGENTS in
/etc/makepkg.conf) _only_ for sources with the protocol https://. It
does not do this for http sources, and of course does not know about
any redirects to https.
So my question is, what is the recommended course of action here,
updating all PKGBUILDs that grab from github to point to the https
source? Or is it wget's problem and we should just wait for an update?
It has been fixed in wget's git repo but not released yet .
FYI: This is known to the github people, and they consider it wget's