[06:21] <nothingspecial> Hi, forgive my hazy memory but is this where someone would ask for a ubuntu members cloak?
[06:38] <nothingspecial> I have just found out that it is. Never mind. Carry on ladies and gentlemen.
[14:20] <em> Hey popey are you here?
[14:52] <pycoderf> does anyone know what causes this error: "ath5k could not wake the mac chip"
[15:32] <oldos2er> Hi. I'd like an ubuntu members cloak, please. https://launchpad.net/~lagnappe
[16:01] <oldos2er> hi. i would like an ubuntu members cloak please. https://launchpad.net/~lagnappe
[16:09] <oldos2er> hi, here to ask for an ubuntu members cloak https://launchpad.net/~lagnappe
[16:31] <pangolin> IRCC oldos2er would like a member cloak. Congrats on membership oldos2er!.
[16:31] <oldos2er> thanks!  :)
[16:31] <pangolin> Hopefully one of the Group Contacts is awake and it won't be too long.
[16:32] <oldos2er> i'm trying to be patient, lol
[17:12] <oldos2er> hi, here to ask for an ubuntu members cloak  https://launchpad.net/~lagnappe
[17:15] <pangolin> oldos2er: There is no need to repeat your request, when the IRCC members become active they will see it.
[17:18] <oldos2er> thanks pangolin. bodhizazen told me i should be 'politely persistent'
[17:19] <pangolin> well, yeah but there is no activity in this channel currently so the request is still visible.
[17:19] <oldos2er> ok
[17:19] <pangolin> We can try one more thing...
[17:20] <pangolin> jussi topyli elky You nice folks awake :)
[17:21] <Unit193> Shoul he identify?
[17:21] <Unit193> I need a D
[17:22] <pangolin> indeed
[17:22] <oldos2er> sorry, a D? what?
[17:22] <pangolin> oldos2er: you will need to be identified to nickserv
[17:22] <oldos2er> my nick is registered to nickserv
[17:23] <pangolin> yes but you also need to /msg nickserv identify PASWORD
[17:23] <pangolin> PASSWORD*
[17:24] <oldos2er> ok
[20:03] <oldos2er> sorry to be repititious, but i'd like an ubuntu members cloak please.
[20:03] <oldos2er> https://launchpad.net/~lagnappe


[02:14] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/4213 Failed to build
[08:23] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4182 Successfully built
[08:43] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4182 Pending binary packages
[09:01] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4220 Pending binary packages (focal/postgresql-common). Successfully built (focal/postgresql-12)
[09:03] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4182 Successfully built
[09:21] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4220 Diff missing (focal/postgresql-common). Successfully built (focal/postgresql-12)
[09:26] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4220 Generating diffs
[09:27] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4220 Successfully built
[12:55] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4055 Dependency wait (groovy/gjs). Diff missing (groovy/mozjs78). Needs rebuild due to higher version at destination (groovy/meson). Ready to build (groovy/icu)
[12:56] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4222 Generating diffs
[12:57] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4222 Successfully built
[16:34] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/4213 Failed to build
[17:24] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4184 Needs rebuild due to higher version at destination
[17:33] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/4213 Dependency wait
[19:13] -queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/4213 Dependency wait


[06:04] <dholbach> good morning
[08:33] <bkerensa_> pleia2: are you working through till the later A.M.? :)
[08:37] <pleia2> bkerensa_: heh, no, going to bed at some point :)
[08:52]  * nigelb points out that it's probably past that point
[09:01] <bkerensa_> nigelb the Sheriff
[09:01] <bkerensa_> :)
[09:08] <nigelb> :)
[09:20] <pleia2> alright, I shall return in the proper morning
[09:20]  * pleia2 sets alarm
[14:09] <dholbach> popey, mhall119, balloons: shall we catch up on UGJ prep in our team call tomorrow?
[14:09] <dholbach> we could also talk about lp:ubuntudeveloperportal bug triage
[14:10] <popey> ya!
[14:12] <mhall119> dholbach: sure
[14:13] <mhall119> balloons: I'm going to go ahead and create the hangout event for today's Q&A
[14:22] <popey> mhall119: tweeted it
[14:22] <mhall119> thanks popey
[14:22] <popey> np
[14:23] <mhall119> balloons: will you be able to start the hangout? I have a scopes meeting from 10:30-11:00
[14:30] <balloons> mhall119, ohh sure, I can start it up and send over the link
[14:31] <balloons> nvm, I see it's setup
[14:33] <mhall119> balloons: I just need you to start it, the event is created and ubuntuonair.com is updated
[14:37]  * dholbach hugs popey
[14:40] <balloons> dholbach, I noticed I cannot set importance on https://bugs.launchpad.net/ubuntudeveloperportal
[14:40] <dholbach> balloons, let me see if I have the right keys for changing this
[14:41] <dholbach> balloons, better now?
[14:41] <dholbach> I'm never quite sure which knows to use :)
[14:41] <balloons> dholbach, indeed
[14:42] <balloons> there's some real low hanging fruit in here, I think I'm sucked in
[14:45]  * dholbach hugs balloons
[14:45] <dholbach> fantastico
[14:45] <dholbach> let me know which batch you're working on, and I'll take one of the others
[14:46] <balloons> I started on the bottom batch, but I found it easier just to look at the big list
[14:46] <dholbach> ok cool
[14:47] <dholbach> I just didn't want us all to review the same batch of 22 bugs :)
[14:47] <balloons> many in the batch were already triaged by you
[14:48] <pleia2> o/
[14:49] <mhall119> morning pleia2, got your coffee?
[14:49] <balloons> morning pleia2
[14:49] <pleia2> water, good enough :)
[14:49] <mhall119> I doubt that
[14:49] <pleia2> haha
[16:02] <balloons> jose, mhall119 and I would like you to be a guest with us on the community team live q and a. Interested? Would you be able to join a hangout at 1500 UTC?
[16:05] <mhall119> on Tuesdays
[16:10] <dholbach> all right my friends - I call it a day - see you all tomorrow again! :)
[16:10] <belkinsa> See ya
[16:19] <balloons> pleia2, I'd like to get our slides for the talk @ fossetcon organized. Do you want to start by sharing your slides from scale and I can add to them?
[19:08] <pleia2> balloons: just uploaded the source version, here you go: http://princessleia.com/presentations/5WaysToGetInvolvedWithUbuntuToday.odp
[19:56] <jose> balloons: I'd love to, but I'd only be able to be there from 1500 to 1530 as I have classes at 1600 and need to get take a bus :)
[19:57] <balloons> jose, that's fine.. we'll keep your piece short so you don't miss the bus :-)
[19:57] <jose> balloons: cool then! is it next week?
[19:57] <balloons> pleia2, thanks, I'll review
[19:57] <balloons> jose, umm, does Sept 2nd work for you?
[19:58] <jose> lemme check
[19:58] <jose> wfm
[20:00] <balloons> jose, awesome you are on the schedule. Thanks!
[20:00] <balloons> mhall119, just fyi ^^
[20:00] <jose> no prob, thanks to you for the invite!
[20:01] <balloons> jose, personally I promise to be nice, and ask easy questions, but I can't speak for mhall119 :-)
[20:04] <jose> hehe
[20:04] <jose> well, I'll still have to deal with you at FOSSETCON
[20:49]  * mhall119 isn't sure whether to be scared or excited by that


