[aur-general] Please delete some chicken-egg packages

2010-09-10 Thread Jim Pryor
Hi I maintain all the chicken-* packages in AUR; these are "eggs" or
extensions for the Chicken Scheme compiler and interpreter.

I'll soon push a bunch of updates.

However, these eggs are now unsupported and should be removed from AUR:

chicken-crypto-tools http://aur.archlinux.org/packages.php?ID=32677
chicken-mailbox-threads http://aur.archlinux.org/packages.php?ID=32763
chicken-multimethod http://aur.archlinux.org/packages.php?ID=32770
chicken-termite http://aur.archlinux.org/packages.php?ID=32835
chicken-wiki-parse http://aur.archlinux.org/packages.php?ID=32851

Thanks.

-- 
Jim Pryor
prof...@jimpryor.net


Re: [aur-general] Lua packages (Was: TU Resignation)

2010-02-01 Thread Jim Pryor
On Mon, Feb 01, 2010 at 03:58:02PM +0100, Ronald van Haren wrote:
> > I think luadoc is the only (make)dependency for awesome, right?
> no, luadoc in itself depends on lualogging and luafilesystem so the
> only package which is not covered yet is luajit. Anybody needs that
> for a package (according to the package it is some lua code compiler?)

Oh yeah, of course.

LuaJIT is an alternative, just-in-time compiler for Lua. The package is
going through some radical growth right now, from different directions.
I don't expect to see a stable LuaJIT 2.0 release, or a release for
x86_64, or a release that tracks Lua 5.2 (now in development releases)
anytime very soon.

It looks from http://www.archlinux.org/packages/community/i686/luajit/
like nothing in the repos depends on it. 

-- 
Jim Pryor
prof...@jimpryor.net


[aur-general] Lua packages (Was: TU Resignation)

2010-02-01 Thread Jim Pryor
On Mon, Feb 01, 2010 at 12:06:34PM +0100, Ronald van Haren wrote:
> > - lua-related (luadoc, luafilesystem, luajit, lualogging)
> 
> please don't! :-p I bet most of them are makedepends of my awesome
> package. So unless someone with more time also needs them as
> makedepends I suppose I take them next week or so.

I'm glad these packages will have good homes.

I think luadoc is the only (make)dependency for awesome, right?


On Mon, Feb 01, 2010 at 09:08:22AM +, Pierre Chapuis wrote:

> I am also a Lua user, and as I was reading posts by the Arch Haskell
> team I thought maybe a project like that should be created for Lua. I
> would love to see a better support for it in Arch, and especially to
> see all of Kepler packaged (including Xavante).
> 
> If other users on this list are interrested, please email me and maybe
> we could set up a user repository for lua modules...

Yeah, I was thinking of setting up an automated luarocks2arch system,
like Haskell's cabal2arch. I did something like this for most of the Chicken 
Scheme
modules (they're all in AUR, the automatic PKGBUILD-generater works but 
it's fragile and I haven't distributed it).

I just haven't had time to make any progress on this for lua. But I'm
willing to participate when I can.

-- 
Jim Pryor
prof...@jimpryor.net


Re: [aur-general] TU Resignation

2010-01-31 Thread Jim Pryor
On Sun, Jan 31, 2010 at 04:12:43PM -0200, Paulo Matias wrote:
> [community]
> - oss-related (oss, skype-oss)
> - djvu-related (djview4, pdf2djvu -> pstreams)
> - lua-related (luadoc, luafilesystem, luajit, lualogging)
> - netsurf-related (netsurf -> hubbub, libnsbmp, libnsgif, libparserutils)
> - latex-related (texmaker)
> 
> [unsupported]
> - vbox-related (virtualbox_bin)
> - oss-related (xulrunner-oss)
> - electronics-related (alliance, chipmunksystem, logisim)
> - lua-related (iup, cd, im, gnuplot-luaterm)
> - ion3-related (ion-3, trayion)
> - djvu-related (gsdjvu)
> - irc-related (kvirc-svn, qirssi)
> - driver stuff (samsutools)
> - other stuff (chestnut-dialer, eresi-svn, python-mpmath, uspnet)
> Best regards,
> 
> Paulo Matias

Hi Paulo, thanks for your contributions.

I'm closely following Lua, and can help out with the luadoc, luafilesystem, and
lualogging. luajit doesn't yet work on x86_64, which my machines are,
and I haven't played with it at all, so I won't say I can help with
that.

Now I'm not a TU, and don't really have the time to take
on TU responsibilities even if you trusted me! I'm just offering to
help out, in case some TU is willing to adopt them but hesitates on account of 
lack of experience with Lua. Or if these were to go to AUR, then I could
take them.

The four Lua packages in AUR are graphics/plotting packages I don't use.
Hopefully there's someone else who does. But if not, I could be a foster
parent until someone comes along.

-- 
Jim Pryor
prof...@jimpryor.net


Re: [aur-general] Can't upload package to AUR

