- Aur-general - lists.archlinux.org

[aur-general] Duplicate package: libpam_mysql
by Firebird347 24 Jan '11

24 Jan '11

libpam_mysql (http://aur.archlinux.org/packages.php?ID=25249) is a duplicate of the package 'pam_mysql' in community. Thanks, Cody Maloney Random side note: pam_mysql should depend on libmysqlclient not mysql. Every client doesn't need to have MySQL installed.

2 1

[aur-general] TU Bylaws Amendment (SVP Section): Discussion Period
by Xyne 23 Jan '11

23 Jan '11

The following is a proposed replacement for the current SVP section of the TU bylaws: https://wiki.archlinux.org/index.php?title=Bylaw_Amendment&oldid=124557 The changes address several issues recently brought up on this list. Briefly, these include: * enabling a vote to pass in the absence of quorum when more than 50% of active TUs have voted YES * enabling a vote to fail in the absence of quorum when 50% or more of active TUs have voted NO * clarifying the text to eliminate ambiguities Please see Kaiting's "[aur-general]Amendment" thread and Loui's "[aur-general][PATCH]tu-bylaws: Amend Standard Voting Procedure" thread for more details. This message marks the beginning of the 5-day discussion period before the amendment is put to a vote.

9 15

[aur-general] A duplicate
by François Boulogne 23 Jan '11

23 Jan '11

Hello, Please, could you remove [1], it is a duplicate of [2]. I pushed this PKGBUILD by mistake. Cheers. [1] http://aur.archlinux.org/packages.php?ID=45689 [2] http://www.archlinux.org/packages/extra/any/perl-uri/ -- François Boulogne. Membre de l'April - Promouvoir et défendre le logiciel libre http://www.april.org

2 1

Re: [aur-general] TU Application - Seblu
by Seblu 23 Jan '11

23 Jan '11

On Mon, Jan 17, 2011 at 10:04 AM, Ronald van Haren <pressh(a)gmail.com> wrote: > On Mon, Jan 17, 2011 at 12:41 AM, Seblu <seblu(a)seblu.net> wrote: >> On Sun, Jan 16, 2011 at 10:09 PM, Ronald van Haren <c> wrote: > Some pointers > > - cairo-xcb is broken and unmaintained by upstream http://cgit.freedesktop.org/cairo/log/ i see several commit from this january about xcb. Reading changelog, the backend does not seem abandoned. i see activity on ml: http://lists.cairographics.org/archives/cairo/2010-December/thread.html http://lists.cairographics.org/archives/cairo/2010-November/thread.html http://lists.cairographics.org/archives/cairo/2010-October/thread.html i see patched on last release changelog: http://cairographics.org/news/cairo-1.10.2/ > - cairo-xcb is known to cause X crashes and rendering issues Crawling arch bugtracker is not really revelent of this. I don't find many bugs around this issue (maybe not detected as corollary). RedHat bug is not really accurate. I also use cairo-xcb from aur everyday and i don't see issues. > - crashes and redering issues will probably appear in other > applications than awesome Sure! This is to avoid. > - people don't know that they are using something that is unsupported > (at least by upstream) Upstream speak about experimental feature, not unsupported (see README). By our bleeding edge point of view, we enable a lot of experimental feature (in particular in linux kernel). Experimental "tag" is not always a synonym of unstable (or unsuported) but more like really Bleeding edge. > - it is generally a bad idea to support something which is encouraged > not to by upstream I agree. But i'm wondering why debian include it by default in next release (squeeze) http://git.debian.org/?p=collab-maint/cairo.git;a=blob;f=debian/rules;h=927… I see in configure, they include --enable-xlib and --enable-xcb. _Maybe_ we can enable the two to have the best of both worlds. This need more investigation. > So unless you want to fix all issues in cairo-xcb, it is probably not > a good idea to support it. In case you will, upstream is also looking > for a maintainer of the xcb backend if I'm not mistaken. I don't see the job offer :) > But then > again, you may need to first fix all issues before you bring it in :-) > I see the point. I would contact cairo debian maintainers about that. To have their point of view. -- Sébastien Luttringer www.seblu.net

7 11

[aur-general] Please orphan python-wtforms
by Felix Kaiser 23 Jan '11

23 Jan '11

Dear TUs, can someone please orphan python-wtforms [1]? The PKGBUILD is heavily outdated, it hasn't been modified for over a year and doesn't even build anymore. Another user (FSX) said in the comments that he has emailed the current package maintainer (welterde) a while back but never got a reply. Thank you very much! Felix [1] http://aur.archlinux.org/packages.php?ID=26120

2 1

[aur-general] deletion request ffmpeg-svn
by Christian Scharkus 22 Jan '11

22 Jan '11

Hi :) I would like ffmpeg-svn to be deleted because it's out-of-date and the ffmpeg svn repository won't receive any more updates by reason of the ffmpeg project switching to git. So it would be kind of misleading to have two development packages in aur and one of them frozen. thanks raubkopierer

