| === doko_ is now known as doko | ||
| micahg | hi doko, if I have an FTBFS fix for a new package, should I sync from Debian first, then upload the fix? | 07:07 |
|---|---|---|
| doko | I don't mind ;) | 07:08 |
| micahg | I'm just wondering what's better in terms of archive integrity | 07:08 |
| micahg | doko: ok, animal-sniffer in NEW | 07:10 |
| micahg | BTW, this fixes a depwait :) | 07:11 |
| micahg | doko: assuming it was you, thanks | 07:42 |
| pitti | GrueMaster, slangasek: -omap kernel> argh, I thought I caught them all when overriding; sorry | 07:50 |
| pitti | no idea how that one weaseled out :( | 07:50 |
| === rickspencer3_ is now known as rickspencer3 | ||
| cjwatson | Why does http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html only have one entry? That looks wrong. | 12:13 |
| === bladernr_afk is now known as bladernr_ | ||
| cjwatson | Laney,tumbleweed: if all autosyncs started to be done like https://launchpad.net/ubuntu/+source/autodocktools/1.5.6~rc2+cvs.20111222-1, would that work for you guys? | 14:23 |
| cjwatson | >>> autodocktools_spphs[0].creator | 14:23 |
| cjwatson | <person at https://api.launchpad.net/1.0/~katie> | 14:23 |
| cjwatson | >>> autodocktools_spphs[0].package_creator | 14:23 |
| cjwatson | <team at https://api.launchpad.net/1.0/~debian-med> | 14:23 |
| cjwatson | contrast with https://launchpad.net/ubuntu/+source/pybik/0.4.2-1: | 14:24 |
| cjwatson | >>> pybik_spphs[0].creator | 14:24 |
| cjwatson | >>> pybik_spphs[0].package_creator | 14:24 |
| cjwatson | <person at https://api.launchpad.net/1.0/~katie> | 14:24 |
| Laney | I think we get N/A for katie ATM | 14:25 |
| Laney | oh, wait | 14:26 |
| Laney | In [1]: lp.people['katie'].display_name | 14:26 |
| Laney | Out[1]: u'Ubuntu Archive Auto-Sync' | 14:26 |
| Laney | did that always work? | 14:26 |
| tumbleweed | it's the e-mail address that breaks, IIRC | 14:26 |
| Laney | In [2]: lp.people['katie'].preferred_email_address.email | 14:26 |
| Laney | Out[2]: u'archive@ubuntu.com' | 14:26 |
| tumbleweed | hrm | 14:26 |
| tumbleweed | something used to break badly... | 14:26 |
| Laney | In [9]: lp.distributions['ubuntu'].getArchive(name='primary').getPublishedSources(source_name='autodocktools')[0].creator.display_name | 14:28 |
| Laney | Out[9]: u'Ubuntu Archive Auto-Sync' | 14:28 |
| Laney | so it should be fine … | 14:28 |
| tumbleweed | http://paste.ubuntu.com/794897/ LGTM | 14:29 |
| Laney | something must have been fixed | 14:29 |
| cjwatson | I got the katie user unsuspended | 14:33 |
| cjwatson | https://answers.launchpad.net/launchpad/+question/183109 | 14:33 |
| cjwatson | that was necessary before I could do this | 14:33 |
| Laney | ah, great, good work | 14:33 |
| cjwatson | hmm, annoyingly I get e-mail for this sort of sync though | 14:34 |
| Laney | they're essentially syncs you are sponsoring for katie? | 14:35 |
| cjwatson | yes, in fact that was just syncpackage -s katie | 14:36 |
| cjwatson | though I'll write a new tool for it | 14:36 |
| cjwatson | well - I get mail myself, and it says that precise-changes will get mail, but it doesn't actually appear to | 14:36 |
| cjwatson | so I can probably put up with the spam until I get round to fixing it | 14:36 |
| Laney | I suppose that will email, indeed, until copyPackage grows a quiet mode. | 14:37 |
| cjwatson | I can probably just add more special-casing of katie | 14:37 |
| cjwatson | after all it's a celebrity so that special-casing is possible ... | 14:37 |
| Laney | more fun in the notification code either way | 14:39 |
| tumbleweed | Laney: I note that the sponsor still isn't visible in the SPPH? | 14:40 |
| Laney | yes | 14:40 |
| tumbleweed | grumble | 14:40 |
| Laney | there is a bug and a vague wish to look at it myself | 14:40 |
| Laney | but as bigjools didn't JFDI right away I suspect there might be something else there | 14:41 |
| cjwatson | so is there anything else that stops us transitioning entirely to API syncs for everything? | 14:44 |
| cjwatson | https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-admin-shell-access | 14:45 |
| tumbleweed | we can't do API backporting | 14:47 |
| cjwatson | I thought the plan for that was to just switch to backportpackage | 14:47 |
| tumbleweed | sounds fine, I guess | 14:48 |
| cjwatson | the reason I always wanted LP doing syncs was because they have the same version number and therefore I want something to assure that they're really verbatim copies; backports don't have that problem | 14:48 |
| cjwatson | I don't recall whether backporters can definitely always upload to -backports, but that's fixable if not | 14:49 |
| tumbleweed | aren't there still issues with timeouts, when copying from PPAs via API? | 14:49 |
| cjwatson | (and worst case we can have something like the current system where archive admins help them out) | 14:49 |
| cjwatson | possibly, I don't know. Do you have a bug#? | 14:49 |
| Laney | we can modify backport-helper to use backportpackage indeed | 14:50 |
| cjwatson | actually finishing all the stuff is clearly a few months' of work | 14:50 |
| tumbleweed | search turns up bug 575450 and bug 817358 | 14:51 |
| cjwatson | *this stuff | 14:51 |
| ubot4 | Launchpad bug 575450 in launchpad "Archive:+copy-packages nearly unusable due to timeouts (affects: 13) (dups: 6) (heat: 75)" [Critical,Triaged] https://launchpad.net/bugs/575450 | 14:51 |
| ubot4 | Launchpad bug 817358 in launchpad "Copying packages with lots of associated bugs can cause timeout (affects: 1) (heat: 1)" [Critical,Triaged] https://launchpad.net/bugs/817358 | 14:51 |
| Laney | it would be good to have blacklist in LP too, but not a blocker if the tools continue to look at sync-blacklist.txt | 14:51 |
| cjwatson | the first is a UI copy which I strongly suspect is more susceptible to timeouts | 14:51 |
| cjwatson | Laney: I was shelving that until I could do API autosyncs; now that I almost can I'll be ready to push the blacklist to LP soonish | 14:51 |
| cjwatson | sru-release is using .syncSource and should probably be using .copyPackage | 14:52 |
| tumbleweed | cjwatson: IIRC copyPackage can't copy from PPAs, and syncSource can but isn't synchronous | 14:52 |
| cjwatson | .syncSource is synchronous so is bound to timeout | 14:52 |
| tumbleweed | err is synchronous | 14:52 |
| cjwatson | I think copyPackage has been fixed; https://launchpad.net/+apidoc/devel.html#archive shows a from_archive parameter | 14:53 |
| cjwatson | surely that's enough to copy from PPAs | 14:53 |
| cjwatson | Bug 902114 is kind of unfortunate, but if we kept on using bugs and just had mass-sync use a different backend, it wouldn't be a showstopper | 14:57 |
| ubot4 | Launchpad bug 902114 in launchpad "When sponsoring using copyPackage, the sponsored person is not sent email from Soyuz (affects: 1) (heat: 13)" [High,Triaged] https://launchpad.net/bugs/902114 | 14:57 |
| Laney | you can't copy /to/ PPAs, don't know about from | 14:57 |
| cjwatson | Hm, how come? | 14:57 |
| Laney | Response body: | 14:57 |
| Laney | --- | 14:57 |
| Laney | Not enabled for copying to PPAs yet. | 14:57 |
| Laney | --- | 14:57 |
| cjwatson | sigh, ok | 14:58 |
| cjwatson | It's behind a feature flag | 14:58 |
| cjwatson | # We have no way of giving feedback about failed jobs yet, | 14:59 |
| cjwatson | # so this is disabled for now. | 14:59 |
| Laney | looks like it only applies to PPA as destination though? | 14:59 |
| Daviey | Hmm... does syncSource() not work now? | 14:59 |
| Daviey | from archive -> PPA ? | 15:00 |
| cjwatson | Laney: I think so | 15:00 |
| cjwatson | Daviey: sure, but syncSource often times out | 15:00 |
| Daviey | ahh | 15:00 |
| cjwatson | Daviey: it's a synchronous API call | 15:00 |
| Laney | I'll just test with something | 15:00 |
| Daviey | bug 334858 | 15:01 |
| ubot4 | Launchpad bug 334858 in launchpad "Require a way to copy [P]PPA packages into Ubuntu (dups: 1) (heat: 9)" [High,Triaged] https://launchpad.net/bugs/334858 | 15:01 |
| cjwatson | thanks for the link | 15:03 |
| cjwatson | it might be enough for sru-release though; I'll have to give that a try | 15:04 |
| cjwatson | pitti: re bug 891886 et al, given that oneiric and precise are in sync, is there any reason I shouldn't just sru-release --devel it? (Please don't just do that though; I was hoping to use it as a test case for an sru-release change) | 15:11 |
| ubot4 | Launchpad bug 891886 in compiz-plugins-main (Ubuntu Precise) (and 2 other projects) "Compiz grid plugin is fired when resizing a window (affects: 4) (dups: 1) (heat: 25)" [High,In progress] https://launchpad.net/bugs/891886 | 15:11 |
| Laney | https://launchpad.net/ubuntu/+source/haskell-skein/0.1.0.3-2 worked | 15:11 |
| Laney | (sync from PPA) | 15:11 |
| * Laney gets briefly freaked out by "Component: main" | 15:12 | |
| cjwatson | Neat. With include_binaries=False presumably? | 15:12 |
| jdstrand | skaet: hey, not sure if you are aware, but http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html lost a bunch of bugs. seems I looked at it yesterday and it was full | 15:13 |
| Laney | well, there aren't any yet, but yes | 15:13 |
| skaet | jstrand, thanks for the head's up. Hadn't checked it this morning. Will look into it later. | 15:14 |
| jdstrand | skaet: may be that only critical bugs are shown, even though the options say everything should be | 15:14 |
| skaet | hmm... interesting. | 15:14 |
| skaet | ok, after the meeting. | 15:14 |
| jdstrand | toggling the non-critical checkboxes indeed does nothing. toggling critical does what you would expect | 15:15 |
| pitti | cjwatson: not technically, just policy-wise (build packages against precise and all that) | 15:18 |
| pitti | cjwatson: but we'll get a compiz release next Monday anyway, so I don't object | 15:18 |
| pitti | cjwatson: at UDS we had a discussion about SRU policy, and skaet and me argued pretty strongly for actually uploading to precise first | 15:18 |
| pitti | we had quite some trouble with oneiric-proposed -> precise copying in particular when there was buildd lag/powerpc failure | 15:19 |
| cjwatson | oh, I agree in general | 15:23 |
| cjwatson | do you know if it would be a problem in this specific case? | 15:23 |
| cjwatson | mostly just because it's the only available test case right now :-) | 15:24 |
| pitti | cjwatson: no, should be fine here | 15:36 |
| pitti | cjwatson: armhf should get a new build record automatically | 15:36 |
| pitti | (sorry, didn't see your response) | 15:36 |
| cjwatson | hm, I hadn't thought of armhf; let's see | 15:37 |
| cjwatson | https://launchpad.net/ubuntu/precise/+source/compiz-plugins-main/1:0.9.6-0ubuntu4.2 looks OK | 15:42 |
| cjwatson | https://launchpad.net/ubuntu/+source/compiz-plugins-main/+publishinghistory not seeing anything for oneiric-updates though | 15:44 |
| micahg | cjwatson: just got a -changes E-Mail for that copy | 15:46 |
| skaet | Daviey, "nothing to declare"... lol. Am wondering if there is an equivalent of random search that should come into play like at customs when crossing a border. ;) | 15:50 |
| cjwatson | micahg: I've got one for precise, but not for oneiric | 15:51 |
| pitti | cjwatson: but sru-release didn't crash? hm, strange; it's been a while since I used -d | 15:51 |
| pitti | cjwatson: can you try to run it again without -d? | 15:51 |
| cjwatson | http://paste.ubuntu.com/794968/ | 15:52 |
| cjwatson | this is with http://paste.ubuntu.com/794970/ applied | 15:52 |
| micahg | cjwatson: right, the one for oneiric was originally 18 days ago | 15:52 |
| pitti | cjwatson: so with syncSource (as well as copy-package.py) the copy to devel needed to happen first, then -updates; otherwise it complained about unpublished stuff in oneiric-updates when trying to copy to precise afterwards; perhaps copyPackage behaves differently now? | 15:53 |
| cjwatson | in that case it's possible it doesn't work because copyPackage is asynchronous so when it returns the copy hasn't actually happened yet | 15:54 |
| cjwatson | did it have to actually be published? | 15:54 |
| cjwatson | I tried again and it still isn't working; asking on the LP ops channel if anyone can help me debug | 16:02 |
| cjwatson | I'll probably revert to syncSource in half an hour or so if I don't hear anything | 16:03 |
| Daviey | skaet: if there are rubber gloves, i'll be there. | 16:09 |
| skaet | Daviey, LOL. | 16:11 |
| cjwatson | compiz-plugins-main 1:0.9.6-0ubuntu4.2 in precise (same version already building in the destination archive for Precise) | 16:16 |
| cjwatson | Maybe that's blocking copyPackage too | 16:16 |
| * cjwatson cranks up the armhf build score there | 16:16 | |
| cjwatson | this is a bug though | 16:18 |
| ev | I'll have a new wubi finally up just as soon as people.c.c rises from the dead | 16:37 |
| cjwatson | OK. New auto-sync script not absolutely the fastest thing ever but it seems to be at least minimally managing to scan the differences. | 21:16 |
| cjwatson | Things I still need to do to it: (1) test that it returns the same set of results as sync-source.py -a; (2) add checks for conflicting binary versions; (3) add checks for syncs that require fakesyncs; (4) possibly check for pending Ubuntu publications as well as published ones | 21:17 |
| cjwatson | oh and (5) make it scan the blacklist, pending shifting that into LP | 21:17 |
| cjwatson | I might be able to make the last autosync for precise be API-based :-) | 21:18 |
| Laney | :-) | 22:21 |
| cjwatson | (5) done | 22:21 |
| Laney | are you still seeing many bug based sync requests from developers? | 22:22 |
| Laney | if so, we might want to announce syncpackage a bit | 22:22 |
| cjwatson | a handful, very few | 22:22 |
| cjwatson | but probably, yes | 22:22 |
| Laney | syncpackage can do (3) … | 22:23 |
| tumbleweed | and announce avoiding +localpackagediffs at the same time, so we can refer to it in future :) | 22:23 |
| cjwatson | Laney: true, may steal / call some code | 22:23 |
| Laney | maybe it could be extended to work on multiple packages at once | 22:23 |
| Laney | or get / become a library indeed | 22:23 |
| cjwatson | I do want auto-sync to be a separate thing really; it has slightly odd semantics and I don't want it to have the same kinds of options | 22:24 |
| cjwatson | e.g. auto-sync -f would be very bad | 22:24 |
| Laney | I was thinking you could have it hand off to syncpackage at some stage | 22:24 |
| cjwatson | (2) is a bit awkward because sync-source.py never got that *quite* right | 22:24 |
| Laney | not sure what that means | 22:24 |
| cjwatson | I don't think I'd want it to actually call syncpackage, but maybe use some common code | 22:25 |
| cjwatson | that said, the actual sync bit really isn't very much code | 22:25 |
| cjwatson | only the fakesync detection is actually hard in any way | 22:25 |
| tumbleweed | common checks sounds like a useful thing | 22:25 |
| cjwatson | wrapping things up in udt objects to call syncpackage might be more trouble than it's worth | 22:25 |
| cjwatson | given that I'm calculating the sync list from a distro_series_difference collection | 22:26 |
| tumbleweed | agreed | 22:26 |
| tumbleweed | I also don't understand (2) | 22:26 |
| cjwatson | syncpackage probably ought to gain (2) actually. That's a check that the binary versions that are produced by the source package don't accidentally override binaries from another source that have an ubuntu version number | 22:27 |
| cjwatson | so any such syncs require -f | 22:27 |
| tumbleweed | sounds useful, yes | 22:27 |
| cjwatson | so if you have libfoo 1.0-1ubuntu1 -> [libfoo0 1.0-1ubuntu1, libfoo-dev 1.0-1ubuntu1] and you try to sync foo 1.0-1 -> [foo 1.0-1] ==> foo 1.0-2 -> [foo 1.0-2, libfoo0 1.0-2, libfoo-dev 1.0-2], that should require forcing | 22:28 |
| cjwatson | if that notation makes sense | 22:28 |
| cjwatson | sync-source.py checked this rather crudely and got it wrong in two ways, possibly with the same potential fix: | 22:29 |
| cjwatson | (1) in the above example, if foo 1.0-2 failed to build and you then tried to sync foo 1.0-3, you had to force that as well because it checked the set of binaries actually in the archive rather than the set of binaries that would be in the archive if everything had built | 22:30 |
| cjwatson | (2) packages that have a source with no ubuntu version substring but binaries with an ubuntu version substring have to be forcibly synced every time (yes, there is a real example of this in the archive!) | 22:30 |
| cjwatson | (it's something that generates binaries based on binutils-source and concatenates binutils' version number with its own, or something along those lines) | 22:31 |
| tumbleweed | hah | 22:31 |
| tumbleweed | (1) isn't a dig problem, though | 22:31 |
| cjwatson | I think the fix is not to check actual binaries based on Packages or getPublishedBinaries, but instead to check whether each of the binaries produced by the new source are in the Binary field of any other source package with an ubuntu version substring | 22:32 |
| cjwatson | that would deal with both problems | 22:32 |
| cjwatson | possibly excluding binaries that have already been superseded | 22:32 |
| cjwatson | need to figure out how to do that quickly in the API though | 22:33 |
| tumbleweed | sounds reasonable | 22:33 |
| Laney | can you do that in the API? | 22:34 |
| cjwatson | I'm not sure | 22:34 |
| tumbleweed | it'll involve reading the .dsc too | 22:34 |
| cjwatson | reading *every* .dsc | 22:34 |
| cjwatson | which would suck | 22:34 |
| Laney | yeah. not the fastest thing to do. | 22:34 |
| cjwatson | might be quicker to just download Sources | 22:35 |
| tumbleweed | oh, right | 22:35 |
| cjwatson | I was hoping to avoid that, but ... | 22:35 |
| Laney | unless an external job maintains a database | 22:35 |
| tumbleweed | (which would be preferable fo syncpackage) | 22:35 |
| cjwatson | I wouldn't do that, I'd extend LP if I really needed that | 22:35 |
| tumbleweed | extending LP to know the contents of .dsc s would be handy for other bits of u-dt | 22:35 |
| cjwatson | it already does, but this is sort of a reverse lookup | 22:36 |
| tumbleweed | yes | 22:36 |
| cjwatson | I mean, internally it has SPR.dsc_binaries (although it's sometimes wrong; I have a branch in progress at the moment to fix that up) | 22:36 |
| cjwatson | but we want to search for any source that has this binary in dsc_binaries | 22:36 |
| cjwatson | indeed a binary -> source(s) lookup would be a useful thing to have in general | 22:37 |
| cjwatson | maybe just getPublishedSources(binary_name=...) | 22:38 |
| cjwatson | I'll file an LP bug in a bit and see if anyone has comments; DVD time now | 22:39 |
| Laney | I wonder what checks mass-sync would perform that we wouldn't also want syncpackage to | 22:43 |
| Laney | seeya | 22:43 |
| === bladernr_ is now known as bladernr_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!