Trent requested that I made a bugtracker entry for this.
Thanks!
(by the way, if we do get this, it should probably be submitted to the gitit
folks too)

Attached is an implementation that DOES NOT WORK.
It is broken because of this misfeature in gitit:

    # gitit -f /etc/gitit.conf </dev/null
    gitit: <stdin>: hGetChar: end of file

gitit requires its input stream to be non-null.  I can't imagine why.

Anyway, the update-metainit(8) tool turns gitit.metainit into
gitit.orig.  I then fixed up a metainit bug to get gitit.  This file
(gitit) should be placed in /etc/init.d/gitit, and the appropriate
symlinks created, e.g.

    /etc/rc1.d/K20gitit -> ../init.d/gitit
    /etc/rc2.d/S20gitit -> ../init.d/gitit
    /etc/rc3.d/S20gitit -> ../init.d/gitit
    /etc/rc4.d/S20gitit -> ../init.d/gitit
    /etc/rc5.d/S20gitit -> ../init.d/gitit

The file /etc/init.d/gitit should also be mode 0755 (executable).

This init script will run gitit as root (very bad),
cf. http://bugs.debian.org/468046.  It can be fixed by manually adding
the appropriate option to the start-stop-daemon call(s).

This init script DOES NOT change directory or perform chrooting.  This
could be done by editing start-stop-daemon call(s), too.  Note that in
particular the script assumes that you have /etc/gitit.conf, and this
config file will need ALL paths to be absolute, since gitit assumes
gitit.conf paths are relative to the working directory, rather than
relative to the wiki data directory.  An example gitit.conf is included.

Attachments

• gitit
• gitit.conf
• gitit.metainit
• gitit.orig

There's a bugtracker for Gitit, y'know. I've posted a link to here at
http://code.google.com/p/gitit/issues/detail?id=54

On Wed, Jun 17, 2009 at 13:14:47 -0000, gwern wrote:
> There's a bugtracker for Gitit, y'know. I've posted a link to here at
> http://code.google.com/p/gitit/issues/detail?id=54

While we're at it, I've also posted the request for an init-style
script there too.  I imagine it'll be useful for other gitit users:
  http://code.google.com/p/gitit/issues/detail?id=55

John says that the gitit misfeature has been fixed in the library branch (which
now appears to have been merged into mainline).

So is there any more work needed to get this script working?

In any case, I'm closing this bug as a duplicate.  Please follow and comment on
the gitit tracker instead (I hope that's the right thing to do).

Once again for convenience: http://code.google.com/p/gitit/issues/detail?id=55

On Thu, Jun 25, 2009 at 04:34:11PM -0000, Eric Kow wrote:
> John says that the gitit misfeature has been fixed in the library
> branch (which now appears to have been merged into mainline).

Is that version deployed on wiki.darcs.net?

> So is there any more work needed to get this script working?

I will need to review the init script against a current gitit build.
I don't think I'll have time for this before the 2.3 release.

> In any case, I'm closing this bug as a duplicate.  Please follow and
> comment on the gitit tracker instead (I hope that's the right thing
> to do).
>
> Once again for convenience: http://code.google.com/p/gitit/issues/detail?id=55

In Debian that would be the wrong thing, there's a specific
"forwarded" status which takes a web page (as above) or an email
address, indicating the upstream ticket.  I don't know if roundup has
such a thing.

Failing that, I'd prefer to see this tagged "wontfix" than "closed",
to indicate that we haven't actually resolved the issue, just decided
that it's something for upstream to deal with.

On Fri, Jun 26, 2009 at 00:07:02 -0000, Trent Buck wrote:
> > John says that the gitit misfeature has been fixed in the library
> > branch (which now appears to have been merged into mainline).
> 
> Is that version deployed on wiki.darcs.net?

I have recently uploaded the latest gitit marked (2009-06-26),
but it has not yet been deployed.

> > In any case, I'm closing this bug as a duplicate.  Please follow and
> > comment on the gitit tracker instead (I hope that's the right thing
> > to do).
> >
> > Once again for convenience: http://code.google.com/p/gitit/issues/detail?id=55
> 
> In Debian that would be the wrong thing, there's a specific
> "forwarded" status which takes a web page (as above) or an email
> address, indicating the upstream ticket.  I don't know if roundup has
> such a thing.
> 
> Failing that, I'd prefer to see this tagged "wontfix" than "closed",
> to indicate that we haven't actually resolved the issue, just decided
> that it's something for upstream to deal with.

OK.  It's marked "duplicate" now, but feel free to change it to "wontfix"
if it's better (I assume Thorkil will jump in here if he has any
feelings on the matter)

