Re: [arch-general] We want to help
Hi guys.
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
http://www.archlinux-br.org/
--
On Thu, Dec 16, 2010 at 13:46, Thomas Dziedzic wrote:
> On Thu, Dec 16, 2010 at 9:33 AM, C Anthony Risinger wrote:
>> On Thu, Dec 16, 2010 at 1:09 AM, Alexander Duscheleit
>> wrote:
>>> On Tue, 14 Dec 2010 12:12:46 -0600
>>> C Anthony Risinger wrote:
>>>
On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae
wrote:
>> * 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:
https://github.com/extofme/aur-pyjs/tree/pmvc-refactor
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
javascript (or python-DOM) application requiring nothing from the
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
> https://bugs.archlinux.org/task/15043?project=2
> Does this need explaining? It's also pretty annoying.
> There are tons of examples on the aur where download sources are like
> http://foo.com/foo-{pkgver:0:5.tar.gz
> 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
> https://bugs.archlinux.org/task/16394?project=2
> Obviously things like mesa would greatly benefit from this. Also would
> allow us to remove a lot of redundant packages.
>
> FS#21600 - canonical links
> https://bugs.archlinux.org/task/21600?project=2
> 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.
> Cheers!
>
Re: [arch-general] We want to help
On Thu, Dec 16, 2010 at 9:33 AM, C Anthony Risinger wrote:
> On Thu, Dec 16, 2010 at 1:09 AM, Alexander Duscheleit
> wrote:
>> On Tue, 14 Dec 2010 12:12:46 -0600
>> C Anthony Risinger wrote:
>>
>>> On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae
>>> wrote:
>>> >> * 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:
>>>
>>> https://github.com/extofme/aur-pyjs/tree/pmvc-refactor
>>>
>>> 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
>>> javascript (or python-DOM) application requiring nothing from the
>>> 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
https://bugs.archlinux.org/task/15043?project=2
Does this need explaining? It's also pretty annoying.
There are tons of examples on the aur where download sources are like
http://foo.com/foo-{pkgver:0:5.tar.gz
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
https://bugs.archlinux.org/task/16394?project=2
Obviously things like mesa would greatly benefit from this. Also would
allow us to remove a lot of redundant packages.
FS#21600 - canonical links
https://bugs.archlinux.org/task/21600?project=2
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.
Cheers!
Re: [arch-general] We want to help
On Thu, Dec 16, 2010 at 1:09 AM, Alexander Duscheleit wrote: > On Tue, 14 Dec 2010 12:12:46 -0600 > C Anthony Risinger wrote: > >> On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae >> wrote: >> >> * 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: >> >> https://github.com/extofme/aur-pyjs/tree/pmvc-refactor >> >> 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 >> javascript (or python-DOM) application requiring nothing from the >> 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
Re: [arch-general] We want to help
On Thu, Dec 16, 2010 at 05:57, Andrea Scarpino wrote: > On Wednesday 15 December 2010 22:45:21 Loui Chang wrote: >> Finally, I'd like to honestly say I don't see AUR2 as really being a >> worthwhile investment for the next generation of the AUR. It's just >> another web app like the current AUR, it might have a couple extra >> frills, but I don't think it makes sense to rewrite the whole thing just >> for that sake. They can probably added easily enough to the current >> code. > I agree. > Instead of write code for AUR2, you guys should help fixing current AUR bugs > or > implement new AUR features. Just my two cents. Guys, we're here to help where project needs. If you say the best effort is expand the current AUR, we gonna help on this. If you say that we need to close bug reports in flyspray, we gonna help on this. I agree that rewrite AUR just to have it running on Django but with no new BIG features is like working in vain. I'll start looking for PHP developers (to implement features on current AUR) and looking people to help on closing bur reports on flyspray. It that OK for you guys? > > Cheers > > -- > Andrea Scarpino > Arch Linux Developer > -- Tomás A. Schertel -- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ --
Re: [arch-general] We want to help
On Wednesday 15 December 2010 22:45:21 Loui Chang wrote: > Finally, I'd like to honestly say I don't see AUR2 as really being a > worthwhile investment for the next generation of the AUR. It's just > another web app like the current AUR, it might have a couple extra > frills, but I don't think it makes sense to rewrite the whole thing just > for that sake. They can probably added easily enough to the current > code. I agree. Instead of write code for AUR2, you guys should help fixing current AUR bugs or implement new AUR features. Just my two cents. Cheers -- Andrea Scarpino Arch Linux Developer
Re: [arch-general] We want to help
On Tue, 14 Dec 2010 12:12:46 -0600 C Anthony Risinger wrote: > On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae > wrote: > >> * 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: > > https://github.com/extofme/aur-pyjs/tree/pmvc-refactor > > 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 > javascript (or python-DOM) application requiring nothing from the > 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?
Re: [arch-general] We want to help
On Tue 14 Dec 2010 09:54 -0200, Tomás Acauan Schertel wrote: > The Brazilian Arch Linux Community wants to help Arch Linux project, > working on bug reports and feature requests. > As first task, we plan to help conclude the development of AUR version 2. > > We don't have lots of developers, but we really want to help. And > maybe others join us on this effort. > > To accomplish this, we need to enlighten some points: > > 1 - where should we look for feature requests? > * bugs.archlinux.org? > * AUR2 wiki page? > > 2 - what code repository should we take as start point? > * git://gitorious.org/aur2/aur2.git -- the "central" repository with > the stable branch > * git://github.com/sebnow/aur2.git -- Xilon's repository > * 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. > > 3 - How Feature Requests / Bug Reports will be closed on flyspray? > * Maybe a TU can do the job. > > Maybe things get easier if just one (maybe two) TU`s leads us on work. Well, the AUR2 is a completely independent project. I don't think that it should be tracked on the bugtracker for the current AUR - that's unless the Trusted Users decide to adopt it instead of the current codebase. So the answer to question 1 would be the wiki page. 2. I believe you should follow the "central" repo if you decide to develop on AUR2. 3. I think it's best if AUR2 had a separate tracker. Finally, I'd like to honestly say I don't see AUR2 as really being a worthwhile investment for the next generation of the AUR. It's just another web app like the current AUR, it might have a couple extra frills, but I don't think it makes sense to rewrite the whole thing just for that sake. They can probably added easily enough to the current code. As I see it I agree totally with Anthony's vision of what the future of the AUR should look like. I've actually thought about this for a few years, but I lack the talent to start any implementation. I'm not sure if we will be able to jump right into it though. It might take a couple of generations of the system. A first step would be to take the interface out of the server and have the client deal with that. I think you should take a look at Eli Janssen's AUR json daemon. https://github.com/cactus/spew and C Anthony Risinger's aur-pyjs https://github.com/extofme/aur-pyjs Cheers.
Re: [arch-general] We want to help
> On Tue, Dec 14, 2010 at 1:23 PM, Kaiting Chen wrote: >> Out of curiosity why is everyone so again just writing Javascript? Everyone >> seems to want to write in some other language and then compile to Javascript >> these days. --Kaiting. >> >> -- >> Kiwis and Limes: http://kaitocracy.blogspot.com/ >> > On Tue, Dec 14, 2010 at 2:57 PM, Ignacio Galmarino wrote: > Because writing javascript that is compatible con every mayor browser > "by hand" is a very hard work > > Ignacio > Sorry for top posting ...fg gmail defaults ! Ignacio
Re: [arch-general] We want to help
Because writing javascript that is compatible con every mayor browser "by hand" is a very hard work Ignacio On Tue, Dec 14, 2010 at 1:23 PM, Kaiting Chen wrote: > On Tue, Dec 14, 2010 at 2:14 PM, C Anthony Risinger wrote: > >> the benefit to the pyjs approach is 100% client side operation, so it >> can run without online access. additionally, the python-DOM version >> (or the pyjs version if proxying thru a local daemon) could >> potentially direct install from the website, leading to "install now" >> functionality. lastly, python means you could use the same lang to >> write the front end and the backend, and communicate using JSON >> messages. >> >> as a professional web applications developer by day, i can vouch that >> writing webapps requires knowledge of about 4 different haphazardly >> implemented "standards", requiring far to much painfully acquired >> knowledge. by using a library like pyjamas, you allow anyone with >> python experience to write incredibly functional plugins/modules, and >> share maintenance load. django is a great platform, but after i >> discovered pyjamas about 1yr ago, i haven't looked back, and am >> convinced that compiler technology is the only sane way to develop >> complex and maintainable web-based applications. >> > > Out of curiosity why is everyone so again just writing Javascript? Everyone > seems to want to write in some other language and then compile to Javascript > these days. --Kaiting. > > -- > Kiwis and Limes: http://kaitocracy.blogspot.com/ >
Re: [arch-general] We want to help
El 14/12/10 01:14, C Anthony Risinger dijo: > On Tue, Dec 14, 2010 at 12:39 PM, Tomás Acauan Schertel > wrote: > > You've done a great job Anthony. Your app is a all-in-one! > > Our focus is (was) create a better AUR, with new features and using > > other platform (from php to django). I think your focus is a little > > different, isn't? > > well, the immediate focus is to create a better AUR, feature > complete++ to the current one, but with the additional goal of > eventually decoupling it from a client-server model, and ultimately > from archlinux altogether. i have some ideas about a 100% > "distributed distribution", but that's neither here nor there :-). > > so no, not really. i intend to create a sweet AUR. the AUR really > stood out when i came to archlinux, and set it apart from others; it's > highly related to my own research and interests, and in general just > needs an overhaul. > > the benefit to the pyjs approach is 100% client side operation, so it > can run without online access. additionally, the python-DOM version > (or the pyjs version if proxying thru a local daemon) could > potentially direct install from the website, leading to "install now" > functionality. lastly, python means you could use the same lang to > write the front end and the backend, and communicate using JSON > messages. > > but yeah in the medium run, i'd like to see archlinux.org function as > a simple state tracker, linking users together, and letting them share > and manage their own PKGBUILD repositories. in the long run, > archlinux.org is dropped altogether, and the AUR is completely P2P. > > as a professional web applications developer by day, i can vouch that > writing webapps requires knowledge of about 4 different haphazardly > implemented "standards", requiring far to much painfully acquired > knowledge. by using a library like pyjamas, you allow anyone with > python experience to write incredibly functional plugins/modules, and > share maintenance load. django is a great platform, but after i > discovered pyjamas about 1yr ago, i haven't looked back, and am > convinced that compiler technology is the only sane way to develop > complex and maintainable web-based applications. > > C Anthony > p2p-aur \o/ -- Salud! Nicolás Reynolds, xmpp:fa...@kiwwwi.com.ar omb:http://identi.ca/fauno blog:http://selfdandi.com.ar/ gnu/linux user #455044 http://librecultivo.org.ar http://parabolagnulinux.org pgp3HcLCy6ybI.pgp Description: PGP signature
Re: [arch-general] We want to help
On Tue, Dec 14, 2010 at 2:14 PM, C Anthony Risinger wrote: > the benefit to the pyjs approach is 100% client side operation, so it > can run without online access. additionally, the python-DOM version > (or the pyjs version if proxying thru a local daemon) could > potentially direct install from the website, leading to "install now" > functionality. lastly, python means you could use the same lang to > write the front end and the backend, and communicate using JSON > messages. > > as a professional web applications developer by day, i can vouch that > writing webapps requires knowledge of about 4 different haphazardly > implemented "standards", requiring far to much painfully acquired > knowledge. by using a library like pyjamas, you allow anyone with > python experience to write incredibly functional plugins/modules, and > share maintenance load. django is a great platform, but after i > discovered pyjamas about 1yr ago, i haven't looked back, and am > convinced that compiler technology is the only sane way to develop > complex and maintainable web-based applications. > Out of curiosity why is everyone so again just writing Javascript? Everyone seems to want to write in some other language and then compile to Javascript these days. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] We want to help
On Tue, Dec 14, 2010 at 12:39 PM, Tomás Acauan Schertel wrote: > You've done a great job Anthony. Your app is a all-in-one! > Our focus is (was) create a better AUR, with new features and using > other platform (from php to django). I think your focus is a little > different, isn't? well, the immediate focus is to create a better AUR, feature complete++ to the current one, but with the additional goal of eventually decoupling it from a client-server model, and ultimately from archlinux altogether. i have some ideas about a 100% "distributed distribution", but that's neither here nor there :-). so no, not really. i intend to create a sweet AUR. the AUR really stood out when i came to archlinux, and set it apart from others; it's highly related to my own research and interests, and in general just needs an overhaul. the benefit to the pyjs approach is 100% client side operation, so it can run without online access. additionally, the python-DOM version (or the pyjs version if proxying thru a local daemon) could potentially direct install from the website, leading to "install now" functionality. lastly, python means you could use the same lang to write the front end and the backend, and communicate using JSON messages. but yeah in the medium run, i'd like to see archlinux.org function as a simple state tracker, linking users together, and letting them share and manage their own PKGBUILD repositories. in the long run, archlinux.org is dropped altogether, and the AUR is completely P2P. as a professional web applications developer by day, i can vouch that writing webapps requires knowledge of about 4 different haphazardly implemented "standards", requiring far to much painfully acquired knowledge. by using a library like pyjamas, you allow anyone with python experience to write incredibly functional plugins/modules, and share maintenance load. django is a great platform, but after i discovered pyjamas about 1yr ago, i haven't looked back, and am convinced that compiler technology is the only sane way to develop complex and maintainable web-based applications. C Anthony
Re: [arch-general] We want to help
You've done a great job Anthony. Your app is a all-in-one! Our focus is (was) create a better AUR, with new features and using other platform (from php to django). I think your focus is a little different, isn't? -- Tomás A. Schertel -- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ -- On Tue, Dec 14, 2010 at 16:23, C Anthony Risinger wrote: > On Tue, Dec 14, 2010 at 12:12 PM, C Anthony Risinger wrote: >> On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae wrote: * 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: >> >> https://github.com/extofme/aur-pyjs/tree/pmvc-refactor >> >> 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 >> javascript (or python-DOM) application requiring nothing from the >> server (or a local daemon...) other than JSON-RPC endpoints, which can >> be implemented in any language. >> >> the entire GUI is reusable in desktop mode (python bindings to DOM). >> everything is hot pluggable at runtime, right down to the core and >> shell. users will in time be able to make any layout change they >> wish. the slight stagnation on this project is only due to me working >> on pyjamas itself to support runtime hot-loading of python modules via >> AJAX... ie. variable/conditional imports... to enable dependency >> injection (of AUR modules), [more] efficient bootstrap and runtime, >> and other dynamicisms. >> >> currently, local PKGBUILD database expected to be dulwich/git based, >> to easily support forking/etc of PKGBUILDs, but im also considering >> couchdb (the couchdb python API could be ported to pyjs... then i >> could make parallel databases calls via iframe proxies DIRECTLY from >> the browser!!). the ultimate idea is a distributed AUR. >> >> im not in a hurry to complete it, as i have some far reaching goals, >> but it is very much active and open for input. in short, this message >> is a shameless self-promotion, but i believe the approach holds more >> potential than existing solutions, simpler extensibility, and a lower >> barrier of entry to non web/HTML/CSS/Javascript/.../.../... (have you >> ever wrote a good webapp before? sheesh...) developers. > > oops i forgot to mention an interesting thing ill be adding soon... > > i managed to integrate the google translate API into pyjs, so i can > make translation calls. the idea will be to dynamically determine the > users language at runtime and translate everything on the fly, > comments and all. i want users to be able to write comments etc. in > their native language (and be stored this way), and everyone still > able to read each other. as i unfortunately can only speak english > (curse you USA grade school system!), i can't speak for other langs, > but the google translation works very well for conversion to english, > far more than enough to understand the text... i even managed to set > up a CNAME in DNS with a spanish CSR/company once, using translation > on the fly :-) > > also, instead of git/couchdb, im also considering using the local > database of HTML5, which is sqlite3 based i believe, though i'm not as > sure the limitations here. the benefit is that it keeps everything in > the bowser, making the AUR fully self contained and able to run as an > offline app. > > C Anthony >
Re: [arch-general] We want to help
On Tue, Dec 14, 2010 at 12:12 PM, C Anthony Risinger wrote: > On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae wrote: >>> * 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: > > https://github.com/extofme/aur-pyjs/tree/pmvc-refactor > > 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 > javascript (or python-DOM) application requiring nothing from the > server (or a local daemon...) other than JSON-RPC endpoints, which can > be implemented in any language. > > the entire GUI is reusable in desktop mode (python bindings to DOM). > everything is hot pluggable at runtime, right down to the core and > shell. users will in time be able to make any layout change they > wish. the slight stagnation on this project is only due to me working > on pyjamas itself to support runtime hot-loading of python modules via > AJAX... ie. variable/conditional imports... to enable dependency > injection (of AUR modules), [more] efficient bootstrap and runtime, > and other dynamicisms. > > currently, local PKGBUILD database expected to be dulwich/git based, > to easily support forking/etc of PKGBUILDs, but im also considering > couchdb (the couchdb python API could be ported to pyjs... then i > could make parallel databases calls via iframe proxies DIRECTLY from > the browser!!). the ultimate idea is a distributed AUR. > > im not in a hurry to complete it, as i have some far reaching goals, > but it is very much active and open for input. in short, this message > is a shameless self-promotion, but i believe the approach holds more > potential than existing solutions, simpler extensibility, and a lower > barrier of entry to non web/HTML/CSS/Javascript/.../.../... (have you > ever wrote a good webapp before? sheesh...) developers. oops i forgot to mention an interesting thing ill be adding soon... i managed to integrate the google translate API into pyjs, so i can make translation calls. the idea will be to dynamically determine the users language at runtime and translate everything on the fly, comments and all. i want users to be able to write comments etc. in their native language (and be stored this way), and everyone still able to read each other. as i unfortunately can only speak english (curse you USA grade school system!), i can't speak for other langs, but the google translation works very well for conversion to english, far more than enough to understand the text... i even managed to set up a CNAME in DNS with a spanish CSR/company once, using translation on the fly :-) also, instead of git/couchdb, im also considering using the local database of HTML5, which is sqlite3 based i believe, though i'm not as sure the limitations here. the benefit is that it keeps everything in the bowser, making the AUR fully self contained and able to run as an offline app. C Anthony
Re: [arch-general] We want to help
On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae wrote: >> * 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: https://github.com/extofme/aur-pyjs/tree/pmvc-refactor 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 javascript (or python-DOM) application requiring nothing from the server (or a local daemon...) other than JSON-RPC endpoints, which can be implemented in any language. the entire GUI is reusable in desktop mode (python bindings to DOM). everything is hot pluggable at runtime, right down to the core and shell. users will in time be able to make any layout change they wish. the slight stagnation on this project is only due to me working on pyjamas itself to support runtime hot-loading of python modules via AJAX... ie. variable/conditional imports... to enable dependency injection (of AUR modules), [more] efficient bootstrap and runtime, and other dynamicisms. currently, local PKGBUILD database expected to be dulwich/git based, to easily support forking/etc of PKGBUILDs, but im also considering couchdb (the couchdb python API could be ported to pyjs... then i could make parallel databases calls via iframe proxies DIRECTLY from the browser!!). the ultimate idea is a distributed AUR. im not in a hurry to complete it, as i have some far reaching goals, but it is very much active and open for input. in short, this message is a shameless self-promotion, but i believe the approach holds more potential than existing solutions, simpler extensibility, and a lower barrier of entry to non web/HTML/CSS/Javascript/.../.../... (have you ever wrote a good webapp before? sheesh...) developers. C Anthony
Re: [arch-general] We want to help
Thanks for your answer Allan. We gonna start working and sending code ASAP. -- Tomás A. Schertel -- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ -- On Tue, Dec 14, 2010 at 11:14, Allan McRae wrote: > On 14/12/10 21:54, Tomás Acauan Schertel wrote: >> >> The Brazilian Arch Linux Community wants to help Arch Linux project, >> working on bug reports and feature requests. >> As first task, we plan to help conclude the development of AUR version 2. > > That is a big goal! But it just might be crazy enough to succeed. > Especially if there is a group of you. > >> We don't have lots of developers, but we really want to help. And >> maybe others join us on this effort. >> >> To accomplish this, we need to enlighten some points: >> >> 1 - where should we look for feature requests? >> * bugs.archlinux.org? >> * AUR2 wiki page? > > Both I would guess... > >> 2 - what code repository should we take as start point? >> * git://gitorious.org/aur2/aur2.git -- the "central" repository with >> the stable branch >> * git://github.com/sebnow/aur2.git -- Xilon's repository > > This one is probably the best. > >> * 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 > > >> 3 - How Feature Requests / Bug Reports will be closed on flyspray? >> * Maybe a TU can do the job. > > You can request bug closures which will eventually get dealt with by a > relevant person. > > Allan >
Re: [arch-general] We want to help
On 14/12/10 21:54, Tomás Acauan Schertel wrote: The Brazilian Arch Linux Community wants to help Arch Linux project, working on bug reports and feature requests. As first task, we plan to help conclude the development of AUR version 2. That is a big goal! But it just might be crazy enough to succeed. Especially if there is a group of you. We don't have lots of developers, but we really want to help. And maybe others join us on this effort. To accomplish this, we need to enlighten some points: 1 - where should we look for feature requests? * bugs.archlinux.org? * AUR2 wiki page? Both I would guess... 2 - what code repository should we take as start point? * git://gitorious.org/aur2/aur2.git -- the "central" repository with the stable branch * git://github.com/sebnow/aur2.git -- Xilon's repository This one is probably the best. * 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 3 - How Feature Requests / Bug Reports will be closed on flyspray? * Maybe a TU can do the job. You can request bug closures which will eventually get dealt with by a relevant person. Allan
[arch-general] We want to help
The Brazilian Arch Linux Community wants to help Arch Linux project, working on bug reports and feature requests. As first task, we plan to help conclude the development of AUR version 2. We don't have lots of developers, but we really want to help. And maybe others join us on this effort. To accomplish this, we need to enlighten some points: 1 - where should we look for feature requests? * bugs.archlinux.org? * AUR2 wiki page? 2 - what code repository should we take as start point? * git://gitorious.org/aur2/aur2.git -- the "central" repository with the stable branch * git://github.com/sebnow/aur2.git -- Xilon's repository * 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. 3 - How Feature Requests / Bug Reports will be closed on flyspray? * Maybe a TU can do the job. Maybe things get easier if just one (maybe two) TU`s leads us on work. -- Tomás A. Schertel -- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ --
