[05:41] <cpaelzer> good morning
[06:18] <mrparanoid> im having some trouble with loading a preseed file from an iso image, I can see the preseed file on the iso and it is also in the append to call the file, however it isn't working and the UI install prompts are still appearing.. is there anything else that needs to be set/configured for it to load?
[06:26] <eatingthenight> hello, anyone know a trick to get settings changes made in /sys to take effect faster. in my case I am setting the cpu to performance mode and it takes about 40 seconds until it actually registers that it's using max cpufreq.
[06:26] <eatingthenight> can you trigger this to happen faster?
[09:46] <fishcooker> how to know the detail of these 2 lines information of 49 packages can be updated and 28 updates are security updates ?
[09:48] <ikonia> fishcooker: I don't know what you are asking
[10:01] <M3mphiZ> How can i get the welcome message telling me the last login time, updates, restart required, etc. wihtout logging out and in again?
[10:37] <cpaelzer> M3mphiZ: some are executed as needed - but mostly you get what you need from man update-motd
[10:37] <cpaelzer> M3mphiZ: e.g. parts are in /var/run/motd.dynamic
[10:37] <cpaelzer> M3mphiZ: do you want to see "what you had on login" or to regenerate it as t would be now?
[10:38] <cpaelzer> Since this is a thing multiple programs can plug in the output can differ and be modified
[11:09] <cpaelzer> M3mphiZ: and as addendum - for e.g. the last login "lastlog" gives you way wider overview than just motd
[14:16] <hallyn> cpaelzer: re libvirt, i'm not reading the bug emails closely (and am driving all day today), but if i skimmed them correctly, the weird packages in question were part of trying ot get back in sync with debian;
[14:16] <hallyn> so as you work to fix whatever is broken, i'd recommend making sure to either go in the direction of completing that or ditch the idea entirely.
[14:17]  * hallyn out
[14:25] <winem_> hey guys, (sorry if you read my question in #ubuntu as well, but I guess this is the right place to place it) I have to setup a postgresql or mysql / mariadb / galera db cluster. requirements are that failover and a virtual shared IP is supported. some years ago I used a combination of mysql, heartbeat, pacemaker to achieve this. but I did not use such a setup in the last few years. so which db (postgresql or mariadb / galera)
[14:25] <winem_> would you recommend and why? I guess this can save me some googling. requirements: a couple of reads and about ~20k writes per minute (so they are not that high...)
[15:19] <cpaelzer> hallyn: thank you
[15:19] <cpaelzer> hallyn: yeah it is about completing the move to align with Debian
[15:20] <cpaelzer> hallyn: I'm fine cleaning up, just the list for this cycle seems to get longer and longer
[15:20] <cpaelzer> due to myself being able to identify more things
[15:20] <cpaelzer> hallyn: you just left too sudden and I'm the one missing you most due to the follow on work :-)
[15:21] <cpaelzer> hallyn: have a good trip
[15:39] <cpaelzer> hallyn: TL;DR I just didn't realize before that this part of the move was only half way done - but we will complete that now
[18:02] <M3mphiZ> cpaelzer: thanks for the hint, im using the following script now to show the motd: for i in /etc/update-motd.d/*; do if [ "$i" != "/etc/update-motd.d/98-fsck-at-reboot" ]; then $i; fi; done


[01:13] <thumper> rockstar: ping
[01:13]  * thumper does TZ math
[01:13] <rockstar> thumper, hi
[01:14] <thumper> rockstar: it's getting late for you right?
[01:14] <thumper> rockstar: bug 527450
[01:14] <mup> Bug #527450: email unsubscribe link is fragile (broken-ish) <email> <notification> <qa-needstesting> <trivial> <Launchpad Bazaar Integration:Fix Committed by rockstar> <https://launchpad.net/bugs/527450>
[01:14] <thumper> rockstar: are you able to qa this?
[01:14] <rockstar> thumper, I just got back from a bike ride.
[01:14] <rockstar> thumper, I think I can.  I have to get the imap mail thing working again, which is always a PITA.
[01:14] <thumper> rockstar: can you put qa onto your TODO list for tomorrow morning?
[01:14] <rockstar> thumper, yessir.
[01:15] <thumper> rockstar: awesome, thanks
[01:15] <rockstar> (sorry you had to remind me)
[01:15] <mwhudson> thumper, rockstar: can i beg a couple of reviews off you?
[01:15] <thumper> mwhudson: hit me
[01:15] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/fewer-spurious-partial-code-imports-bug-532402/+merge/21416
[01:15] <rockstar> mwhudson, you can, but I'm upgrading to Lucid right so...
[01:15] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/back-off-failing-imports-bug-413637/+merge/21411
[01:16] <mwhudson> (jml already sort of half reviewed the last one)
[01:34] <mwhudson> thumper: ta
[01:35] <mwhudson> thumper: can you approve the merge proposals too?
[01:35] <mwhudson> or i can of course...
[01:36] <Ursinha> ²²±/16
[01:38] <thumper> Ursinha: eh?
[01:40] <Ursinha> thumper: nevermind my irssi fail
[01:40] <thumper> Ursinha: you just had me confused
[01:41] <Ursinha> thumper: sorry
[01:41] <Ursinha> :)
[03:44] <wgrant> jtv: Has there been any further discussion about what to do about generalised builder histories?
[03:44] <wgrant> (in particular, has there been any discussion about making the model suck less?)
[03:44] <jtv> wgrant: hi!  apparently the thinking right now is "just implement buildbase somehow"
[03:45] <jtv> Maybe we should just start out by renaming BuildBase to BuildRecord and Build to PackageBuildRecord or something.
[03:45] <wgrant> Hmmm. That seems silly.
[03:45] <jtv> BTW you said that the builder UI also stumbles over recipe builds, right?
[03:46] <wgrant> It won't crash any more (they have a canonical URL as of a few days ago).
[03:47] <wgrant> I had a little play around with remodeling the model to remove duplication and actually allow generalised histories to work. Some of the output is at http://people.ubuntu.com/~wgrant/launchpad/buildfarm/
[04:01] <jtv> wgrant: so the idea is to split Build into "build attempt," "binary build," and "source package build"?
[04:03] <wgrant> jtv: I'd like to store attempts, but others probably don't, so there's one without that too.
[04:04] <wgrant> (at the moment if a build fails, clicking "Retry" will reset and obliterate the build's history. this can make things very opaque)
[04:05] <jtv> Oh, that's exactly the kind of situation where I'd have expected Build to be useful as an historical record.
[04:05] <wgrant> We can't really create a new Build, I don't think.
[04:07] <wgrant> Although that might work better
[04:07] <wgrant> Hmm.
[04:07] <wgrant> Excluding UI problems, I think the Soyuz model might actually cope with having duplicate Builds.
[04:07] <jtv> Why have a BinaryPackageBuild.buildstate and a SourcePackageRecipeBuild.build_state?
[04:08] <wgrant> Because I haven't resolved the unresolved issue.
[04:08] <wgrant> And I apparently forgot to rename the attributes that I copied from the original classes.
[04:09] <wgrant> But the whole result thing needs to be rethough. SPRB and BPB can share them. I'm just not sure where to put it.
[04:10] <jtv> Another point is that what we are working on is not a "package" build.
[04:10] <wgrant> "we"?
[04:11] <wgrant> Do you refer to the template jobs?
[04:13] <jtv> Right.
[04:14] <wgrant> I don't see any implication in the current model or my experiments that it is.
[04:15] <jtv> Well, none of PackageBuild would be applicable to us.
[04:16] <jtv> Okay, "job" would.  :-)
[04:16] <james_w> wgrant: hey, do you have a pointer to the object served as the root over the API? I'm looking to export a new collection, it's in the wadl, but I need to serve the link to it in the root.
[04:16] <wgrant> jtv: That's why it's not connected to any of the Translations bits.
[04:17] <jtv> wgrant: so if we wanted to keep history for the translations jobs as well, where would it fit into your model?
[04:17] <wgrant> james_w: Which collection?
[04:17] <james_w> wgrant: code-imports
[04:17] <wgrant> jtv: TTB
[04:17] <jtv> oh, I had been completely ignoring the lhs!
[04:17] <wgrant> james_w: I don't think you should export that. Code imports exist under branches, and should be created from under productserieses.
[04:17] <wgrant> I don't think exporting the root collection is useful.
[04:18] <james_w> wgrant: productserieses/distributionsourcepackage?
[04:18] <wgrant> jtv: Heh.
[04:18] <jtv> wgrant: I now see why.
[04:18] <wgrant> james_w: Hmmm.
[04:18] <jtv> wgrant: I don't see any meaningful difference between TTB and TranslationTemplatesBuildJob.
[04:18] <james_w> wgrant: what I want to achieve is to be able write a script that syncs Vcs-* with LP
[04:19] <wgrant> james_w: Expose it on IBranchTarget or whatever it is, then.
[04:19] <james_w> ok
[04:19]  * james_w changes direction
[04:19] <wgrant> jtv: TTBJ doesn't exist, does it?
[04:19] <jtv> wgrant: does too!
[04:20] <wgrant> I thought it was just Branch<->BranchJob<->Job<->BuildQueue
[04:20] <jtv> In the database, yes.
[04:20] <jtv> In terms of storage, a TTBJ is just a BranchJob.
[04:20] <jtv> But it's also a BuildFarmJob.
[04:20] <wgrant> james_w: Root collections should be avoided if at all possible. Both operations (retrieving and creating code imports) have logical parents, so they should be exposed there.
[04:21] <james_w> wgrant: right
[04:21] <wgrant> jtv: OK, so the meaningful difference is probably that TTBJs die when the operation completes.
[04:21] <wgrant> And the current model has too many duplicated classes, so I want to kill it.
[04:21] <jtv> wgrant: right, so the TTB would simply be a copy of the TTBJ
[04:21] <wgrant> jtv: TTBJ ceases to exist.
[04:21] <james_w> wgrant: so, code imports should be retrieved by getting a subordinate URI of the branch they import to?
[04:22] <jtv> wgrant: TTBJ shares a table with all sorts of other jobs of different types, so I don't think we should dictate our lifetime semantics to it.
[04:22] <mwhudson> james_w: my understanding was that someone tried that and lazr.restful stabbed them
[04:22] <mwhudson> james_w: but noone's completely sure any more :-)
[04:22] <wgrant> mwhudson: '@stepto("+code-import")'?
[04:23] <wgrant> jtv: I mean, why does TTBJ need to exist if TTB does?
[04:23] <wgrant> Is there any point in it sharing the table?
[04:23] <wgrant> Same for Job itself.
[04:23] <james_w> mwhudson: I am equipped with a stab-proof vest, my naivety, and a glass of wine, I hope to prevail
[04:23] <mwhudson> wgrant: eh?
[04:23] <wgrant> mwhudson: Do you recall what the problem was?
[04:23] <mwhudson> wgrant: no
[04:23] <wgrant> It seems like one could just add @stepto("+code-import") to BranchNavigation, and it would have to work.
[04:23] <mwhudson> i don't think i ever knew
[04:24] <wgrant> I recall I brought it up in Wellington one day, and nobody knew there either :(
[04:24] <wgrant> Which is odd, since all of Code in recent memory was there.
[04:24] <mwhudson> something to do with having an entry as part of another entry rather than as part of a collection
[04:24] <mwhudson> james_w: please try, and if it fails, please explain what happens in the bug report
[04:25] <james_w> I know the API well from the client-side, but know little about implementing it server side, so this is partly a learning exercise
[04:25] <jtv> wgrant: wouldn't that mean that TTB represented a past, ongoing, or future build whereas the other Build types represent only past or ongoing ones?
[04:25] <wgrant> jtv: The other Build types can never be removed.
[04:26] <mwhudson> the bug btw https://bugs.edge.launchpad.net/launchpad-code/+bug/366102
[04:26] <mup> Bug #366102: API for creating and managing code imports <api> <code-import> <package-branches> <udd> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/366102>
[04:26] <wgrant> If they succeed, they are deeply integrated into the terrible web that is the Soyuz data model.
[04:26] <wgrant> They are never removed.
[04:26] <wgrant> Oh, misread.
[04:27] <wgrant> jtv: I don't see how the futureness is different.
[04:27] <wgrant> A TTB will start to exist moments before it is queued.
[04:27] <wgrant> SPRBs and BPBs do as well.
[04:28] <jtv> wgrant: I thought that was in the same transaction that also dispatched it.
[04:28] <wgrant> jtv: No. They are created by any one of a number of processes on several different machines.
[04:28] <jtv> Does build candidate selection etc. use Build?
[04:28] <wgrant> Yes.
[04:28] <jtv> I see.  Then it's not really different.
[04:28] <wgrant> Exactly.
[04:30] <wgrant> No class in my non-current diagrams gets deleted.
[04:30] <wgrant> (except when a branch gets deleted, but mrrhrhrrhrhr)
[04:32] <wgrant> Whereas all the common classes in the old one do.
[04:32] <jtv> That's the kind of case where I'd be in favour of either cascading deletes or a denormalized history table—the latter being something we should do only if there is a proven need.
[04:32] <wgrant> I think we should probably just ban branch deletes in some circumstances.
[04:33] <wgrant> What happens if I try to delete a branch referenced by a recipe referenced by sourcepackagerecipebuilds with dozens of sourcepackagereleases in dozens of archives?
[04:33] <mwhudson> we have a kind of denormalized history for code imports
[04:33] <mwhudson> completely unused :/
[04:33] <wgrant> Heh.
[04:34] <jtv> wgrant: so what?  If the recipe is basically there to service the branch, it should die.  The SPRs don't depend on the recipebuilds, do they?
[04:34] <wgrant> jtv: SPR references SPRB.
[04:35] <wgrant> Deleting an SPRB removes all accountability information for any SPR built from it.
[04:35] <jtv> wgrant: and the reference from SPR to the branch does not go through the recipe?
[04:35] <jtv> Because if it does, well, cascading nulls solve it very nicely.  :)
[04:36] <wgrant> It does. But then you end up with a broken recipe.
[04:36] <mwhudson> grar
[04:37] <wgrant> Hm?
[04:37] <mwhudson> i revoked ec2 lands oauth token and now it's broken
[04:37] <mwhudson> do i have to clear some cache somewhere?
[04:37] <wgrant> Hah.
[04:37] <wgrant> Try removing the launchpadlib cache, i guess...
[04:38]  * mwhudson finds /home/mwh/.launchpadlib/api.edge.launchpad.net/credentials/launchpad-branch-lander
[04:38] <wgrant> jtv: Anyway, any more impressions of the model?
[04:39] <mwhudson> and a few other similarly named files
[04:40] <jtv> wgrant: contrary to all experience so far, emotionally I still have trouble believing that something so much simpler can work.  :-)
[04:41] <wgrant> Haha.
[04:41] <wgrant> The current one has too many arrows.
[04:41] <wgrant> It makes me sad.
[04:41] <mwhudson> oh what now
[04:42] <jtv> wgrant: mwhudson is from a place where every place where you might conceivably want to cross a street has a big arrow saying which direction to look in.
[04:42] <mwhudson> jtv: i think that's only london
[04:43] <jtv> mwhudson: oh, London stops somewhere before the coast?  I never really noticed.
[04:44] <jtv> wgrant: the current one has enough arrows to scare us out of cleaning up.
[04:44] <wgrant> True.
[04:44] <jtv> So I think it's a great thing you're doing, but it looks like one hell of a job.
[04:44] <james_w> mwhudson: I'm starting to see the issue
[04:45] <wgrant> jtv: Well, we need to get some centralised permanent history table for builder history to work.
[04:45] <wgrant> And it's not that much more work to fix the rest up.
[04:45] <mwhudson> james_w: :(
[04:45] <wgrant> james_w: What's going wrong?
[04:46] <james_w> you want to export an entry that is subordinate to another entry, so lazr.restful dutifully tries to create a link for you
[04:46] <wgrant> "create a link"?
[04:46] <james_w> oh no, I've confused myself
[04:46] <james_w> it seems that wine was not my ally on this adventure
[04:46] <wgrant> Heh.
[04:47] <mwhudson> :)
[04:47] <james_w> I'm stuck trying to work out how to export() code_import on IBranch though
[04:47] <james_w> as it's just Attribute currently, apparently due to circular import issues.
[04:47] <wgrant> code_import = exported(Reference(..., schema=Interface))
[04:47] <james_w> I've seen workarounds for that elsewhere
[04:47] <wgrant> Then patch it in _schema_circular_imports.py with the rest.
[04:48] <james_w> ah, I was wondering if it had to be a *Choice
[04:49] <wgrant> I don't believe so.
[04:49] <wgrant> I think ReferenceChoices are only used for fields editable in the UI.
[04:51] <james_w> ok
[04:51]  * wgrant heads trainward.
[04:54]  * mwhudson stops too
[06:33] <wgrant> spm: How much RAM does crowberry have to be able to survive two >13GiB RSS processes!? The bug says 8GiB, but that can't be right...
[06:37] <jtv1> hi al-maisan!  Say, do you know of any pagetests for the access check on build logs?
[06:38] <wgrant> Access check?
[06:38] <al-maisan> jtv: not off the top of my head ..
[06:38] <al-maisan> page tests that verify the access to build logs I assume..?
[06:39] <jtv1> wgrant: yes, the bit that hides build logs when private.
[06:41] <wgrant> jtv1: The build itself is hidden, and the log is accessed by a proxying view on Archive. I don't see how the latter is relevant to your work.
[06:41] <jtv1> wgrant: there are more places that access the log, without going through archive.
[06:41] <jtv1> Builder page.
[06:42] <wgrant> jtv1: All build details are hidden from the builder page when the build is private. There's no special handling for the log.
[06:43] <wgrant> Oh, unless you mean logtail?
[06:45] <StevenK> Ddoes anyone know off hand how to run the test suite for gina? test_gina.py is being unhelpful.
[06:47] <wgrant> StevenK: IIRC I've just 'bin/test -vvt gina' in the past.
[06:47]  * wgrant tries.
[06:48] <wgrant> That looks like it's working.
[06:49] <StevenK> I was trying bin/test -vvt test_gina, which just did nothing
[06:49] <wgrant> Ah.
[06:49] <wgrant> Most of them are doctests.
[06:50] <wgrant> So that won't catch them.
[06:50] <wgrant> You're fixing it too like multiple published versions of the same source?
[06:50] <StevenK> Yeah
[06:51] <wgrant> StevenK: Which archive admins use the queue web UI?
[06:51] <wgrant> It's been requested that I fix it to show package sets, and I'm wondering who is likely to kill me if they disagree.
[06:52] <StevenK> wgrant: The ones that don't have shell on cocoplum, so probably just ScottK
[06:53]  * persia has also seen folk with shell use non-shell for trivial tasks
[06:53]  * wgrant too.
[06:53] <jtv1> wgrant: that's right, the logtail...  I'm moving that check into security.py.
[06:53] <wgrant> jtv1: Ah. Ew.
[06:53] <wgrant> (good idea)
[06:54] <jtv1> wgrant: the two opinions seem ill-matched.  :)
[06:54] <persia> wgrant: You might check with infinity also, although I haven't seen much activity from him in a while.
[06:54] <wgrant> jtv: The current status is ew. Fixing it properly is a good idea.
[06:54] <jtv> ah :)
[06:54] <wgrant> persia: infinity has been gone for a long time now.
[06:54] <persia> He's still listed as archive-admin though.
[06:55] <wgrant> Hm. that seems odd.
[06:55] <StevenK> And a member of ubuntu-cdimage
[06:55] <persia> He's just no longer a buildd-admin
[06:55] <jtv> wgrant: I'm making the view use View permissions for IBuildFarmJob, which I newly defined & provided with checks for private builds & branches.
[06:56] <wgrant> jtv: It's probably untested.
[06:56] <wgrant> I can't see any tests for it.
[06:56] <wgrant> And it was Soyuz until recently.
[06:56] <jtv> wgrant: oh well, then I guess I'll write some.
[06:56] <jtv> (grumble grumble bloody nuisance)
[06:57] <wgrant> persia: He is still a buildd admin, though.
[06:57] <persia> Ah.  I thought he stopped being something.  Maybe I was misinformed.
[06:57] <wgrant> An admin, perhaps.
[06:57] <persia> perhaps.
[07:19] <jtv> wgrant, al-maisan: xx-private-builds.txt tests for access.
[07:19] <al-maisan> jtv: thanks for the pointer!
[07:19] <jtv> I think I'll write up an MP now before I go mad with it all.  :-)
[08:01] <wgrant> henninge: Thanks for landing those.
[08:02] <henninge> wgrant: you are welcome
[08:02] <adeuring> good morning
[08:04] <stub> intellectronica, gmb: Is there anything to guarantee that AportJob rows eventually get removed? I need to know if the Librarian garbage collector should not collect blobs linked to AportJob rows, or if it should delete the corresponding AportJob and Job rows in addition to the blob.
[08:07] <wgrant> A branch I'm about to propose for review has new config keys and a new script that needs to be run regularly. What special stuff do I need to know?
[09:07] <bigjools> morning
[09:07] <wgrant> Morning.
[09:12] <gmb> stub: There's nothing pruning them at the moment. I can easily add something that does, though.
[09:13] <gmb> stub: But if that table's bloating you can probably delete anything more than a day old.
[09:13] <stub> gmb: If it is simple (delete any apportjob and job rows linked to a blob older than a day or three) I can do that in the librariangc
[09:14] <stub> gmb: Otherwise it should go in garbo.py, and possibly need to be cherry picked too to avoid the Librarian exploding.
[09:14] <gmb> stub: It is. Once the Job is completed the +filebug process will use the data stored in the ApportJobs json_data field, but after that it's never used again. Librarian gc should be sufficient
[09:15] <stub> ok
[09:15] <mrevell> Morning
[10:00] <deryck> Morning, all.
[10:09] <jtv> henninge: I got a little bit further with the FSM problem on the slave side: I think things go awry because the success code becomes None somehow.
[10:11] <henninge> jtv: is "None" supposed to mean "success" of "failure"?
[10:11] <jtv> henninge: neither.  AFAICT it's not supposed to happen.
[10:11] <jtv> 0 means success.
[10:11] <henninge> jtv: I know that
[10:12] <henninge> jtv: what I mean is that anything != 0 is treated as a failure.
[10:12] <wgrant> So the subprocess ends without a return code?
[10:12] <jtv> The code treats it as a failure; it explicitly compares to 0.
[10:12] <henninge> yes, looks like it
[10:12] <wgrant> Huh
[10:12] <jtv> Or _somehow_ twisted feeds us a None.
[10:12] <henninge> jtv: which state was it again?
[10:13] <jtv> I'll double-check.
[10:13] <jtv> Oh, can't check that now.  IIRC it was UNPACK.
[10:13] <henninge> jtv: I did notice that "None" in there but thought it was a sign of failure
[10:13] <henninge> (and it does not happen in our code ... ;)
[10:13] <jtv> Maybe it was.
[10:14] <jtv> Nope, that's what makes it so infuriating.
[10:14] <wgrant> An early stage that's used by two other managers? Really?
[10:14] <henninge> wgrant: yup
[10:14] <jtv> Well, I'm sure we're _causing_ it somehow, but...
[10:14] <jtv> Does twisted get a timeout somewhere, after which it passes None?
[10:14] <henninge> jtv: you always feel guilty
[10:14] <henninge> ;-)
[10:14] <wgrant> Does a recipe build work OK on the same machine?
[10:14] <jtv> henninge: sorry.
[10:15] <jtv> wgrant: I haven't tried that; is there documentation on how to test that?
[10:15] <wgrant> jtv: Not really, no. But a binary build is well-documented on HowToUseSoyuzLocally, and just as useful.
[10:17] <bigjools> james_w: did you do any QA on your fix for https://bugs.edge.launchpad.net/soyuz/+bug/89150 ?
[10:17] <mup> Bug #89150: sync-source should not assume 0 is the lowest version number possible <qa-needstesting> <soyuz-ftpmaster-tools> <Soyuz:Fix Committed by james-w> <https://launchpad.net/bugs/89150>
[10:18] <jtv> wgrant: the instructions don't say anything about signing, but dput complains that the package is not signed.  I've had to look this up before, but what was the option again?
[10:21] <wgrant> jtv: Give debuild '-kKEYID'.
[10:21] <wgrant> jtv: Normally if the changelog matches your key it won't be necessary, though.
[10:23] <jtv> wgrant: I didn't have a changelog of my own handy
[10:25] <jtv> wgrant: wait... you're saying I need to rebuild the package for this?
[10:25] <jtv> I thought there was a way around that...
[10:26] <wgrant> jtv: debsign blah.changes
[10:27] <jtv> nope, that's not it
[10:27] <jtv> that still complains when I'm not in the changelog.
[10:28] <jtv> ahhh, -u does it.
[10:30] <jtv> gah, unable to find mandatory field 'files' in the changes file.
[10:31] <wgrant> jtv: Insufficiently signed.
[10:32] <bigjools> yeah that error sucks
[10:33] <jtv> okay, debsign<EMAIL_ADDRESS><foo>_source.changes
[10:33] <jtv> debsign: Only a .changes, .dsc or .commands file is allowed as argument!
[10:33] <jtv> one gets so tired...
[10:34] <wgrant> Actually, you might be able to use a policy that allows unsigned uploads now. When I started looking it forbade PPA uploads, but I might have fixed that...
[10:34] <jtv> ah, I had a space after the -k
[10:34] <bigjools> -C absolutely-anything
[10:34] <jtv> bigjools: ?
[10:34] <wgrant> Yeah, absolutely-anything will work now.
[10:34] <bigjools> it's a policy for process-upload
[10:35] <wgrant> jtv: If you give that to process-upload.py, it should not require a sig.
[10:35] <bigjools> wgrant: as opposed to "anything" which is not anything!
[10:35] <wgrant> Yep.
[10:35] <jtv> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!
[10:35] <jtv> and just when I got my changes file signed...
[10:39] <bigjools> jtv: I made that policy explicitly for testing
[10:40] <bigjools> see the comment on it :)
[10:40] <jtv> bigjools: and very welcome it is too...  I've added it on the wiki page.
[10:40]  * wgrant fixed it a few months ago, but then forgot.
[10:40] <bigjools> though I'd like to rename it to "anything" and rename the existing "anything" to what it really is
[10:48] <jtv> wgrant: not getting the slave to do much...  says it's still idle.
[10:49] <jtv> maybe one of my failed attempts got in the way somehow.
[10:49] <jtv> Or I missed a step.
[10:49] <jtv> But it's definitely not getting to the point where the translations fsm is breaking.
[10:54] <wgrant> jtv: The virtualisation setting matches between the PPA and builder?
[10:54] <jtv> wgrant: uhhh...  I'll have a look.
[10:56] <jtv> wgrant: ppa does not require a virtualized builder; builder is virtualized.
[10:56] <wgrant> jtv: Flip the PPA's flag.
[10:56] <wgrant> 'Does not require a virtualized builder' means 'Requires a non-virtualized builder'
[10:57] <jtv> ah
[11:03] <jtv> $ ./scripts/process-upload.py /var/tmp/poppy -C absolutely-anything -vvv
[11:04] <jtv> 2010-03-16 11:01:45 INFO    creating lockfile
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Initialising connection.
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Beginning processing
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Checked in /var/tmp/poppy/incoming, found []
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Rolling back any remaining transactions.
[11:04] <jtv> 2010-03-16 11:01:49 DEBUG   Removing lock file: /var/lock/process-upload-absolutely-anything.lock
[11:04] <jtv> wgrant: ^^^ doesn't look right, does it?
[11:06] <wgrant> jtv: You've not uploaded it?
[11:07] <jtv> wgrant: I dput it, and dput said it was successful.  What else do I need to do?
[11:08] <wgrant> jtv: Try uploading it again, I guess (you'll probably need to give dput '-f').
[11:08] <jtv> wgrant: did that several times
[11:08] <wgrant> Unless poppy is being stupid...
[11:08] <jtv> with different changes files
[11:09] <wgrant> Are you getting any errors in the terminal in which you started poppy?
[11:09] <bigjools> why are you using poppy?
[11:09] <wgrant> When it works it's a trivial way to get the directory structure right.
[11:09] <wgrant> But since it doesn't seem to be working...
[11:10] <jtv> wgrant: I have a lot of output mixed together... when exactly should the poppy error happen?  During dput?
[11:11] <wgrant> jtv: Generally at the end of dput.
[11:11] <wgrant> But as bigjools says, you could work out the directory structure and avoid poppy.
[11:11] <bigjools> what is in /var/tmp/poppy?
[11:11] <jtv> one item (dir+file) in failed, one (dir+file) in rejected.
[11:11] <jtv> I dput rather more.
[11:12] <bigjools> poppy is not putting stuff where you think it is then
[11:12] <wgrant> Which generally means you're getting that client accept hook failure or whatever it is.
[11:12] <wgrant> Which should be spewing tracebacks everywhere.
[11:14] <jtv> maybe it's in a different shell then... I have to stop now.
[11:14] <bigjools> jtv: just mkdir -p /var/tmp/poppy/incoming/jtv
[11:14] <bigjools> then copy your upload there
[11:14] <jtv> why jtv?
[11:14] <bigjools> it doesn't matter
[11:14] <bigjools> anything
[11:15] <jtv> ah ok
[11:15] <jtv> and my upload is the changes file, dsc file etc?
[11:15] <bigjools> call it I_hump_donkeys
[11:15] <bigjools> yes
[11:15] <wgrant> Doesn't it need an upload path?
[11:15] <bigjools> this is a PPA upload?
[11:16] <bigjools> then yes
[11:18] <jtv> I'm afraid I really have to stop typing now
[11:20] <jml> wtf https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1536EA471
[11:24] <bigjools> jml: foundations bug
[11:24] <bigjools> they're working on it
[11:24] <jml> oh good.
[11:24] <bigjools> something to do with assuming all views are LPViews
[11:42] <jml> heh heh
[11:43] <jml> Unable to obtain lock lp-66556816:///~launchpad/lp-source-dependencies/trunk/.bzr/branch/lock
[11:43] <jml> held by<EMAIL_ADDRESS>on host crowberry [process #5035]
[11:43] <leonardr> jml: i'm committing right now
[11:43] <jml> leonardr, so I gathered :)
[11:43] <leonardr> jml: all done
[11:43]  * jml parties like its 1999
[11:44]  * bigjools sighs at lucid bugs
[11:58] <maxb> lucid bugs?
[12:05] <bigjools> laptop suspending at battery low instead of critical
[12:05] <bigjools> laptop not resuming from suspend 50% of the time
[12:05] <bigjools> fsck at boot freezing
[12:06] <jtv> henninge: I filed bug 539499 about my FSM problem.  I'll go to my office tomorrow and see how things work out on a different machine.  If you have any notes, please add them!
[12:06] <mup> Bug #539499: Build-farm slave FSM fails early on <buildfarm> <Launchpad Translations:New> <https://launchpad.net/bugs/539499>
[12:09] <wgrant> jtv, henninge: I ran a template job through from the master a few days back (just as one of henninge's branches was landing), and it went through fine (except for not actually generating a template tarball, since that wasn't implemented yet)
[12:09] <wgrant> So it's either something broken on your machine, or something very recently broken.
[12:12] <jtv> wgrant: so intltool was actually run on your branch?
[12:13] <wgrant> jtv: Yes.
[12:13] <wgrant> It printed out the template paths and everything.
[12:13] <jtv> wgrant: that's great news, thanks.  This was the Debian-based FSM, right?
[12:13] <wgrant> jtv: Uh, not sure. I merged the henninge branch that you had linked to on the wiki page.
[12:13]  * wgrant will check logs tomorrow.
[12:13] <wgrant> But... sleep.
[12:14] <jtv> thanks.  yes.  Very glad to hear this.
[12:14]  * jtv really buggers off
[12:14] <wgrant> (it worked sufficiently that I could just push a branch, run 'make sync_branches', and it would print out the template names.
[12:14] <wgrant> Night.
[12:15] <jtv> cool cool cool sweet dreams
[12:16] <henninge> wgrant: yes, printing out template names is success. cool!
[12:16] <henninge> g'night
[13:56] <sinzui> salgado: ping
[13:56] <salgado> hi sinzui
[13:58] <sinzui> salgado: I am seeing several questions about how to change launchpad passwords. I think I should update the FAQs about this. Maybe you are planning to update the user profile page to explain that accounts/emails/passwords are managed at login.ubuntu.com?
[13:59] <salgado> sinzui, I didn't have plans to do it, but I could do so.  also, it's only the password that is managed by login.lp.net; email addresses are still managed by LP
[14:00] <sinzui> understood
[14:01] <sinzui> salgado: Can we do something as simple as a sentence:
[14:01] <sinzui> "Manage your Ubuntu account and password > login.launchpad.net"
[14:02] <salgado> sinzui, I suppose so, but I think we should s/Ubuntu/Login Service
[14:03] <sinzui> I think that will lead to confusion. Changing my Launchpad password is changing my Ubuntu password isn't it?
[14:05] <james_w> bigjools: how would I QA sync-source.py?
[14:05] <james_w> bigjools: or is it on production?
[14:06] <salgado> sinzui, login.u.c and ubuntu accounts are not used/mentioned when logging into LP, but I'm not sure what's the plan on the SplitIt front -- can you check with flacoste?
[14:06] <sinzui> I will
[14:10] <flacoste> salgado, sinzui: they should be mentioned since they are the same thing
[14:11] <flacoste> a Launchpad login service account is really a Ubuntu account
[14:12] <sinzui> flacoste: I was thinking to using a sentence on user +edit sending the user to l.l.n. We want to update the header/footer of l.l.n to state the service is provided by l.u.c
[14:12] <flacoste> sinzui: right, can you file a bug about this on the ISD project?
[14:13] <sinzui> I will
[14:19] <bigjools> james_w: I can run it on dogfood, I was just wondering if you had a test case or had already tested it
[14:20] <james_w> I don't know one offhand, and I haven't tested it
[14:20] <james_w> let me see if I can find one
[14:29] <james_w> bigjools: I can't find anything waiting to be synced from Debian that has an appropriate version number
[14:31] <bigjools> james_w: :(
[14:41] <kfogel> vila: so I think I finally have it working.  What's weird is I successfully pushed a commit to a branch (up to a server using the kind of authn we were talking about), and on the server side I can't figure out where the actual commit data lives.  See http://paste.ubuntu.com/396199/ -- just out of academic curiousity, what file under .bzr has the commit?  I created a file named "fish.txt" with the text "Hello, world!", and it's hard to see, even with
[14:41] <kfogel> compression, where that data is.
[14:41] <kfogel> vila: mind you, it *is* working.  If I branch that branch again, the data is there.
[14:42] <vila> kfogel: that's because there is no working tree here, try 'bzr co .'
[14:42] <vila> kfogel: or 'bzr cat fish.txt'
[14:43] <kfogel> vila: yeah, no working tree, but the data has to be *somewhere* in there.
[14:43] <kfogel> vila: I understand the upstream doesn't have a working tree, but it obviously is remembering this data somewhere.
[14:43] <vila> kfogel: what does 'bzr info -v' says ? maybe a shared repo up
[14:43] <kfogel> vila: AAAAAAAAAAAAAAAAAAAH
[14:43] <kfogel> vila: that's right, I did create a shared repo upstream
[14:43] <kfogel> vila: thanks, that's it
[15:56] <james_w> anybody recognise "RuntimeError: Property used in an unknown class" ?
[15:56] <james_w> I'm just trying to use the factory
[16:14] <james_w> an, using a project in place of a product
[16:36] <jml> james_w, more context please
[17:53] <james_w> jml: if you pass product=IProject to a factory method you get a cryptic error message
[18:28] <mrevell> nytol
[18:39] <mwhudson> good morning
[18:51] <james_w> morning mwhudson
[19:01] <jml> mwhudson, good morning
[19:01] <jml> I've got buildout building subunit from the tarball and installing it in the parts/ directory
[19:01] <jml> but I'm not sure how to get it into the PYTHONPATH
[19:04] <jml> gary-lunch, when you're back, I'd appreciate some advice
[19:17] <james_w> mwhudson: would you like to help me get https://code.edge.launchpad.net/~james-w/launchpad/export-code-import/+merge/21472 finished?
[19:17] <mwhudson> james_w: probably
[19:17]  * mwhudson looks
[19:17] <mwhudson> (actually i kinda want to go back to bed already, but struggling on...)
[19:18] <mwhudson> james_w: "This exports ICodeReview." ?
[19:18] <james_w> ach
[19:18] <maxb> salgado_: Uploading to the launchpad PPA with a Debian-lookalike version isn't optimal
[19:18] <james_w> fixed
[19:19] <salgado> maxb, you mean the -2 bit?
[19:20] <maxb> yes
[19:20] <maxb> Preferably the name or version of every package would contain 'launchpad' so that people can easily identify them as non-distro packages
[19:20] <salgado> ah, right
[19:20] <mwhudson> james_w: i don't think ICodeImport['owner'] is used anywere at all
[19:21] <gary_poster> jml: yo
[19:21] <gary_poster> jml: extra-paths might be what you are looking for
[19:21] <gary_poster> see how mailman is done?
[19:21] <salgado> maxb, I'll upload another one and delete the -2 one
[19:21] <mwhudson> i'm not even sure registrant is
[19:22] <james_w> mwhudson: yeah, I was a bit confused between registrant, owner and assignee
[19:22] <james_w> you mean I should export the latter instead?
[19:22] <maxb> salgado: So, given its effectively a backport from lucid, it should be named something like 0.2.0-1~BLAH
[19:22] <mwhudson> james_w: all a legacy of over design
[19:23] <gary_poster> jml: extra-paths = ${buildout:directory}/lib/mailman is what we have now.  You would add a newline and then an indented value for the other directory
[19:23] <maxb> salgado: For example, look at what I did with the python-imaging backports in the LP PPA
[19:24] <maxb> But really, the main problem with 0.2.0-2 is that's what the next upload to Debian itself will be! :-)
[19:24] <james_w> mwhudson: one thing that I was unsure about is the information that seems to be duplicated with ICodeImport.branch, e.g. product
[19:24] <james_w> especially since I would like to have code imports for package branches as well as product branches
[19:25] <mwhudson> um
[19:25] <mwhudson> that looks screwy
[19:25] <mwhudson> i wonder if _that's_ used anywhere
[19:25] <james_w> series I can kind-of understand, as that's not an attribute of branch
[19:25]  * mwhudson is tempted to delete a few things from ICodeImport and run the tests...
[19:25] <salgado> maxb, heh, good point.  thanks for the heads up; I'll re-upload with proper versions (following the pattern used in python-imaging)
[19:26] <maxb> thanks
[19:26] <mwhudson> james_w: i think you shouldn't export registrant, owner, assignee, product, series
[19:28] <mwhudson> james_w: actually, registrant might be worth exporting
[19:28] <james_w> deleted the export of owner, so now none of those are exported
[19:28] <mwhudson> ok
[19:28] <mwhudson> easier to add than remove an export i guess :-)
[19:28] <james_w> it tends not to be exported elsewhere
[19:29] <mwhudson> james_w: so when you say "help you finish", what does that mean?
[19:30] <james_w> review if that is all it takes
[19:30] <james_w> I expected there to be several more things involved though
[19:30] <mwhudson> it looks like a start
[19:30] <mwhudson> i'm not super familiar with api stuff
[19:31] <mwhudson> james_w: have you tried accessing code imports on launchpad.dev ?
[19:31] <james_w> adding exported() around things and testing that they are in the representation is easy
[19:31] <james_w> it' the traversal stuff that I wasn't sure about
[19:31] <mwhudson> with launchpadlib
[19:31] <james_w> I'll try that now
[19:32] <mwhudson> james_w: well, webservice.get() in the page test is testing the traversal stuff
[19:33] <mwhudson> i presume $branch/+code-import will still 404 in the webapp as there are no pages registered
[19:35] <james_w> mwhudson: well, there's working and then the "correct" way to do it :-)
[19:36] <mwhudson> james_w: it looks ok to me
[19:36] <james_w> thankfully there was a wiki page for that, so I took enough from there to get the tests to pass
[19:36] <mwhudson> i wonder why the first people to try this couldn't get it to work
[19:36] <james_w> the rest seemed to be presenting it in the webapp as you say, but we don't want that
[19:36] <mwhudson> maybe lazr.restful bugs that are now fixed
[19:36] <james_w> mwhudson: any idea who it was? We should get their review if so, as they may spot something I missed
[19:37] <mwhudson> james_w: no, maybe i'm in fact making up that this problem was encountered :/
[19:37] <mwhudson> if it works it works, there is limited potential for subtle traps here
[19:37] <james_w> right
 the rest seemed to be presenting it in the webapp as you say, but we don't want that
[19:38] <mwhudson> james_w: i don't understand what you mean here
[19:39] <james_w> the rest of the wiki page seemed to be about linking up pages to interfaces so that the webapp would render them
[19:39] <mwhudson> ah ok
[19:40] <mwhudson> i wasn't completely sure that 'rest' in what you said was the english word :)
[19:40] <james_w> heh
[19:49] <james_w> mwhudson: yep, it all shows up in +apidoc, +code-import 404s in the webapp, and lplib can query the code import in sampledata
[19:50] <james_w> the only issue is that most attributes are writeable, I assume we don't want that
[19:53] <mwhudson> oh right
[19:59] <james_w> if I just mark everything as read-only will that break other code?
[20:02] <mwhudson> james_w: i think it might break the +new form
[20:02] <mwhudson> but that's fixable
[20:03] <mwhudson> hm, no it shouldn't, should it?
[20:21] <wgrant> james_w: So it all pretty much just worked?
[20:21] <james_w> wgrant: seems like it
[20:22] <james_w> once I worked out how to do canonical_url for ICodeImport and then traversal
[20:39] <mwhudson> james_w: trying to set attributes through launchpadlib fails in a pretty strange way
[20:39] <mwhudson> they should be read_only for now
[20:40] <mwhudson> and any fallout that causes should just be fixed
[20:41] <james_w> mwhudson: changed and ec2 test running to discover any fallout
[20:41] <mwhudson> james_w: awesome
[20:42] <mwhudson> that means i can ignore the issue for a few hours :-)
[20:42] <james_w> you and me both
[21:03] <maxb> Gaaah setuptools distribute pkg_resources buildout namespace-packages ARGH
[21:03] <maxb> Clean bootstrap on lucid appears broken
[23:34]  * thumper is back around
[23:41]  * mwhudson lunches


[09:51] <Mark_> deactivating my account doesnt seem to delete it
[09:51] <Mark_> how can i actually delete it
[09:53] <Mark_> ive already logged back in and deactivated my account like 4 times now
[09:53] <Mark_> i wonder how many times itll append -deactivatedaccount to my username
[09:53] <Mark_> lol
[10:06] <wgrant> I can permanently kill it for you.
[10:07] <wgrant> Mark_: What's your email address or Launchpad username?
[10:07] <Mark_> lol, ive already made a mess
[10:07] <Mark_> but if you can fix it, rock on
[10:07] <Mark_> i started the 'abandoning process'
[10:07] <Mark_> but if you could just blow whatever away id appreciate it
[10:07] <wgrant> The abandoning process?
[10:07] <Mark_> changing it all to bunk information
[10:08] <Mark_> it was created with<EMAIL_ADDRESS>[10:08] <Mark_> but i started changing it to<EMAIL_ADDRESS>[10:08] <Mark_> i was in the process of trying to demolish the ubuntu openid login and start over
[10:09] <wgrant> What is your Launchpad username at the moment?
[10:09] <Mark_> poorlywrittensoftware
[10:10] <Mark_> but it was msturgill-deactivatedaccount-deactivatedaccount-deactivatedaccount-deactivatedaccount
[10:10] <Mark_> before i switched to that
[10:10] <Mark_> it just kept appending
[10:12] <wgrant> People have a bad habit of rage-deleting their accounts because they had a disagreement with some project maintainer and then regretting it later, so we don't permakill unless they explicitly request it and seem to actually be thinking straight... https://launchpad.net/~poorlywrittensoftware is gone now.
[10:12] <Mark_> rock on
[10:12] <Mark_> well it was a rage delete
[10:12] <Mark_> but not really launchpad's fault
[10:12] <Mark_> more pgp (well, technically gnupg's fault)
[10:13] <Mark_> there were some bad keys imported and although i could deactivate them i couldnt remove them from the account
[10:13] <Mark_> and it trolled me way too hard to see them there, even if they were greyed out
[10:13] <Mark_> i didnt want a testament to my stupidity on a 20 minute old account
[10:13] <Mark_> :P
[10:13] <wgrant> Only you can see deactivated keys :)
[10:14] <Mark_> yea but im the only person that would really annoy
[10:18] <Mark_> but nah launchpad was just the last stop on technorage
[10:19] <Mark_> stackoverflow spammed my phone and annoyed my gf, so i muted my phone, and incidentally something crashed at like 6am and i missed notifications until 10, and then some pgp snafus, and then seeing those snafus permanent
[10:19] <Mark_> thats the slash life story for the day of technology
[10:19] <Mark_> at least its a friday
[10:20] <Mark_> or was
[10:20] <Mark_> hah
[10:21] <Mark_> but ty for helping me out
[10:21] <Mark_> i only really wanted a launchpad account to make 1 single lonely ppa
[13:00] <l3on> Hi all .. I'm having issue marking bugs as duplicate: timeout error (via web and via lptools )
[13:00] <l3on> lazr.restfulclient.errors.ServerError: HTTP Error 503: Service Unavailable
[13:00] <l3on> Response headers:
[13:06] <nickoe> Hello, is it possible to get a list of all tags on the bugs site of a project?


[00:00] <melodie> "based on Lubuntu and featuring the LXDE desktop environment."
[00:00] <melodie> ok got it
[00:00] <god__> yes
[00:00] <god__> im n00b 2 all this
[00:01] <god__> sneaky linux did a video on lxle on youtube.
[00:01] <melodie> See ? Free Live Help: Lubuntu IRC, LXLE IRC, Screencasts
[00:01] <melodie> http://lxle.net/index.php?id=support
[00:01] <god__> ok
[00:01] <melodie> lxle also has a chan it seems
[00:01] <phillw> god__: lxle is a spin of lubuntu, we cannot help you with issues that you have on it. Head over to http://www.lxle.net/ for support details
[00:02] <god__> ok
[00:02] <god__> ty
[00:02] <god__> :)
[00:02] <melodie> phillw lxle does not bother: "Free Email Based Help: Lubuntu Mailing List, LXLE Mailing List"
[00:02] <melodie> ^^
[00:10] <krismaguire> If you're having problems with LXLE we simply recommend shifting to Lubuntu :P
[00:14] <phillw> melodie: lxle != lubuntu
[00:20] <melodie> phillw of course it's not the same
[19:27] <filmfan> hello
[19:29] <filmfan> does anyone in here know if there is a substitute for wildwine that makes hbo nordic work with lubuntu?
[20:33] <speckmade> what's the default password on a lubuntu live system?
[20:34] <speckmade> (tried lubuntu/lubuntu, ubuntu/ubuntu)
[20:34] <Halyard> enter, blank
[20:34] <Halyard> nothing in the field
[20:34] <speckmade> (tried sudo passwd)
[20:35] <speckmade> I can't enter via SSH... :-(
[20:35] <speckmade> although I passwd to lubuntu/lubuntu
[20:36] <speckmade> openssh-server doesn't seem to like entering no password
[20:36] <Unit193> Of course it wouldn't, you can use a key though.


[00:06] <Atamira> afternoon
[07:03] <kieppie> hi all.
[07:03] <kieppie> who's responsible for Ubuntu NZ? Catalyst?
[08:41] <ajmitch> kieppie: there are some catalyst people involved
[21:50] <Atamira> morning


[15:57] <NCommander> Morning all, who's around?
[16:00] <NCommander> #startmeeting
[16:00] <MootBot> Meeting started at 10:00. The chair is NCommander.
[16:00] <ogra_> moop
[16:01] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110519
[16:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110519
[16:01]  * NCommander pokes ogra_'s moop
[16:01] <ogra_> ouch !
[16:01] <ogra_> dont you touch my moop !
[16:02] <NCommander> [topic] Standing Items
[16:02] <MootBot> New Topic:  Standing Items
[16:02] <NCommander> [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html
[16:02] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html
[16:02] <NCommander> [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html
[16:02] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html
[16:02] <NCommander> None of my specs are showing up ...
[16:02]  * ogra_ isnt done yet with spec writing
[16:03] <NCommander> Oh right, it has to be approved, doesn't it
[16:03] <NCommander> bah
[16:03] <ogra_> NCommander, lets go over them to see if everything is set right (accepted etcd)
[16:03] <ogra_> after meeting
[16:03]  * davidm is happy bp are getting done
[16:03] <ogra_> but its good to see the tracker work
[16:04] <ogra_> doesnt look like as much hassle for me as last round
[16:04]  * NCommander likes our '2.0' blueprints for A1 :-)
[16:04] <NCommander> Right
[16:04] <NCommander> so moving on
[16:05] <NCommander> if my web browser didn't force quit ...
[16:05] <NCommander> [topic] Unity 2D Status
[16:05] <MootBot> New Topic:  Unity 2D Status
[16:05] <ogra_> use an ac100, its more stable :P
[16:05] <ogra_> i think we can drop that
[16:05] <ogra_> desktop team takes over now
[16:06] <ogra_> i talked to didrocks in budapest
[16:06] <davidm> I think it's DX team and desktop team
[16:06] <NCommander> cool
[16:06]  * NCommander brings dead to this standing item
[16:06] <ogra_> well, i think upstream is still the same
[16:06] <ogra_> not DX afaik
[16:06] <NCommander> [topic] Kernel Status (cooloney, rsalveti)
[16:06] <MootBot> New Topic:  Kernel Status (cooloney, rsalveti)
[16:06] <ogra_> heh
[16:06] <ogra_> NCommander, ppisati
[16:06] <rsalveti> :-)
[16:07] <ogra_> and we should probably include the linaro platform guys that work on kernel bits in that
[16:07] <ogra_> do you have any ?
[16:07] <rsalveti> send an SRU for bug 770679
[16:07] <NCommander> rsalveti: won't that require an item respin of natty, no?
[16:07] <rsalveti> still waiting for comments
[16:07] <rsalveti> NCommander: in theory yes
[16:08] <rsalveti> but we can just publish a new kernel file somewhere and update the wiki
[16:08] <rsalveti> like we did with maverick
[16:08] <ogra_> well, we can alsways provice replacement uInitrd and uImage
[16:08] <rsalveti> yeah, that's what we did with maverick
[16:08] <ogra_> right
[16:08] <rsalveti> but no other update
[16:08] <rsalveti> ti-omap4 kernel is kind of the same
[16:09] <rsalveti> will be sending another SRU for the drm driver next week
[16:09] <ogra_> do you have anyone in your team that should be included in the topic ping ?
[16:09] <rsalveti> now that I got that sorted out with linaro kernel
[16:09] <rsalveti> ogra_: that depends on what exactly we want to discuss
[16:09] <ogra_> same for any other of the standing topics :)
[16:09] <rsalveti> sure, we can solve this offline
[16:10] <ogra_> yeah
[16:10] <rsalveti> that's all for me
[16:10] <ogra_> ppisati, everything fine in your world ?
[16:11] <rsalveti> NCommander: put an action for you to include ppisati at this topic :-)
[16:11] <NCommander> rsalveti: I already edited the wiki
[16:11] <ogra_> well, seems he isnt around ... neither is cooloney
[16:11] <ogra_> so move :)
[16:12] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, janimo)
[16:12] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, janimo)
[16:12] <ogra_> its horrid
[16:12] <NCommander> fpc was bootstrapped on armel but beside that not much to add as the buildds drain
[16:12] <ogra_> yeah, will still need a while to lighten up
[16:12]  * NCommander isn't going to touch it until the build queue is close to empty
[16:13] <ogra_> i occasionally go over them and give back what looks like being worth it
[16:13] <ppisati> ogra_: let me read...
[16:14]  * ogra_ wonders where jani is
[16:14] <ogra_> still jetlagged from the 100km train ride probably :)
[16:14] <GrueMaster> heh
[16:14] <NCommander> ogra_: :-P
[16:14] <NCommander> can I move on?
[16:15] <ogra_> yeah
[16:15] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[16:15] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[16:15] <ogra_> well ...
[16:15] <ogra_> waiting for live-build to be implemented for x86
[16:15] <ppisati> ah k :)
[16:15] <ogra_> i guess then we have a very small window to make it work for A1
[16:16] <ogra_> the risk is high that we wont make A1 though
[16:16] <GrueMaster> Always is.
[16:16] <NCommander> Yeah
[16:16] <ogra_> in other news i worked the week on preparing everything for the ac100 image
[16:16] <NCommander> right now all CD image work is depwait A1, though cjwatson said if we implement stuff in livecd-rootfs, then he'll migrate it to livehelper
[16:16] <ogra_> the bits from https://launchpad.net/~ac100/+archive/ppa will land in oneiric next week
[16:17] <ogra_> so that we can start rolling images
[16:17] <ogra_> look, its a jani :)
[16:17]  * NCommander throws a pokeball at wild janimo
[16:17] <janimo> sorry, forgot what time it was
[16:17] <NCommander> :-P
[16:17] <ogra_> well, thats all about images atm ... toboin ?
[16:18] <ogra_> anything to say about nook ?
[16:18] <ogra_> GrueMaster, ^^
[16:18] <GrueMaster> Not yet.  Main focus has been on usbboot for panda.
[16:18] <ogra_> yeah, thought so
[16:18] <ogra_> though you had lots of converation going on about nook images in the channel :)
[16:18] <GrueMaster> Although one user has gotten some work towards making it boot natty.
[16:18] <ogra_> *conversation
[16:19] <NCommander> can I move on?
[16:19] <ogra_> go
[16:19] <NCommander> [topic] QA Status (GrueMaster)
[16:19] <MootBot> New Topic:  QA Status (GrueMaster)
[16:20] <GrueMaster> Hey, that's me!
[16:20] <ogra_> wohoo !
[16:20] <GrueMaster> My focus this week has been gitting panda to boot via usb blob from a host system.
[16:20] <ogra_> for automated image testing ;)
[16:21] <janimo> GrueMaster, this means no SD card needed at all?
[16:21] <ogra_> yeah
[16:21] <GrueMaster> This will help a lot for the new buildd deployment, and also help to build an image automation framework.
[16:21] <janimo> sweet
[16:21] <GrueMaster> No SD card was harmed in the making of thisproduction.
[16:21] <ogra_> lol
[16:21] <janimo> some SD cards deserve to be harmed though
[16:21] <ogra_> hehe
[16:22] <GrueMaster> Currently I am hung on getting the usb & network ports initialized.  I have a working kernel & initrd.
[16:22] <GrueMaster> Reviewing x-loader & u-boot code tosee what they do to enable them.
[16:22] <ogra_> i'll get you the initrd bits until monday
[16:23] <NCommander> GrueMaster: seems like a lot of it is hte board just isn't happy coming up OTG. could be an issue of whats being iniialized vs what isn't?
[16:23] <GrueMaster> I'm using the headless image as a test base.   I have the rootfs on a USB drive andam pushing down the kernel with a modified initrd.
[16:23] <GrueMaster> Yes.
[16:24] <GrueMaster> Not sure if it is the otg port getting in the way,but it shouldn't as they are completely separate circuits.
[16:24] <ogra_> NCommander, well, its the decision of putting half the board init code into x-loader and u-boot
[16:24] <NCommander> well yes
[16:24] <ogra_> if it would live in the kernel as it should, there wouldnt be any probs
[16:24] <GrueMaster> btw:  u-boot doesn't appear to support usb.
[16:24] <ogra_> GrueMaster, rsalveti is working on it
[16:25] <GrueMaster> yes, I know.
[16:25] <rsalveti> GrueMaster: u-boot supports usb now ;-)
[16:25] <ogra_> and martyn told me yesterday that the PXE support patch landed upstream
[16:25] <rsalveti> and TFTP
[16:25] <GrueMaster> Hopefully we can work together today and get a solution.
[16:25] <rsalveti> on my branch
[16:25] <GrueMaster> Nice.
[16:25] <rsalveti> but I still prefer to jump into the kernel directly
[16:25] <ogra_> \o/
[16:25] <ogra_> ++
[16:26] <ogra_> but at least we have something even if that doesnt work
[16:26] <rsalveti> anyway, just working with GrueMaster to see what we can get
[16:26] <rsalveti> yup :-)
[16:26] <GrueMaster> The aboot->kernel method is much cleaner, but what ever it takes to get forward progress is semi-acceptable.
[16:26] <ogra_> the good thing is that we could even use it in the images and boot *way* faster
[16:26] <rsalveti> let's spend some more time trying to get this to work
[16:27] <ogra_> we should inspect that
[16:27] <GrueMaster> once I get this working (critical priority), I'll focus on blueprint refinement and nook color.
[16:27] <rsalveti> yeah, can add that at my u-boot tftp bp
[16:27] <rsalveti> I'll be changing it to "alternatives to boot ubuntu images"
[16:27] <rsalveti> something like that
[16:27] <rsalveti> omap4boot
[16:27] <ogra_> cool !
[16:27] <rsalveti> u-boot with TFTP and PXE
[16:27] <rsalveti> and u-boot with fastboot
[16:28] <rsalveti> that should cover most of the cases, if not all
[16:28] <GrueMaster> That's all from me.  Questions?
[16:28] <ogra_> not here
[16:29] <NCommander> [topic] Specification Status
[16:29] <MootBot> New Topic:  Specification Status
[16:29] <NCommander> probably a good idea to go over this
[16:30] <NCommander> I have two spcs drafted, one reviewed, one I mostly completed then handed off, and one that still needs a writeup
[16:30]  * ogra_ has nothing to report yet ... mine will be ready by monday
[16:31] <ogra_> janimo, GrueMaster ?
[16:31] <janimo> I have work items more or less written up on my specs
[16:31] <janimo> but no other work. Drafting means filling up the wiki template?
[16:31] <ogra_> (and anyone else having specs on the team tracker :) )
[16:31] <ogra_> janimo, yeah
[16:31] <GrueMaster> I think NCommander has been plastering me with work items.  I have been toofocused to check.
[16:31] <janimo> team tracker == burndown charts?
[16:31] <ogra_> you dont need all topics from the tamplate, only what makes sense in your context
[16:32] <ogra_> yeah team tracker == burndown
[16:34] <NCommander> [topic] ABO
[16:34] <MootBot> New Topic:  ABO
[16:34]  * NCommander has nothing
[16:34] <GrueMaster> ABO???
[16:34] <ogra_> ABO ?
[16:34] <ogra_> OBA ?
[16:34] <NCommander> [topic] AOB
[16:34] <MootBot> New Topic:  AOB
[16:34] <ogra_> BOA ?
[16:34] <GrueMaster> BOA?
[16:34]  * NCommander beats ogra_
[16:34] <ogra_> BAOBAB
[16:34] <GrueMaster> BAO?
[16:34] <ogra_> BLAH :)
[16:34]  * ogra_ doesnt have anything for this topic
[16:34] <NCommander> I'm guessing we don't
[16:35] <NCommander> closiging the meeting in 3
[16:35] <NCommander> 2
[16:35] <NCommander> 1
[16:35] <NCommander> #endmeeting
[16:35] <MootBot> Meeting finished at 10:35.
[18:59] <pitti> cjwatson, mdz, kees, Keybuk: TB meeting now?
[18:59] <Keybuk> present
[19:02] <kees> \o
[19:02] <sabdfl> o/ ?
[19:02] <sabdfl> ;-)
[19:02] <kees> I have a hard-stop in 30 minutes, though
[19:04] <Keybuk> who is chair today?
[19:04] <kees> agenda says mdz
[19:04] <pitti> sent SMS to mdz and cjwatson
[19:05] <sabdfl> https://wiki.ubuntu.com/TechnicalBoardAgenda
[19:05] <sabdfl> should we just dive in?
[19:05] <sabdfl> do we have anything like a quorum?
[19:05] <pitti> four people should be enough?
[19:05] <kees> yeah, we have 4
[19:06] <sabdfl> ok, i'll take the chair, i'm somewhat overdue
[19:06] <sabdfl> MootBot: #startmeeting
[19:06] <sabdfl> sigh
[19:07] <sabdfl> help
[19:07] <pitti> without the mootbot: I think
[19:07] <persia> Don't highlight MootBot when starting
[19:07] <sabdfl> #startmeeting
[19:07] <MootBot> Meeting started at 13:07. The chair is sabdfl.
[19:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:07] <cjwatson> hi, I'm here now
[19:07] <sabdfl> [TOPIC] Status of Lubuntu
[19:07] <MootBot> New Topic:  Status of Lubuntu
[19:08] <sabdfl> we had a session or two at UDS on this
[19:08] <cjwatson> I think Lubuntu was adequately resolved at UDS, yes
[19:08] <cjwatson> it is blocked on more disk on antimony + cdimage.ubuntu.com internal mirrors, but that is in train
[19:08] <sabdfl> cjwatson: elmo says np to bigger disks on cdimage
[19:08] <cjwatson> right
[19:08] <cjwatson> blocked as in that-hasn't-happened-yet, not as in we-need-to-convince-people
[19:08] <sabdfl> okdokey
[19:09] <sabdfl> so, the status is it will be official as soon as we have the new space, and that's approved, just not actioned
[19:09] <kees> sounds good to me
[19:09] <cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=45727, for Canonical folks
[19:09] <sabdfl> i'll document that in the meeting report, i don't think we need to announce anything till we actually have a release
[19:09] <Keybuk> cool
[19:09] <cjwatson> agreed - it'll be easy to turn on once we have headroom
[19:09] <sabdfl> i'm sure the Lubuntu folks will take the opportunity to raise their banner
[19:10] <sabdfl> ok, wrapped
[19:10] <pitti> shoudl we follow up to Julien on the list?  or was that already resolved at UDS?
[19:10] <sabdfl> [TOPIC] ffmpeg vs libav
[19:10] <MootBot> New Topic:  ffmpeg vs libav
[19:10] <sabdfl> pitti: i think it's resolved, but feel free to send him this snippet of IRC?
[19:10] <pitti> sabdfl: sure
[19:11] <cjwatson> pitti: yeah, Julien knows
[19:11] <kees> so, it's not just Ubuntu -- Debian did the ffmpeg -> libav thing too, but that masks a bit that it's the same maintainer
[19:11] <sabdfl> hmm.. why are we not listed at https://wiki.ubuntu.com/Teams ?
[19:12] <sabdfl> i was looking for the team report page
[19:12] <cjwatson> good question
[19:13] <sabdfl> ok, will find that later
[19:13] <cjwatson> https://wiki.ubuntu.com/TechnicalBoard/TeamReports
[19:13] <sabdfl> kees, so we are de-facto diverged from debian, for lack of consensus on this within ubuntu?
[19:13] <pitti> would be intersting to hear siretart's side of the storey
[19:13] <pitti> story
[19:13] <cjwatson> libav is currently waiting in NEW IIRC
[19:13] <cjwatson> not due to any particular archive admin animus that I'm aware of, but just post-oneiric-opening/UDS backlog
[19:14] <cjwatson> oh, wait, I stand corrected
[19:14] <cjwatson> libav is in oneiric
[19:14] <cjwatson> so we are not at present diverged from Debian, except by an Ubuntu delta to the libav package
[19:14] <cjwatson> which is small: http://patches.ubuntu.com/liba/libav/libav_4:0.7~b1-1ubuntu1.patch
[19:14] <kees> libav is even in _natty_
[19:15] <kees> and their versioning is charging ahead.
[19:15] <sabdfl> is there any certainty that libav will be a more cohesive community?
[19:15] <cjwatson> you're right, I must have been thinking of binary NEW
[19:15] <sabdfl> for example, will they take a more dev-friendly approach to sonames?
[19:15] <cjwatson> personally I'm extremely reluctant to take any view at all on this without hearing both sides - has anyone been in touch with Reinhard about this?
[19:16] <cjwatson> libav has what looks like actual versions rather than datestamps
[19:16] <kees> sabdfl: that's my question too. I don't feel like I have all the information I need to form an opinion
[19:16] <cjwatson> oh, blah, so did our ffmpeg packages
[19:16] <kees> cjwatson: I haven't heard from siretart
[19:17]  * micahg is a little sore about breaking BC in the libavcodec52 to libavcodec53 transition, but idk what that's worth
[19:17] <cjwatson> it's clear to me that there's a social split in the community, but I don't think we should be attempting to judge that
[19:17] <sabdfl> is there an active thread on -tb? is this something that needs a private conversation, if it's about social dynamics that are already stressed upstream?
[19:17] <pitti> no active thread AFAICS
[19:17] <cjwatson> we should be taking a decision on technical merit, which probably to some extent needs to include the views of the developers willing to work on this in Debian/Ubuntu (although not necessarily be dominated by that)
[19:18] <cjwatson> much of the impetus for the mail sent to us seems to be social
[19:18] <pitti> realistically, if we'd decide for ffmpeg instead of libav, we'd need someone else to maintain it, though
[19:18] <cjwatson> (though there is some technical content)
[19:19] <kees> yeah, if the Debian and Ubuntu maintainer chose libav, that does carry a fair bit of weight
[19:19] <cjwatson> micahg: BC?
[19:19] <kees> binary compat
[19:19] <micahg> cjwatson: backwards compatability
[19:19] <kees> oh
[19:19] <kees> heh. I thought you meant ABI
[19:19] <cjwatson> in a sense stronger than what usually happens when you change soname?
[19:19] <cjwatson> was it an API break as well?
[19:19] <micahg> cjwatson: yes
[19:20] <kees> owch
[19:20] <cjwatson> ok, well - that does happen sometimes, I'm not sure that should be determining without details
[19:20] <cjwatson> if we never allowed API breaks there wouldn't be much in the platform :-)
[19:20] <kees> right
[19:20] <kees> but to do it so "soon" after a fork makes things almost more painful.
[19:21] <cjwatson> I'm feeling very low on facts here
[19:21] <micahg> some of it was cleaning up namespaces
[19:21] <cjwatson> can somebody take an action to catch up with siretart and get his side?
[19:21] <kees> I'll take that
[19:22] <cjwatson> sorry, I'm back-seat-chairing, I should stop that
[19:23] <sabdfl> it's very helpful when it's helpful :-)
[19:23] <sabdfl> [ACTION] kees, invite siretart to comment on TB list, or in private, as appropriate
[19:23] <MootBot> ACTION received:  kees, invite siretart to comment on TB list, or in private, as appropriate
[19:23] <cjwatson> I was about to say that we should have somebody with relevant expertise go off and produce an impartial report, but one might reasonably argue that that's the TB's job :-P
[19:24] <sabdfl> [TOPIC] Follow up on https://bugs.launchpad.net/bugs/451390 (mdz)
[19:24] <MootBot> New Topic:  Follow up on https://bugs.launchpad.net/bugs/451390 (mdz)
[19:25] <pitti> hm, fixed a week ago
[19:25] <cjwatson> that bug is apparently closed in LP, but I have not got round to finding somebody with the right set of privileges to real-world-test it
[19:25] <pitti> I can take that
[19:25] <kees> cjwatson: we could maybe try bjf?
[19:25] <pitti> we have plenty of non-core-devs in the desktop team
[19:25] <kees> he was most recently added to ubuntu-drivers for the nominations purpose
[19:25] <micahg> I tested it, I can now approve stuff in main that I can upload even though I"m MOTU
[19:25] <kees> micahg: ah! even better, thanks!
[19:26] <pitti> ah, good
[19:26] <sabdfl> so, that's fix confirmed?
[19:26] <pitti> so we can also close the community task then
[19:26] <kees> we probably need another action to purge ubuntu-drivers of people that were added there as a work-around for this bug
[19:26] <sabdfl> pitti: can you take care of that?
[19:27] <pitti> sabdfl: no, because I already did it :)
[19:27] <sabdfl> :-)
[19:27] <sabdfl> it's that time machine of yours, pitti
[19:27] <sabdfl> do we all have admin on ubuntu-drivers?
[19:27] <sabdfl> do we know who was added just for that purpose?
[19:27] <pitti> sabdfl: yes, TB owns it
[19:28] <pitti> jasoncwarner is the latest member, I think that was done at UDS
[19:28] <pitti> so that he could shuffle around the summit schedule
[19:28] <sabdfl> i doubt that's for this case, though
[19:28] <pitti> right
[19:28] <pitti> it was for blueprint handling
[19:28] <pitti> I only overheard it, though
[19:29] <sabdfl> we could of course just purge -drivers and add those who notice :-)
[19:29] <sabdfl> were all such additions documented in TB meetings, or ad-hoc?
[19:29] <pitti> https://launchpad.net/~ubuntu-drivers/+members doesn't look unreasonable, though
[19:30] <pitti> pretty much the tech leads, and folks who should be able to approve/change blueprints
[19:30] <sabdfl> josh hoover?
[19:30] <kees> it's been ad-hoc, afaik. I have removed bjf, as he was one I added and documented in the nominations bug report
[19:30] <pitti> sabdfl: U1 team uses ubuntu blueprints for their work
[19:30] <sabdfl> ok, let's consider that done
[19:30] <sabdfl> [TOPIC] Action review
[19:30] <MootBot> New Topic:  Action review
[19:31] <kees> I have to go now; I'll check backscroll when I'm back.
[19:31] <sabdfl> cheers kees
[19:31] <sabdfl> Action: rickspencer3 will bring up the state of unity on the -desktop list for public review and discussion
[19:31] <sabdfl> done
[19:32] <sabdfl> I asked for a review between TB and DX and Desktop on Natty/Unity at UDS, but failed to get to it myself.
[19:32] <sabdfl> I saw good dialogue between DX and Platform-Desktop about how to improve processed for Oneiric
[19:32] <sabdfl> but figured TB would have useful commentary and critique
[19:33] <sabdfl> did anyone here get to that session?
[19:34] <pitti> not me unfortunately
[19:34] <pitti> oh, except if that was the session where everyone brought up their pet bugs
[19:34] <pitti> (and praises)
[19:34] <pitti> I was in that one
[19:34] <sabdfl> no, i think that was the Unity design review
[19:34] <pitti> right
[19:35] <sabdfl> from a governance point of view, i thought the debate / discussion about unity-by-default was healthy
[19:35] <pitti> on -devel@? I agree
[19:35] <sabdfl> however, i think it flagged a lack of clarity on responsibilities and delegation
[19:35] <cjwatson> I think I was in that session - http://summit.ubuntu.com/uds-o/meeting/community-o-natty-retrospective/
[19:36] <sabdfl> from my perspective, TB is on the hook for technical decisions, the health of the developer community, quality, across the whole archive
[19:36] <pitti> ah, now I remember, thanks cjwatson for the link
[19:36] <cjwatson> there was a lot of discussion about when people felt it appropriate to involve the TB in things, and some fairly obvious disconnect
[19:36] <sabdfl> i think the TB could rightly have provided guidance and critique on freezes, testing, dependencies, delivery
[19:36] <cjwatson> also discussion about the role of the TB versus the release team
[19:37] <sabdfl> i think teh release and desktop teams, however, need to feel they have a mandate too
[19:37] <cjwatson> I think I view the release team as sort of the "ordinary" authority on these matters, and the TB is an appeals/escalation body as well as sort of wider policy setting
[19:37] <sabdfl> right
[19:37] <ScottK> I was in the session and expressed views similar to cjwatson
[19:37] <pitti> that mainly clarified the status quo of reactive "where the buck stops" dispute resolution (TB) vs. "day-to-day exception processing and archive consistency" (release)
[19:38] <sabdfl> i felt we undermined the desktop team a little by leaving the scope of the conversation so wide
[19:38] <cjwatson> in my view the unity-by-default debate should probably have involved the release team more than it did, but at the time, bouncing things around between groups would have been unnecessary bureaucracy
[19:38] <cjwatson> given the short timescales involvd
[19:38] <sabdfl> i hoped the natty retro would give the TB an opportunity to set tighter guidelines on things which define the quality of the release, while also strengthening the desktop teams ability to make in/out calls
[19:38] <pitti> TBH the discussion about unity or not wasn't really a good release team matter anyway, as this is was a major project-wide decision
[19:39] <sabdfl> right - we'll likely only ever see micro-versions of that debate in future
[19:39] <cjwatson> we talked about the way the TB is quite reactive, and I mentioned that a while back we started trying to deal with something proactively every now and again, but it kind of fizzled out
[19:39] <sabdfl> and those are unlikely to get kicked up
[19:39] <cjwatson> somebody suggested having a secretary to the TB whose job it is to keep track of the kinds of things we ought to be discussing, which I think is a great idea
[19:39] <cjwatson> was that ScottK?
[19:39] <ScottK> That was me.
[19:40] <sabdfl> i think it would help if we had non-Canonical representation in the desktop team
[19:40] <sabdfl> however, such folk will certainly feel pressure, possibly unfairly, from all quarters
[19:40] <cjwatson> I'm slightly cautious of fighting the last war (if you'll excuse the martial metaphor)
[19:40] <cjwatson> the next debate of this king may not be anything to do with the desktop
[19:40] <cjwatson> *kind
[19:41] <sabdfl> right, but the underlying principle should hold
[19:41] <pitti> *cough* systemd *cough*
[19:41] <persia> Encouraging teams to consist of members from several viewpoints is likely useful regardless of the conflict.
[19:41] <sabdfl> well, that one may well be for the TB, as it's hardly desktop OR Server OR kubuntu OR ...
[19:41] <pitti> (as a totally random example of what might come up as a similar discussion)
[19:43] <sabdfl> but is there any difference of opinion about the TB as guardian of quality, of talent and code, delegating decisions like in/out app selections to teams like -desktop?
[19:43] <ScottK> Also for technical dispute resolution.
[19:44] <sabdfl> that too
[19:44] <cjwatson> sabdfl: I don't think anyone is of the opinion that the TB should be micromanaging day-to-day (or even month-to-month) decisions
[19:44] <sabdfl> Keybuk: as a non-Canonical voice, what say you?
[19:44] <persia> For consistency with the ReleaseManifests, I'd prefer if the TB delegated those decisions to the Product Managers, but in practice, it's nearly the same thing.
[19:44] <cjwatson> which is good because I don't think we could if we wanted to :-)
[19:45] <Keybuk> sabdfl: I think as long as things are discussed in Ubuntu forums, it's ok
[19:45] <Keybuk> e.g. UDS is a great place to have those kinds of technical discussions
[19:45] <Keybuk> likewise the Ubuntu mailing lists
[19:45]  * pitti has some difficulty with answering that question about the unity example, as the desktop team (and me) was quite biased
[19:46] <sabdfl> agreed
[19:46]  * ScottK died a little inside when Keybuk said "Ubuntu forums" as a place for technical discussions.  Thanks for clarifying.
[19:46] <Keybuk> I think we only have a problem if technical decisions for Ubuntu are made entirely within Canonical, and that's an appropriate juncture for the TB to step in, at least if only to bring the community back into the mix
[19:46] <Keybuk> ScottK: the lowercase "f" was deliberate
[19:46] <sabdfl> the English sense of "forum" :-)
[19:46] <cjwatson> Ubuntu fora, to distinguish ;-)
[19:46]  * cjwatson hides
[19:46] <sabdfl> the Latin sense of fora :-)
[19:46] <sabdfl> alright
[19:46] <sabdfl> let's stop buggering around
[19:46] <Keybuk> cjwatson: fora, forii or foruum?
[19:46]  * ScottK knew, but it was too funny to leave there.
[19:47] <sabdfl> Action: mdz to attach missing patches for debian bugs<PHONE_NUMBER>32 35325 and 326677
[19:47] <Keybuk> pitti: I think there will always be bias, humans are biased things
[19:47] <Keybuk> but another word for bias is passion ;-)
[19:47] <pitti> from my POV, the TB was quite the right place to resolve that question of "unity by default", modulo sabdfl decision
[19:47] <pitti> Keybuk: that's what I really meant, I guess
[19:47] <Keybuk> and I think if one person is particularly passionate about something, and the opposing side can't drum up equivalent amounts of passion to debate
[19:48] <Keybuk> then meh, passion wins :)
[19:48] <pitti> and I can't really claim that I have always been 100% objective in my appraisals for unity by default
[19:48] <cjwatson> the second and third of those Debian bugs have been dealt with
[19:48] <cjwatson> or at least in progress
[19:48] <cjwatson> I don't see action on the first and fourth, though I know mdz is tracking this as part of DEX and perhaps we don't need to track it hre
[19:48] <pitti> Keybuk: fair enough
[19:48] <cjwatson> but how about we leave it on the list 'til mdz's next here to answer
[19:49]  * Keybuk has to run in a minute
[19:49] <sabdfl> ok
[19:49] <sabdfl> [TOPIC] Mailing items outstanding
[19:49] <MootBot> New Topic:  Mailing items outstanding
[19:50] <cjwatson> https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html is the biggest one
[19:50] <Keybuk> there's the item from Evan, but since neither Evan or Steve are here to debate it, we should probably defer
[19:50] <cjwatson> I don't know if we can do it justice in ten minutes, anyway
[19:50] <cjwatson> let's apologise and properly agenda-ify it for next time, maybe?
[19:50] <sabdfl> this is brand new, isn't it?
[19:50] <sabdfl> yes
[19:50] <cjwatson> it is
[19:50] <sabdfl> ok, we should give it some email air
[19:51] <sabdfl> [TOPIC] Community bugs
[19:51] <MootBot> New Topic:  Community bugs
[19:52] <sabdfl> anything of note?
[19:52] <cjwatson> mdz has assigned https://bugs.launchpad.net/ubuntu-community/+bug/252368 to us
[19:52] <cjwatson> (the other one is old)
[19:53] <sabdfl> sounds like something for the stakeholders meeting, or a call-for-a-patch
[19:53] <cjwatson> but I'm not clear what he wants to discuss there - it seemed to me that Debian had already offered some suggestions and it was just that it wasn't easy to do in LP?
[19:53] <sabdfl> sounds entirely scriptable with LP's API
[19:53] <pitti> the "if" is (hopefully?) not much of a debate, or does anyone think this shouldn't be done for some reason?
[19:54] <sabdfl> iirc, this was something we wanted to do at the start, so no debate here
[19:54] <pitti> so, "Triaged"?
[19:55] <sabdfl> does it being assigned to us mean we need to do something beyond raise it on the stakeholders discussion with LP?
[19:55] <sabdfl> sure
[19:55] <micahg> just to clarify, this is only for e-mail access and not soyuz, right?
[19:55] <pitti> that's how I understand it; for actions in emails to be effective you need to gpg sign
[19:55] <pitti> like " status fixcommitted"
[19:56] <persia> Unless someone does something special, it would work for soyuz as well (but is unrelated to upload rights to Ubuntu: initially affects Soyuz through PPAs)
[19:56] <sabdfl> ok. i think that's a wrap
[19:56] <sabdfl> next meeting? and chair?
[19:56] <cjwatson> I have one AOB
[19:56] <cjwatson> just briefly?
[19:56] <sabdfl> go ahead of course
[19:57] <cjwatson> somebody (I forget who, sorry) asked me at UDS about the status of appointing an Ubuntu community representative on the Launchpad stakeholders meeting
[19:57] <cjwatson> I remembered that we discussed it but couldn't remember how far we got
[19:57] <sabdfl> elected by the non-Canonical contributors to LP? ;-)
[19:57] <cjwatson> does anyone remember the status, or shall I put it on the agenda for next time?
[19:58] <cjwatson> no, somebody to put forward the interests of the Ubuntu community as opposed to Ubuntu Platform Engineering
[19:58] <pitti> I think we discussed something like this in Orlando, but back then it wasn't "non-Canonical"
[19:58] <persia> I don't remember getting any feedback to my mail to the TB from some time back: I asked for the TB to appoint someone, without restrictions on the person the TB selected.
[19:58] <sabdfl> i'm sure Francis would be happy to entertain it
[19:58] <pitti> just "someone who is credibly speaking for the ubuntu community"
[19:58] <cjwatson> sabdfl: yes, he was, and we discussed it in the TB
[19:58] <cjwatson> what I have no idea about, stateless automaton that I am, is how far we got :-)
[19:59] <cjwatson> how about I do some homework on it and follow up next time, then
[19:59] <sabdfl> i was only partly joking about picking from the pool of contributors
[19:59] <pitti> a year ago we had three candidates on the table, IIRC
[19:59] <sabdfl> some familiarity with processes, scale, pace of change, complexity would be helpful if that person wants real influence
[19:59] <pitti> Keybuk, bryce, sladen were proposed back then
[19:59] <persia> https://lists.ubuntu.com/archives/technical-board/2010-November/000571.html
[20:00] <sabdfl> bryce has certainly climbed in with both feet
[20:00] <pitti> https://lists.ubuntu.com/archives/technical-board/2010-November/000571.html
[20:00] <pitti> ah
[20:01] <sabdfl> i'd be +1 bryce
[20:01] <cjwatson> anyway, I realise we're out of time, so I'll chase down the discussions I'm sure I remember beyond that mail
[20:01] <persia> It's probably worth reconfirming with the nominees that they would still be willing to serve.  I haven't spoken to any of them about it in ~6 months.
[20:01] <sabdfl> persia, will you chat to bryce about it?
[20:01] <sabdfl> next meeting is...
[20:01] <persia> Sure.  I can re-canvass, and send another mail.
[20:01] <sabdfl> and chair... mdz?
[20:02] <cjwatson> seems like his turn
[20:02] <sabdfl> anyone know the date?
[20:02] <sabdfl> then we can wrap :-)
[20:02] <persia> 2nd June (UTC)?
[20:02] <sabdfl> ok, done. thank you all!
[20:02] <sabdfl> #endmeeting
[20:02] <MootBot> Meeting finished at 14:02.
[20:02] <pitti> thanks everyone!
[20:03] <cjwatson> cheers