[02:59] How do I push a branch to staging again? It trips me up every time. "Read-only transport," it says, whether I use lp: or bzr+ssh: [02:59] lp-staging:// [02:59] or is it lp://staging/... [02:59] one of them [02:59] if its connecting and then saying read-only, you're not in the team :> [03:04] jtv: qastaing? or staging? I used bzr push lp://qastaging/~rharding/... for qastaging with success [03:04] lifeless: what team? [03:04] rick_h_: I suppose I could try qastaging, thanks. [03:05] the one you are pushing to a branch of [03:05] lifeless: I tried lp://staging/, which is what the UI tells me to do, but same error. [03:05] jtv: what was the full url [03:05] lifeless: so "read-only transport" from bzr can actually mean that I don't have privileges? [03:06] it means it tried to write and failed [03:06] lp://staging/~stellarium/stellarium/auto-po [03:06] either because its using http or can't write [03:06] jtv: and are you a member of ~stellarium on staging? [03:06] No. [03:07] ok, so thats working as expected [03:07] Except for the misleading error message. [03:07] bzr doesn't know the cause for being unable to write [03:09] That's not very comforting to me, is it? It tells me "read-only transport" when there's nothing wrong with the transport, only with where I'm trying to transport to. [03:12] indeed [03:12] its also exactly what will happen if you push locally to a directory you only have rx bits on [03:12] for instance [03:13] feel free to file a bug on bzr/bzr+lp [03:21] hah [03:22] dead code in LP's DB migration system [03:22] win [03:22] lifeless: Where? [03:22] jtv: Bug #894177 [03:22] <_mup_> Bug #894177: run_jobs.py pofile_stats oopses: permission denied for relation productseries