[03:26] <nhandler> Where does the software center get the small application icons from (i.e. the ones on https://apps.ubuntu.com/cat/search/?q=rhythmbox) ? If it looks within the binary deb, where, what size, and what format must the icons be?
[06:56] <dholbach> good morning
[17:53]  * Laney phases in from another dimension
[17:53] <Laney> anyone here ever set up wanna-build?
[17:54] <tumbleweed> what are you using it for?
[17:54] <tumbleweed> (going to be)
[17:54] <Laney> well, we got this hp cloud stuff
[17:54] <Laney> so I thought I might have a go at my charm idea
[17:54] <tumbleweed> aah
[17:55] <Laney> I think you can add units or something (not looked into it much)
[17:55] <Laney> so each one of those can be a buildd
[17:55] <Laney> and a controlling wanna-build instance
[17:55] <Laney> anyway it seems fairly painful to actually set up
[17:55] <Laney> maybe there's another solution?
[17:56] <tumbleweed> I was about to suggest you look at lucas' EC2 rebuilding setup, but that's not wanna-build
[17:56] <Laney> could prove useful though
[17:56] <Laney> now where's that xnox?
[17:57]  * tumbleweed goes. pub quiz demands that we be offline
[17:59] <ScottK> Laney: xnox seems to avoid this channel.
[18:00] <iulian> Oh no. How so?
[18:00] <Laney> he's not on 24/7. strange behaviour.
[18:00] <micahg> ScottK: but he seems to know if we talk about him :)
[18:00] <ScottK> I often see him on #ubuntu-devel when he's not here.
[18:00] <ScottK> micahg: Canonical cabal no doubt.
[18:01] <micahg> TINC :)
[18:01] <iulian> That must be a new acronym. No idea what that means. :)
[18:01] <Laney> That means you are the cabal.
[18:02]  * micahg had to look it up the first time as well
[18:03] <iulian> Oh.
[18:03] <ScottK> http://www.acronymfinder.com/TINC.html
[18:03] <ScottK> #1 result.
[18:04]  * iulian nods.


