[01:36]  * mwhudson shoves branching-ubuntu into ec2 land (at last!) and goes to lunch
[01:37] <james_w> \o/
[01:37] <james_w> thanks mwhudson
[01:38] <mwhudson> james_w: you can see the diff at https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269 if you want
[01:38] <mwhudson> james_w: shouldn't you be asleep?
[01:38] <james_w> I should
[01:38] <james_w> so I will look tomorrow
[01:40] <mwhudson> cool
[02:22] <mwhudson> thumper: didn't i worry at you about which zcml was executing in scripts vs the webapp?
[02:23] <mwhudson> thumper: looking at the errorreportingutility lookup failures
[02:23] <thumper> mwhudson: yes you did
[02:23] <mwhudson> oh well, use globalErrorReportingUtility and don't worry over much i guess :/
[02:24] <thumper> mwhudson: my branch adds the registration of the utility for scripts
[02:24] <thumper> mwhudson: after talking with flacoste_afk
[02:24] <mwhudson> thumper: ah cool, that's a better solution
[02:24] <thumper> mwhudson: the code should be moved from c.l.webapp to lp.services.error
[02:24] <thumper> but hey
[02:25] <mwhudson> thumper: world hunger also needs fixing
[02:26] <thumper> mwhudson: :)
[02:26] <thumper> my desire to file bugs about ubuntu drops significantly as soon as things work again, even if intermittantly
[02:37] <mwhudson> hmm
[02:37] <mwhudson> the commit message area in https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269 looks seriously ugly
[02:39] <thumper> mwhudson: yes it does
[02:39]  * thumper has a cunning plan
[03:54] <thumper> mwhudson: https://pastebin.canonical.com/23283/
[03:54] <thumper> https://code.edge.launchpad.net/~andrea-bs/launchpadlib/fix-set_data_store/+merge/619
[03:54] <thumper> has a null date review requested
[03:54] <thumper> causing the oops
[03:54] <thumper> now how the hell did that happen?
[03:54] <mwhudson> thumper: that's really olkd
[03:54] <mwhudson> old
[03:55] <thumper> 619? yeah
[03:55] <thumper> I wonder if it slipped through early before we knew what we were doing
[03:55] <thumper> ...
[03:58] <thumper> rejected the proposal and now we have a working active reviews again
[03:58] <thumper> should look into that at some stage
[03:59] <thumper> maybe add a DB constraint
[04:05] <thumper> mwhudson: http://pastebin.ubuntu.com/292816/ ideas?
[04:05] <mwhudson> thumper: apt-get install python-boto ??
[04:05] <thumper> what is boto?
[04:06] <mwhudson> like launchpadlib is to launchpad, boto is to amazon web services
[04:06] <mwhudson> thumper: have you run ec2 on this laptop yet?
[04:06] <thumper> just about to
[04:07] <thumper> mwhudson: does land have --dry-run?
[04:07] <mwhudson> thumper: yes
[04:07] <thumper> heh, it tells me the mp is not approved :)
[04:07] <thumper> if I approve it does that make it r=me or you?
[04:08] <mwhudson> thumper: it looks at the votes
[04:08] <mwhudson> thumper: finish autoapprove already :-)
[04:08] <thumper> mwhudson: help me come up with the db schema and we can land it this cycle
[04:20]  * thumper needs to copy across aws credentials
[05:50] <mwhudson> sigh
[05:51] <mwhudson> so it turns out that writing a simulator for a confusingly concurrent situation is, in and of itself, confusingly concurrent
[05:52] <stub> Can mocker help?
[05:53] <mwhudson> stub: several processes involved so maybe not
[06:10] <mwhudson> hmmm straage, two successive calls to acquireBranchToPull are returning the same branch
[06:32] <mwhudson> well, that's a bug to fix i guess
[06:54] <mwhudson> argh
[06:55] <mwhudson> there's no way to tell the difference between a branch which failed last time that the puller is currently working on and one that failed last time :(
[06:56] <mwhudson> i can think of various stupid ways that you could encode this, but maybe we should just use jobs
[06:59] <mwhudson> right *now* however, i'm going to the pub
[08:21] <adeuring> good morning
[09:15] <mrevell> morning
[09:27] <wgrant> bigjools: I think I am attempting the impossible (establishing the matching publication for a deb's ddeb).
[09:28] <bigjools> wgrant: it should be possible
[09:28] <bigjools> you need to join via the BPR
[09:29] <wgrant> bigjools: I know, but there is no way to identify which of the potentially several BPPHs matches (think overrides).
[09:29] <bigjools> wgrant: the ddeb should not be overridden differently
[09:29] <noodles775> wgrant: let me know if you've got any improvements for bug 450124
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <ubot3`> Malone bug 450124 in soyuz "Improvements to IBuilder.findBuildCandidate()" [High,In progress] https://launchpad.net/bugs/450124
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <mup> Bug #450124: Improvements to IBuilder.findBuildCandidate() <soyuz-build> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/450124>
[09:29] <bigjools> GAH
[09:30] <wgrant> bigjools: Matching based on overrides sounds horribly fragile.
[09:30] <bigjools> who keeps putting bots in here
[09:30] <wgrant> And it's not been donebefore.
[09:30]  * wgrant hunts out jussi01.
[09:30] <bigjools> it's not an override, it's a matching publication in the same series, component and pocket
[09:31] <wgrant> But there's nothing unique about that.
[09:31] <bigjools> apart from the archive
[09:32] <wgrant> I mean, I can easily have duplicate (bpr, archive, distroseries, pocket, component, section)
[09:33] <jussi01> wgrant: just get one of your ops to quiet it for now is probably the best course of action
[09:33] <jussi01> wgrant: I dont have access to ubot3, thats nalioth, but if you just quiet it, it sits here and isnt a problem
[09:33] <wgrant> jussi01: ubot3 says you own it :(
[09:34] <jussi01> wgrant: unfortunately thats because it syncs the factoids from ubottu
[09:34] <wgrant> jussi01: Ahh.
[09:34] <bigjools> wgrant: well yes any model code can screw up the DB, but if it's encapsulated properly and the rules are self-contained then I don't see a problem
[09:35] <wgrant> bigjools: I have a deb and ddeb, in universe. I promote them to main, then demote them again.
[09:35] <wgrant> Now there are three publications for each, but two are duplicates.
[09:35] <wgrant> I now remove the deb, and it tries to drag along the ddeb.
[09:35] <wgrant> But how does it know whihc publication is the right one?
[09:36] <bigjools> wgrant: the one that's PUBLISHED
[09:36] <wgrant> bigjools: But I did all three override changes semi-accidentally in a single publication cycle.
[09:36] <bigjools> or the one with the most recent ID
[09:36] <wgrant> (it has happened)
[09:37] <bigjools> then you need to supersede old publications if you find inconsistencies
[09:37] <wgrant> Inconsistencies?
[09:37] <bigjools> gimme 10 I need to have a call
[09:37] <wgrant> Sure.
[09:49] <jml> hello
[09:50] <maxb> Hi, has anyone else seen failures on    lib/canonical/launchpad/pagetests/webservice/xx-wadl.txt ?
[09:52] <jml> hmm
[09:52] <wgrant> That name is familiar. What sort of failure?
[09:52] <maxb> wadl_schema.validate(wadl) returning False
[09:52] <noodles775> maxb: passes here locally (r9691 on karmic)
[09:53] <maxb> noodles775: How "interesting" :-)
[09:56] <BjornT> maxb: the wadl file is generated automatically, so my guess is that something went wrong generating it
[09:56] <jml> maxb, I get that failure when running the test on the stable branch.
[09:57] <jml> updating download-cache & running 'make build'
[09:59] <jml> still get the error
[10:00] <bigjools> wgrant: ok back
[10:00] <bigjools> so, you just need to take the publication with the most recent ID
[10:00] <bigjools> the publisher should supersede the others
[10:01] <wgrant> bigjools: Even if the latest one is no longer active? That sounds convenient.
[10:01] <wgrant> Although still a bit ew.
[10:01] <bigjools> yeah
[10:02] <bigjools> which makes me think, you might want to check that the publisher will work with debug archives :)
[10:02] <wgrant> Actually, this isn't safe.
[10:02] <wgrant> deb_bpph.supersede() should also supersede the corresponding ddeb.
[10:03] <bigjools> yes
[10:03] <wgrant> This is to handle the case that a package ceases to produce a ddeb.
[10:03] <wgrant> But what if it doesn't cease to produce it?
[10:03] <wgrant> Hmm.
[10:03] <wgrant> I guess it should be safe as long as we only look within the build.
[10:04] <wgrant> Yeah, I guess that will work.
[10:04] <bigjools> I don't quite follow this case
[10:05] <wgrant> I wasn't thinking properly. There is no problem.
[10:05] <bigjools> ok :)
[10:05] <wgrant> It is guessing, but very safely.
[10:05] <bigjools> if we assume the publisher will deal with old publications, taking the most recent one is always safe
[10:06] <wgrant> Right. I had forgotten about other restrictions on the search.
[10:07] <wgrant> Maybe it's not safe. How I hate guessing.
[10:08] <wgrant> I have a deb and ddeb, both with Published publications. I promote them, giving them a new Pending publication each.
[10:08] <wgrant> The publisher runs.
[10:08] <wgrant> It sees that the deb is superseded, and calls deb_bpph.supersede()
[10:08] <wgrant> The Pending ddeb publication screams and dies.
[10:08] <wgrant> This is not correct behaviour.
[10:09] <wgrant> s/deb_bpph/deb_old_bpph/
[10:10] <jml> bigjools, are there docs anywhere describing how the buildmaster works?
[10:10] <wgrant> Ha ha ha.
[10:10] <wgrant> jml, this is Soyuz.
[10:10] <bigjools> ROFL
[10:11] <jml> fair point.
[10:11] <noodles775> buildd-dispatching.txt ?
[10:11] <jml> wgrant, do _you_ have docs describing how the buildmaster works?
[10:11] <bigjools> thge buildmaster was oringally hacked up by the early LP devs (daniel etc) and more recently re-written by Celso in a hurry
[10:11] <bigjools> yes, the doctest is the closest we have
[10:11] <wgrant> jml: Although I know it internally fairly well now, I only have docs on how to run it.
[10:11] <jml> yeah, I remember him being in a hurry. :)
[10:12] <bigjools> when wasn't he? :)
[10:13] <bigjools> jml we have a plan on how to generalise the buildmaster side but it was written before the re-write of the scanner
[10:13] <wgrant> bigjools: Any ideas on the above example?
[10:13]  * bigjools missed that, just a sec
[10:13] <jml> bigjools, is the plan written down?
[10:13] <wgrant> https://dev.launchpad.net/Soyuz/Specs/BuilddGeneralisation
[10:13] <jml> I might have a poke around the code once I do today's CHR duties & finish off this damn imports branch and review al-maisan's branch.
[10:13] <jml> I guess that means tomorrow.
[10:14] <jml> wgrant, thanks.
[10:14] <bigjools> wgrant: why would it scream and die?
[10:14] <maxb>     <wadl:method name="PUT" id="HostedFile-put"/>
[10:14] <maxb>     <wadl:method name="DELETE" id="HostedFile-put"/>
[10:14] <maxb> ^ Well, oops :-)
[10:15] <wgrant> bigjools: Because it has the latest ID, so gets superseded.
[10:15] <bigjools> jml: the code is pretty bad, most of it was written before we had real coding standards.  Feel free to hassle me to explain stuff.
[10:15]  * al-maisan takes a peek at lp:~jml/launchpad/upload-permission-joy
[10:16] <bigjools> wgrant: ok I see
[10:18] <bigjools> wgrant: if the last publication is pending then it should be clever enough to go to the previous one
[10:19] <wgrant> bigjools: This is getting more and more into inaccurate guess territory, and sounds like it will go horribly wrong if there are multiple pending publications at once.
[10:19] <jml> bigjools, I remember someone asking me for a generic sftp server based on the one we have in codehosting...
[10:19] <maxb> I'd like one of those too :-)
[10:19] <jml> bigjools, I guess that's for a different thing
[10:20] <bigjools> jml: yeah we could do with replacing poppy
[10:20] <jml> maxb, remind me to actually put license text in txsshserver one of these days.
[10:21] <bigjools> wgrant: there is already code like this in the publisher
[10:21] <maxb> jml: Your verification of the xx-wadl.txt failure was on jaunty/karmic? py2.4?
[10:21] <bigjools> wgrant: I suggest we try and map out all of the operations that can happen like this, and work through them carefully
[10:22] <jml> maxb, karmic.
[10:22] <jml> maxb, ./bin/test -1cvvt xx-wadl.txt in stable branch
[10:23]  * maxb wonders if this is a mysterious jaunty vs. karmic oddity
[10:23] <jml> maxb, I'm deleting the unversioned files in lib/canonical/launchpad/apidoc and running the test again.
[10:23] <maxb> jml: the wadl tested in the test is generated on the fly
[10:24] <jml> maxb, ... as my experiment just demonstrated :)
[10:25] <maxb> I'll have to dig out a jaunty system and retest there
[10:27]  * bigjools laughs a lot at https://answers.launchpad.net/soyuz/+question/85773
[10:29] <bigjools> jml --^
[10:33] <maxb> How does the wadl generation actually work? There is stuff in the comments in the wadl which I don't find by grepping anywhere in the source?!
[10:36] <jml> bigjools, heh heh.
[10:36] <jml> bigjools, what's the blueprint URL?
[10:36] <wgrant> maxb: Possibly stuff in lazr.restful(client)?
[10:36] <bigjools> jml: I haven't done one yet, I will sort it out soon
[10:38] <jml> bigjools, no worries.
[10:38] <bigjools> jml: I cleaned up the buildd manager one yesterday as that's more important to me right now :)
[10:39] <maxb> Hmm... looks like the bugged wadl is copied verbatim from wadl-root.py in lazr.restful
[10:39] <jml> bigjools, ahh sure.
[10:39] <jml> bigjools, I can just register the blueprint and link it to the already-written spec
[10:40] <bigjools> jml: I can do it, it's on my list of things to do anyway
[10:41] <jml> bigjools, ok.
[10:41]  * jml would really love to scrub the launchpad-code blueprints at some point
[10:41] <jmux> Hi - is there a good way to debug traversal errors? I'm getting a backtrace from base-layout-macros.pt for "json" and I didn't really find a way to find the original error.
[10:43] <jml> hmm
[10:43] <jml> jmux, nothing leaps to mind.
[10:43] <jml> https://dev.launchpad.net/Debugging might help.
[10:44] <maxb> eww. lazr.restful has no tags :-(
[10:44] <james_w> does logger.exception in LP log sys.exc_info() or similar?
[10:45] <jml> james_w, it really depends.
[10:46] <james_w> 258	+ except:
[10:46] <james_w> 259	+ ok = False
[10:46] <james_w> 260	+ self.logger.exception(
[10:46] <james_w> 261	+ "Unexpected error checking %s!", db_branch)
[10:46] <jml> james_w, that behaviour comes standard in Python :)
[10:46] <james_w> I'd like to know that this logs the exception, otherwise we are going to be scratching our heads when something goes wrong
[10:46] <jml> james_w, http://www.python.org/doc/2.4.4/lib/node341.html
[10:47] <james_w> ah, so it does
[10:47] <wgrant> eg. try to catch an exception and call logging.exception("blah")
[10:47] <jml> james_w, I'll need more context
[10:47] <james_w> thanks, will be useful in future
[10:47] <jml> james_w, because it's the log _handlers_ that really make the difference
[10:47] <james_w> I'm looking at https://code.edge.launchpad.net/~mwhudson/launchpad/branching-ubuntu/+merge/13269
[10:47] <james_w> def checkNewBranches(self):
[10:48] <james_w> so in this case logger comes from LaunchpadScript
[10:49] <jml> james_w, which in turn uses canonical.launchpad.scripts.logger.logger
[10:49] <jml> james_w, which uses a default Python StreamHandler
[10:50] <jml> which is fine.
[10:51] <james_w> cool, thanks for checking
[10:52] <jml> np
[10:52] <jml> thanks for asking :)
[11:12] <wgrant> bigjools: http://williamgrant.id.au/f/1/2009/ddeb-supersedure-cases.html describes most supersedure cases, I think.
[11:15] <bigjools> wgrant: ok, thanks, I'll look through it in a bit
[12:37] <jml> bigjools, the buildd-generalizing spec is for running arbitrary jobs, right
[12:37] <bigjools> jml: yes
[12:38] <jml> bigjools, is there another spec for generalizing across machine type? (physical machine, local vm, ec2 instance etc)
[12:38] <bigjools> there's a bug
[12:38] <bigjools> well
[12:39] <bigjools> there's a bug for building any type of arch/virtual on the existing builders
[12:39] <bigjools> there's no spec for going as far as what you say there
[12:39] <jml> ok, thanks.
[12:40] <bigjools> which I think is slightly crazy BTW :)
[12:40] <jml> perhaps it is.
[12:41] <jml> what I'm actually worried about is build capacity
[12:41] <bigjools> yes, me too
[12:41] <jml> s/worried/thinking/
[12:41] <bigjools> we'll need a lot more builders
[12:41] <jml> yeah.
[12:41] <bigjools> we'll also need some more optimisation done to the buildd-manager
[12:41] <bigjools> because finished builds are uploaded synchronously
[12:42] <jml> oh right, I remember talking to cprov about that.
[12:42] <bigjools> it's a very hard problem to solve
[12:42] <elmo> err, why?
[12:42] <bigjools> error conditions mainly
[12:43] <bigjools> I forgot the exact details
[12:43] <elmo> mmk
[12:43] <elmo> I may be overlooking something, but Debian has done uploads asynchronously for over a decade
[12:43] <jml> bigjools, ISTR it as more being a case of getting round to it.
[12:44] <bigjools> well don't let me stop you fixing the buildd-manager then ;)
[12:44] <elmo> it just means the extra section of the state machine where a package can be either 'uploaded' or 'installed' (i.e. the upload completed successfully) and you just have to make sure nothing stays in 'uploaded' for overly long
[12:44] <elmo> also, why are we worried about capacity?
[12:44] <bigjools> ah I remember more about this now
[12:44] <jml> dammit. etsu lunch again.
[12:44] <bigjools> the upload processor is single-threaded
[12:44] <wgrant> But it's run in a subprocess.
[12:45] <bigjools> with a lock
[12:45] <wgrant> Oh. Right.
[12:45] <bigjools> and no, it's not a subprocess when uploading binaries
[12:45] <wgrant> Then why does the builddmaster have a config option for the command to run to upload the binaries?
[12:45] <bigjools> NFI
[12:46] <wgrant> It spawns process-upload.py.
[12:46] <wgrant> This is why it takes /forever/.
[12:46] <bigjools> hmmm last time I looked it didn't do that
[12:47] <bigjools> but anyway, it's still has a bunch of issues that prevent it running more than one copy at once
[12:47] <jml> I am full of unhappiness and empty of food.
[12:47] <jml> brb.
[12:47] <bigjools> and there are other issues with the buildd-manager just dumping the binary in an upload queue - for example how to deal with upload failures
[12:47] <wgrant> bigjools: lp.buildmaster.buildergroup.BuilderGroup.buildStatus_OK certainly seems to spawn a subprocess.
[12:54] <jml> bigjools, how do you deal with them now?
[12:54] <bigjools> it marks the build as failed
[12:56] <jml> bigjools, I see.
[12:56] <bigjools> which the upload processor can't do, since it doesn't know about the build
[12:57] <wgrant> It does, actually.
[12:57] <jml> bigjools, you could write the builder asynchronously
[12:57] <wgrant> The upload processor sets the build to Successfully Built, and attaches the binaries.
[12:57] <wgrant> If it completes successfully, the buildmaster attaches the build log, sets the finish time, unassigns the builder, deletes the buildqueue.
[12:58] <wgrant> If it fails, it attaches the upload log and marks the build as Failed to Upload.
[12:58] <wgrant> But the upload processor does (and has to) know about the build.
[13:11] <bigjools> wgrant: of course, you're right.  I think I need more coffee.
[14:33] <sinzui> EdwinGrubbs: barry: bac: standup in two minutes
[14:39] <EdwinGrubbs> sinzui: standup?
[14:55] <barry> reviewers, interested developers, and lurkers: ameu reviewers meeting -> #launchpad-meeting in 5m
[15:00] <barry> ameu reviewers meeting -> #launchpad-meeting
[15:04] <barry> abentley: -> #launchpad-meeting.  i'm about to talk about pipelines :)
[15:48] <Fox_1_> hi all
[15:49] <Fox_1_> people do you know the place where I can get documentation about putting Launchpad on Debian
[15:49] <Fox_1_> ?
[16:00] <sinzui> Fox_1_: you are in unexplored territory. I am not aware is has been done, let alone documented
[16:01] <sinzui> bac: ready for our call?
[16:01] <bac> yes
[16:46] <jml> leonardr, were you making a trusted client for the API?
[16:46] <leonardr> jml: yes, it is on my list of things to do, but pretty far down the list
[16:46] <leonardr> i can point you to the bug if you want to take over
[16:47] <jml> leonardr, what if I don't want to take over but just want to leer speculatively, one day dreaming of having enough time to want to take over?
[16:48] <leonardr> i think pointing you to the bug would still be appropriate
[16:48] <leonardr> it might not be as difficult as you think, i did write the client, i just didn't write the tests for it
[16:48] <jml> heh.
[16:49] <jml> leonardr, in that case, please point me to the bug report.
[16:49] <jml> I'm actually planning on working with launchpadlib on Canonical time during the Bazaar sprint in November.
[16:49] <jml> so I might do trusted client work on the plane or something. maybe.
[16:52] <leonardr> jml: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/387297
[16:52] <mup> Bug #387297: manage-credentials should not ask for Launchpad password directly <ubuntu-dev-tools (Ubuntu):Triaged> <https://launchpad.net/bugs/387297>
[16:52] <ubot3`> Malone bug 387297 in ubuntu-dev-tools "manage-credentials should not ask for Launchpad password directly" [Medium,Triaged]
[16:52] <leonardr> https://code.launchpad.net/~leonardr/launchpadlib/trusted-client
[16:52] <mup> Bug #387297: manage-credentials should not ask for Launchpad password directly <ubuntu-dev-tools (Ubuntu):Triaged> <https://launchpad.net/bugs/387297>
[16:53] <jml> I thought we asked ubot3 to leave. :(
[16:53] <jml> leonardr, thanks.
[17:06] <intellectronica> bigjools: halp. i don't know anything about upload permissions. can you give me some pointers? do you know how the driver permission for a distroseries is calculated?
[17:06] <bigjools> intellectronica: I don't know that, I only know about upload permissions
[17:08] <jml> intellectronica, for a distroseries?
[17:08] <jml> hm
[17:08] <jml> wait. I'm focusing.
[17:08] <intellectronica> jml: nm, i think i just found out
[17:08] <jml> intellectronica, glad to hear it.
[18:04] <mrevell> night all
[19:21] <barry> danilos: ping
[19:27] <Ursinha> barry: danilos is ill today, and it's pretty late for him, I don't think he'll answer in a reasonable time :)
[19:28] <barry> Ursinha: okay, thanks.  danilos hope you feel better soon!
[21:05]  * jgay attempts to install launchpad.
[21:10] <jgay> Does anybody know if I will likely get a successful build and install on intrepid?
[21:11] <mwhudson> jgay: unlikely
[21:11] <mwhudson> jgay: nothing fundamental, but some of the packages needed haven't been built for intrepid i think
[21:12] <jgay> mwhudson: ok, thanks. I'll see how far I get before things start to breakdown.
[21:16] <rockstar> mwhudson, abentley, who's hosting today?
[21:16] <mwhudson> rockstar: good question!
[21:16] <rockstar> mwhudson, would you like me to?
[21:16] <abentley> rockstar: Go for it.
[21:16] <mwhudson> rockstar: sure
[21:30] <rockstar> The windmill tests don't run concurrently as threads, do they?
[21:41] <barry> rockstar, mwhudson thumper's off line today.  do you still want to meet today?
[21:41] <rockstar> barry, yeah, abentley said today was pretty exciting.
[21:41] <barry> rockstar: okay cool.  i'll update the minutes and we can meet in 19m
[21:42] <rockstar> barry, ack
[21:42] <mwhudson> barry: ok
[22:01] <barry> rockstar, mwhudson, wgrant  -> #launchpad-meeting
[22:12]  * rockstar goes on a short walk
[22:50] <wgrant> intellectronica: jml refactored the upload permission stuff recently, so it should be pretty easy to remove the duplicated logic from the bug nomination permissions.


[04:42] <lotuspsychje> good morning to all
[05:33] <lotuspsychje> wafflejock and cfhowlett morning!
[05:34] <cfhowlett> heyheyhey!
[05:36] <wafflejock> lotuspsychje, hey just had some strangeness with my connection actually getting late here, but g'morning
[07:40] <lordievader> Good morning.
[11:37] <BluesKaj> Hey folks
[11:56] <lordievader> o/
[14:09] <lotuspsychje> afternoon to all
[14:11] <lordievader> o/
[14:11] <lotuspsychje> lordievader: hello mate
[14:11] <lotuspsychje> all ok?
[14:15] <lordievader> Jup, trying to install Plasma 5.3.1
[14:16] <lotuspsychje> nice!
[14:16] <lotuspsychje> http://www.omgubuntu.co.uk/2015/04/kde-plasma-5-3-released-heres-how-to-upgrade-in-kubuntu-15-04
[14:17] <lordievader> That's 5.3 not 5.3.1 ;)
[14:17] <lotuspsychje> yeah
[14:18] <lordievader> sgclark has just finished packaging 5.3.1 and she needs testers.
[14:30] <lotuspsychje> lordievader: and your the pioneer to test it first :p
[14:38] <lordievader> lotuspsychje: Nope, soee beat me to it ;)
[15:06] <lotuspsychje> EriC^^: :p
[15:06] <EriC^^> lotuspsychje: :P
[15:06] <lotuspsychje> EriC^^: welcome, what can we do for you
[15:06] <lotuspsychje> :p:p
[15:06] <EriC^^> :P
[15:07] <EriC^^> xP
[15:07] <lotuspsychje> EriC^^: lordievader has waked up to help you on qmeu
[15:07] <lotuspsychje> EriC^^: or you dont play with snappy anymore
[15:08] <EriC^^> nah i didn't play with it anymore
[15:08] <lotuspsychje> kk
[15:08] <lordievader> lotuspsychje: What?
[15:08] <lotuspsychje> lordievader: oh lordie has played with snappy, and had a question on qemu for you, but its not needed anymore :p
[15:08] <lotuspsychje> EriC^^
[15:09] <lordievader> Err, I'm no qemu expert. I like the program. But I am in no way an expert.
[15:13] <lotuspsychje> http://linux.softpedia.com/blog/All-Supported-Ubuntu-OSes-Receive-Update-for-OpenLDAP-Vulnerabilities-482731.shtml
[15:13] <lotuspsychje> so much security holes been patched these days
[15:13] <lotuspsychje> is there any channel you guys know, that handles ubuntu security?
[15:14] <lotuspsychje> or report an exploit?
[15:16] <EriC^^> nice


[07:53] <hallyn> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1531747   more overlay fun
[07:53] <hallyn> too wiped at this point to look at the source
[07:59] <mjg59> hallyn: Oh ouch
[08:11] <hallyn> mjg59: oh it's only in a user ns
[08:11] <hallyn> i failed to point that out in the bug, bad me
[08:19] <mjg59> hallyn: That's especially weird
[08:22] <hallyn> yeah a bit funky :)
[08:22] <hallyn> i'll look at the src tomorrow in the unlikely event apw doesn't have it sorted out :)
[08:22]  * hallyn out
[16:43] <manjo> apw, you have a few mts for me to pick your brain about something related to using root=PARTUUID ?
[16:43] <apw> manjo, best to just ask, you never know who might know
[16:43] <manjo> :)
[16:44] <manjo> I have a UEFI system and form the uefi shell if I say root=PARTUUID=<partuuid> it does not seem to find root but if I say root=/dev/disk/by-partuuid/<partuuid> it finds root and mounts it
[16:44] <manjo> in the former case I get an initramfs prompt
[16:45] <manjo> comments in kernel source says  6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
[16:45] <manjo> 194 * unique id of a partition if the partition table provides it.
[16:46] <manjo> as a valid syntax for root=
[16:47] <manjo> or acceptable "root=" formats ... any ideas why root=PARTUUID= does not work but root=/dev/disk/by-partuuid/<partuuid>  works?
[16:49] <manjo> you can find the valid acceptable syntax under init/do_mounts.c
[16:51] <manjo> I have tried MSDOS and GPT partuuids but neither work with PARTUUID=
[16:54] <manjo> and I am passing initramfs .. so thatis not the issue
[16:55] <manjo> could it be that initramfs does not fetch these identifiers ?
[17:00] <manjo> could this be a regression in initramfs-tools ?
[17:00] <manjo> anyone know ?
[17:02] <JanC> sure it's not UUID instead of PARTUUID ?
[17:03] <manjo> JanC, I have tried both  UUID and PARTUUID .. UUID If initrd is not used and partuuid if using initrd .. is waht I gather from the source
[17:05] <apw> because you have an initramfs isn't it that which is parsing thigns like UUIDs, and so it would need to support them i think
[17:05] <apw> which is why the by-partuuid works, because udev is running in the initrd to make them
[17:05] <TJ-> manjo: as apw just said; initramfs-tools function resolve_device() doesn't support PARTUUID
[17:06] <manjo> that is s bug then ?
[17:06] <manjo> coz it is supposed to as per kernel source
[17:06] <apw> initramfs-tools isn't meant to do anything because there are comments in the kernel ?
[17:06] <apw> you have an initrd, the kernel useds the initrd as root, it is happy
[17:07] <apw> it has no concept of the real root you mount later by hand in the initrd and then chroot into
[17:07] <apw> that is just you messing about with root etc, it doesn't really know that is being found, mounted and switched to
[17:07] <apw> now, why do you care if PARTUUID does or does not work
[17:08] <apw> should you not be gettting the real UUID of the contents of that parittion and using that
[17:08] <apw> as that (if it has a filesystem on it) will have a separate UUID which is more normal to want to boot
[17:08] <apw> so if you move the contents to a new drive you still mount the right contents
[17:09] <manjo> apw, fair enough .. but the kernel supports partuuid as a valid syntax
[17:09] <apw> and
[17:09] <apw> ?
[17:09] <apw> it isn't a useful syntax really, you _should_ be using the filesystem uuid
[17:10] <manjo> apw, AH! I found a bug ... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801154
[17:10] <manjo> apw, that was fixed in December ..
[17:10] <apw> then we have that fixed in xenial
[17:10] <apw> that still doesn't make it sensible
[17:11] <TJ-> it strikes me as a hidden gotchya! partition may contain no valid file-system
[17:11] <apw> and in fact we have 0.120 in wily as well
[17:12] <JanC> well, I guess it's more of a feature request for special cases than a bug fix also then?  :)
[17:12] <apw> i can't see any valid use for that other than having a filesystem in there which does not have a UUID, which ... i can't think of one off hte top of my head
[17:14] <TJ-> The bug seems to be more aimed at taking a pass-through from a bootloader that may not know file-systems
[17:14] <manjo> yeah like when booting from shell prompt on efi systems
[17:14] <manjo> ie command line
[17:15] <apw> when you are typing in random strings nayhow to make it work, hrm
[17:15] <apw> manjo, well either way the bug is fixed so you should have no problems right
[17:15] <manjo> apw, yes looks like it .. I will update my initramfs-tools to latest and see if that makes it work
[17:16] <apw> manjo, that version has been default for a very long time
[17:16] <manjo> oh as per the bug report the fix went to debian on Sun, 27 Dec 2015
[17:17] <apw> manjo, then i don't thnk it can be in 120
[17:17] <TJ-> 0.121~rc1
[17:17] <manjo> apw, ok so I will need to wait for you guys to referesh ?
[17:17] <apw> that is more believeable
[17:18] <apw> manjo, i am waiting for 1.121 to leave -rc and will merge that when it doe
[17:18] <apw> s
[17:18] <apw> manjo, if it is urgent then i can prolly pull that one fix
[17:18] <manjo> ok as long as xeniel has it coming .. I am ok ... I can ask the people to wait for a bit
[17:19] <apw> manjo, no idea as to timescales tho. for debian
[17:19] <manjo> apw, if you can make that patch available in xenial by end of Jan ... I can hold down the fork here
[17:21] <apw> manjo, can't make any guarentees of that nature against debian, so ...
[17:21] <apw> manjo, you need to file a bug against initramfs-tools in xenial and link the bug report, and assign it to me, and let me knwo the bug# here
[17:21] <apw> (link the debian one)
[17:21] <manjo> yep doing as we speak you read my mind
[17:26] <manjo> apw, https://bugs.launchpad.net/initramfs-tools/+bug/1531928
[17:50] <dobey> hi. anyone have ideas on how to figure out why the lowlatency kernel hangs, but only when intel video is driving the monitor at 30Hz, and not at 60Hz?
[18:04] <apw> dobey, hangs hard with no output?  have you tried sysrq ?
[18:05] <dobey> apw: yeah, just all of a sudden the system would be locked hard, and i can't even ssh in
[18:05] <dobey> didn't try sysrq
[18:05] <dobey> (totally forgot about sysrq actually)
[18:08] <JanC> IME the Intel video drivers are really badly tested
[18:09] <dobey> i won't disagree with that. this certainly isn't my only problem with intel, but it is a more important one to me
[18:09] <dobey> hmm, actually, i'm not even sure if i have a sysrq on my keyboard
[18:10] <JanC> PrtScr ?
[18:10] <dobey> i have a happy hacking lite 2
[18:11] <JanC> PrtScr is the same key, but the SysRq label is sometimes left off
[18:11] <JanC> and on some small form factor / laptop keyboards you might need Fn
[18:11] <dobey> well, most of the function key text has been worn off, so i'm not sure
[18:12] <dobey> ah, ok, found prntscr
[18:13] <dobey> https://mjbdiver.files.wordpress.com/2011/09/304964-full.gif
[18:13] <dobey> hah :)


