[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#164903: Megahal package.



On Sat, 23 Aug 2003, Laurent Fousse wrote:

> Le Fri, Aug 22, 2003 at 03:43:15PM -0500, Drew Scott Daniels écrivait:
> > On Fri, 22 Aug 2003, Laurent Fousse wrote:
> > > If you like we can try to work together, merge our work if you have
> > > something ready as well.
> > >
> > I'd love to work together on this. I don't have much to merge though. My
> > approach was/is much more conservative than yours, far less detailed too.
>
> I'll try to clean my changes a bit (the package was a native source
> package with no diff, but I'll try to split the upstream part and the
> debian part).
>
Some people diff the native tarball. I'd prefer if we could release a
tarball that isn't native upstream.

> > > My package is available here:
> > >
> > > http://komite.net/laurent/debian/megahal/
> > >
> > > The python and the perl library need beta-testing, and we should add a
> > > C library (closing #107318).
> > >
> > Looking over the changes I have some questions and comments...
> > - I would have forgot to update megahal_interfaces(3) after applying the
> >   patch. I didn't apply the patch...
>
> If you mean the patch I've sent in #169805, it has not been included
> as such my package. I moved the patch from the megahal end user
> program to the "megahal library", it's probably cleaner.
>
> > - I don't know if it's a good idea to split the package as some of the
> >   packages seem rather small. The ftp people may reject the additional
> >   packages.
>
> It's a compromise:
>  - if you're a perl developper and you need to install python you
>    might get upset.
>
> It's okay for me if you want to join the three in the same package,
> with an udpated description that states this clearly.
>
Take a look and see what the ftp maintainers are doing these days. Maybe
ask on some open forum what enough justification is... That said I don't
see all that big a problem with this split personaly, but then I haven't
looked hard to see the possible implications (archive bloat?).

> Thanks to Martin F. Krafft. It's not an easy choice, Games or even
> Apps/Text could almost fit. Apps/Science is probably the better
> choice.
>
It'd be nice if there were a better way to do menus, but that seems to be
a higher level problem. We should look at the tag collection to make sure
megahal is tagged properly...

> I read through upgrading-checklist. 10.1 is more or less implemented
> using a template debian/rules for another package. But it need further
> examination, to be sure.
>
Perhaps it'd be worth asking on debian-mentors? Once I had some time I was
going to explain the issue there and ask for help.

> When I first started hacking I made a diff between latest CVS and
> 9.1.0, which was almost empty. My package are based on latest CVS and
> I forgot to update the upstream version to 9.1.0 in the package.
>
> Having a new upstream release is a good idea, it's on my TODO list,
> but don't expect my work to be done before monday.
>
My home computer is broken and I don't come into work on the weekends. I
don't tend to do Debian work on the weekend.

> > Looking of the source I have some comments:
[...]
> I'll drop the CVS directory. No sensitive information was lost :-)
>
Yup. I wonder if we should look at the update package via CVS tools and
make sure we can let users easly update their package from the CVS. I know
I enjoy the uscan tools (that uses debian/watch).

> > - I like how you handled the python dependency... much nicer than my
> >   solution. I'm guessing the correct python version gets set as a
> >   binary dependency?
>
> I've changed the python interface part using a template found in
> another python package. Not sure if this still works with any python
> version though.
>
Perhaps we should ask on debian-python.
It seems that megahal depended on "python-dev" in the past as indicated by
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/megahal/megahal/debian/control.diff?r1=1.2&r2=1.3&sortby=date
There may be a justification archived in the BTS. Try adding the
&archive=yes to the URL for megahal's bug listing.

> > - For the Debian version I'd like the no brain found to suggest that the
> >   user might want to use megahal_personal. It would also be nice to tell
> >   the user that MegaHal needs to be taught... maybe something the #quit
> >   command too.
>
> Good idea.
>
> > After writing most of this I'm getting the feeling that you have more
> > energy than me for working on this package... I suggest you consider my
> > comments and then ask my sponsor if he'd sponsor you.
>
> I've asked an debian-qa for a sponsor for the package. I'll ask your
> sponsor to upload my current package if you like (is he madduck?). Are
> we short on time for sarge release?
>
I hope he'll consider sponsoring the package from you. We have at least
unil Sept 4th. Sept 15th is the first "Freeze". It seems October 15th is
the last day that changes might be accepted. We should thus have what we
want for sarge by very early October at the latest. Don't forget about the
10 day delay and hopefully we can get an upload asap to avoid getting
stuck in any dependancy holdups.

> > I still want to do an audit of MegaHal, especially if it's to be run
> > exposed to non local users. I.e. as a bot on IRC. To do this audit I'm
> > going to start with all the warnings (even low ones) from rats.
>
> Good idea, I'm also concerned by security but didn't have time to check
> for vulnerabilities myself.
>
I'll get more into that in a few days. I have to do a bit of overtime at
work...

> > Fwiw, you may be interested to know that there are "better" conversation
> > simulators out there. I.e. ones that fooled more judges at the Lobner
> > Turing Test competition. I like MegaHal for the algorithm that it uses.
> > I'd even like to modify the algorithm a bit, but I think it'd be better
> > for me to create a new project to do that.
>
> Are the other simulators able to learn as well? I'm also interested in
> your algorithm modifications.
>
Well, maybe not better. You may be interested in Alice bot. You can find
out about it at: http://www.alicebot.org I found Program V to look the
most promising for packaging although J-Alice looks pretty good too. I
haven't looked at them much to know how good they are, but they certainly
are newer. You may be also interested in reading
http://www.loebner.net/Prizef/loebner-prize.html
http://www.chatterboxchallenge.com/contest_news.html
http://www.loebner.net/Prizef/Loebner_2000_Finalists.html
etc...

     Drew Daniels




Reply to: