Joerg Jaspert [Wed, 3 Jun 2009 23:11:20 +0000 (01:11 +0200)]
dinstall
background two function calls.
once for the initial ssh to merkel and the other the dak-dev cluster
projectb reload on ries.
The first does not need to be foreground, we do not care if we are already
continuing in dinstall, its only informative for the qa user on merkel.
The second also doesnt need to run alone. The next thing after it is the 1hour
apt-fuckthearchive call. So the dak-dev reload will well be done, with its 15 minutes
runtime, before the next function is also done. And there is no harm done
in having the two run at the same time.
Joerg Jaspert [Wed, 3 Jun 2009 23:09:01 +0000 (01:09 +0200)]
dinstall
put all log created by the varios functions into files named after
their stage lockfile. At the end of the function, redirect log
back to the global LOGFILE, after their stage logfile got appended to
it.
Use the stage logfile in the ERRtrap, so whenever an error happen the
stuff that gets mailed is the short part that happens to be around the
error, not the whole long stuff the complete dinstall log happens to be.
Joerg Jaspert [Sat, 23 May 2009 17:35:22 +0000 (19:35 +0200)]
mail address
somehow some people got confused with a From: "Debian Installer <installer@ftp-master.d.o>".
While I dont see how one can mistaken that to be from a tool you
install your system with, change it to archive administrator instead.
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.
projects / dak.git / log