[00:02] <bregma> well, I'm going to try again: desktop Unity 8 has been dead in the water for a while, segfaulting in the Intel driver on uninitialized buffers when the Mir server does a glClear()
[00:03] <bregma> currently logged as https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1336854
[00:03] <bregma> wit han attached stack trace
[00:03] <bregma> I'm looking for suggestions on what may have changed in the stack in the last week or two, and/or suggestions on how to chase down more information to help narrow the cause down
[00:03] <RAOF> bregma: Yeah, I noticed that yesterday.
[00:04] <RAOF> It's going to be a mesa problem.
[00:04] <bregma> unity-system-compositor continues to run fine, so it could be something wacky higher in the stack, it's under a lot of churn lately too
[00:05] <RAOF> usc is fine because it's not using the Mir EGL platform.
[00:05] <RAOF> I suspect that you first saw this on the 23rd?
[00:05] <RAOF> That's when Maarten uploaded hte new mesa.
[00:05] <bregma> sounds suspicious
[00:06] <bregma> if I can perhaps revert to an older version, that would point the finger
[00:06] <RAOF> Give it a whirl.
[00:06] <RAOF> I'll poke around in the mesa code.
[00:34] <bregma> FTR, reverting libgl1-mesa-dri to 10.1.3-0ubuntu0.1 fixes the segfault
[00:42] <RAOF> Thanks. I'm installing a debug build, so it shouldn't be long before working out what's wrong and fixing it.
[01:34] <RAOF> Ah! There's the problem.
[01:54] <RAOF> bregma: Mesa 10
[01:55] <RAOF> bregma: Mesa 10.2.1-2ubuntu3 fixes your problem. Enjoy!
[02:57] <duflu> racarr: What's a prompt session?
[03:07] <racarr> duflu: trust sessions
[03:07] <racarr> ;)
[03:07] <racarr> https://wiki.ubuntu.com/Security/TrustStoreAndSessions
[03:08] <racarr> sort of explains how the name prompt session
[03:08] <racarr> comes about
[03:09] <duflu> racarr: OK then...
[06:25] <RAOF> Oh, whoops. We appear to call all manner of un-signal-safe functions in the emergency cleanup signal handler.
[06:25] <RAOF> Including allocations!
[06:48] <duflu> RAOF: Sounds a bit silly. Incidentally I mentioned we shouldn't ever do such a thing in a branch that's pending... https://code.launchpad.net/~vanvugt/mir/fatal-error/+merge/219471
[06:48] <RAOF> Yeah, reviewing that is what brought me to look at the emergency cleanup bit.
[06:49] <duflu> RAOF: Well the latest emergency cleanup stuff I don't think I reviewed either
[06:49] <duflu> The plate was piled too high in May
[06:51] <duflu> Hmm Chrome in Trusty has annoyingly bad tearing (diagonal/triangles)... I wonder if that's Chrome or Compiz
[06:52] <duflu> If it's Compiz then of course we don't care any more
[06:53] <RAOF> I think it's Chrome; it started with the Aura drop, IIRC.
[06:53]  * duflu looks up Aura
[06:54] <duflu> Oh, nice one Google... they really should be able to do better than that
[07:12] <alf_> RAOF: duflu: where are we doing allocations in the emergency cleanup handlers?
[07:12] <duflu> No idea
[07:12]  * duflu points to RAOF
[07:13] <RAOF> alf_: You assign to a vector; that's at least potentially doing allocation.
[07:13] <duflu> Oh that will do it
[07:13] <RAOF> Also, pthreads isn't threadsafe, right?
[07:13] <duflu> Depending on the method...
[07:13] <duflu> RAOF: Umm, what?
[07:13] <RAOF> Ahem.
[07:13] <RAOF> Signalsafe
[07:13] <RAOF> 'cause we also lock a mutex in there.
[07:14] <duflu> RAOF: It never used to be... Signals could arrive in _any_ thread but should arrive in just one. So unpredictable but safe I think
[07:14] <RAOF> Right, but what happens if pthread_lock gets interrupted by a signal?
[07:14] <duflu> If you want to determine the thread to use then pthread_kill
[07:15] <alf_> RAOF: duflu: at vector, right, that's easy to fix I will take a look
[07:15] <duflu> RAOF: "If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted."
[07:15] <duflu> [http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_lock.html]
[07:16] <RAOF> I'm not sure that covers my concern.
[07:16] <RAOF> But signal-safety documentation isn't the best :)
[07:17] <duflu> RAOF: Well that's just the spec. Everyone has their own implementation
[07:17] <RAOF> No, I mean that it's not clear that documentation covers the case I'm concerned about.
[07:17] <alf_> RAOF: "The mutex functions are not async-signal safe. What this means is that they should not be called from a signal handler. In particular, calling pthread_mutex_lock or pthread_mutex_unlock from a signal handler may deadlock the calling thread."
[07:17] <alf_> RAOF: :)
[07:18] <RAOF> alf_: Ding!
[07:18] <duflu> Certainly, locking in signal handlers is also bad
[07:18] <duflu> Then again without such bugs I would have received more core files in my life time than I have
[07:18] <RAOF> Basically, the set of things you can _safely_ do in a signal handler is poke at memory addresses :)