< https://launchpad.net/bugs/894177 > [03:22] wgrant: oh, so what I filed was a dupe. :( [03:23] Looks like the script was converted to a job, and then not tested under realistic access rights. [03:23] Yeah. You might want to throw your info into that one. [03:23] Yes. [03:23] Thanks. [03:23] Well. [03:23] It works fine for distro templates. [03:23] Just not product ones. [03:23] I've tested locally and product+productseries is sufficient. [03:24] wgrant: upgradelog [03:25] wgrant: implemented on non-slony environments only [03:25] I see no upgradelog [03:26] ah, its new, not dead [03:26] stub is capturing the sql executed [03:26] * lifeless ports [03:26] Is that the thing I reverted over the weekend? [03:26] yes [03:26] because it was broken, yes. [03:27] did it break on qastaging or staging ? [03:28] if it broke on staging, its because the autodetect stuff for it was only on the non-slony case [03:29] buildbot [03:29] ah, interesting [03:30] https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1617/steps/compile_1/logs/stdio [03:30] File "upgrade.py", line 645, in get_bzr_details [03:30] ValueError: need more than 1 value to unpack [03:30] branch_nick, revno, revision_id = out.split(' ', 3) [03:33] hmmm, I think I want to chat to sub. And I started early today; so going to EODish. (As in , will be back later) [03:33] kk [07:09] it [07:09] oops, was going to say that it's weird that I get E-Mails that I've assigned myself a bug faster than a page refresh [07:17] stub: can we have a call in ~ 1 hour about trusted.sql etc and lazr_postgresql ? [07:26] lifeless: sure [07:48] lifeless: https://code.launchpad.net/~stub/launchpad/db-deploy/+merge/84231 will affect this work btw [08:10] flacoste: You around? [08:14] bkerensa: Probably not for a few hours yet. [08:15] But there are lots of LP devs around. [08:15] wgrant: K just looking for someone on the Launchpad team to interview for Dev News about the new Beta Bug Listing Features and other things being worked on [08:16] bkerensa: Most people who have been working on that (and flacoste) are in the Americas, so won't be around for a while. [08:17] wgrant: k ;) I'm in the Americas but I'm also a night owl :P so perhaps I'll catch them tomorrow (I will just idle) [08:18] Heh [08:46] good morning [09:00] good morning [09:01] Hello [09:07] has anyone else seen spurious errors in lp.buildmaster.tests.test_builder.TestSlave in ec2? [09:08] bigjools: new bug for you - https://bugs.launchpad.net/txlongpoll/+bug/900579 - I believe its pretty shallow. [09:08] <_mup_> Bug #900579: txlong poll reads any queue < https://launchpad.net/bugs/900579 > [09:08] bigjools: (it may just be a deployment thing in fact) [09:08] bigjools: https://code.launchpad.net/+longpoll/?uuid=oopses&sequence=1 is a good url to make the impact clear ;) [09:08] lifeless: yeah, I tend to err on the side of permissions [09:08] * lifeless really really goes now [09:26] lifeless: Interesting (re. https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715). I may borrow that for an experiment. Ta. [09:44] bigjools: huwshimi had one of those yesterday. First I'd seen of it. === gmb` is now known as gmb === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 3*10^2 [10:47] * cjwatson bangs his head against bug 713764 [10:47] <_mup_> Bug #713764: fake librarian columns cannot be looked up by storm < https://launchpad.net/bugs/713764 > [10:47] How do I revert a reversion on my branch? [10:49] stub: merge a reversion of the reversion :) [10:49] stub: e.g. "bzr merge -r-5..-4 ." [10:49] I mean the magic commit message tags - list it as a reversion there? [10:49] ah [10:50] stub: I'd add the same tags as in the original commit that landed it [bug=YYYYYY][r=...] etc, and a comment saying it's relanding something that was rolled back [10:50] There must surely be other examples in LP of mock objects wrapping Storm objects that can still manage to be looked up by Storm, but I can't find a pattern that works [10:51] Maybe I'll just have to use the full librarian the way everyone else who's run into this seems to have done :-/ [10:53] stub: [rollback=] [10:53] stub: And tag the bug as bad-commit- [10:53] There is no bug [10:53] So that step is easy I guess ;) [10:54] StevenK: wouldn't that just be for the rollback itself, rather than the rollback of the rollback? [10:55] I'm guessing stub is rollbacking the commit, so [rollback= is fine [10:56] He's rollbacking my rollback. [10:56] The commit has already been rolled back. I'm rolling back that rollback (reapplying with what hopefully will fix the issue) [10:56] No [rollback= required. [10:56] k [10:56] My next trick would have been self referential rollback= statements to mess with qa-tagger [10:57] You're a bad person. [10:57] qa-tagger is broken. Early Christmas break everyone! [10:59] \o/ [11:17] * cjwatson tries to understand http://paste.ubuntu.com/761501/ [11:17] What, in general, do I need to do to let my tests get hold of an archive's PublisherConfig? [11:23] cjwatson: you are running in the wrong layer [11:23] you need zopeless [11:24] I thought zopeless didn't give me a librarian [11:25] however now that I work my way through the class hierarchy I see that's wrong [11:27] Thanks. Onto the next failure :-) === matsubara-afk is now known as matsubara [11:31] morning party people [11:32] I really should delete ZopelessLayer at some point. [11:32] Since it doesn't actually do [11:32] much different any more. [11:35] wgrant: Can you remove all layers please? [11:35] Turning the class hierarchy into a stick is a good way to start :) [11:36] wgrant: Me no comprendo. [11:36] If the layer hierachy is closer to a stick than the complex tree it is now, it becomes easier to deal with . [11:38] wgrant: You're being pragmatic again. [11:38] :( [11:39] wgrant: One layer less would be a very healthy step. [11:39] Well, crucially, killing of ZopelessLayer also kills off ZopelessDatabaseLayer, LaunchpadZopelessLayer, and ZopelessAppServerLayer. [11:40] layers were a hack to have slow-starting fixtures available across tests [11:40] I think TestTools is gaining this ability RSN [11:41] wgrant, bigjools: I'm sure we could come up with a layer-like wrapper around testresources. I experimented with something similar once before. [12:44] yay death to zopeless layer! [12:50] gmb: you still around for a review? [12:50] rick_h_: Sure [12:50] gmb: https://code.launchpad.net/~rharding/launchpad/inline_editor/+merge/84528 [12:50] gmb: thanks [12:50] Woah [12:50] rick_h_: That's 1899 lines of diff [12:51] well mostly - [12:51] gmb: yea sorry, ripped out a lot [12:51] rick_h_: Our usual per-branch limit is 800. I won't be able to review that in the time I have left online today. [12:52] rick_h_: You'd be better off talking to someone on your squad to see if they have the time to take a look at that. [12:52] gmb: cool, thanks [12:52] Np === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [13:58] In regards to package set ACL access, is it viable to add a 3rd type, to help with package to team bug triaging? [13:58] * Daviey asks to see if it is worth raising a bug. === jam1 is now known as jam === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [14:32] abentley, ping for standup. [14:35] adeuring: bug 894836 [14:35] <_mup_> Bug #894836: Wrong order-by widget is highlighted when the page has loaded a previously select preference < https://launchpad.net/bugs/894836 > === matsubara is now known as matsubara-lunch [15:03] Anyone fancy reviewing https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 ? [15:08] cjwatson: it's too late for me right now, but please tell me that's your massive speedup branch! [15:10] It is [15:10] Not that I've actually run it in situ yet to demonstrate speedup, merely a stripped-down version on my laptop [15:11] Agonizing. Human intuition is notoriously unreliable for these things. Looking forward to seeing the real-world difference! [15:12] Indeed. I can't really tell for absolute sure without a full Soyuz instance, which is likely to be a bit much for anything I have locally :-) [15:12] But I'm reasonably confident. [15:13] There's a factor of three in the right direction between the old version on cocoplum and the stripped-down version on my laptop. I don't think all of that can be overhead, and if my laptop is that much faster than cocoplum we're all in trouble. :-) [15:15] We should all have laptops as fast as cocoplum! [15:16] I might try syncing over Packages and Sources to mawson and running the stripped-down version there, or something [15:16] Or even as an unprivileged user on cocoplum at a quiet time in the hour [15:17] Not a job for dogfood? [15:17] Yeah, mawson's probably better for it [15:17] As long as I do a control run with current Packages/Sources first [15:18] The control run I did yesterday took six minutes and produced output considerably smaller than current production, so I don't think it's a good comparator [15:18] (comparand?) [15:18] The latter, I suspect. [15:18] But it's not my language. :) [15:28] jtv: you don't get off that easily, you speak it better than the average teenager [15:33] ... and somehow manage to speak it without the annoying Dutch accent === matsubara-lunch is now known as matsubara === al-maisan is now known as almaisan-away === deryck is now known as deryck[lunch] === salgado is now known as salgado-lunch [17:12] bigjools: perhaps this is premature, but at some point when you have a chance, I'd like to chat about the next stage in improving how germination is done: I'd like to move it before apt-ftparchive, so that we get rid of hysteresis and avoid the occasional need for manual action when seeds change [17:12] cjwatson: sounds good [17:12] and I'd like to make sure I understand how to slot that into the publisher properly [17:12] is there a publisher hook for that stage? I can't remember [17:12] I think it would go in between B and C - there's no hook there at this point [17:13] ok, easy to add [17:13] you think it ought to be a hook? It'll need to talk to the DB [17:13] so presumably can't just be the out-of-process kind of thing that distro-parts is [17:13] well germination is an Ubuntu thing - at least nothing else needs it but perhaps it might in the future [17:14] agreed [17:14] some kind of in-process hook then [17:14] there's no reason why it can't be a run-parts that access the DB [17:14] oh - yeah, of course, duh, my generate-extra-overrides is exactly such a thing [17:15] * cjwatson <- idiot [17:15] it's the soyuz effect, roll with it :) [17:15] I'd like to have it mark pockets dirty when seed output changes, too; I guess there's no reason a hook couldn't do that as wewll [17:15] *well [17:15] hmmm yes, that could be quite useful [17:16] then no more having to keep the odd universe package in a queue around release time just in case we need to change seeds in a hurry, whee [17:18] pre-index.d sound OK as a name? (strawman) [17:18] yup [17:19] then I get to find out whether I got the germinate API for this right ... [17:20] there's a method that's supposed to yield a sequence of (enum, {header: value, ...}) [17:22] so I think I do dict(.buildIndexStanzaFields) on every PUBLISHED [SB]PPH and feed that in [17:25] what I don't know is whether doing that extra [SB]PPH query (basically the same as those in _writeComponentIndexes) will be significantly slower than having germinate read and parse Packages/Sources; do we have numbers on how long the _writeComponentIndexes queries take on something Ubuntu-sized? I know we aren't using that mode in Ubuntu at the moment [17:35] cjwatson: I suspect that reading from the DB is always going to be quicker than parsing a file [17:37] bigjools: oh good [17:39] cjwatson: we used _writeComponentIndexes stuff on Ubuntu on dogfood once just to see what it did and it was comparable to running a-f in fact. I'm sure we can optimise it some more. [17:39] the slow part of using a-f is writing its input files... [17:40] it would get a bit slower if it were made fully-compatible - for instance it'd have to read extra override files [17:40] (or we'd have to stuff them into the db) [17:40] yeah [17:40] well I want those in the DB [17:40] I want everything in the DB [17:40] then other parts of LP can benefit [17:41] *cough* https://launchpad.canonical.com/ExtraPackageOverrides [17:42] yeah :) [17:44] comparable to running a-f> germinate parsing those files takes seconds, so it needs to be in that ballpark [17:45] well I am talking overall publisher speed [17:48] right, EOD for me, good night all === deryck[lunch] is now known as deryck [17:49] hmm the update manager could do with a "shutdown after installing" option === salgado-lunch is now known as salgado [18:13] deryck: There's no OCR. Could you review https://code.launchpad.net/~abentley/launchpad/fix-spinner-bugs/+merge/84633 please? [18:14] abentley, sure [18:15] deryck: thanks. [18:21] abentley, I don't know if I understand fetch_only. [18:21] abentley, does that mean, "we're doing XHR only" or "we're only changing out lists" or something else? [18:22] deryck: it means fetch the data, but don't render it. [18:22] abentley, ah ok. so we're still showing the spinner regardless of if the list is loaded from cache or XHR? [18:24] deryck: technically yes, but when the list is loaded from the cache, the spinner is hidden again so quickly that you don't see it. [18:24] abentley, right, that's fine. [18:24] abentley: the main reason we added it so that the re-scroll to top would take effect if the data came from cache/not [18:24] does that still take place? [18:25] rick_h_: I expect it does. [18:25] abentley: ok cool [18:26] ic, the .success is always called, but the spinner might not have been visible. So we basically reassert it's hidden and run scroll to top [18:27] rick_h_: success is only called if the event succeeded, and only if we were loading the batch in order to display it. [18:27] abentley, r=me. [18:28] deryck: thanks. [18:56] benji: howdy, api question for you if you've got a sec [18:56] rick_h_: shoot [18:57] so I'm looking at bug: https://bugs.launchpad.net/launchpad/+bug/808952 [18:57] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments < https://launchpad.net/bugs/808952 > [18:57] and went checking out how the canonical url data stuff works [18:57] and it seems the url generated in this oops was /1.0/ubuntu/+source/b... [18:57] which fails, but if you /version/1.0 it works [18:57] or take out the 1.0 completely [18:58] so it seems to be something more in launchpadlib generating the urls? [19:17] benji: oh sorry, I messed up. The "response" is a 404 when you take off the 1.0. I didn't realize that. [19:19] rick_h_: I'm glad you figured it out -- because I had gone to other things while you wrote and then forgot you had asked :( [19:19] well, nothing figured out as far as the original issue, but at least I misunderstood it and got past that [19:19] * benji wonders if he's the only one that needs people to mention his name to remember that they're talking to him. [19:20] benji: no, I'm supposed to be working on that [19:20] benji: updating irc habits along with other things [19:20] rick_h_: in that case let me check your question and see if I can suggest anything [19:21] benji: basically something is up with the api talking to/about comment #11 on that bug [19:21] benji: if I loop through all comments using the api it works, but if you try to link directly through the api to comment 11 it fails. [19:21] benji: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/805938/comments/11 works though [19:21] <_mup_> Bug #805938: Totem set as default music player after install instead of Banshee

