Adeodato Simó [Sat, 23 May 2009 15:32:19 +0000 (17:32 +0200)]
Send the "transitions completed" mail to debian-devel instead of the RT.
As per http://lists.debian.org/debian-devel/2009/05/msg00673.html, notice
of transition blocks being lifted is going to be sent to debian-devel and
not to the release team.
This commit also reworks the wording of the body of the message (the
important bit being that the block is lifted, rather than the transitions
were removed from the transitions.yaml file), and it includes the names
of the finished transitions in the Subject of the mail.
Joerg Jaspert [Thu, 14 May 2009 22:38:58 +0000 (00:38 +0200)]
p-n
look process-new with an own lockfile.
This wont make a difference for dinstall, same lock time there.
But it will make a big difference whenever cron.unchecked runs (which is far
more often), as it now will lock for a few seconds and not for the
sometimes unbearable long times process-unchecked and the w-b trigger
needs.
Joerg Jaspert [Sat, 9 May 2009 16:52:58 +0000 (18:52 +0200)]
process-new
no longer check the daily lock when we start looking at a package, but
when we try to do modifying actions.
No reason to not allow people to do Check/Reject/Note, those are actions
we can do whenever. Its just modifying overrides which *have* to be
avoided at certain times.
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)
projects / dak.git / log