[07:19] <duflu> I remember plenty of stack traces from customers showing code hanging in a signal handler after a crash :/
[07:20] <RAOF> Yup.
[07:20] <RAOF> It's disturbingly easy to deadlock in one.
[07:21] <alf_> duflu: RAOF: We can drop the locks, making it clear that you are not to call the emergency cleanup while concurrently adding a handler
[07:21] <alf_> duflu: RAOF: plus the emergency cleanup is a best effort cleanup
[07:22] <duflu> alf_: If we can guarantee the signal handler is only called once then I guess reduced locking is OK
[07:22] <RAOF> Well, the signal handler isn't reentrant.
[07:22] <RAOF> (By default)
[07:22] <RAOF> But we should ensure that we don't do anything that's highly likely to deadlock there :)
[07:23] <duflu> Also easy to do by accident though... if someone else asks the signal() function for the existing handler (yours) and calls it
[07:23] <RAOF> ?!
[07:23] <RAOF> Why on earth would they do that?+
[07:24] <alf_> duflu: RAOF: and if we get rid of the locking requirement we might as well drop the vector copy
[07:24] <duflu> RAOF: 3rd party libraries or general dealing with bad APIs where you need a signal handler
[07:24] <RAOF> duflu: Oh, as in wrapping a signal handler?
[07:25] <duflu> RAOF: I think that's one case
[07:25] <duflu> alf_: If the vector never gets too big then an array is fine
[07:26] <RAOF> alf_: Yup. We could, of course, make it a signal-safe data structure, but given that it's basically write-once I think we can happily read without locking.
[07:28] <duflu> If it's write-once and that's guaranteed to happen before the read there is no race. And Helgrind etc will be happy without locking
[07:32] <alf_> duflu: RAOF: it says "The mutex functions are not *async-signal* safe", but the signals we handle with emergency cleanup are synchronous
[07:34] <RAOF> Unless someone sends us SIGsomething :)
[07:35] <duflu> Heh, bypass must be awesome if it's still doing my head in a year later
[18:09] <dobey> who would be best to bug to maybe get a crash in libmirclient on application exit on the phone fixed asap today?
[18:10] <AlbertA> dobey: bug #?
[18:10] <AlbertA> dobey: which image# ?
[18:11] <AlbertA> racarr: can you take a look at https://code.launchpad.net/~albaguirre/unity-system-compositor/no-inactivity-handling-desktop/+merge/225537
[18:11] <AlbertA> racarr: it's fairly small :)
[18:11] <dobey> AlbertA: on 111, but lokos like it's been happening for a little while. i haven't filed a bug yet, the reports on errors.u.c failed to retrace, so there's no "create a bug" link for them. trying to determine the best way to file the bug
[18:12] <AlbertA> dobey: so any application exiting crashes?
[18:12] <dobey> should i just file it with the top of the stack trace and a link to the errors?
[18:12] <AlbertA> dobey: what's the fastest way to reproduce?
[18:12] <dobey> AlbertA: any using the mir backend of qt/qml afaict. open clock app, wait a few seconds, and close it, and there should be a crash report in /var/crash/
[18:13] <dobey> https://errors.ubuntu.com/problem/6552ba4342afeb93d20e22711ac36f655cd885d8
[18:14] <dobey> or go to online accounts, then hit back and should result in in a crash report too
[18:16] <AlbertA> dobey: I couldn't access that link
[18:16] <AlbertA> dobey: but I'll take a look, if you can submit a bug # that would be great
[18:17] <dobey> AlbertA: sure. should i just copy/paste the top of the stack trace in the bug?
[18:17] <AlbertA> dobey: sure
[18:18] <dobey> ok will do
[18:21] <racarr> AlbertA: Sure
[18:28] <dobey> AlbertA: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1337481
[18:59] <racarr> dandrader|afk: greyback: https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320
[18:59] <racarr> err whoops
[18:59] <racarr> but what is up with line 427
[19:01] <racarr> It looks like, state_before_hiding is being used to save the state across minimize state changes
[19:01] <racarr> but why initialize to MAXIMIZED? There must be a default or currentstate
[19:01] <greyback> racarr: indeed. I can't say. Hope dandrader|afk can reply
[19:02] <racarr> anyway good besides that
[19:03] <racarr> if he doesnt come back soon ill leave some comments
[19:03] <racarr> on launchpad
[19:03] <greyback> racarr: please do, and I'll try to fix (daniel off on hols at eod today)
[19:04] <racarr> :) sounds nice
[19:04] <racarr> racarr off on holidays in 51 days
[19:04] <racarr> lol
[21:43] <dandrader> racarr, right, I'm just initializing it to something
[21:44] <dandrader> racarr, the first time you call show(), the state will be set to this value
[21:46] <dandrader> racarr, which is what we want on phablet anyway
[21:46] <dandrader> racarr, "restored" windows make no sense there
[21:48] <dandrader> racarr, and the "beautiful" papi API is not expressive enough at the moment for the user to set the mir surface states properly. eg: "papi::window::show() == mir::surface::set_state(maximized) or mir::surface::set_state(restored?
[21:48] <dandrader> racarr, so I don't bother with this sad situation and just let it go maximized, which is what we want
[21:48] <dandrader> and now I'm repeating myself...
[21:49] <dandrader> racarr, so if you wanna to fix thing you would have to rewrite that papi api to be a 1-to-1 mapping of mir
[21:49] <dandrader> racarr, which is a waste of developer time IMHO
[21:51] <dandrader> and would also require changing papi users: ie, qtubuntu