2010-01-04 Thread Jim Pryor
On Mon, Jan 04, 2010 at 05:14:57PM +0800, Sebastian Nowicki wrote:
> 
> If anyone has the courage to do this, I suggest looking into using a
> PKGBUILD parsing library I wrote[1]. since this would delegate
> parsing to an external library, future changes like these would be
> much easier.
> 
> [1]: http://github.com/sebnow/pkgparse

Cool! A real parser is terrific, thanks for doing it.

-- 
Jim Pryor
prof...@jimpryor.net


Re: [aur-general] Available: A lot of eggs for Chicken Scheme...

2009-12-13 Thread Jim Pryor
On Fri, Dec 11, 2009 at 08:27:59PM -0600, Chris Brannon wrote:
> Jim Pryor wrote:
> > I'm exploring various Scheme implementations and at the moment am liking
> > Chicken. I don't know the community very well, but it sounds like it's
> > one of the large and active Scheme communities. For the casual
> > bystander: the Lisp community is fractured into Scheme and Common Lisp,
> > and each of these is further fractured into many different
> > "implementations." Maybe the biggest Scheme community is PLT Scheme? I
> > don't know. But Chicken is one of the large ones.
> 
> Yes, in terms of popularity, PLT and Chicken seem to be clear leaders.
> Like Chicken, PLT has its own package system, with plenty of third-party
> libraries.
> 
> One neat thing about Chicken Scheme is its integration with C.  The compiler,
> csc, produces small executables as well.
> 
> > Now I've got all of these chicken-* packages I could make available on
> > AUR. I think anyone else using Arch and Chicken would find them very
> > convenient. Chicken has its own package management system, but if you
> > use Arch I think it's nicer to do things through pacman.
> 
> It's too bad that we don't have a really solid way to integrate pacman
> with the proliferation of "alien" package management systems in use today.
> 
> > What should I do? Post them to AUR and maintain them minimally
> > until someone else comes along who can commit more seriously to them?
> 
> That sounds reasonable to me.

Thanks Chris. I've posted all the packages now, under the names
chicken-*.


-- 
Jim Pryor
prof...@jimpryor.net


[aur-general] Available: A lot of eggs for Chicken Scheme...

2009-12-11 Thread Jim Pryor
I'm exploring various Scheme implementations and at the moment am liking
Chicken. I don't know the community very well, but it sounds like it's
one of the large and active Scheme communities. For the casual
bystander: the Lisp community is fractured into Scheme and Common Lisp,
and each of these is further fractured into many different
"implementations." Maybe the biggest Scheme community is PLT Scheme? I
don't know. But Chicken is one of the large ones.

Chicken Scheme has a package system. They call their packages "eggs" (they
did this before Python did) and there's a lot of them available, at
<http://chicken.wiki.br/chicken-projects/egg-index-4.html>.

For my own use, I converted all of these I could build (217 of them, I
think) to Arch packages. Of course I automated the process, but there
was a lot of refining of the automation and further tweaking.

Now I've got all of these chicken-* packages I could make available on
AUR. I think anyone else using Arch and Chicken would find them very
convenient. Chicken has its own package management system, but if you
use Arch I think it's nicer to do things through pacman. (In the same way
that we like to manage perl modules through pacman.)

However, I don't know how much I'm going to be able to commit to
maintaining these packages. Some of the packages I certainly won't be
using myself. I'm not even sure how long, or how seriously, I'll be
using Chicken Scheme. It won't be my main programming environment. 
But I do like it so far and I want to find a Scheme implementation I can stick 
with
and have handy. Maybe this is it.

Still, I don't have much time and I'm not confident I'll be able to give
these packages much attention down the road.

What should I do? Post them to AUR and maintain them minimally
until someone else comes along who can commit more seriously to them?
Or just leave this note out on the list in the off chance such another
person might come across it?

The packages I'd submit all check fine with namcap (and as I've said,
I've built and installed them all, though I haven't run the tests on them. I 
didn't have the time
to automate or tweak the building of the test dependencies.) The only
exceptions are: there are often some redundant dependencies, for
instance if package A depends on B and C, and B also depends on C,
namcap wants you just to list B in A's depends. But the way
Chicken calculates dependencies made it much easier to automate the
PKGBUILD-generation with A depending on both B and C.

The other exception is the licenses. A few unclear cases aside, I was
always able to list the right license in the PKGBUILD.
But there are a lot of BSD and MIT licenses in the pack. What I'm
supposed to do then is say license=(BSD) and install a copy of the
license in /usr/share/licenses/$pkgname. But the downloads from the
Chicken repository don't provide separate license files. I'd have to
extract the license from comments in the source code, and I haven't done
that for these 217 packages.

Other than that I think the packages are all fine. My automatic script
generates all but 10 or so of them, those last 10 it's easiest to tweak by hand.


-- 
Jim Pryor
prof...@jimpryor.net


[aur-general] remove request: nfs4-utils

2009-08-16 Thread Jim Pryor
Now that aur/nfs4-utils has been incorporated into core/nfs-utils,
shouldn't aur/nfs4-utils be removed?

-- 
Jim Pryor
prof...@jimpryor.net