[12:15] <kiko> bradb, yes, stub's working on that AFAIK
[12:15] <bradb> ok, cool
[12:36] <Ubugtu> New bug: #60874 in conglomerate "crashes when trying to play sounds" [Unknown,Unknown]  http://launchpad.net/bugs/60874
[12:44] <kiko> cprov-afk, ping?
[01:35] <Ubugtu> New bug: #61183 in launchpad "Search packages has an unhelpful sort order" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61183
[02:32] <mpt> Gooooooooooooooooood afternoon Launchpadders!
[09:02] <SteveA> morning
[09:15] <carlos> morning
[09:19] <SteveA> hi carlos
[09:19] <carlos> SteveA: hi
[09:38] <SteveA> mpt: ping
[09:42] <mpt> SteveA, pong
[09:43] <SteveA> mpt: when can we have a chat?
[09:45] <mpt> SteveA, now's good
[09:59] <SteveA> it would be possible for them to allow that, but it would make the code a lot more complicated
[10:03] <malcc> From my point of view, it'd be an improvement if it just pretended, ie. blocked waiting for the lock rather than giving me an error and making me think
[10:04] <ddaa> malcc: there was some discussion on the ML about that, likely bzr-0.11 will do "wait on lock"
[10:05] <malcc> Cool!
[10:06] <ddaa> there was also discussion on allowing per-knit locking in some cases, but it sounded like it was not going to happen soon. More likely, some smart server could be used instead of inter-process locking
[10:08] <jamesh> mpt: if you're merging from rocketfuel into one of your branches, you'll find that most of the work for the second merge was already done for the first
[10:09] <jamesh> mpt: since the new revisions will already be in the repository, it just needs to merge the changes into the working copy
[10:11] <mpt> jamesh, that would normally be an advantage, but in this case I was merging first from an sftp:// branch and secondly from my local rocketfuel-built copy
[10:11] <mpt> I guess I should have done them the other way around
[10:12] <jamesh> mpt: you can do "bzr fetch $FROM $TO" to do the "pull revisions into my repository" without setting up a pending merge in your working tree
[10:13] <jamesh> e.g. fetch from your rocketfuel-built copy, then merge from sftp
[10:13] <jamesh> to minimise the number of revs that need to be fetched via sftp
[10:18] <SteveA> jamesh: nice, I didn't know about bzr fetch
[10:36] <mpt> I remember bzr fetch, because someone (mpool?) asked me what its opposite should be called
[10:36] <mpt> bzr throw :-)
[10:40] <SteveA> bzr unappeal
[11:14] <SteveA> ddaa: ping
[11:16] <ddaa> SteveA: pong
[11:17] <SteveA> ddaa: I'd like your advice on a bzr problem
[11:17] <SteveA> I have a tree where bzr info gives me info
[11:17] <SteveA> and then says
[11:17] <SteveA> NoSuchRevision: Branch BzrBranch5('file:///srv/launchpad.net/launchpad/') has no revision<EMAIL_ADDRESS>[11:17] <SteveA> with a traceback
[11:17] <SteveA> bzr revert doesn't fix it
[11:17] <SteveA> bzr pull --overwrite doesn't fix it either
[11:18] <SteveA> is there something I can do to explicitly pull in this revision?
[11:19] <ddaa> SteveA: fetch-ghosts, maybe
[11:19] <SteveA> unknown command
[11:20] <ddaa> ha, it's from bzrtools
[11:22] <ddaa> SteveA: what I'd do would be branch into a populated repository
[11:24] <SteveA> how will that help?
[11:24] <danilos> carlos, jordi: anyone doing the Divehi plural forms? ;)
[11:25] <SteveA> I just tried to pull --overwrite from a populated repository, assuming I understand "populated repository" right
[11:25] <carlos> danilos: not me
[11:25] <danilos> carlos: ok, I'll handle that
[11:25] <carlos> danilos: neither jordi, he's without network connection in his other job
[11:26] <ddaa> SteveA: it pulls revision into a repository
[11:26] <SteveA> how does that help me?
[11:26] <SteveA> the repository has that revision
[11:26] <SteveA> how does that get the revision into the branch I want it in?
[11:26] <ddaa> SteveA: I do not understand what is your situation and what you are trying to do, so I can only guess.
[11:27] <SteveA> I have a branch.
[11:27] <SteveA> I cannot do stuff I want to do with it, because bzr info gives that exception
[11:27] <SteveA> the exception indicates there is a missing revision
[11:27] <SteveA> I have the revision in a repository elsewhere
[11:27] <SteveA> but I do not know how to get that revision from the repository into the branch that is missing it
[11:30] <ddaa> SteveA: bzr info should never give you that sort of error, so you have another problem as well. And I do not know what it is. I suggest:
[11:30] <ddaa> cd broken-branch ; bzr branch /path/to/repo/branch-name
[11:31] <ddaa> Then repo/branch-name should work. Replace broken-branch by a lightweight checkout or a fresh branch from repo/branch-name
[11:32] <SteveA> okay I can do that.  although, it is annoying because this is a launchpad branch
[11:32] <ddaa> actually "bzr branch broken-branch /path/to/repo/branch-name"
[11:32] <SteveA> and so I have to mess around with the subtrees / symlink things
[11:32] <ddaa> SteveA: all the more a reason to use a repository and light checkouts
[11:33] <SteveA> I don't know a good way to maintain these things in bzr currently
[11:33] <ddaa> What you can do to avoid messing with subtrees etc is to replace the .bzr in your broken tree by the one you created when doing a fresh checkout/branch
[11:34] <SteveA> that sounds like flaky magic
[11:34] <SteveA> until bzr has a supported way of doing this I'll
[11:34] <SteveA>  - use the most obvious thing
[11:34] <SteveA>  - consider reorganising the launchpad tree in RF so that it works well within the limitations of bzr as now
[11:34] <ddaa> on minute
[11:35] <ddaa> need music to cover the screams of the walking foetuses outside
[11:35] <SteveA> I'm sure there's a French punk band called "the walking foetuses"
[11:37] <ddaa> SteveA: I think you are talking about two issues now and that's confusing me
[11:38] <sabdfl> lifeless: squid question: is it possible to setup a browser and proxy so that the browser<->proxy connection is always over https even for http URL's?
[11:38] <ddaa> There are several issues here:
[11:38] <SteveA> sabdfl: you can do that with apache, or with any proxy
[11:39] <sabdfl> i find myself stuck behind national firewalls like in china and want to bypass those
[11:39] <ddaa> 1. you have a branch that causes bzr info to barf. It's highly anomalous, I did not have anything like that in weeks or months. We look for ways to recover your data.
[11:39] <SteveA> sabdfl: the proxy setting will be https://your.proxy
[11:39] <SteveA> and the proxy itself will be sent queries by the browser like  GET http://the/site/you/want HTTP/1.1
[11:39] <sabdfl> i tried running firefox on my home desktop with X forwarded over SSH to my laptop but that's.... painful
[11:39] <ddaa> 2. you appears to have issues with dealing with nested trees. I do not understand clearly what is your issue
[11:40] <sabdfl> ok, thanks stevea
[11:40] <SteveA> the tricky thing is, making sure only you can use this https proxy
[11:40] <SteveA> as you don't want to be running an open proxy
[11:40] <sabdfl> SteveA: why not?
[11:40] <ddaa> 3. I recommend that you use repositories and light checkouts when working with launchpad because it makes things perform much better
[11:41] <SteveA> if it is discovered by spammers, they can use it to send spam, for one thing
[11:41] <sabdfl> ok
[11:41] <SteveA> ddaa: thanks for your comments and assistance.  I'm rebuilding that tree.  There was no important data in it that I can't get from elsewhere.
[11:42] <SteveA> ddaa: there are various issues with how obvious it is to do stuff with nested trees.  I've seen how confused non-bzr-experts find it, and I include myself in that group.
[11:42] <SteveA> ddaa: so, don't worry that you don't understand the difficulty.  But do believe me when I say there are difficulties.
[11:43] <SteveA> so, I have no current problem.  I've archived the faulty branch and mailed martin about it, so he can examine it later if he wants to.
[11:43] <ddaa> SteveA: my pet solution for launchpad is to use my "bzr switch" command, in bzrtools. It works only on light checkouts.
[11:43] <SteveA> sabdfl: elmo has set up some kind of VPN thing to talk to the brilliant machine.  so, a VPN is an alternative for you when traveling.
[11:44] <ddaa> So I can change the branch of the launchpad branch w/o having to touch the nested trees.
[11:44] <ddaa> It's fast, cheap in disk space, and reliable.
[11:45] <ddaa> sabdfl: I see firefox can use a SOCKS proxy. Then you can use ssh to setup such a proxy that tunnels you to e.g. the data center.
[11:46] <ddaa> e.g. "ssh -N -D 5191 remote-host"
[11:47] <sabdfl> thanks ddaa, will try that too
[11:48] <ddaa> SOCKS rocks to gets through hostile firewalls
[11:49] <Fujitsu> It really rocks!
[11:55] <ddaa> hey sidarus
[11:56] <sidarus> hello ddaa :)
[11:56] <ddaa> bzr branch http://bazaar.launchpad.net/~vcs-imports/oscss/trunk oscss
[11:56] <ddaa> enjoy
[11:56] <SteveA> win 9
[11:56] <sidarus> we have also a channel on this server : #oscss
[11:56] <sidarus> ddaa>thank's a lot ;)
[11:57] <ddaa> Thanks too, there was a config issue in one of the internal services that caused php to try parsing bzr branch data... Fixed now.
[11:58] <sidarus> ddaa> Ha ok. Merci
[12:21] <carlos> stub: do you have 5 minutes to talk about Rosetta?
[12:21] <stub> carlos: yes
[12:21] <carlos> stub: several people asked us to run the script to copy translations from Dapper to Edgy before Edgy release so they can concentrate on Dapper and get their work reused for free in Edgy
[12:22] <carlos> the copy from Breezy to Dapper took around 25 minutes, and I guess this Dapper -> Edgy copy would take more or less the same amount of time
[12:22] <stub> We can test that
[12:23] <carlos> I think it would be really good to have
[12:23] <carlos> stub: would be useful if I time it on carbon?
[12:23] <carlos> I think it should be quite fast, at least faster than staging, isn't it?
[12:23] <stub> yes, although the timing now won't match the timing come edgy release time, will it?
[12:23] <stub> It will be faster on carbon than on staging, yess.
[12:24] <carlos> no, timing would be different because new translations will be added
[12:24] <stub> Significantly?
[12:24] <carlos> well, I don't think so
[12:24] <carlos> because the amount of templates will not change
[12:25] <stub> Anyway, I think your assumption is right and it won't be a major hassle to have a 40 minute downtime instead of a 10 minute downtime one update.
[12:25] <carlos> and the amount of new rows will not be as high as the amount of rows we already have
[12:25] <carlos> so, could I announce that we will do that migration?
[12:25] <stub> It will be nice though when no downtime is needed or we have inheritance and no need for such bloated tables :)
[12:26] <carlos> without a fixed date, but just that it will happen before Edgy release
[12:26] <stub> carlos: Sure
[12:26] <carlos> stub: yeah, inheritance would rock here
[12:26] <stub> Will this mean people are translating obsolete versions though?
[12:26] <carlos> no, people will translate Dapper as their main target
[12:26] <carlos> and those translations will still be used for the next 4 years
[12:27] <carlos> with regular language packs updates
[12:27] <stub> Ok.
[12:27] <carlos> when we implement multicasttranslations spec this migration will not be required anymore
[12:27] <stub> Makes me think translations should not be tied to versions though, and when you are translating 'an application' you actually should be translating several versions all mushed together. But I digress ;)
[12:27] <carlos> because translators will be able to do the migration while they translate the system
[12:28] <carlos> stub: yeah, that would be another way to implement inheritance ;-)
[12:28] <jamesh> the pending-reviews script seems a lot slower to process all branches than it was a few days ago
[12:29] <jamesh> the current run has been going for almost 2 hours
[12:50] <ddaa> I'm going out soon for a doctor appointment.
[12:52] <malcc> stub: ping
[12:52] <stub> malcc: pong
[12:53] <malcc> stub: Hi. I've got a patch I'm developing which, among other things, renames distroreleasequeue to "upload"
[12:53] <stub> That is a bit vague
[12:53] <malcc> stub: I'm having trouble with the sequence distroreleasequeue_id_seq, it seems tied to the id
[12:53] <stub> Lots of bits of launchpad have uploads
[12:55] <stub> malcc: have a look at database/scheme/archive/patch-25-48-0.sql, and try to think up a better name for our flat table namespace
[12:55] <malcc> stub: Thanks, will do
[12:56] <jordi> danilo-brb: I was telling about the divehi plurals yesterday
[12:56] <jordi> I mailed you during the weekend
[12:56] <stub> malcc: (and yes, it is not a typo that you need to use alter table to rename sequences)
[12:57] <malcc> stub: I didn't think it was, it suddenly explained why alter sequence was so little help :)
[01:24] <danilos> jordi: uhm, then I must have missed that one
[01:58] <salgado> stub, around?
[01:58] <stub> salgado: yes
[02:00] <salgado> hey stub, have you seen that cherry pick request I placed on LaunchpadProductionStatus?
[02:01] <stub> Maybe. I'll have a look.
[02:03] <stub> Yer - I've seen it. I guess I should push it out :)
[02:10] <lifeless> SteveA: next you see sabdfl, the answer is 'no;
[02:10] <lifeless> SteveA: because most (all?) browsers dont use https to talk to the proxy
[02:10] <lifeless> SteveA: squid built with ssl, and apache built with ssl can definately do it as far as the proxy logic goes, but the browser is currently your weak point.
[02:11] <lifeless> SteveA: my recommendation is one of the [excellent]  SSL tunneling VPN things like ssltunnel et al
[02:11] <lifeless> which tunnel all your traffic through, giving you access to email and so on problem free.
[02:16] <salgado> thanks stub!
[02:16] <salgado> is there anybody using dogfood?
[02:16] <malcc> Yes, I am
[02:17] <salgado> I guess it will take long?
[02:17] <malcc> A while, yes
[02:30] <cprov> stub: do you think indexing the SourcePackageRelease.changelog would be expensive ? (see bug #48735)
[02:31] <Ubugtu> Malone bug 48735 in soyuz "changelog histories for packages are not viewable/searchable" [Medium,Needs info]  http://launchpad.net/bugs/48735
[02:42] <stub> salgado: We have test failures with that cherry pick
[02:43] <stub> salgado: https://devpad.canonical.com/~andrew/paste/filedeulLf.html
[02:45] <salgado> ah, right
[02:46] <salgado> stub, apparently the cherry pick included the tests I added in r4038 but not the changes themselves. is that possible?
[02:48] <stub> That would be odd considering the cherry pick was r4050
[02:49] <salgado> indeed, but that line was actually added in r4038.  I just checked the diff for that revision
[02:50] <salgado> I guess this happened because I touched the same file in r4050
[02:51] <salgado> and r4038 is a pretty small change, but includes a db patch. :-(
[02:51] <stub> test_shipit.py? There is a conflict on that file. I'll look at that again.
[02:52] <salgado> just removing TestShippingRun should be enough, I think
[02:53] <LarstiQ> heya sabdfl
[02:54] <stub> Can't see anything wrong with how I resolved the conflicts... https://devpad.canonical.com/~andrew/paste/fileHi1qEy.html
[02:54] <LarstiQ> sabdfl: safely back from travel?
[02:54] <sabdfl> LarstiQ: yup and mostly in home timezones too, now
[02:54] <LarstiQ> sabdfl: "mostly"? :)
[02:54] <sabdfl> still waking up a bit early
[02:54] <jsgotangco> heh
[02:56] <LarstiQ> sabdfl: have you spoken with SteveA about rosetta output copyright yet?
[02:56] <stub> lifeless: You might want to look at that if salgado is correct and changes made in r4038 have leaked into a cherry pick of r4050
[02:57] <sabdfl> LarstiQ: he said he was working up a proposal
[02:58] <salgado> stub, could the problem be that both revisions (4038 and 4050) came from the same branch of mine (shipit-trivialities)?
[02:59] <LarstiQ> sabdfl: thanks
[03:00] <salgado> stub, for now, if you remove the TestShippingRun tests, everything should work just fine.  but I'd like to have a look at the diff of the cherry pick, just to make sure this is the only thing that shouldn't be included in it
[03:19] <salgado> stub, any luck with that?
[03:19] <stub> salgado: tests are still running
[03:20] <salgado> ah, right
[03:21] <salgado> stub, would it be possible for you to merge from my person-creation-rationale into staging and run a script there, or grant me persmission to access staging's db, so that I can do it myself?
[03:29] <kiko> hi
[03:30] <malcc> kiko: Morning dude. Will you have some time today to look at my review response for the post-sprint fixes?
[03:31] <kiko> malcc, sure -- where is it?
[03:32] <malcc> kiko: Emailed yesterday afternoon, subject "Re: REVIEW: Soyuz smoketest fixes, was Re: Soyuz System Test Progress"
[03:33] <kiko> malcc, I didn't get this. was it To: kiko?
[03:33] <malcc> kiko: Yes. I'll re-send it to you now
[03:33] <stub> salgado: tests run fine, I can cherry pick that
[03:34] <SteveA> kiko: call in 2 hrs
[03:34] <kiko> SteveA, with mark?
[03:34] <stub> salgado: I'll do staging after the cherry pick
[03:34] <SteveA> yes
[03:34] <kiko> kay
[03:34] <salgado> stub, cool. thanks a lot!
[03:37] <SteveA> go kiko
[03:37] <SteveA> actually, that was a mistyped irssi command
[03:37] <SteveA> but you can accept it as encouragement
[03:37] <kiko> thanks
[03:39] <stub> salgado: cherry picked
[03:39] <SteveA> ddaa: ping
[03:49] <SteveA> carlos, danilos: ping.  want a quick catch-up chat sometime
[03:49] <carlos> SteveA: I'm here
[03:50] <SteveA> carlos: can we say, 10 mins, on the hour?
[03:50] <carlos> SteveA: danilo and I have a couple of meetings today, would be possible to have it tomorrow?
[03:50] <carlos> or if it's really fast, is fine for me...
[03:50] <SteveA> I want it, but fast is good
[03:51] <carlos> SteveA: the meetings are related to our current tasks and I guess are related to the meeting you want to have with us
[03:51] <SteveA> so, is meeting in 10 mins okay?
[03:52] <carlos> yes, it works for me
[03:52] <carlos> not sure whether danilo is around
[03:52] <SteveA> ok, let's see in 10
[03:53] <carlos> ok
[04:00] <carlos> SteveA: #cm ?
[04:01] <SteveA> how about #l-m ?
[04:02] <SteveA> I mean, #launchpad-meeting
[04:03] <ddaa> SteveA: pong
[04:03] <ddaa> back from the doc
[04:03] <carlos> sure
[04:23] <WebMaven> SteveA: Mornin'
[04:25] <flacoste> kiko: ping
[04:27] <kiko> flacoste, pongus
[04:28] <flacoste> flacoste: will you have time to take a look at the 4 unresolved issues on the SupportTrackerWorkflowSpec (and they were alo mentioned in some emails you were Cc on)
[04:29] <flacoste> flacoste: they are: a) multiple best answers or not; b) should we migrate old ticketmessage more precisely; c) should we keep TicketReopenings; d) should we generate karmaaction for all the workflow transitions
[04:29] <flacoste> kiko: ^^
[04:30] <flacoste> kiko: my standing: a) no, b) more yes, than no, c) no, d) no
[04:32] <kiko> flacoste, yeah, I will. just ping me in the afternoon after my phone call
[04:32] <flacoste> kiko: ok
[04:34] <stub> salgado: I reworked your db patch a bit as the update was taking too long: https://devpad.canonical.com/~andrew/paste/fileFFEFZ1.html
[04:35] <stub> (although I don't know if it is really any faster...)
[04:35] <stub> salgado: staging is back up with your branch
[04:36] <salgado> stub, cool. I'll fix the patch on my branch
[04:36] <stub> salgado: Do you need me to disable tomorrows update, or do you only need a short time to check it out?
[04:36] <salgado> stub, can you run python ./scripts/guess-person-creation-rationale.py
[04:36] <salgado> I just want the output of that script, actually, and maybe check the results on the UI today, so there's no need to disable tomorrow's update
[04:37] <stub> Running now
[04:39] <stub> salgado: Does that script process all people in order of id?
[04:40] <salgado> stub, all unvalidated people in no specific order
[04:40] <WebMaven> SteveA: ping
[04:40] <stub> So we have no way of telling how long this will take...
[04:41] <malcc> stub: I need to re-shuffle some dbs on mawson, and a long-running EXPLAIN process is stopping me. Can you come kill it for me?
[04:41] <SteveA> WebMaven: kinda busy right now
[04:42] <stub> salgado: If it happens to be processing in id numeric order, which is highly likely given the staging database is rebuilt fresh daily, then this run will take about 17 hours.
[04:42] <salgado> wow
[04:43] <WebMaven> SteveA: later, then.
[04:43] <stub> salgado: (extrapolating from https://devpad.canonical.com/~andrew/paste/fileISPhj9.html)
[04:43] <stub> salgado: Does this run in a single transaction?
[04:43] <salgado> stub, no, one transaction for each person
[04:44] <salgado> stub, https://devpad.canonical.com/~andrew/paste/fileuTud5L.html is how I fetch the list of people ids
[04:44] <stub> That could be a cause - should batch them in lots of about 5000
[04:44] <salgado> stub, it won't print tthese messages for all profiles
[04:44] <salgado> only for a few of them, I expect
[04:45] <salgado> very few, in fact
[04:46] <stub> Yes, but looking at that query the ids will be ordered (to do the EXCEPT, both queries will be ordered before being merged I think). So we have so far processed about 6000, and there are over 600,000 rows to do.
[04:46] <stub> oh - so only commit per row it prints out. I see.
[04:47] <salgado> no, it commits for all rows, but that "Select ... EXCEPT Select ..." won't return 600000 rows, will it?
[04:48] <stub> salgado: No - only 15,000 or so
[04:53] <stub> salgado: Need to test with that batching though - this seems very slow
[04:53] <stub> I'm going to need to kill it and re-run it under screen
[04:55] <salgado> stub, sure, I'll add the batching quickly
[04:56] <salgado> stub, so, since we'll be processing around 15k rows, would it be okay to have a batch of 500?
[04:57] <stub> Maybe 50 actually - it depends on how long it takes to process each row
[04:58] <salgado> it shouldn't take too long, I think
[04:59] <malcc> stub: Ping
[05:00] <stub> salgado: It is still going to take at least 30 mins - seems to be a maximum of 10 per second
[05:02] <stub> And maybe down to around 1 per second on avg
[05:05] <malcc> Can anybody help me with the db on mawson? I need to rename launchpad_dogfood (as I often do during SoyuzSystemTest stuff) and another process is using it.
[05:06] <kiko> malcc, which process?
[05:06] <kiko> or is that the question? :)
[05:06] <malcc> kiko: postgres  9539  1433 96 Sep18 ?        17:15:51 postgres: launchpad launchpad_dogfood [local]  EXPLAIN
[05:06] <malcc> kiko: Or at least that's my guess, it looks a likely candidate
[05:07] <stub> malcc: Process 9539 is the source
[05:08] <stub> Which looks like salgado, but I've killed it.
[05:08] <malcc> stub: Cool, thanks
[05:09] <salgado> yeah, I had one psql session doing an explain there yesterday and I lost the connection at some point.  I guess it was mine
[05:09] <kiko> don't kill salgado
[05:11] <salgado> kiko, https://staging.launchpad.net/people/mckinstry
[05:11] <salgado> (a problem in the sort order is causing the latest uploaded package to be used in the comment, but I've fixed it already)
[05:11] <kiko> salgado, very nice. I don't know whether parenthesized text is the right way to deliver this, but that's another matter.
[05:12] <salgado> kiko, please comment on the spec. that's what mpt suggested on the spec
[05:12] <kiko> salgado, I'm happy the way it is, just that I wasn't sure.
[05:24] <salgado> stub, not finished yet?
[05:34] <malcc> kiko: Did you get my forwarding of that email?
[05:34] <kiko> malcc, yes, but I'm in a phone call.
[05:35] <malcc> kiko: Sure, no hurry, just wanted to avoid the case if it went missing of losing another day.
[05:35] <malcc> elmo: Ping
[05:36] <kiko> malcc, can you ask somebody else to look at it meanwhile?
[05:36] <SteveA> kiko: ping
[05:36] <malcc> kiko: I have to go out in half an hour, if you'll get time later today it'll be quicker to stick with you. If that's not looking likely, sure, I'll look for another reviewer
[05:37] <kiko> that's likely, just don't want any waste
[05:37] <malcc> kiko: Cool, I'll wait then, and if there's nothing tomorrow morning I'll find a euro-timezone reviewer then
[05:50] <jordi> oh man
[05:50] <jordi> are you guys aware of stuff in Tailand
[05:50] <kiko> Thailand?
[05:51] <jordi> yeah
[05:51] <jordi> possible coup d
[05:51] <jordi> oh man
[05:51] <jordi> I can-t type with this keyboard
[05:51] <jordi> coup d'etat
[06:00] <malcc> elmo: unping
[06:03] <kristog> hello *
[06:04] <kristog> i wonder if you know how i can setup a commit-message mailing list for a project
[06:04] <kristog> the project is ~telepathy hosted on bazaar.lp.net
[06:25] <carlos> mpt: hi, around?
[06:27] <carlos> danilos: hi?
[06:47] <danilos> SteveA, carlos: hey guys, sorry about this, I just crashed (and laid down just to relax for 5 mins), guess I caught a cold or something, can concentrate only in 4h slots :(
[06:47] <carlos> danilos: don't worry
[06:47] <SteveA> danilos: no worries.  carlos and I discussed the things about rosetta we needed to
[06:47] <carlos> I think we should leave our meetings for tomorrow
[06:47] <carlos> so you are more concentrated
[06:47] <carlos> what do you think?
[06:48] <danilos> carlos: sure, but there is already https://launchpad.canonical.com/ITranslationImporter you can look at
[06:48] <danilos> SteveA: ok, can you fill me in with some details?
[06:49] <carlos> danilos: I can send you the log
[06:49] <SteveA> go kiko
[06:49] <carlos> danilos: ok, I will read it so the meeting will be more productive, thanks
[06:50] <danilos> carlos: ok, thanks
[06:51] <carlos> danilos: sent
[06:52] <SteveA> stub: ping
[06:52] <stub> SteveA: pong
[06:54] <kiko> stub, how's th?
[06:54] <stub> Dark and raining
[06:55] <kiko> what is this news we hear about tanks?
[06:55] <stub> They just took CNN and BBC off the air so you will probably know news before I do
[06:55] <stub> Just another coup
[07:02] <stub> Heh - interesting quote "I just spoke to a friend on Suk: He said there's a big f**king party going on to celebrate Thaksin's downfall! In his words.. "..time for another line of coke and a blowjob"
[07:22] <imbrandon> ping .... um i dont think i should be seeing the accept/reject buttons for the NEW queue am I ? heh
[07:22] <imbrandon> https://launchpad.net/distros/ubuntu/edgy/+queue  ^^
[07:23] <elmo> they don't do anything
[07:23] <imbrandon> ok whew, just wanted to make sure it wasent a major problem, i'm smart enough not to test if they worked but someone else might not have
[07:23] <imbrandon> heh thanks elmo
[07:25] <salgado> stub, still around?
[07:49] <kiko> BjornT... you donna love me :)
[08:00] <BjornT> kiko: don't worry, i'm going to review your patch tonight :) just need to get something to eat first.
[08:00] <kiko> BjornT, if you take too long I will give you ANOTHER patch!
[08:18] <Kuhrscher> Hi, is it possible that there went something wrong during the import of kdeaccessibility's pot files?
[08:18] <Kuhrscher> There is for example a template for kttsd without any strings...
[08:19] <ddaa> If somebody thinks that the "subversion repository" on this page https://launchpad.net/products/python/trunk looks weird, it's normal. I'm running the import from a local copy of the repository so it does not take forever.
[08:19] <Kuhrscher> (instead of 462)
[08:21] <stub> salgado: sodium:~stub/person-creation-rationale.txt
[08:23] <salgado> thanks a lot, stub!
[08:25] <salgado> stub, at some point you killed the script and started it again, right?
[08:31] <stub> yes - I needed to rerun it under screen
[08:31] <salgado> ok. I was wondering why some profiles already had a creation rationale
[08:32] <salgado> stub, can you check if the account named sutton-david-merged has a preferred email in production?
[08:32] <carlos> Kuhrscher: let me check
[08:35] <salgado> stub, would you be kind enough to run another script on staging for me? (https://devpad.canonical.com/~andrew/paste/filePU9NaR.html)
[08:43] <stub> salgado: Yes, sutton-david-merged has a preferred email address on production
[08:44] <kiko> stub, would you approve of the trivial https://sodium.ubuntu.com/~andrew/paste/fileoM0oDN.html
[08:47] <stub> kiko: That seems broken. Why is the (1,2,3) quoted?
[08:47] <kiko> stub, that's the test part..
[08:48] <stub> Yes, and it seems to be demonstrating broken behavior (?)
[08:48] <kiko> hmmm
[08:48] <kiko> right
[08:48] <kiko> so omit the external ""s
[08:48] <stub> I would have throught quote(set([1,2,3] ) would return "(1,2,3)", not "'(1,2,3)'"
[08:49] <stub> ie. not a string
[08:49] <kiko> stub, it does
[08:50] <kiko> my test was just broken
[08:50] <stub> The tests show it returning a single quoted string
[08:50] <stub> Ahh
[08:50] <kiko> right
[08:51] <kiko> >>> quote(set([1,2,3] ))
[08:51] <kiko> '(1, 2, 3)'
[08:51] <kiko> that's a make harness run
[08:51] <kiko> I just hadn't run the ftests for that file
[08:51] <stub> fine then
[08:51] <kiko> stub, do you have other philosophical issues with the patch?
[08:51] <kiko> ah, thanks.
[08:54] <carlos> Kuhrscher: yeah, the .pot file is broken
[08:54] <salgado> stub, kiko, I just reported https://launchpad.net/products/launchpad/+bug/61288. any idea how that could have happened?
[08:55] <Kuhrscher> Carlos: Thanks for checking it
[08:55] <carlos> Kuhrscher: Jonathan is fixing that issue with other template in kdebase, and he just told me that will fix those ones too
[08:56] <stub> salgado: Your script doesn't actually connect to the db - might need some basic testing
[08:56] <Kuhrscher> Do we have to upload all translations manually or will they be implemented automatically?
[08:56] <kiko> salgado, that kinda sucks, eh?
[08:56] <kiko> salgado, how long ago was it created?
[08:56] <stub> Could have been a manual update sometime
[08:56] <salgado> stub, ah, sorry.  that code is meant to be run in a "make harness" section
[08:56] <salgado> session
[08:56] <stub> whatever that means
[08:57] <Kuhrscher> Carlos: Do we have to upload all translations manually or will they be implemented automatically?
[08:57] <carlos> Kuhrscher: for ubuntu, they are updated automatically with every new package upload into Ubuntu's archive
[08:57] <salgado> stub, an interactive session. either python -i canonical/database/harness.py or simply "make harness"
[08:58] <salgado> stub, that is not actually a script... is just a collection of hacks I used to use when I had access to staging
[08:58] <kiko> salgado, why don't you have access to staging any longer?
[08:58] <salgado> kiko, matsubara is going to check that for us
[08:59] <Kuhrscher> Carlos: Yes I know, but this won't be really a package upload right?
[08:59] <salgado> kiko, no idea
[08:59] <carlos> Kuhrscher: yes, it is
[08:59] <Kuhrscher> Great :)
[08:59] <Kuhrscher> Carlos: Thank you
[09:00] <kiko> salgado, it is now accessed from devpad. have you tried from there?
[09:00] <salgado> actually, I think I had access to staging only for one or two days
[09:01] <salgado> yeah, it lasted until it was rebuilt
[09:01] <salgado> it wasn't "official" access
[09:02] <salgado> kiko, it was created on 2005-06-15, but we can't tell when it was merged
[09:02] <kiko> salgado, when was the account where it was merged to created?
[09:03] <matsubara> > select name, merged, datecreated from person where name = 'suttondavid';
[09:03] <matsubara>     name     | merged |        datecreated
[09:03] <matsubara> -------------+--------+----------------------------
[09:03] <matsubara>  suttondavid |        | 2005-11-30 07:20:59.936869
[09:03] <matsubara> (1 row)
[09:05] <kiko> so recently merged
[09:05] <kiko> weird
[09:05] <salgado> recently?
[09:05] <salgado> it could have been merged last week or 10 months ago... we can't tell for sure
[09:06] <kiko> well, less than a year ago.
[09:08] <kiko> salgado, could it be  race condition, i.e. gina ran at /exactly/ the same time as this dude was created?
[09:09] <salgado> at the time it was merged, you mean?
[09:10] <salgado> I doubt that, because gina wouldn't set a preferred email
[09:10] <salgado> s/wouldn't/shouldn't
[09:14] <kiko> humm.
[09:15] <kiko> what about the guy has a token open for a preferred email
[09:15] <kiko> then merges
[09:15] <kiko> then approves the token?
[09:15] <kiko> do we check for pending tokens?
[09:16] <salgado> the token should have been carried, AFAICS
[09:19] <kiko> I guess.
[09:22] <salgado> stub, did you manage to run that hackish script on the interactive session?
[09:23] <andrunko> i uploaded my package to launchpad.net (only the debian dir) to http://bazaar.launchpad.net/~telepathy/telepathy-qt/ubuntu, how can i upload the source package to get it to build?
[09:23] <andrunko> hi all btw :)
[09:28] <kiko> andrunko, heh, you're a month or so ahead of us. we don't have a custom package-building facility yet
[09:29] <andrunko> heh
[09:29] <andrunko> so what should i do to get it to build?
[09:31] <kiko> andrunko, well, you could talk to a motu at #ubuntu-motu..
[09:31] <kiko> andrunko, what are you trying to build?
[09:33] <andrunko> kiko: i would like to add telepathy-qt to https://launchpad.net/distros/ubuntu/edgy/+queue
[09:34] <kiko> andrunko, talk to a motu.
[09:34] <andrunko> ok
[09:43] <stub> salgado: sodium:~stub/invalid-people-with-non-bug-references.txt
[09:45] <flacoste> kiko-afk: remdinder to reply to the pending unresolved issues on SupportTrackerWorkflowSpec
[09:46] <salgado> stub, you rock! thanks a lot again
[09:50] <Ubugtu> New bug: #61296 in rosetta "Please remove "no" from picard" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61296
[09:52] <kiko> stub, I have an SQL question for you.. have amoment?
[10:04] <cprov> kiko: ping
[10:04] <kiko> cprov, pong
[10:04] <kiko> ahoy there.
[10:04] <cprov> kiko: hi, do you think we can apply the partial fix for bug #58144 in soyuz production (see https://sodium.ubuntu.com/~andrew/paste/filePGGlNa.html)
[10:04] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,Fix committed]  http://launchpad.net/bugs/58144
[10:05] <kiko> cprov, it's a simple change isn't it?
[10:05] <cprov> kiko: the RF 4066 can't be applied entirely ...
[10:05] <kiko> oh?
[10:05] <cprov> kiko: I've isolated the important chunk to nascentupload
[10:06] <cprov> kiko: dude, the current codeline is RF3909 based with tons of cherrypicks (17) and a local change ... i.e. a mess ;)
[10:07] <kiko> which local change?
[10:07] <cprov> kiko: on of the malcc bug fix, commited in RF but the changeset could not be applied too, let me see the bug number
[10:08] <cprov> kiko: bug # 58187
[10:09] <cprov> bug #58187 ?! Mr. bot ?
[10:09] <Ubugtu> Malone bug 58187 in soyuz "uploads to frozen should land in unapproved, not be rejected" [Critical,In progress]  http://launchpad.net/bugs/58187
[10:09] <cprov> ahh
[10:10] <kiko> hmm
[10:10] <kiko> cprov, isn't there yet another bug related to backports? or is that proposed?
[10:12] <cprov> kiko: dunno, the other backport related was broken release file or so, fixed during mawson tests, but we may be talking about different things ...
[10:13] <cprov> kiko: ahh, sending announceemail to a different mbox when dealling with dapper-backports
[10:13] <cprov> kiko: bug #59443
[10:13] <Ubugtu> Malone bug 59443 in soyuz "Soyuz should send announce messages for backports to different list" [High,Confirmed]  http://launchpad.net/bugs/59443
[10:14] <kiko> no, I thought there was something else
[10:16] <kiko> cprov, I am okay with you applying that there, I guess.
[10:16] <kiko> malcc?
[10:16] <cprov> kiko: nice, thank you
[10:18] <Mez> hmm - out of curiosity - which mbox will it be sent to ?
[10:18] <kiko> hmm, can't remember
[10:19] <Mez> also - when a backport gets uploaded - is it possible to set the Changed-by to the backports mailing list - :D so that the backports mailing list gets an email
[10:19] <Mez> (atm - iirc, soyuz sends an email to the maintainer, the changed-by, and the person who signed the upload)
[10:20] <cprov> Mez: announcelist & signer only
[10:21] <cprov> Mez: do you think we are going to have one ML per pocket (dapper, dapper-updates, dapper-backports, etc) ?
[10:21] <Mez> cprov: well thats weird - because I remember getting mail as a maintainer when Riddell uploaded katapult
[10:23] <cprov> Mez: only if you have preferredemail set in LP ... that's right
[10:24] <cprov> Mez: at the end, announcelist + signer (always has preferredemail) + maintainer (if he has preferredemail)
[10:25] <Mez> ah, kk
[10:27] <webben> siretart, i'd like to try your vim7 build --- if i want the entire shebang, is vim-full all i need?
[10:35] <siretart> webben:
[10:36] <kiko> flacoste, pong
[10:36] <flacoste> kiko-afk: ping
[10:36] <siretart> webben: err, check which package of vim you have installed and then upgrade the one you have installed
[10:36] <kiko> flacoste, what do I need to look at?
[10:36] <flacoste> kiko-afk: (about the unresolved issues on SUpportTrackerWorkflowSpec)
[10:37] <flacoste> kiko-afk: you can take a look at https://launchpad.canonical.com/SupportTrackerWorkflowSpec
[10:37] <webben> siretart, ah that was a whole batch of packages; i guess i should replace each of those then, thanks
[10:37] <flacoste> kiko-afk: in the Unresolved Issues section, you'll find the summary with links to the emails in the archive, you were Cced on those
[10:38] <kiko> okidok.
[11:54] <kiko> hey BjornT?


