Re: propogate-fixes
* Andreas Barth (aba@not.so.argh.org) [050911 15:15]:
> 2. if only some architectures are not built in unstable, that leads to
> REJECTs due to missing sources in unstable for the propogated
> architectures
> 3. if the package is removed from the overrides, the updates go to NEW.
obviously, we have now two counter-examples for both cases. The core reason
is the same:
The suites the upload go to is one variable for all packages, so
> --- /usr/bin/kelly~ 2005-09-10 19:37:45.676001000 +0200
> +++ /usr/bin/kelly 2005-09-10 20:43:38.961011112 +0200
> @@ -129,8 +129,13 @@
> (reject_msg, is_in_incoming) = Katie.check_dsc_against_db(file);
> reject(reject_msg, "");
>
> + # propogate in the case it is in the override tables:
> + if changes.has_key("propdistribution"):
> + for suite in changes["propdistribution"].keys():
> + if not Katie.in_override_p(files[file]["package"], files[file]["component"], suite, files[file].get("dbtype",""), file): continue
> + changes["distribution"][suite] = 1
> # Check the package is still in the override tables
> for suite in changes["distribution"].keys():
> if not Katie.in_override_p(files[file]["package"], files[file]["component"], suite, files[file].get("dbtype",""), file):
> reject("%s is NEW for %s." % (file, suite));
this loop will lead to rejects for all but the first file, because the
changes["distribution"] is per changes-file, and not per file, so the
propogate-suite gets added after the first file.
There is another issue - how should files be handled that are partly
missing overrides (like the current libkde-upload to stable-security,
where the lib is renamed in unstable due to the c++-abi-transition)? Of
course, the fix for this case is to add testing overrides, but the same
could happen for fucked_arches in testing or even in unstable. The two
options are either to propogate without an override entry, or to not
propogate any file of this changes-file. (The third option is of course
to unaccept, and the fourth to allow individual distributions per file -
but both are IMHO way too ugly :).
So, the fix would be to do the propogation after all files are done:
--- /org/ftp.debian.org/katie/kelly 2005-10-01 23:30:35.000000000 -0700
+++ ./kelly 2005-10-03 12:49:27.906246420 -0700
@@ -107,6 +108,8 @@
# frozen between accept and our run time.
def check():
+ propogate={}
+ nopropogate={}
for file in files.keys():
# The .orig.tar.gz can disappear out from under us is it's a
# duplicate of one in the archive.
@@ -132,8 +135,15 @@
# propogate in the case it is in the override tables:
if changes.has_key("propdistribution"):
for suite in changes["propdistribution"].keys():
- if not Katie.in_override_p(files[file]["package"], files[file]
["component"], suite, files[file].get("dbtype",""), file): continue
- changes["distribution"][suite] = 1
+ if not Katie.in_override_p(files[file]["package"], files[file]
["component"], suite, files[file].get("dbtype",""), file): nopropogate[suite] =
1
+ else: propogate[suite] = 1
+
+ for suite in propogate.keys():
+ if suite in nopropogate:
+ continue
+ changes["distribution"][suite] = 1
+
+ for file in files.keys():
# Check the package is still in the override tables
for suite in changes["distribution"].keys():
if not Katie.in_override_p(files[file]["package"], files[file]["co
mponent"], suite, files[file].get("dbtype",""), file):
This fix doesn't propogate if the overrides are missing for at least one
file. The other option would just require the propogate-hash, and just
propogate all of it's members ...
And, sadly this showed that
> Following these thoughts, I created a preliminary patch. I also did an
> test in the situation of 1. Further talks and thoughts are definitly
> necessary, but I'll still send the mail to (hopefully) get some further
> input.
was not really a wrong forecast. :/
Cheers,
Andi
Reply to: