I am an avid FreeBSD user and can contribute(head up maybe?) a FreeBSD group
and thus would like to ensure that enlightenment runs on this platform
I'm not a terribly skilled progammer or anything, but I can hack my way
through basic porting of software. I already maintain edb, imlib2, evas, ecore,
and gevas in the FreeBSD ports collection.
Also, I can verify that right now, cvs e17 builds and runs for FreeBSD/i386.
On Fri, May 25, 2001 at 01:22:27PM -0700, Ben Rockwood wrote:
> If such a team is put together I'd be interested making sure that
> we lay some rules down. Namely, that version numbers stay under the
> control of Raster (I can just see someone desciding it was 1.0 time...
> that wouldn't be a pretty discussion). Then we'd have to just
> divide up into groups of maintainers. I'll take Solaris/Sparc.
> I don't like RPM or Debian, but I know many of you do. Then we
> also need to make sure that all platforms that people want are supported,
> namely Linux (RPM and DEB), AIX (4.3.3 and 5L), HP-UX (10.20, hopefully,
> and 11), Solaris Sparc 2.6 (compatable for 2.6, 7, 8), Solaris x86.
> The distros I'm debating now (but don't wanna persue) would be IRIX,
> Tru64/DECUnix, and FreeBSD x86.
> At the moment, looks like we're supported something like this:
> AIX 4.3.3/5L: IBM
> Solaris/Sparc 2.6: Cuddletech
> HP-UX 10.20/11: PENDING (Cuddletech)
> IRIX: None Known/Planned
> Tru64: LOL
> FreeBSD: FreeBSD Group
> RPM/DEB: E Core Devel
> If anyone on the list has done ports, it's time to let everyone know.
> There is one thing I'd like to see changed in E (and FNLIB, IMLIB, etc),
> which would be "movability". Lots of Solaris users can't use my packages
> because if they try to install 'em into a place other than were I compiled
> 'em to install (/usr/local) the build breaks. So non-root holding users
> have to compile themselves. I've tried to code out these issues but
> had little luck. If everything can be found via relitive paths instead of
> absolute (ie: "../lib/something.so" instead of
> "/usr/local/lib/something.so"), that'd be a solution too.
> > * Mark Bainter (mark-e@...) wrote:
> >> Rasterman [raster@...] wrote:
> >> > nup... this guy woudl probably be "release god" ie - developerrs say
> >> > "done. ready for release" and the developer ups the version. release
> >> > god takes over form here - makes sure the package builds cleanly and
> >> > fixes & patches as needed (or if its highly complex communicates
> >> > with the developer), he makes sure packages are built (rpm's for
> >> > redhat, mandrake, suse etc.) and makes surr the debian people
> >> > upstream know
> > Well, I've done some of them in the past. But I don't have the time
> > anymore, and I've been phasing redhat out of my network anyway ;)
> >> Oooh. Hey, now /that/ is something I can help with. If you want
> >> someone to take over managing the RPM spec file and the testing/etc
> >> that goes along with it I hereby volunteer for the job. ;-) At least
> >> on the x86 side. I'm afraid I don't have any other hardware types to
> >> test on.
> > I asked someone on the web team to be the "release maintainer", and
> > someone volunteered (I apologize for not remembering who, but I wrote
> > it down :). If you can create the releases, this person can manage them
> > and make sure people can access them, etc. How's that?
> > term
> > _______________________________________________
> > Enlightenment-devel mailing list
> > Enlightenment-devel@...
> > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> Enlightenment-devel mailing list