| === AlanChicken is now known as AlanBell | ||
| cjwatson | so it turns out that the API autosyncs over the weekend synced rather more than intended | 11:47 |
|---|---|---|
| cjwatson | the selection of source packages to sync was correct, and based on testing | 11:47 |
| cjwatson | but the API method used to do the actual sync doesn't take a from_series parameter, so it took the most recent published source in Debian for each of the named source packages | 11:48 |
| cjwatson | in some cases that would have been from unstable or even experimental :-/ | 11:48 |
| Laney | do you know what was affected? | 11:48 |
| cjwatson | I'm going to fix LP as a priority, and then try to figure out a list of affected packages | 11:48 |
| cjwatson | libcdio was the one that alerted me to this | 11:49 |
| Laney | last time we didn't pay anywhere near good enough attention to the impact of the borked sync and it kept cropping up later on in the cycle | 11:52 |
| === jdstrand1 is now known as jdstrand | ||
| cjwatson | Laney: OK, report sent to ubuntu-release@ | 13:57 |
| Laney | great, thanks | 13:57 |
| Laney | doesn't look as bad as it could be | 13:58 |
| Laney | actually it is a bit surprising that it's only ~15 packages | 13:59 |
| cjwatson | the selection of packages to sync worked properly | 14:02 |
| cjwatson | it was only the selection of versions for those packages | 14:02 |
| cjwatson | so the only packages affected were those that were going to be synced anyway (newer in testing since the last autosync, or just plain new in testing) and that also had newer versions in unstable and/or experimental | 14:03 |
| cjwatson | that limited the damage quite a bit | 14:03 |
| Laney | ah | 14:04 |
| Laney | that is fortunate indeed | 14:04 |
| cjwatson | I've nearly got it fixed, just can't quite get the last damn test to pass | 14:04 |
| cjwatson | feeding all the libcdio rdeps to sbuild now | 14:11 |
| === bladernr_afk is now known as bladernr_ | ||
| Laney | maradns ftbfs almost everywhere :( | 14:13 |
| Laney | at first glance looks like arch/indep fail | 14:14 |
| cjwatson | hm, must have missed that | 14:14 |
| tumbleweed | given that it's a day old in experimental, that'll probably be fixed soon | 14:14 |
| cjwatson | maybe we should get in touch with the Debian maintainer there and find out what's going on | 14:14 |
| Laney | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654987 | 14:14 |
| ubot4 | Debian bug 654987 in maradns "maradns: FTBS in experimental" [Important,Open] | 14:14 |
| cjwatson | if maradns and a single library transition is the worst of it, though, that could be a lot worse | 14:15 |
| cjwatson | depending on how groovy looks | 14:15 |
| cjwatson | oh, meant to CC jamespage, will bounce it to him | 14:15 |
| Laney | I can't fix maradns quickly enough to do it in work hours | 14:20 |
| Laney | surprised the maintainer is so confused by it though … | 14:22 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| cjwatson | pitti: do you think I can safely go ahead and promote mvo's release-upgrader-apt and release-upgrader-python-apt from lucid-proposed to lucid-updates? | 16:37 |
| cjwatson | it doesn't have bugs associated so doesn't magically go green; but these are new packages so should be no impact | 16:38 |
| pitti | cjwatson: oh, sure; I haven't talked to mvo about testing them, but if he is happy, I am | 16:38 |
| cjwatson | he said he'd tested with the packages in his PPA | 16:38 |
| mvo | should be fine, its tested in the auto-upgrade tester for the lucid->precise upgrade profile automatically and seems to be doing ok afaict | 16:40 |
| pitti | mvo: great, thanks; so, fine for me | 16:42 |
| mvo | thanks! I will update update-manager to use the version from -updates then, thats great | 16:42 |
| cjwatson | copying | 16:43 |
| cjwatson | oh damn I forgot the command-line syntax and also copied to -security by mistake | 16:43 |
| cjwatson | I suppose I should delete that | 16:43 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| jbicha | Laney: I mistakenly uploaded totem 3.3.4 meant for a PPA to precise, how should I fix this? | 21:48 |
| Laney | err | 22:24 |
| micahg | Laney: sorry, that wasn't the question he was supposed to ask you :) | 22:26 |
| Laney | hmm? | 22:26 |
| micahg | Laney: I thought he was asking for dput tips, so that's why I sent him to you | 22:27 |
| Laney | am I considered particularly knowledgable about dput? :P | 22:28 |
| micahg | Laney: weren't you the one suggesting people change their default dput localtion? | 22:28 |
| Laney | I do suggest that, yes, but I thought it was common practice | 22:29 |
| Laney | jbicha: anyway, if that's why you did it then I suggest you change the defaultkrkeyman__ | 22:29 |
| Laney | err wtf | 22:30 |
| * Laney bashes the x keyboard hard | 22:30 | |
| Laney | clipboard | 22:30 |
| Laney | as for the specific upload, I assume you don't want that series to be in precise? | 22:31 |
| jbicha | Laney: we will definitely be sticking with totem 3.0 for precise | 22:31 |
| Laney | then you'll need to revert to the previous version | 22:32 |
| jbicha | since the new version is in depwait, is there a way to remove/overwrite the new upload so we don't have to use 3.3.4+really3.0? | 22:33 |
| micahg | right, but I think the best thing to do is to have an archive admin remove 3.3.4 and he upload a regular 3.0.1-0ubuntu13 | 22:33 |
| micahg | otherwise we're stuck with that horrible version for 5 years :( | 22:33 |
| Laney | well, the source is there even if binaries are not | 22:34 |
| micahg | yes, but that can be removed easily :) | 22:34 |
| Laney | really? | 22:35 |
| micahg | yeah, it's just a source, so no problems with apt upgrading (that's the main reason to revert by uploading a higher version) | 22:36 |
| Laney | does launchpad let you do that? there will still be publications for this version | 22:37 |
| micahg | yep | 22:37 |
| Laney | weird | 22:37 |
| micahg | unless something was "fixed" recently | 22:37 |
| cjwatson | we aren't going to remove that version, and we would have to edit LP code to upload an older one anyway | 23:03 |
| cjwatson | at least I'm fairly sure of that | 23:05 |
| cjwatson | I suppose I can try it on the basis that you're going to be uploading a newer version anyway, although I'm a bit worried of screwing up the database | 23:06 |
| Laney | hrm, might set a precedent that this is the way to deal with accidental uploads | 23:07 |
| cjwatson | well, I may actually be wrong; soyuz seems to check against the ancestry whose definition includes a restriction to pending and published SPPHs | 23:26 |
| cjwatson | jbicha: still around? | 23:26 |
| jbicha | cjwatson: yes | 23:42 |
| cjwatson | jbicha: will you be around in about 45 minutes? | 23:47 |
| jbicha | cjwatson: sure | 23:47 |
| cjwatson | jbicha: this is very much against my better judgement, but I'll try removing the totem 3.3.4-0ubuntu1~precise1 source | 23:48 |
| lamont | arm maintenence... sorry for the wave | 23:48 |
| cjwatson | jbicha: I think you may be able to try re-uploading now | 23:49 |
| cjwatson | but I'm not sure; it may have to publish the deletion first | 23:49 |
| cjwatson | and it may get the package ancestry wrong | 23:50 |
| cjwatson | I can't predict the exact effects, although I don't think they'll be too horrible | 23:50 |
| cjwatson | jbicha: I'd like to know when you've done it so I can watch logs, though | 23:52 |
| jbicha | cjwatson: ok, I just dputted 3.0.1-0ubuntu13 | 23:55 |
| cjwatson | two minutes ... | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!