[06:55] <jam> mmrazik: feel free to ping me when you come back online
[06:56] <jam> I'm guessing paramiko + tarmac is actually trying to prompt for a password/etc which is why it is hanging. (Since you probably have credentials set for openssh that paramiko might not know about.)
[06:56] <jam> we can debug that if we want, but given it looks like the connection is being retried and is *still* failing, I think we need to dig deeper.
[06:57] <jam> So I'd like to debug it in a bit more hands-on way.
[07:10] <mmrazik> jam: ok. Let me try to re-create the setup. Will take me a few minutes.
[08:01] <mmrazik> jam: so this is where I'm right now: http://pastebin.ubuntu.com/1190380/
[08:01] <mmrazik> jam: but I'll be on a phone for a while now
[08:02] <mgz> morning!
[08:03] <vila> hi mgz
[08:07] <mgz> hey vila
[08:16] <jam> mmrazik: k, I'll be doing lunch and digging into some lp stuff for a bit, but I'll try to be responsive when you get back.
[08:16] <mmrazik> jam: is there something I should try now?
[08:16] <mmrazik> I'm a bit stuck TBH
[08:17] <jam> mmrazik: do you know what version of tarmac you are running (just to try to set things up similarly here)
[08:35] <jam> mmrazik: line numbers in your traceback don't quite match up to tarmac trunk, but you might be able to do something like: http://paste.ubuntu.com/1190405/
[08:36] <jam> ah, you might need to do both branches, 1 sec
[08:39] <jam> http://paste.ubuntu.com/1190407/
[08:39] <jam> mmrazik: ^^ should re-open both branches, creating new connections. at least as a stop-gap. I'd like to fix bzrlib, though, if you don't mind helping me investigate.
[08:43] <mmrazik> jam: I'm on it now
[08:43] <mmrazik> jam: regarding tarmac -- its unfortunately custom tarmac extension I didn't even write
[08:43] <mmrazik> let me check if it is somewhere on bzr
[08:43] <mmrazik> but the setup is fairly complex and requires jenkins
[08:44] <mmrazik> the exension is some jenkins pre-commit logic and that is also why it fails. It waits for the jenkins job to finish only then commits.
[08:44] <mmrazik> jam: I think the easiest way to reproduce will be to create some custom "sleep 420" pre-commit hook
[08:45] <jam> mmrazik: is this the same one that sidnei was looking at recently?
[08:45] <jam> (not sure which team you're on)
[08:45] <mmrazik> jam: I don't know but we are different teams (and this one was written by yet another team)
[08:45] <mmrazik> for me this tarmac stuff is almost end of life and I want to get rid of it
[08:46] <mmrazik> its just some legacy I had to maintain
[08:46] <jam> mmrazik: what are you switching to?
[08:46] <mmrazik> jam: more jenkins driven approach. where the logic is in jenkins.
[08:46] <mmrazik> it also scales better because jenkins can schedule build slaves
[08:46] <mmrazik> right now tarmac must be running on the same node where the jenkins job runs
[08:47] <mmrazik> anyway... going to patch tarmac with the patch you provided
[08:49] <mmrazik> patched/running
[08:50] <mmrazik> jam: I believe it is this one: https://code.launchpad.net/~didrocks/tarmac/tarmac-jenkins
[08:50] <mmrazik> but as I said there should be a simpler way how to reproduce
[08:57] <jam> mmrazik: seeing if I can reproduce it trivially.
[09:00] <mmrazik> jam: the tarmac patch you provided didn't help :-/
[09:01] <mmrazik> http://pastebin.ubuntu.com/1190430/
[09:02] <mmrazik> AFAICT it now fails in the  "source.bzr_branch = source.bzr_branch.bzrdir.open_branch()" which I just added
[09:08] <jam> mmrazi|otp: http://paste.ubuntu.com/1190441/
[09:08] <jam> is another patch you can try when you get back.
[09:09] <jam> mgz: poke
[09:32] <mmrazi|otp> jam: running it
[10:43] <mmrazik> jam: still no luck :-/ http://pastebin.ubuntu.com/1190559/
[10:43] <jam> mmrazik: the traceback shows it isn't the new code: source.bzr_branch = source.bzr_branch.bzrdir.open_branch()
[10:44] <mmrazik> jam... argh... sorry. I didn't apply it correctly
[10:44] <mmrazik> jam: yes. Just looking at it
[10:54] <mmrazik> jam: looks better now. There is still a stacktrace but I think its because the tarmac user is not allowed to push into the branch
[10:58] <mmrazik> I'm now trying with the real thing
[11:02] <mmrazik> jam: ack. it works with the tarmac patch.
[11:02] <jam> mmrazik: so that at least gets you up and running again.
[11:02] <jam> I'm trying to see if I can reproduce here. The 5-min wait to test is a bit annoying.
[11:02] <mmrazik> jam: yep. Many thanks for the help.
[11:02] <jam> I think I tried paramiko, and found it hangs at the point of reconnect.
[11:02] <jam> which might be what you saw.
[11:03] <mmrazik> let me know if you need some more help with this
[11:06] <jam> well, I should know in about 200 more seconds if it reproduces locally.
[11:11] <jam> mmrazik: :( it doesn't reproduce here, the retry works: http://paste.ubuntu.com/1190598/
[11:11] <jam> (that is seconds *10)
[11:11] <jam> at 5 min it gets the 'you're disconnected' from the server.
[11:12] <jam> at 35s, the client notices, and retries the connection.
[11:12] <jam> and successfully gets Branch.last_revision()
[11:13] <mgz> hm. I wonder what's different.
[11:13] <mmrazik> :-/
[11:38] <jam> mgz: well offhand I wouldn't expect EPIPE from a *socket* object, but the traceback clearly looks like it is failing while retrying, not failing in the initial request (and then failing to retry)
[11:46] <jam> mgz: hmm.. right now I'm running on Windows, which uses actual pipes, rather than socketpair. I wonder if that matters.
[11:46] <jam> mgz: can you run this on your machine: http://paste.ubuntu.com/1190654/
[11:50] <jam> and maybe you as well mmrazik ^^
[11:51] <mgz> jam: sure
[11:51] <jam> I can see that if I run BZR_SSH=paramiko, I don't see the stderr 'you have been disconnected' message.
[11:53] <mmrazik> jam: running
[11:53] <mmrazik> so far so good. just numbers
[11:53] <mmrazik> oh..
[11:53] <mmrazik> thats expected :)
[11:53] <jam> mmrazik: well, expected for 350s :)
[11:54] <jam> mgz, mmrazik: weird, when running with paramiko, we end up looping on a socket.sendall trying to send 119 bytes, and we just keep failing.
[11:54]  * mmrazik shour read the code before copy&pasting&running something
[11:54] <mmrazik> s/shour/should/
[11:54] <jam> it gives us a "sent 0 bytes" in response, but doesn't actually give an error.
[11:54] <jam> I think we should probably have a check for 'if bytes sent == 0: EOF"
[11:58] <mmrazik> jam: the code can reproduce the error
[11:58] <mmrazik> http://pastebin.ubuntu.com/1190681/
[11:58] <jam> mmrazik: so... progress of a sort.
[12:03] <jam> bug #1047309
[12:04] <jam> mgz, jelmer: can you think if sock.send() can legitimately say "I couldn't send any content right now" without raising EINTR?
[12:04] <jam> I realize it returns the number of bytes written, but if it can't write *any* bytes, should we treat that as EOF immediately or should we try a couple times.
[12:07] <jelmer> jam: couldn't there be a buffer that's full, or something like that?
[12:09] <jam> jelmer: man send says: http://paste.ubuntu.com/1190698/
[12:09] <jam> it will block until it can send what you asked
[12:09] <jam> unless you are in non-blocking mode
[12:09] <jam> but then send should fail with EWOULDBLOCK
[12:10] <jam> MSG_NOSIGNAL (since Linux 2.2)
[12:10] <jam>        Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connec-
[12:10] <jam>        tion.  The EPIPE error is still returned.
[12:10] <jam> interesting.
[12:11] <jam> and we use blocking sockets (because when you set nonblocking it causes the smart server tests to fail)
[12:12] <jam> mmrazik|otp: ok, in this particular case, it looks like it is getting EPIPE during the first send, not during the retry, so I think our code just isn't handling EPIPE as a connection reset
[12:12] <jam> I'll try to dig some more.
[12:12] <jam> mgz: can you confirm that it fails for you?
[12:22] <mgz> onesec
[12:23] <mgz> okay, running remotely, will tell you when it returns
[12:28] <mgz> 30
[12:28] <mgz> Connection Timeout: disconnecting client after 300.0 seconds
[12:29] <mgz> and traceback at loop end.
[12:29] <mgz> same as mmrazik.
[12:36] <jam> mgz: k, I think I know the bug, and i'll put up a fix, can you run the fixed code in a sec.
[12:39] <jam> mgz, mmrazik: If you are comfortable running bzr from source: lp:///~jameinel/bzr/2.5-conn-reset-socket-pipe-1047325
[12:39] <jam> it doesn't have a test, but it should fix the problem
[12:39] <jam> (if it is that we aren't retrying at all.)
[12:39] <mgz> sure, I'll test that.
[12:39] <mgz> probably just want the builddeps on this..
[13:18] <jam> mgz: did you get a chance to test the branch?
[13:18] <jam> I also have: https://code.launchpad.net/~jameinel/bzr/2.5-unending-sendall-1047309/+merge/123268
[13:18] <jam> up for review.
[13:20] <mgz> jam:
[13:20] <mgz> Connection Timeout: disconnecting client after 300.0 seconds
[13:20] <mgz> 31
[13:20] <mgz> 32
[13:20] <mgz> 33
[13:20] <mgz> 34
[13:20] <mgz> ConnectionReset calling 'Branch.last_revision_info', retrying
[13:28] <jam> mgz: did it print the revision_id at the end?
[13:28] <mgz> so, will review other branch, and that fix looks good
[13:29] <mgz> jam: yup, the lack of traceback was the main thing :)
[13:30] <jam> mgz: I think the fix is good, I'd like a test for it, so if you have ideas, I'm listening.
[13:31] <jam> I might get to it over the weekend, and then we should do 2.5.2
[13:32] <mgz> I do wonder about if we've got the exception wrapping at the right level
[13:33] <mgz> there are some tests that try to check connection reset stuff, but are a little unreliable as terminiation a connection from one thread in a process to another thread is not actually the same as what really happens
[13:34] <mgz> the short answer is you replace the underlying call to raise an exception we've observed it raising and make sure it propogates wrapped up netly
[13:34] <mgz> *neatly
[13:34] <mgz> but a more real world test would be grand...
[13:34] <awilkins> Gah, why did I ever set things up with NTLM auth (answer : because most of my users are noobs and it's easier when it works...)
[13:35] <awilkins> In the position where I have a tree that SVN can check out fine (anonymously) but Bazaar can't branch it (fails the NTLM auth)
[13:38] <awilkins> Does Bazaar just use PyCurl if it's installed?
[13:38] <awilkins> Hmm, maybe not
[13:38] <mgedmin> every time I see "Aborting commit due to empty commit message." I feel that I ♥git
[13:38] <mgedmin> you're missing an opportunity here with that interactive roadblock
[13:46] <mgz> mgedmin: I'm not sure what you're referring to, but every time, and you've never got as far as just sending a patch?
[14:21] <awilkins> Every time I see a commit without a log message, I feel that I ☠☢☹ the annoying sod that committed it.
[15:09] <jml> you guys are going to force me to implement 'bzr branches --merged' aren't you?
[15:11] <mgz> are we?
[15:13] <fullermd> Look, I never _said_ I'd kill your puppy if you didn't...
[23:05] <mark06> is it possible to make bazaar recognize mac newlines?
[23:06] <mark06> it's considering the whole file changed when no newline conversion happened in fact


[21:20] <bigpet> did anything change regarding the procedure of getting intels vulkan drivers to run on the xenial preview? I got it working 3 weeks ago
[21:21] <bigpet> but now I tried the same steps and I get a undefined symbol with a sha1 function in mesa
[21:22] <tjaalton> it's broken
[21:22] <tjaalton> still haven't fixed it
[21:23] <bigpet> oh, ok. I was wondering. I recompiled mesa but didn't install the recompiled version just tried to set some env var to the vulkan loader json and got some other error
[21:24] <bigpet> but theoretically just recompiling and then installing the recompiled version could fix it? or is there something else I'd be missing?
[21:24] <tjaalton> a commit needs to be reverted
[21:25] <tjaalton> or figure out why it works on fedora
[21:32] <bigpet> I mean if it's just the sha1 thing, I found irc logs dating back to like october of last months of people disussing it being a bug in the configure script of mesa
[21:32] <bigpet> *of last year
[23:01] <bigpet> neat, got vkcube running
[23:02] <bigpet> thanks for the help