< [19:22] rick_h_: I don't remember exactly how the URL generation is divvied up between LP and lazr.restful, but lazr.restful isn't very big and that's where I'd look first [19:22] benji: ok cool. Will head there. I've been chasing the ICanonicalDataURL stuff in LP up until now [19:23] statik: flacoste: just confirming we have a call in 70 minutes? (e.g. did the calendar work...) [19:24] lifeless: yes [19:24] lifeless: 66 minutes actually :-) [19:24] clickety click [20:43] deryck: I'm looking at bug 892211 and I can see the problem: updateFieldVisibilty is calling _extraRenderUI(), which is calling updateFromCookie. Can we talk about solutions? [20:43] <_mup_> Bug #892211: reset to default in bug listing visibility widget doesn't work < https://launchpad.net/bugs/892211 > [20:46] hi flacoste -- can we decide on the lplib recipe and get it done? [20:48] bac: on the phone, will ping you when i'm done [20:48] flacoste: perfect [20:57] abentley, I'm not available today. cast about for someone else, or I can chat with you about it tomorrow. [20:57] deryck: okay. [20:58] We have a branch that hardens teams to such a degree, that to write a test that logs in as the teamowner, you must first login as an admin [20:58] I think I will take a 30 minute break to ponder the irony [21:09] bac: out of tree is best here [21:09] bac: leverage (ha hate that phrase) the ubuntu packaging [21:09] bac: besides what lifeless is saying [21:09] what other open issues remains? [21:10] given jelmer pointers, i agree that having the debian tree separate is best [21:10] flacoste: where to put it. ~launchpad vs ~lazr-developers [21:10] i think ~launchpad is better [21:10] ~lazr-developers is hysterical raisins to me [21:10] branch ownership? [21:10] Its in the wiki [21:10] see dev.launchpad.net/CreatingNewProjects [21:11] lifeless: recipe ownership [21:11] (tl;dr: ~canonical-launchpad-branches) [21:11] LP is in that team, but so are other canonical folk like ex-launchpadders who may help maintain it if they have access [21:11] lifeless: any reasons that we kept "or '~lazr-developers'." on that page? [21:12] flacoste: wanted it to be consistent with current ownerships [21:12] flacoste: no deeper reason [21:12] ok, i'd prefer if we don't extend the set of things owner by that team though [21:12] flacoste: happy for us to remove if [21:12] editing now [21:12] thx [21:13] bac: so the recipe could be owned by ~canonical-launchpad-branches also then [21:13] and i would put this in a ppa on the launchpad team [21:13] flacoste: ok, i'll do that [21:13] bac: thanks! [21:14] lifeless: can you expand your thought on, ahem, leveraging the ubuntu packaging? are you saying we don't need the packaging branch i created? [21:14] should be able to use the nest command to grab just the debian dir directly from ubuntu [21:15] you may need a packaging branch if we need to diverge [21:15] lifeless: but i'd like for us to be able to update the changelog, thus the branch [21:15] hmm, just realised. ~canonical-launchpad-branches may be an issue because of the insane notifications we do. Do we notify recipe owners always? [21:15] If so, then ~launchpad will be needed, even if its conceptually wrong. [21:16] bac: auto build recipes don't bother with that [21:16] bac: that said, it is up to you, I don't have a strong recommendation. [21:16] lifeless: they do get the debupstream version from the changelog [21:17] yes, but every build starts fresh from the branches === salgado is now known as salgado-afk [21:18] bac: ah, I think you mean 'I want the package major version to match our releases, not the latest version in Ubuntu' [21:18] lifeless: yes, for the PPA [21:18] bac: you can do that three ways = custom packaging branch; just set it in the recipe rather than using debupstream; make sure we release into Ubuntu very quickly. [21:18] bac: the easiest is just to set it in the recipe instead of using debupstream [21:18] lifeless: as seen here: https://launchpad.net/~bac/+archive/ppa [21:23] hi all [21:24] anyone fancy a quick review? https://code.launchpad.net/~benji/launchpad/bug-894177-2/+merge/84676 [21:26] o/ benji [21:26] poolie: thanks [21:27] It looks plausible to me but you probably want another review from someone more experienced. [21:29] poolie: thanks [21:49] benji: there is a context manager for switching db user [21:49] benji: it might be nicer [21:50] lifeless: ooh, indeed it would; thanks [21:51] bac: absolutely, I'm now a card-carying QA instructionist [21:51] heh, 3 reviews :P [21:51] * benji looses 10 cross-channel discussion points. [21:52] I missed that bac had [21:52] lifeless: sorry, i failed to claim it. [21:52] lifeless: I now feel very good about my MP, thanks ;) [21:52] bac: no worries [21:52] lifeless: but it's good as you added the cm bit [21:53] teamwork [21:53] redundancy [22:02] Hmm. My stripped-down version of lp:~cjwatson/launchpad/refactor-cron-germinate noddy-benchmarks at about twice the speed of the current implementation, for identical output; but I think I've got something wrong that means that it isn't extracting all the benefit it could [22:03] * cjwatson wasn't expecting that [22:03] cjwatson: nice