December 2008 - Aur-general - lists.archlinux.org

Re: [aur-general] [arch-general] opensp compile fails
by Daenyth Blank 03 Dec '08

03 Dec '08

On Tue, Dec 2, 2008 at 20:33, Baho Utot <baho-utot(a)columbus.rr.com> wrote: > > OpenSp PKGBUILD fails to compile with the following error: > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic -march=native -O2 -pipe -fomit-frame-pointer -c > ArcEngine.cxx -MT > ArcEngine.lo -MD -MP -MF .deps/ArcEngine.TPlo -fPIC -DPIC -o .libs/ArcEngine.lo > In file included from ArcEngine.cxx:20: > ../include/InternalInputSource.h:37: error: extra > qualification 'OpenSP::InternalInputSource::' on > member 'asInternalInputSource' > make[3]: *** [ArcEngine.lo] Error 1 > make[3]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/scrat/ARCH/opensp/src/OpenSP-1.5.1' > make: *** [all] Error 2 > ==> ERROR: Build Failed. > > It looks like it is orphaned so > > Here is a patch to fix this: > > cat InternalInputSource.patch > > --- OpenSP-1.5.1~/include/InternalInputSource.h 2003-07-17 > 14:14:00.000000000 -0400 > +++ OpenSP-1.5.1/include/InternalInputSource.h 2008-11-13 > 12:24:04.591406546 -0500 > @@ -34,7 +34,7 @@ > void pushCharRef(Char ch, const NamedCharRef &); > Boolean rewind(Messenger &); > const StringC *contents(); > - InternalInputSource *InternalInputSource::asInternalInputSource(); > + InternalInputSource *asInternalInputSource(); > ~InternalInputSource(); > private: > InternalInputSource(const InternalInputSource &); // undefined > > Here is a patch file for the PKGBUILD > > cat PKGBUILD.patch > > --- PKGBUILD 2008-12-02 20:27:40.102778984 -0500 > +++ pkgbuild 2008-12-02 20:27:29.412780668 -0500 > @@ -15,6 +15,7 @@ > cd $startdir/src/OpenSP-$pkgver > pwd > patch -Np1 -i ../opensp-gcc34.patch || return 1 > + patch -Np1 -i ../InternalInputSource.patch || return 1 > ./configure --prefix=/usr \ > --disable-nls \ > --enable-http \ > If it's orphaned in the AUR, simply adopt it and update it with your fixes.

1 0

[aur-general] Orphan request: nestopia gens yabause
by Tiago Pierezan Camargo 03 Dec '08

03 Dec '08

Hi, Those packages (nestopia, gens, and yabause) are flagged out of date for some time. I tried to contact the maintainer without success. I'd like to adopt those packages. -- Tiago Pierezan Camargo milopi @ irc.freenode.net

5 8

[aur-general] pkgstats and community - attempt 2
by Allan McRae 03 Dec '08

03 Dec '08

This whole thing has got a bit out of hand... All I wanted to do was organize a meeting for TUs to discuss the results of the pkgstats script. And now I arrive back to ~70 email with back and forward about how things should be. I am actually quite disappointed with some of the responses there. I'll put this out there first before I carry on with this email. I am a dev. I am a TU. I do not care about titles and my only aim here is to serve the Arch community better. I am not taking a dev or TU point of view here at all. I may not have been around as long as others but I know the history of the community repo and the AUR voting system. That being said, the pkgstats results point to a problem in the [community] repo. I suggested we should discuss this on IRC at some stage. ~70 emails later, that option seems to have been forgotten. So here is the issue: * There is no point taking up server space and bandwidth with packages that nobody or very, very few people use. * pkgstats points to a few hundred packages that fall into the not very used category in both [extra] and [community]. The devs are discussing what to with packages in [extra]. Note that does not necessarily mean those packages are automatically dropped to the AUR as that make no sense for some packages. I.e. compromise is being made. Please read that again. Compromise... So we need to think about what the purpose of the [community] repo is. It is obviously to supplement [core] and [extra]. Packages in [core] are the base of a system, packages in [extra] define Arch as a distro and are widely used by its users, packages in [community] do what? So lets start there. What should the [community] repo be doing? What is its purpose? There is no point discussing anything else until that is well defined. All responses must start with "The [community] repo is ..." Allan

6 5

[aur-general] package update request
by Henri Häkkinen 02 Dec '08

02 Dec '08

