jtv | 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 |
---|---|---|
lifeless | lp-staging:// | 02:59 |
lifeless | or is it lp://staging/... | 02:59 |
lifeless | one of them | 02:59 |
lifeless | if its connecting and then saying read-only, you're not in the team :> | 02:59 |
rick_h_ | jtv: qastaing? or staging? I used bzr push lp://qastaging/~rharding/... for qastaging with success | 03:04 |
jtv | lifeless: what team? | 03:04 |
jtv | rick_h_: I suppose I could try qastaging, thanks. | 03:04 |
lifeless | the one you are pushing to a branch of | 03:05 |
jtv | lifeless: I tried lp://staging/, which is what the UI tells me to do, but same error. | 03:05 |
lifeless | jtv: what was the full url | 03:05 |
jtv | lifeless: so "read-only transport" from bzr can actually mean that I don't have privileges? | 03:05 |
lifeless | it means it tried to write and failed | 03:06 |
jtv | lp://staging/~stellarium/stellarium/auto-po | 03:06 |
lifeless | either because its using http or can't write | 03:06 |
lifeless | jtv: and are you a member of ~stellarium on staging? | 03:06 |
jtv | No. | 03:06 |
lifeless | ok, so thats working as expected | 03:07 |
jtv | Except for the misleading error message. | 03:07 |
lifeless | bzr doesn't know the cause for being unable to write | 03:07 |
jtv | 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:09 |
lifeless | indeed | 03:12 |
lifeless | its also exactly what will happen if you push locally to a directory you only have rx bits on | 03:12 |
lifeless | for instance | 03:12 |
lifeless | feel free to file a bug on bzr/bzr+lp | 03:13 |
lifeless | hah | 03:21 |
lifeless | dead code in LP's DB migration system | 03:22 |
lifeless | win | 03:22 |
wgrant | lifeless: Where? | 03:22 |
wgrant | jtv: Bug #894177 | 03:22 |
_mup_ | Bug #894177: run_jobs.py pofile_stats oopses: permission denied for relation productseries <oops> <translations-handoff> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/894177 > | 03:22 |
jtv | wgrant: oh, so what I filed was a dupe. :( | 03:22 |
jtv | Looks like the script was converted to a job, and then not tested under realistic access rights. | 03:23 |
wgrant | Yeah. You might want to throw your info into that one. | 03:23 |
wgrant | Yes. | 03:23 |
jtv | Thanks. | 03:23 |
wgrant | Well. | 03:23 |
wgrant | It works fine for distro templates. | 03:23 |
wgrant | Just not product ones. | 03:23 |
wgrant | I've tested locally and product+productseries is sufficient. | 03:23 |
lifeless | wgrant: upgradelog | 03:24 |
lifeless | wgrant: implemented on non-slony environments only | 03:25 |
wgrant | I see no upgradelog | 03:25 |
lifeless | ah, its new, not dead | 03:26 |
lifeless | stub is capturing the sql executed | 03:26 |
* lifeless ports | 03:26 | |
wgrant | Is that the thing I reverted over the weekend? | 03:26 |
lifeless | yes | 03:26 |
lifeless | because it was broken, yes. | 03:26 |
lifeless | did it break on qastaging or staging ? | 03:27 |
lifeless | if it broke on staging, its because the autodetect stuff for it was only on the non-slony case | 03:28 |
wgrant | buildbot | 03:29 |
lifeless | ah, interesting | 03:29 |
wgrant | https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1617/steps/compile_1/logs/stdio | 03:30 |
wgrant | File "upgrade.py", line 645, in get_bzr_details | 03:30 |
wgrant | ValueError: need more than 1 value to unpack | 03:30 |
wgrant | branch_nick, revno, revision_id = out.split(' ', 3) | 03:30 |
lifeless | 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 |
wgrant | kk | 03:33 |
micahg | it | 07:09 |
micahg | 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:09 |
lifeless | stub: can we have a call in ~ 1 hour about trusted.sql etc and lazr_postgresql ? | 07:17 |
stub | lifeless: sure | 07:26 |
stub | lifeless: https://code.launchpad.net/~stub/launchpad/db-deploy/+merge/84231 will affect this work btw | 07:48 |
bkerensa | flacoste: You around? | 08:10 |
wgrant | bkerensa: Probably not for a few hours yet. | 08:14 |
wgrant | But there are lots of LP devs around. | 08:15 |
bkerensa | 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:15 |
wgrant | bkerensa: Most people who have been working on that (and flacoste) are in the Americas, so won't be around for a while. | 08:16 |
bkerensa | 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:17 |
wgrant | Heh | 08:18 |
adeuring | good morning | 08:46 |
frankban | good morning | 09:00 |
mrevell | Hello | 09:01 |
bigjools | has anyone else seen spurious errors in lp.buildmaster.tests.test_builder.TestSlave in ec2? | 09:07 |
lifeless | 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 <txlongpoll:Triaged> < https://launchpad.net/bugs/900579 > | 09:08 |
lifeless | bigjools: (it may just be a deployment thing in fact) | 09:08 |
lifeless | bigjools: https://code.launchpad.net/+longpoll/?uuid=oopses&sequence=1 is a good url to make the impact clear ;) | 09:08 |
bigjools | lifeless: yeah, I tend to err on the side of permissions | 09:08 |
* lifeless really really goes now | 09:08 | |
allenap | lifeless: Interesting (re. https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715). I may borrow that for an experiment. Ta. | 09:26 |
wgrant | bigjools: huwshimi had one of those yesterday. First I'd seen of it. | 09:44 |
=== 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 | ||
* cjwatson bangs his head against bug 713764 | 10:47 | |
_mup_ | Bug #713764: fake librarian columns cannot be looked up by storm <Launchpad itself:Triaged> < https://launchpad.net/bugs/713764 > | 10:47 |
stub | How do I revert a reversion on my branch? | 10:47 |
jelmer | stub: merge a reversion of the reversion :) | 10:49 |
jelmer | stub: e.g. "bzr merge -r-5..-4 ." | 10:49 |
stub | I mean the magic commit message tags - list it as a reversion there? | 10:49 |
jelmer | ah | 10:49 |
jelmer | 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 |
cjwatson | 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:50 |
cjwatson | Maybe I'll just have to use the full librarian the way everyone else who's run into this seems to have done :-/ | 10:51 |
StevenK | stub: [rollback=<rev>] | 10:53 |
StevenK | stub: And tag the bug as bad-commit-<rev> | 10:53 |
stub | There is no bug | 10:53 |
stub | So that step is easy I guess ;) | 10:53 |
jelmer | StevenK: wouldn't that just be for the rollback itself, rather than the rollback of the rollback? | 10:54 |
StevenK | I'm guessing stub is rollbacking the commit, so [rollback= is fine | 10:55 |
wgrant | He's rollbacking my rollback. | 10:56 |
stub | The commit has already been rolled back. I'm rolling back that rollback (reapplying with what hopefully will fix the issue) | 10:56 |
wgrant | No [rollback= required. | 10:56 |
stub | k | 10:56 |
stub | My next trick would have been self referential rollback= statements to mess with qa-tagger | 10:56 |
wgrant | You're a bad person. | 10:57 |
stub | qa-tagger is broken. Early Christmas break everyone! | 10:57 |
bigjools | \o/ | 10:59 |
* cjwatson tries to understand http://paste.ubuntu.com/761501/ | 11:17 | |
cjwatson | What, in general, do I need to do to let my tests get hold of an archive's PublisherConfig? | 11:17 |
bigjools | cjwatson: you are running in the wrong layer | 11:23 |
bigjools | you need zopeless | 11:23 |
cjwatson | I thought zopeless didn't give me a librarian | 11:24 |
cjwatson | however now that I work my way through the class hierarchy I see that's wrong | 11:25 |
cjwatson | Thanks. Onto the next failure :-) | 11:27 |
=== matsubara-afk is now known as matsubara | ||
rick_h_ | morning party people | 11:31 |
wgrant | I really should delete ZopelessLayer at some point. | 11:32 |
wgrant | Since it doesn't actually do | 11:32 |
wgrant | much different any more. | 11:32 |
allenap | wgrant: Can you remove all layers please? | 11:35 |
wgrant | Turning the class hierarchy into a stick is a good way to start :) | 11:35 |
allenap | wgrant: Me no comprendo. | 11:36 |
wgrant | If the layer hierachy is closer to a stick than the complex tree it is now, it becomes easier to deal with . | 11:36 |
allenap | wgrant: You're being pragmatic again. | 11:38 |
wgrant | :( | 11:38 |
allenap | wgrant: One layer less would be a very healthy step. | 11:39 |
wgrant | Well, crucially, killing of ZopelessLayer also kills off ZopelessDatabaseLayer, LaunchpadZopelessLayer, and ZopelessAppServerLayer. | 11:39 |
bigjools | layers were a hack to have slow-starting fixtures available across tests | 11:40 |
bigjools | I think TestTools is gaining this ability RSN | 11:40 |
allenap | wgrant, bigjools: I'm sure we could come up with a layer-like wrapper around testresources. I experimented with something similar once before. | 11:41 |
jml | yay death to zopeless layer! | 12:44 |
rick_h_ | gmb: you still around for a review? | 12:50 |
gmb | rick_h_: Sure | 12:50 |
rick_h_ | gmb: https://code.launchpad.net/~rharding/launchpad/inline_editor/+merge/84528 | 12:50 |
rick_h_ | gmb: thanks | 12:50 |
gmb | Woah | 12:50 |
gmb | rick_h_: That's 1899 lines of diff | 12:50 |
rick_h_ | well mostly - | 12:51 |
rick_h_ | gmb: yea sorry, ripped out a lot | 12:51 |
gmb | 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:51 |
gmb | 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 |
rick_h_ | gmb: cool, thanks | 12:52 |
gmb | Np | 12:52 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== almaisan-away is now known as al-maisan | ||
Daviey | 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. | 13:58 | |
=== 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 | ||
deryck | abentley, ping for standup. | 14:32 |
abentley | adeuring: bug 894836 | 14:35 |
_mup_ | Bug #894836: Wrong order-by widget is highlighted when the page has loaded a previously select preference <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894836 > | 14:35 |
=== matsubara is now known as matsubara-lunch | ||
cjwatson | Anyone fancy reviewing https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 ? | 15:03 |
jtv | cjwatson: it's too late for me right now, but please tell me that's your massive speedup branch! | 15:08 |
cjwatson | It is | 15:10 |
cjwatson | Not that I've actually run it in situ yet to demonstrate speedup, merely a stripped-down version on my laptop | 15:10 |
jtv | Agonizing. Human intuition is notoriously unreliable for these things. Looking forward to seeing the real-world difference! | 15:11 |
cjwatson | 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 |
cjwatson | But I'm reasonably confident. | 15:12 |
cjwatson | 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:13 |
jtv | We should all have laptops as fast as cocoplum! | 15:15 |
cjwatson | I might try syncing over Packages and Sources to mawson and running the stripped-down version there, or something | 15:16 |
cjwatson | Or even as an unprivileged user on cocoplum at a quiet time in the hour | 15:16 |
jtv | Not a job for dogfood? | 15:17 |
cjwatson | Yeah, mawson's probably better for it | 15:17 |
cjwatson | As long as I do a control run with current Packages/Sources first | 15:17 |
cjwatson | 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 |
cjwatson | (comparand?) | 15:18 |
jtv | The latter, I suspect. | 15:18 |
jtv | But it's not my language. :) | 15:18 |
bigjools | jtv: you don't get off that easily, you speak it better than the average teenager | 15:28 |
jelmer | ... and somehow manage to speak it without the annoying Dutch accent | 15:33 |
=== 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 | ||
cjwatson | 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 |
bigjools | cjwatson: sounds good | 17:12 |
cjwatson | and I'd like to make sure I understand how to slot that into the publisher properly | 17:12 |
bigjools | is there a publisher hook for that stage? I can't remember | 17:12 |
cjwatson | I think it would go in between B and C - there's no hook there at this point | 17:12 |
bigjools | ok, easy to add | 17:13 |
cjwatson | you think it ought to be a hook? It'll need to talk to the DB | 17:13 |
cjwatson | so presumably can't just be the out-of-process kind of thing that distro-parts is | 17:13 |
bigjools | well germination is an Ubuntu thing - at least nothing else needs it but perhaps it might in the future | 17:13 |
cjwatson | agreed | 17:14 |
cjwatson | some kind of in-process hook then | 17:14 |
bigjools | there's no reason why it can't be a run-parts that access the DB | 17:14 |
cjwatson | oh - yeah, of course, duh, my generate-extra-overrides is exactly such a thing | 17:14 |
* cjwatson <- idiot | 17:15 | |
bigjools | it's the soyuz effect, roll with it :) | 17:15 |
cjwatson | 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 |
cjwatson | *well | 17:15 |
bigjools | hmmm yes, that could be quite useful | 17:15 |
cjwatson | 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:16 |
cjwatson | pre-index.d sound OK as a name? (strawman) | 17:18 |
bigjools | yup | 17:18 |
cjwatson | then I get to find out whether I got the germinate API for this right ... | 17:19 |
cjwatson | there's a method that's supposed to yield a sequence of (enum, {header: value, ...}) | 17:20 |
cjwatson | so I think I do dict(.buildIndexStanzaFields) on every PUBLISHED [SB]PPH and feed that in | 17:22 |
cjwatson | 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:25 |
bigjools | cjwatson: I suspect that reading from the DB is always going to be quicker than parsing a file | 17:35 |
cjwatson | bigjools: oh good | 17:37 |
bigjools | 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 |
bigjools | the slow part of using a-f is writing its input files... | 17:39 |
cjwatson | it would get a bit slower if it were made fully-compatible - for instance it'd have to read extra override files | 17:40 |
cjwatson | (or we'd have to stuff them into the db) | 17:40 |
bigjools | yeah | 17:40 |
bigjools | well I want those in the DB | 17:40 |
bigjools | I want everything in the DB | 17:40 |
bigjools | then other parts of LP can benefit | 17:40 |
cjwatson | *cough* https://launchpad.canonical.com/ExtraPackageOverrides | 17:41 |
bigjools | yeah :) | 17:42 |
cjwatson | comparable to running a-f> germinate parsing those files takes seconds, so it needs to be in that ballpark | 17:44 |
bigjools | well I am talking overall publisher speed | 17:45 |
bigjools | right, EOD for me, good night all | 17:48 |
=== deryck[lunch] is now known as deryck | ||
bigjools | hmm the update manager could do with a "shutdown after installing" option | 17:49 |
=== salgado-lunch is now known as salgado | ||
abentley | deryck: There's no OCR. Could you review https://code.launchpad.net/~abentley/launchpad/fix-spinner-bugs/+merge/84633 please? | 18:13 |
deryck | abentley, sure | 18:14 |
abentley | deryck: thanks. | 18:15 |
deryck | abentley, I don't know if I understand fetch_only. | 18:21 |
deryck | abentley, does that mean, "we're doing XHR only" or "we're only changing out lists" or something else? | 18:21 |
abentley | deryck: it means fetch the data, but don't render it. | 18:22 |
deryck | abentley, ah ok. so we're still showing the spinner regardless of if the list is loaded from cache or XHR? | 18:22 |
abentley | 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 |
deryck | abentley, right, that's fine. | 18:24 |
rick_h_ | 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 |
rick_h_ | does that still take place? | 18:24 |
abentley | rick_h_: I expect it does. | 18:25 |
rick_h_ | abentley: ok cool | 18:25 |
rick_h_ | 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:26 |
abentley | 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 |
deryck | abentley, r=me. | 18:27 |
abentley | deryck: thanks. | 18:28 |
rick_h_ | benji: howdy, api question for you if you've got a sec | 18:56 |
benji | rick_h_: shoot | 18:56 |
rick_h_ | 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 <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 > | 18:57 |
rick_h_ | and went checking out how the canonical url data stuff works | 18:57 |
rick_h_ | and it seems the url generated in this oops was /1.0/ubuntu/+source/b... | 18:57 |
rick_h_ | which fails, but if you /version/1.0 it works | 18:57 |
rick_h_ | or take out the 1.0 completely | 18:57 |
rick_h_ | so it seems to be something more in launchpadlib generating the urls? | 18:58 |
rick_h_ | benji: oh sorry, I messed up. The "response" is a 404 when you take off the 1.0. I didn't realize that. | 19:17 |
benji | 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 |
rick_h_ | 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:19 | |
rick_h_ | benji: no, I'm supposed to be working on that | 19:20 |
rick_h_ | benji: updating irc habits along with other things | 19:20 |
benji | rick_h_: in that case let me check your question and see if I can suggest anything | 19:20 |
rick_h_ | benji: basically something is up with the api talking to/about comment #11 on that bug | 19:21 |
rick_h_ | 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 |
rick_h_ | 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 <apport-bug> <i386> <iso-testing> <oneiric> <patch> <running-unity> <unity-2d> <unity:Fix Released> <banshee (Ubuntu):Invalid> <desktop-file-utils (Ubuntu):Fix Released> <unity (Ubuntu):Fix Released by canonical-dx-team> <banshee (Ubuntu Oneiric):Invalid> <desktop-file-utils (Ubuntu Oneiric):Fix Released> <unity (Ubuntu Oneiric):Fix Released by canonical-dx-team> < | 19:21 |
benji | 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 |
rick_h_ | benji: ok cool. Will head there. I've been chasing the ICanonicalDataURL stuff in LP up until now | 19:22 |
lifeless | statik: flacoste: just confirming we have a call in 70 minutes? (e.g. did the calendar work...) | 19:23 |
flacoste | lifeless: yes | 19:24 |
flacoste | lifeless: 66 minutes actually :-) | 19:24 |
lifeless | clickety click | 19:24 |
abentley | 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 <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/892211 > | 20:43 |
bac | hi flacoste -- can we decide on the lplib recipe and get it done? | 20:46 |
flacoste | bac: on the phone, will ping you when i'm done | 20:48 |
bac | flacoste: perfect | 20:48 |
deryck | abentley, I'm not available today. cast about for someone else, or I can chat with you about it tomorrow. | 20:57 |
abentley | deryck: okay. | 20:57 |
sinzui | 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 |
sinzui | I think I will take a 30 minute break to ponder the irony | 20:58 |
lifeless | bac: out of tree is best here | 21:09 |
lifeless | bac: leverage (ha hate that phrase) the ubuntu packaging | 21:09 |
flacoste | bac: besides what lifeless is saying | 21:09 |
flacoste | what other open issues remains? | 21:09 |
flacoste | given jelmer pointers, i agree that having the debian tree separate is best | 21:10 |
bac | flacoste: where to put it. ~launchpad vs ~lazr-developers | 21:10 |
flacoste | i think ~launchpad is better | 21:10 |
flacoste | ~lazr-developers is hysterical raisins to me | 21:10 |
lifeless | branch ownership? | 21:10 |
lifeless | Its in the wiki | 21:10 |
lifeless | see dev.launchpad.net/CreatingNewProjects | 21:10 |
bac | lifeless: recipe ownership | 21:11 |
lifeless | (tl;dr: ~canonical-launchpad-branches) | 21:11 |
lifeless | 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 |
flacoste | lifeless: any reasons that we kept "or '~lazr-developers'." on that page? | 21:11 |
lifeless | flacoste: wanted it to be consistent with current ownerships | 21:12 |
lifeless | flacoste: no deeper reason | 21:12 |
flacoste | ok, i'd prefer if we don't extend the set of things owner by that team though | 21:12 |
lifeless | flacoste: happy for us to remove if | 21:12 |
lifeless | editing now | 21:12 |
flacoste | thx | 21:12 |
flacoste | bac: so the recipe could be owned by ~canonical-launchpad-branches also then | 21:13 |
flacoste | and i would put this in a ppa on the launchpad team | 21:13 |
bac | flacoste: ok, i'll do that | 21:13 |
flacoste | bac: thanks! | 21:13 |
bac | 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 |
lifeless | should be able to use the nest command to grab just the debian dir directly from ubuntu | 21:14 |
lifeless | you may need a packaging branch if we need to diverge | 21:15 |
bac | lifeless: but i'd like for us to be able to update the changelog, thus the branch | 21:15 |
lifeless | 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 |
lifeless | If so, then ~launchpad will be needed, even if its conceptually wrong. | 21:15 |
lifeless | bac: auto build recipes don't bother with that | 21:16 |
lifeless | bac: that said, it is up to you, I don't have a strong recommendation. | 21:16 |
bac | lifeless: they do get the debupstream version from the changelog | 21:16 |
lifeless | yes, but every build starts fresh from the branches | 21:17 |
=== salgado is now known as salgado-afk | ||
lifeless | bac: ah, I think you mean 'I want the package major version to match our releases, not the latest version in Ubuntu' | 21:18 |
bac | lifeless: yes, for the PPA | 21:18 |
lifeless | 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 |
lifeless | bac: the easiest is just to set it in the recipe instead of using debupstream | 21:18 |
bac | lifeless: as seen here: https://launchpad.net/~bac/+archive/ppa | 21:18 |
poolie | hi all | 21:23 |
benji | anyone fancy a quick review? https://code.launchpad.net/~benji/launchpad/bug-894177-2/+merge/84676 | 21:24 |
poolie | o/ benji | 21:26 |
benji | poolie: thanks | 21:26 |
poolie | It looks plausible to me but you probably want another review from someone more experienced. | 21:27 |
benji | poolie: thanks | 21:29 |
lifeless | benji: there is a context manager for switching db user | 21:49 |
lifeless | benji: it might be nicer | 21:49 |
benji | lifeless: ooh, indeed it would; thanks | 21:50 |
benji | bac: absolutely, I'm now a card-carying QA instructionist | 21:51 |
lifeless | heh, 3 reviews :P | 21:51 |
* benji looses 10 cross-channel discussion points. | 21:51 | |
lifeless | I missed that bac had | 21:52 |
bac | lifeless: sorry, i failed to claim it. | 21:52 |
benji | lifeless: I now feel very good about my MP, thanks ;) | 21:52 |
lifeless | bac: no worries | 21:52 |
bac | lifeless: but it's good as you added the cm bit | 21:52 |
bac | teamwork | 21:53 |
bac | redundancy | 21:53 |
cjwatson | 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:02 |
* cjwatson wasn't expecting that | 22:03 | |
lifeless | cjwatson: nice | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!