We decided keep our AUR2 development and in same time help current AUR.
Besides that, we gonna try close bug reports on flyspray.
We'll be glad if others join us in this effort.
Everyone is invited to send me an email if want to help or just see
what are we doing.
Tomás A. Schertel
Linux Registered User #304838
Arch Linux User
On Thu, Dec 16, 2010 at 13:46, Thomas Dziedzic <email@example.com> wrote:
> On Thu, Dec 16, 2010 at 9:33 AM, C Anthony Risinger <firstname.lastname@example.org> wrote:
>> On Thu, Dec 16, 2010 at 1:09 AM, Alexander Duscheleit
>> <email@example.com> wrote:
>>> On Tue, 14 Dec 2010 12:12:46 -0600
>>> C Anthony Risinger <firstname.lastname@example.org> wrote:
>>>> On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae <email@example.com>
>>>> >> ** git://ius.student.utwente.nl/aur2 -- Thralas's repository
>>>> >> ** git://git.berlios.de/aur2 -- Djszapi's repository
>>>> >> ** git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked
>>>> >> repo with some patches and translation's.
>>>> > I'll add "AUR3" to the mix... -
>>>> > https://bbs.archlinux.org/viewtopic.php?id=99839
>>>> i haven't made any release or update to BBS (or README :-) in some
>>>> time, but a fair amount of work + thought has gone into this. *if
>>>> you'd like, check out the 'pmvc-refactor' branch here:
>>>> it will be the path forward, and is based on the lightweight puremvc
>>>> framework to add a little sanity. *i encourage you to take a look, as
>>>> the code is remarkably small, fast, free of any HTML/compatibility
>>>> nuances, but still leverages the full power of the most advanced GUI
>>>> available... a web browser, an excellent language... python, and a
>>>> competent widget library based on GWT. *it's a fully client side
>>>> server (or a local daemon...) other than JSON-RPC endpoints, which can
>>>> be implemented in any language.
>>> Just out of curiosity, how will this accommodate links/lynx or
>>> brltty/espeak/etc. users?
>> it would not i suppose -- someone else would need to create a front
>> end that renders static HTML. *the rest of the code and library could
>> be reused... i don't have much interest in implementing that, but i do
>> plan to work on a CLI interface once other aspects have been
>> completed, so that would be an option too.
>> the frontends speak with a local JSON-RPC daemon, so really it can be
>> anything (in fact one of my super secret awesomo goals is to wire a
>> visualizer to the daemon once it's distributed, and visualize the
>> Archlinux network).
>> i'm about to have a whole lotta time freed up, so i'll finally be able
>> to work on this again... this project's on my mind everyday and it
>> annoys me when i can't work on it :-)
>> C Anthony
> If you guys are willing to work on any part of the code in the aur,
> there are 3 things that I have always found missing in the aur which I
> think are essential.
> FS#15043 - Need better parsing of PKGBUILDs
> Does this need explaining? It's also pretty annoying.
> There are tons of examples on the aur where download sources are like
> The above example isn't the only thing that is bad at being parsed,
> check out bug report for full details.
> FS#16394 - Split Packages in AUR
> Obviously things like mesa would greatly benefit from this. Also would
> allow us to remove a lot of redundant packages.
> FS#21600 - canonical links
> Although this isn't a necessity, and should probably get low priority,
> I think this would be a nice addition. It would make links to the aur
> human understandable.
> Well hope you take what I said into some consideration.