Hello, The vala 0.3.5-1 package seems to be seriously out of date and the author is not responding to my requests. Could somebody update this or can I assume the ownership of it? http://aur.archlinux.org/packages.php?ID=7203 -- Henri Häkkinen

3 4

[aur-general] community back-end rewrite
by Allan McRae 02 Dec '08

02 Dec '08

Hi all, In the TU meetings there was some discussion about doing a rewrite/update/fix-up of the [community] back-end. I am not sure who all is looking at this and what the plans are - hence this email. Can people who are looking at this or interested in looking at this give a ping back to this message with whatever plans you have or work you have already done. Things I want to flag: - we should get a git repo for a community-backend project on the arch server and separate this from the aur site code. - we should switch SCM tools from CVS. I am strongly in favour of using the same system as the main repos which would allow much code reuse and easily get us a testing repo for community packages. (No more big rebuild issues!). Allan

5 11

[aur-general] Proposed rules for packages entering [community]
by Allan McRae 02 Dec '08

02 Dec '08

Hi all, As part of the TU meetings it was decided to post the proposal for restricting packages entering [community] here for discussion before voting. Here is the current wording: [proposal] * Only "popular" packages may enter the repo, as defined by 1% usage from pkgstats or 10 votes on the AUR. * Automatic exceptions to this rule are: - i18n packages - accessibility packages - drivers - dependencies, including makedeps and optdeps - packages that are part of a collection and are intended to be distributed together, provided the primary part of this collection satisfies the definition of popular * Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package) at which point a general consensus from the TUs will be reached. TUs with large numbers of "non-popular" packages are more likely to be rejected. * TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur. [end proposal] So, go ahead and discuss. Especially focus on the wording and regions that people would feel need clarification before I call for a formal vote. In particular, I think the process for addition of packages which do not meet the popularity criteria needs to be defined better, so any ideas there would be appreciated. Any further additions to do with cleaning the current package load in [community] for low usage package is a separate issue and will be discussed at a later date. Allan

6 9

[aur-general] Current TUs
by Aaron Griffin 02 Dec '08

02 Dec '08

Would someone mind telling me which people on this list are no longer TUs? This is the CVS passwd file... whoops http://dev.archlinux.org/~aaron/tu_names

8 16

Re: [aur-general] Proposed rules for packages entering [community]
by Loui Chang 01 Dec '08

01 Dec '08

On Mon, Dec 01, 2008 at 11:54:20PM +1000, Allan McRae wrote: > Daenyth Blank wrote: > > On Sun, Nov 30, 2008 at 22:27, Allan McRae <allan(a)archlinux.org> wrote: > > > >> Hi all, > >> > >> As part of the TU meetings it was decided to post the proposal for > >> restricting packages entering [community] here for discussion before > >> voting. > >> > > > > My primary issue with the current proposal is that I feel 10 votes is > > slightly high for a first step. I'd *much* rather see 3-5 as a > > minimum, and I think others would as well. > > > > 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. How does that achieve a net result of nothing? If these rules were already in place it could have meant a net result of more than 500 less packages in community that we need to deal with.

2 1

Re: [aur-general] Proposed rules for packages entering [community]
by Daenyth Blank 01 Dec '08

01 Dec '08

> 89/97 packages with 0% usage on package stats have 5 votes or less. So this > would achieve a net result of nothing. > Allan > I didn't realize that was the case. I retract my point then.

1 0

Re: [aur-general] TU Meeting
by Daenyth Blank 01 Dec '08

01 Dec '08

On Mon, Dec 1, 2008 at 08:23, Daenyth Blank <daenyth(a)gmail.com> wrote: >> - It was proposed to add a safe flag on TUs packages in the AUR to encourage >> TUs to leave packages out of community while still being marked in a way as >> they are known to be good PKGBUILDs > > I missed this part... luckily. Safe flags were happily killed with a > few months ago. If you mean to add them to [community] packages only, > then it doesn't make sense to me: to make a TU you don't just need the > User, you also need the Trust. Either you don't T the U from the > beginning (and s/he doesn't get elected) or you T, and then you don't > need to flag anything. If someone notices an anomaly in a TU's > PKGBUILD quality, it should readily be reported to the list to take > action. The idea was that some people were putting packages in community which didn't need to be there, for the reason that having it in community assures that it's safe. If it were brought back, it would be for the purpose of encouraging TUs to use unsupported for packages that don't belong in community, while still allowing users to see *at a glance* if the package was made by a TU or not. Maybe code can explain better... on_upload { [...do stuff...] flag_unsafe $package if $uploader.is_a_tu then flag_safe $package }

1 0