Joerg Jaspert [Mon, 4 May 2009 19:19:37 +0000 (21:19 +0200)]
Merge commit 'allan/bugfixes' into merge
* commit 'allan/bugfixes':
Check for the existance of the function before trying to drop it.
Added mention of groups required by update11.py
Fixed missing DBUpdateError imports.
Joerg Jaspert [Sat, 2 May 2009 15:53:51 +0000 (17:53 +0200)]
p-n
allow process-new to also look in newstage/ for the source. files
might not yet be in one of the other queues if it just got accepted
through one of the NEW queues.
No other process-* should need this, but p-n does.
Allan Lyons [Fri, 1 May 2009 18:28:47 +0000 (12:28 -0600)]
Check for the existance of the function before trying to drop it.
At least on my machine, ignoring the error if the function doesn't exist
doesn't work since psycopg2 bombs. So, we attempt to at least check if
there are any functions with a similar name before trying to drop it.
This way it should work better on an empty database where the function
has never existed.
Signed-off-by: Allan Lyons <Allan_Lyons@wycliffe.ca>
in case we did get called with a directory, do not complain about non-existing
.changes files. silently exit instead. helpful for calls from within cron, if you
dont want to have an additional otherwise useless if around it
unchecked stuff now also in functions.
call a few functions from within dinstall, right before we run accepted.
Otherwise, with the new way of NEW, stuff from (o-)p-u-new would take
two dinstall runs before it is from there into the archive proper...
modified process-new and all related stuff so NEW can now also be processed
during (most of) dinstall. The lock where NEW is forbidden is then down to
some 15 til 20 minutes, instead of 2 hours.
For that process-new moves files into a "staging" directory, from which
cron.unchecked will move them into the accepted queue. As c.u only runs when
it is safe to do so this is fine.
The small part where we still are forbidden to do NEW is between the point where
we run process-accepted and right before we start generating Packages files. As
that is exactly the area daily.lock exists for, process-new now locks on that and
simply refuses to do work then.
we should not return the path, but just set the Cnf values to whatever is
in that local config file, so that can point to the right dak.conf then.
and, as that will be different from default "/etc/dak/dak.conf" then let
the usual process read in our different config files
* merge:
skip arches we should skip
i think contents are actually working on separate thread now?
possibly working multithread contents writer that has udebs disabled
change reject email template to solicit a reply if new files are uploaded
convert binaries.type to a enum
some tweaking to the contents generation queries
strip ./ from front of paths during contents.bootstrap
* commit 'stew/content_generation':
skip arches we should skip
i think contents are actually working on separate thread now?
possibly working multithread contents writer that has udebs disabled
change reject email template to solicit a reply if new files are uploaded
convert binaries.type to a enum
some tweaking to the contents generation queries
strip ./ from front of paths during contents.bootstrap
notes now have a timestamp column.
do not allow to edit old notes, only add new ones
hand over existing notes (if any) to the reject message (unless we get called with -m)
hand over existing notes (if any) to the prod message
add a trainee mode which forbids certain actions to be taken.
This is turned on by the -t option or (more likely) by just being unable
to open the dak logfile.
In trainee mode one can edit and remove notes, "Check" a package and skip or quit
the tool, nothing else. Every other menu option just rewrites the menu.
remove etch-m68k from apt.conf. No need to always regenerate its files.
There hasnt been an upload to it for months.
And starting today, etch-m68k is also untouchable. We should reject uploads for it
Merge branch 'master' of ssh://ftp-master.debian.org/srv/ftp.debian.org/git/dak
* 'master' of ssh://ftp-master.debian.org/srv/ftp.debian.org/git/dak:
fix undefined cursor
Fix the is_dm check to deal with the fact we have typing in our DB layer
Mark Hymers [Wed, 8 Apr 2009 20:45:46 +0000 (21:45 +0100)]
Fix the is_dm check to deal with the fact we have typing in our DB layer
This code is still fundamentally wrong (assuming unknown UIDs are DDs is
idiotic; of course we know that the keys have had to pass the sig check
against the keyring so it's not a security issue thankfully; it just
might give a one shot limited window for DMs to upload non-DM packages)
moved all the code creating this into the common file, new function
cron.unchecked now just calls this function (and so sources the common file)
cron.dinstall also calls this function, immediately after process-accepted did run.
This should get the times where buildds get 403 on files down to at max. the runtime
of process-accepted.
tell merkel that it should sync the dd accessible parts.
do that after the long run of apt-ftparchive clean, so we have a large
delay between the earlier "sync projectb" and this, so to not overload
merkel too much.
projects / dak.git / log