2 1

[aur-general] Deletion request
by Seblu 22 Jan '11

22 Jan '11

Hello, ipset4 is "out-of-date", duplicate of ipset and orphan. http://aur.archlinux.org/packages.php?ID=34078 Regards, -- Sébastien Luttringer www.seblu.net

2 1

[aur-general] Please settle 'base' in 'depends' for all
by Kaiting Chen 21 Jan '11

21 Jan '11

Okay everyone, every time I ask I get a different answer. According to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also Dziedzic votes that *no* package in 'base' should be in 'depends'. Can we settle once and for all what the correct policy is? And then can we update the wiki page and all of these packages http://www.archlinux.org/packages/core/i686/glibc/so that they reflect the policy? --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

19 40

[aur-general] Python 3
by Xyne 21 Jan '11

21 Jan '11

Andrea Scarpino wrote: > Hi AUR maintainers, > I did a change in the pyqt package to add Python 3 support to it and to allow > everyone to install both the Python2 and the Python3 version. > Every package now need to depends on python2-qt (or python-qt if uses Python > 3) instead of pyqt. > The packages in [extra] and [community] have been updated, please do the same > with your packages in AUR. > > Also, the packages which depend on sip have to be fixed with the right > dependence: python2-sip (or python-sip if the package uses Python 3). > > Thank you! > > -- > Andrea I'm replying because this is tangential... why don't we specify "python3" instead of "python" as a dep to make packages future-proof? Even if Python 4 doesn't come out for a decade or more, it just seems that it would be logically consistent.

2 1

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
by Pierre Chapuis 21 Jan '11

21 Jan '11

On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae <allan(a)archlinux.org> wrote: > The problem is that the transitive closure can not be assumed to be > correct. > > e.g. At the time A is built: > > A -> B,C,D,E > B -> C,D,E > C -> D,E > > Then B is updated and > > B -> C,D,E,F. > > Now the assuming a transitive closure for the dependency list for A > is incorrect. Installing the listed dependencies of A with the > equivalent of -Sd would result in F not being installed which would > break A through broken B. > > So either: > 1) we require a largely unnecessary rebuild of A > 2) we always check the dependencies of uninstalled dependencies. > > Note #2 is less burden on packagers and is more efficient in the > examples given above if both B and D are installed (two checks vs > four), and that will be the case for most system updates. When none > of A - E are installed, they are probably equally efficient. Yes, I agree with that: dependencies will always have to be checked at package install time. That means that any approach based on a "transitive closure" at packaging time is useless. What could also happen is that C is updated and no longer needs E. Then, with a "transitive closure", A would still install E, which would be useless for the user. So the only way to be safe is not to be clever and to specify real dependencies, eg: Real deps --------- A -> B,D B -> C C -> D,E Transitive closure ------------------ A -> B,C,D,E B -> C,D,E C -> D,E Current Arch way ---------------- A -> B B -> C C -> D,E What should be done ------------------- A -> B,D B -> C C -> D,E -- Pierre 'catwell' Chapuis

4 3