Brian May <firstname.lastname@example.org> writes:
> - Change paths to config files in utils.py.
Sigh, you don't need to do that. See /etc/katie/katie.cnf on
> - rose creates initial directories (actually some where missing; I can't
> remember which onces were missing and which ones were misconfigured
> though now).
rose uses the provided config file; it'd be hard for her to "misconfigure" a
> (melanie complains that it cannot delete the files from buildd/*,
> but I can't see why, I deleted the same files mentioned manually
> without any problems).
Huh? I don't think you mean melanie, she doesn't delete files.
You seem to be making a fundamental mistake: cron.daily, katie.conf,
apt.conf etc. are all not the best files to start from, they're
ftp-master's real config file. I know that's non-intuitive but that's
just how it is always been hysterically. Don't start from them and
don't assume they're some kind of example to build from. If anything
the security ones are a far better example in many ways.
> - cron.buildd is for buildd, I don't know where to get wanna-build from
> so I don't use it.
Again, you obviously didn't look it's utterly trivial to find.
> - cron.hourly doesn't appear to be required.
WTH are you talking about? required for what? cron.hourly simply
runs julia which syncs postgresql ideas of users and the systems which
is useful if you're using postgresql's 'peer sameuser' (or whatever
it's called these days) access control on a multi-user system. If
you're not, then it's not "required".
> - cron.weekly might be important, but I don't understand what it does.
Dude, it's 8 or so lines of shell script with comments. Where's the
| # Purge empty directories
| # Clean up apt-ftparchive's databases
> - turn off BXA notifications in katie.conf. Or change the template.
No, don't use auric's katie.conf as a starting point. Write your own.
BXA Notification defaults to off if it's not mentioned for this very
> - turn off auto closing bugs in katie.conf. Or at least change
> the template.
> - when new package is accepted it will inform uploader and package
> maintainer; the maintainer might confuse this E-Mail as an
> unauthorised upload to the Debian archive. I am not sure what the best
> solution is here.
See other mail; this can be overriden.
> - some templates in templates/* have E-Mail addresses hardcoded (From
> and To E-Mail addresses).
Err, amber.advisory and lisa.bxa-notification, neither of which anyone
would want to use unedited if at all.
> - cron.* have E-Mail addresses hardcoded.
> kelly -pa *.changes | tee REPORT | \ mail -s "Install for $(date +%D)"
> This comes up with lots of errors if *.changes doesn't exist.
This is simpy because katie's designed for real archives which
invariably have new uploads every day; it's trivial to fix.
> - No way to override component eg. (main,contrib,non-free) without
> changing source; I have a patch that will let you override it in lisa.
> I have also patched/hacked jennifer to use existing overide component
> if one already exists.
You've grossly misunderstood how components work. See other mail.
> - cron.daily is pretty verbose.
IT'S NOT AN EXAMPLE FILE, IT'S AURIC'S AND WE LIKE IT TO BE VERBOSE.
> - cron.daily generates override.potato.all3 and override.sid.all3, but I
> can't see what use these files are.
They're used for legacy-mixed style directories; if you don't have any
of those and/or don't know what they are you don't need to care about
> - Not sure how to move files between components, this might require a
> delete operation followed by a new upload.
No, it doesn't. It's automatic; you simply change the section.
Again, learn how components work in Debian.
> - Where is the check to ensure files aren't uploaded to stable?
There isn't any, they go to proposed-updates and are installed into
stable manually or rejected from proposed-updates.
> - nothing except mkmaintainers seems to use the ftpdir/indices
Err, overrides are installed there by copyoverrides.