Trent's been working on this.   I just upvoted this recently on IRC. 
This is not-our-bug in the sense that it's really about gitit, but it's
also our feature in the Community/Devel sense.  In other words, we're
also using this tracker to track darcs.net issues, not just the darcs one.

Trent W. Buck wrote:
> On Thu, Jun 25, 2009 at 04:34:11PM -0000, Eric Kow wrote:
>> John says that the gitit misfeature has been fixed in the library
>> branch (which now appears to have been merged into mainline).
>
> Is that version deployed on wiki.darcs.net?
>
>> So is there any more work needed to get this script working?
>
> I will need to review the init script against a current gitit build.
> I don't think I'll have time for this before the 2.3 release.

I'm running gitit on a trusted network, using the same init script
posted earlier, and the same gitit version (0.7.3) as seems to be
installed on darcs.net.  It works for me.

I suggest adding "--chuid gitit" to the start-stop-daemon calls.

OK, so then my job is to install this on darcs.net according to msg7736
and if all goes well, forward this to the Gitit team?

Eric Kow wrote:
> OK, so then my job is to install this on darcs.net according to msg7736
> and if all goes well, forward this to the Gitit team?

Yes.

OK, working in stages:

1. to align things with a future stock gitit, I've updated
~gitit/run-gitit.sh to run a /usr/local/bin/gitit with /etc/gitit.conf
(instead of something from the gitit home dir)

2. gitit script modified so that each start-stop-daemon call gets a
--chuid $USER [with USER=gitit]

3. symlinks to rc1.d and rc2.d .. rc5.d (I think these are right ones,
looking in /etc/inittab, but I'm not sure), as instructed

The bad news: when I run sudo /etc/init.d/gitit start, it just exits 1
with no output.  Any chance would make an IRC appointment at your
convenience?  I think I need a little bit more hand-holding.

I'm around for what's left of Sunday 28 Mar, and also starting from
Tuesday.  Thanks!

Eric Kow wrote:
> 1. to align things with a future stock gitit, I've updated
> ~gitit/run-gitit.sh to run a /usr/local/bin/gitit with
> /etc/gitit.conf (instead of something from the gitit home dir)

I checked these, they look OK.  I could also run gitit manually (as
gitit@darcs.net) with

    /usr/local/bin/gitit -f /etc/gitit.conf -p 12345

And I could then browse to http://darcs.net:12345/, so that part is
working.

> 2. gitit script modified so that each start-stop-daemon call gets a
> --chuid $USER [with USER=gitit]

Looks OK to me.

> 3. symlinks to rc1.d and rc2.d .. rc5.d (I think these are right ones,
> looking in /etc/inittab, but I'm not sure), as instructed

Normally you would do

    update-rc.d gitit defaults

The update-rc.d tool is a (slightly confusing) way to manage these
symlinks correctly.

> The bad news: when I run sudo /etc/init.d/gitit start, it just exits 1
> with no output.

I could reproduce this, until I chown'd /var/log/gitit.log to be owned
by gitit.  Then it Just WorkedTM for me, on my very similar Squeeze VM.
So I'm not sure what else could be wrong.

>  Any chance would make an IRC appointment at your
> convenience?  I think I need a little bit more hand-holding.
>
> I'm around for what's left of Sunday 28 Mar, and also starting from
> Tuesday.  Thanks!

I'm usually available from 1PM to 10PM in the Australia/Melbourne
timezone, which is currently GMT +1100 but is usually +1000.

With thanks to Trent for teaching me how to think through an init
script, we now have this installed, and reboot-tested.  Now the wiki
will come back up as soon as darcs.net does.  Hooray, infrastructure!