[00:33] <wgrant> Wow, congrats lifeless.
[00:33] <poolie> yes, indeed
[00:33] <poolie> hi wgrant
[00:34] <wgrant> Morning poolie.
[00:34] <poolie> i think robert's new role will have benefits for you in particular
[00:35] <wgrant> Oh?
[00:35] <poolie> being another step towards openness and ease of contribution
[00:35] <poolie> "think or hope" i suppose
[00:40] <poolie> leonardr: did you read jml's lep about api access to authentication tokens?
[00:41] <lifeless> thumper: thanks
[00:42] <lifeless> wgrant: thanks; poolie: thanks
[00:42] <poolie> i miss you lifelesS!
[00:45] <lifeless> already? I'm not gone till Monday :)
[00:45] <poolie> well, i did briefly
[00:45] <lifeless> and even then, I think its appropriate to think of it as expanding - like my waistline - the bzr team is definitely able to call on me to discuss stuff :)
[00:45] <poolie> :)
[00:46] <lifeless> oh, or did you mean as an office-mate
[00:46] <poolie> yes, that's what i meant
[00:46] <lifeless> righto ! - 5 hours sleep last night, but boy, better sleep than I had been getting
[00:46] <lifeless> have seen allergy doctor this morning
[00:47] <lifeless> so; finally; no medical stuff to do for a month; no frenzy; a feeling of peace surrounds me :)
[00:48] <wgrant> lifeless: I'm sure we can invoke an architecture frenzy for you :P
[00:59] <lifeless> hmm, are we in testfix mode I wonder
[00:59] <lifeless>   restricted_families = archive_arch_set.getRestrictedfamilies(self)
[00:59] <lifeless> ForbiddenAttribute: ('getRestrictedfamilies', <lp.soyuz.model.archivearch.ArchiveArchSet object at 0x143bc190>)
[01:00] <lifeless> seems unrelated to oops infrastructure changes
[01:01] <lifeless> ah yes.
[01:51] <thumper> lifeless: a feeling of peace except for the frantic travelling coming?
[01:53] <lifeless> thumper: compared to the last three months, its quiet
[02:01] <ajmitch> lifeless: great, so I can ask you all my LP questions now? :)
[02:02] <lifeless> yes
[02:02] <lifeless> Not that that would seem to be any different
[02:03] <ajmitch> heh
[02:38] <wgrant> Can I coerce someone into ec2landing https://code.edge.launchpad.net/~wgrant/launchpad/faster-and-more-general-getBuildQueueSizes/+merge/28476 ?
[02:40] <lifeless> wgrant: does that fix henninge's patch ?
[02:41] <lifeless> rev 11093 seems to break everything, or perhaps its just my branch it breaks.
[02:41] <lifeless> if not, then no, I can't be coerced.
[02:41] <wgrant> You mean jelmer's/
[02:41] <lifeless> ah yeah
[02:41] <lifeless> the one reviewed by
[02:41] <wgrant> That is a bit confusing.
[02:42] <wgrant> I wonder why PQM doesn't use --author.
[02:42] <wgrant> lifeless: Which is the test that breaks?
[02:43] <lifeless> wgrant: pqm doesn't use --author because its not the author.
[02:43] <lifeless> log -n0 shows the people totally accurately.
[02:43] <lifeless> alias it on.
[02:43] <wgrant> lifeless: Doesn't help for commit notifications.
[02:43] <lifeless> wgrant: we should fix that, then.
[02:44] <wgrant> Is there a testfix in progress?
[02:44] <lifeless> bzr has the real data; this is a presentation issue IMO: fudging it by feeding PQM an approximation you want to see on the outside just leads to harder to work with data.
[02:45] <lifeless> wgrant: I'm not sure how to look that up yet.
[02:45] <lifeless> wgrant: and today is a bzr day :)
[02:45] <wgrant> lifeless: Well, if you tell me which test fails, I will fix it. It's just an s/f/F/.
[02:46] <lifeless> sure
[02:47] <lifeless> yu have mail
[02:48] <wgrant> Thanks.
[02:48] <lifeless> de nada
[02:54] <wgrant> Huh.
[02:54] <wgrant> Did that get *CPed* without being EC2'd?
[02:54] <wgrant> Crazy.
[02:59] <lifeless> da wtf
[02:59] <poolie> lifeless: i don't know the state of the committed/released distinction
[03:00] <poolie> there are various contradictory bugs
[03:00] <poolie> i don't think it's useful
[03:00] <poolie> in that it makes noise while simplifying reality too much to be useful
[03:00] <poolie> but maybe that's just me
[03:00] <lifeless> I really don't like the noise when a release happens
[03:00] <lifeless> The 'it is available to the user to use now' aspect is good though.
[03:00] <lifeless> perhaps doing daily releases would address it ?
[03:01] <lifeless> (e.g. edge :))
[03:01] <poolie> that's one element of my dissatisfaction
[03:01] <poolie> 'fix released' does not aiui reliably mean you will see the fix, even on edge
[03:02] <poolie> doing daily releases would be good
[03:02] <poolie> it wouldn't reduce the amount of noise
[03:03] <lifeless> whats one of the bug numbers you saw
[03:03] <poolie> istm that a lean view of the process is: it's waiting, it's in progress, it's done
[03:03] <lifeless> I'm wondering if I'm missing a subscription somewhere
[03:03] <poolie> bug 592792
[03:03] <lifeless> yeah, I need to tweak my subscriptions
[03:03] <lifeless> \o/ more mail.
[03:04] <wgrant> poolie: You're saying that's not fixed on edge?
[03:04] <lifeless> poolie: perhaps there are two clients here - the feature requestor and the dev asking 'do I have more to do' ?
[03:04] <poolie> wgrant: that was a bug that sent me mail, i'm not saying it is or isn't fixed on edge
[03:05] <poolie> lifeless: there are
[03:05] <poolie> the feature requester wants to know "is it worth me testing whether it's really fixed"
[03:05] <poolie> or "bothering to try that again" etc
[03:05] <lifeless> if we try we can probably make both deeply unhappy
[03:05] <poolie> heh
[03:05] <lifeless> oops, thats the wrong way around :)
[03:06] <poolie> istm that a state change is not enough
[03:06] <poolie> without saying "this is live on edge now" or "this will be in bzr2.2b4"
[03:07] <lifeless> I need a volunteer at the epic, with a 2 minute 'lightning talk' screen
[03:09] <thumper> lifeless: in a certain light, isn't the point of --author to say who the author of the code is?
[03:09] <thumper> lifeless: a merge isn't really code
[03:09] <thumper> so pqm could be the committer, and set the author
[03:10] <thumper> which is what I think many people think like
[03:10] <lifeless> thumper: if you squint real real hard, but both Aaron and I have argued that this is working around a bug rather than fixing the root cause.
[03:10] <thumper> :)
[03:10] <lifeless> thumper: if we were sending in *patches* it would be trivially correct to use --author
[03:11]  * thumper cranks up the muzak
[03:11] <lifeless> code in an elevator?
[03:12] <thumper> matrix soundtrack
[03:12] <lifeless> nice
[03:57] <wgrant> thumper: So, how do I get this testfix merged?
[03:57]  * thumper looks up
[03:57] <thumper> wgrant: eh?
[03:57] <thumper> what's broken?
[03:57] <foxxtrot> Is there an easy way to run all the windmill tests in a given JS file? I know you can bin/test PATH/TO/PYTHON/FILE.py but that doesn't work for a JS file
[03:57] <wgrant> prod_lp, at least, but devel should be too.
[03:57] <lifeless> wgrant: oh right
[03:57] <lifeless> wgrant: whats the branch, I'll ec2land it
[03:58] <wgrant> lifeless: Is that going to work with [testfix]?
[03:58] <lifeless> I don't know the process yet :)
[03:58] <lifeless> thumper: how does one land a testfix fixing branch
[03:58] <thumper> pqm-submit
[03:58] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/testfix-getRestrictedfamilies is the branch. Trivial -- there were just some references in db-devel that were merged in while the branch was landing.
[03:58] <lifeless> thumper: directly, not ec2land ?
[03:59] <thumper> for a test fix, normally yes, but...
[03:59] <thumper> it depends on the extent of the fix
[03:59] <thumper> since buildbot is broken anyway
[03:59] <thumper> adding an extra ec2 run doesn't add anything
[04:00] <wgrant> All the archive and PPA tests pass fine.
[04:00] <wgrant> Which is, I believe, all that failed in lifeless' run.
[04:00] <wgrant> Although I haven't worked out how to get a list from the gzipped thing yet.
[04:01] <lifeless> wgrant: gunzip -c | subunit-filter | subunit-ls
[04:01] <lifeless> wgrant: or
[04:01] <lifeless> gunzip -c | testr load; testr failing
[04:02] <wgrant> Fancy.
[04:02] <lifeless> nah
[04:02] <lifeless> its all about the onions
[04:02] <lifeless> if you want fancy
[04:02] <lifeless> gunzip -c | tribunal -
[04:02] <lifeless> now thats sexy
[04:03] <thumper> I'd just like the failing tests back in the email body :(
[04:03] <lifeless> thumper: they are
[04:03] <wgrant> thumper: +1
[04:03] <lifeless> aren't they ?
[04:03] <thumper> no
[04:03] <lifeless> oh right, I mailed bac and mars when jml forwarded me mail
[04:03] <lifeless> its very shallow. Lets do it at the epic.
[04:04]  * thumper nods
[04:04] <lifeless> thumper: can you pqm-submit wgrants branch? the change is a three-liner, one char per line ;)
[04:04] <lifeless> thumper: (given you're all setup for it)
[04:04] <lifeless> I've got ec2land setup, not pqm-submit yet.
[04:04] <lifeless> Hmm, I should make hydrazine talk lp targets to
[04:05] <lifeless> too
[04:05] <thumper> I only have devel and db-devel set up
[04:05] <thumper> I should be able to do it without too much problem though
[04:05] <lifeless> it should land on devel fine.
[04:05] <lifeless> in devel if I do a missing on his branch I see just one commit
[04:05] <wgrant> I'm not sure if this will work on production-devel, since I can't see it.
[04:05] <thumper> it seems the error isn't on devel is it?
[04:05] <wgrant> But it should be fine.
[04:05] <wgrant> devel is broken.
[04:05] <lifeless> devel is naffed too
[04:05] <thumper> ah
[04:05] <wgrant> I'm not sure if there's a failure yet, but it is broken.
[04:06] <thumper> the devel failure was a weird twisted one
[04:06] <thumper> I'll land wgrants
[04:06] <wgrant> thumper: Thanks
[04:06] <wgrant> lifeless: How do I run tests with testrepository?
[04:07] <wgrant> quickstart doesn't say.
[04:08] <lifeless> testr run
[04:08] <wgrant> Ah, I presumed I'd have to pipe 'testr failing' in or something.
[04:09] <lifeless> wgrant: you can (testr load - in the quickstart)
[04:09] <lifeless> but you can also run tests directly if there is a .testr.conf
[04:09] <lifeless> please file a bug though
[04:09] <lifeless> that should be polished more
[04:09] <thumper> :(
[04:09] <thumper> bzr crashed
[04:10] <thumper> bzr pqm-submit -m "[testfix][r=thumper] getRestrictedfamilies camel case fixup." --public-location=lp:~wgrant/launchpad/testfix-getRestrictedfamilies --ignore-local --submit-branch=../devel
[04:10] <thumper> that is what I tried
[04:10] <thumper> and it crashed
[04:10] <wgrant> What did it complain about?
[04:10] <Muscovy> Does anyone know anything about: createlang: language installation failed: ERROR:  could not access file "$libdir/plpython": No such file or directory ? It happens in an updated default install of 10.04 server.
[04:10] <thumper> NoPQMSubmissionAddress
[04:11] <thumper> basicly
[04:11] <Muscovy> It happens during "make schema".
[04:11] <wgrant> Muscovy: Make sure you have postgresql-plpython-8.3 or postgresql-plpython-8.4 installed, depending on which version of PostgreSQL you're using.
[04:11] <Muscovy> Thanks, I'll try that.
[04:12] <thumper> lifeless: any idea why my pqm-submit line doesn't work?
[04:13] <lifeless> thumper: does your ../devel have a submit_thingy setting ?
[04:13] <thumper> wgrant: I'll pull your branch into my testfix
[04:13] <thumper> lifeless: yes
[04:13] <lifeless> bzr info on it should say
[04:13] <lifeless> thumper:  then no
[04:13] <wgrant> thumper: Sounds reasonable.
[04:13] <lifeless> I'd like to delete pqm-submit soon
[04:13] <wgrant> But it needs to go to p-d too.
[04:13] <lifeless> wgrant: the magic of auto merge should do that, no ?
[04:13] <wgrant> lifeless: I really hope that production-devel isn't auto-merging anything.
[04:13] <lifeless> devel being the top of the input tree
[04:13] <lifeless> oh right
[04:14] <lifeless> I meant after it percolates to db-devel
[04:14] <thumper> lifeless: but not production devel
[04:14] <lifeless> wgrant: mmm, I disagree on that hope; but there are some necessary conditions to make it safe that aren't true today.
[04:15] <wgrant> lifeless: Well, OK, pre-MergeWorkflowDraft.
[04:16] <wgrant> Is that still happening, what with our new overlord?
[04:17] <thumper> wgrant: branch in the pipe
[04:17] <lifeless> dunno, you'll need to ask him
[04:17] <wgrant> lifeless: Is it still happening?
[04:17] <lifeless> wgrant: :P I was referring to jml, he of the hacking-like-an-evil-overlord talk
[04:18] <wgrant> Heh, indeed.
[04:18] <lifeless> wgrant: not that he can answer the question, just for fun.
[04:18] <lifeless> anyhow
[04:18] <lifeless> I think that reducing developer friction is important
[04:19] <lifeless> that process change should do that, and if there is an available hacker doing it, great.
[04:19] <lifeless> I would like to look a little deeper at how concept -> production all works
[04:20] <lifeless> possibly up the dial on risk mitigation and down on risk avoidance
[04:20] <lifeless> then push rate-of-change up
[04:21] <lifeless> I hope thats not uselessly vague. I haven't dug into the precise details of the process in some time - before buildbot - so Monday I'll be *very* busy indeed :)
[04:22] <wgrant> Heh.
[04:23] <lifeless> concretely, I think we court risk by doing big rollouts
[04:23] <lifeless> this is observation over years
[04:24] <lifeless> so we put a lot of effort into making sure nothing can go wrong in the rollout : but because its always a big change, something always does.
[04:24] <lifeless> FSVO always
[04:24] <lifeless> 30 man-days of changes, more or less.
[04:24] <lifeless> smaller rollouts would have less risk.
[04:25] <lifeless> and if the risk handling stuff is non-linear, then smaller rollouts may be better than just the ratio of sizes-included.
[04:25] <wgrant> Yep.
[04:25] <wgrant> But this requires the ability to handle a crisis effectively at any time.
[04:25] <lifeless> it may be easier to figure out what *can* go wrong looking at a smaller rollout, and so be more prepared for what-ifs.
[04:26] <wgrant> Which is certainly not the case now.
[04:26] <lifeless> wgrant: not quite true. It requires the ability to handle a crisis starting within some time window T of the rollout
[04:27] <lifeless> you could, for instance, have an automerge-wait-for-losa-to-hit-a-red-button situation
[04:27] <lifeless> and every losa at start of shift could assess the risk, and hit the button.
[04:27] <lifeless> if the relevant people are around-and-will-be-for-say-2-hours
[04:27] <wgrant> True.
[04:27]  * lifeless handwaves furiously
[04:28] <lifeless> if you're interested in helping shape something like that, say so
[04:28] <lifeless> I can chat about it with folk at the epic and see if we can give you a set of constraints and requirements
[04:31] <lifeless> I mean to say: this is something that anyone interested should be able to work on.
[04:32] <lifeless> and while I'm interested, I'm unlikely to have personal directed time on it immediately. But I'd love to see things become easier for everyone :)
[04:58] <thumper> wgrant: I'm applying your fix to the prod-devel branch too
[04:58] <wgrant> thumper: Thanks.
[05:07] <spm> fwiw, recognising it is handwaving, we don't look after just LP. we have 3 or 4 (depending on how you count it) major systems. so the implicit assumption that we can treat LP as special/above the others is ... hrm... unwise is harsher than I want, but you get the idea. So 'start of shift, make a choice' stuff would not be great I'm thinking
[05:11] <wgrant> spm: Your name says you only have two services, so any of the others are figments of your imagination. QED.
[05:13]  * spm ponders if suspending wgrants account in retribution would 1. be overkill 2. pointless as he'd hack his way back in anyway 3. seen to be an excessive response 4.. there is no 4.
[05:14] <wgrant> Heh.
[05:17] <spm> lifeless: fwiw#2, yesterdays rollout was incredibly smooth. there were internal comments that a crisis needed to be manufactured so tom'd believe we were actually working. Having said that. 1hr 15 in the actual rollout portion of really quite intense very procedural Do X, then Y; isn't a walk in the sunshine either. :-)
[05:18] <wgrant> Why does it take so long?
[05:18] <wgrant> DB upgrades?
[05:19] <spm> that's part of it, but no means all.
[05:20] <spm> a basic breakdown: 10-15 mins to breakout to R/O and be able to do the DB updates. This includes shutting down the services that currently can't be kept up. code*, soyuz* etc
[05:20] <spm> DB updates themselves, which can vary widely. 20-30 mins'd be the norm
[05:21] <spm> re-enable the DB to be live again; restart all the app servers; verify; restart all the shutdowns.
[05:22] <wgrant> Hm, OK.
[05:23] <spm> And also ignores about 60 minutes of moderately intense prep to get to that stage :-)
[05:24] <wgrant> Prebuilding the new trees on all machines and such?
[05:25] <spm> crontabs, nagios, irc topics, etc yup
[05:25] <spm> verifying the cowboys that are live are known cowboys and are included
[05:42] <lifeless> spm: I know you have massive widespread responsibilities
[05:42] <lifeless> spm: for start of shift, read 'appropriate time' : I find dwelling too much on the minutiae distracts from the concept.
[05:42] <spm> heh
[05:43] <lifeless> spm: I'd _love_ it if everything that makes a rollout slow (e.g. shutting down services to go ro) had bugs. And I knew the bug numbers.
[05:43] <lifeless> spm: do you know if that is the case?
[05:43] <spm> not sure tbh. some parts we have raised in the past. whether they became bugs, probably not.
[05:44] <lifeless> I'm a data monster, really ;)
[05:44] <spm> I hadn't noticed? This is very much news to me!
[05:44] <spm> damn. left my sarcasm meter on. it just exploded.
[05:44] <lifeless> :)
[05:46] <spm> I guess what I'm not saying above - ideally I (personally!) don't want us to be yay/nay a rollout except in *exceptional* circumstances. like edge. it is it assumed it will work; if it doesn't we handle said failure gracefully, and that's the point we'd get involved - but the failure is not critical. Not a respond now event. More a respond soonish.
[05:48] <lifeless> that makes sense to me
[05:48] <lifeless> the nuance here, is that I was proposing you assess the surrounding support for dealing with stuff - controlling the timing, not the do/not do.
[05:48] <spm> or perhaps: it's your code, your system (tho recognising that is an artificial distinction with ownership there...); if you want X, we'll make it so, but pls retain 'ownership' of the responsibility. kinda thiungy.
[05:48] <lifeless> because you are the response team. You know if you're insanely busy, or just flat out busy.
[05:48] <spm> ahh I see
[05:49] <lifeless> we together provide launchpad.net - its lp-devs + lp-managers, not lp-devs alone or lp-managers alone
[05:49] <lifeless> (which you know)
[05:49] <lifeless> :P
[05:49] <spm> I try to forget....
[05:51] <lifeless> back to the example - if there was a buildd change, you might want lamont available
[05:51] <lifeless> so you'd say 'delayed to $his tz'
[05:52] <lifeless> but most changes are relatively shallow and would just be 'doit'
[05:52] <spm> I'd, again very much personally!!!, be very keen if lp prod rollouts were much like edge is now. just a matter of course and all done purty much automagically. The key reason being a somehwat selfish one - is that makes our life much easier. if the rollout is so smooth that simplish scripting can do; then problems are also equally trivial to solve
[05:52] <thumper> lifeless: hey, as your new role as TA, you can give out rc's for production-devel
[05:52] <thumper> lifeless: want to give me an RC for wgrant's fix?
[05:52] <lifeless> thumper: What are the implications here :) - its day -2 :P
[05:53] <thumper> not much in this case, I'm just dotting the i's
[05:53] <spm> actually - if there's a buildd change, I don't believe we have too many options but to wait for him. tbh, not sure of the fine detail there.
[05:53] <lifeless> spm: so you see the point :)
[05:53] <spm> oh yes.
[05:53] <thumper> lifeless: I could equally go release-critical=thumper, but I thought you might like your name there :)
[05:53] <lifeless> spm: FTR, I'm a huge fan a automation. I was surprised by Tom's apparent disinterest in the recent thread about detecting stale trees or whatever it was.
[05:54] <lifeless> thumper: use yours ;)
[05:54] <thumper> :)
[05:54] <thumper> ok
[05:54] <lifeless> thumper: When I'm doooog tired after that terrible hotel, iz not a good time to do new things ;)
[05:54] <spm> which thread was that, don't recall seeing it myself?
[05:54] <thumper> heh
[08:13] <adeuring> good morning
[08:46] <wgrant> Yay, buildbot loves me.
[08:46] <spm> nah, that was me forcing a build :-)
[08:47] <spm> thumper: wgrant: edge1: canonical.database.revision.InvalidDatabaseRevision: patch-2207-56-0.sql has been applied to the database but does not exist in this source code tree. You probably want to run 'make schema'. <== is that you guys causing that?
[08:48] <wgrant> spm: stable is out of date.
[08:48] <spm> oh bah.
[08:48] <wgrant> Since it broke soon after db-stable was merged.
[08:48] <wgrant> buildbot is happy now, though.
[08:48] <wgrant> So it should pull soon.
[08:49] <spm> we can hop. I've reverted the edge update; I guess we'll find out this timish tomorrow if edge is happy again
[08:49] <spm> hope too
[08:51] <wgrant> spm: Heh, it's just pulled now.
[11:16] <jtv> wgrant, do you know of any recipe builds that should work on either dogfood or staging so we can Q/A your change to launchpad-buildd?
[11:17] <wgrant> jtv: I don't know if staging works yet, but I may be able to get something working on dogfood.
[11:17] <wgrant> ... except that I forget how it interacts with codehosting.
[11:17] <wgrant> Does it use staging or production codehosting?
[11:18] <jtv> It just doesn't have any.  So we may have to fake database records or something.
[11:18] <jtv> Actually, if it's just for reading from a branch, it uses production codehosting.
[11:19] <wgrant> Right.
[11:19] <wgrant> Is buildd-manager running?
[11:19]  * jtv checks
[11:20] <wgrant> Oh good, I can't log in on DF.
[11:20] <jtv> how jolly
[11:20] <wgrant> (OOPS-1650DF10)
[11:21] <jtv> On the bright side, buildd-manager is indeed running
[11:26] <wgrant> bigjools: Any idea why DF won't let me log in?
[11:47] <bigjools> wgrant: checking
[11:47] <wgrant> bigjools: Thanks.
[11:48] <bigjools> "HTTP Response status from identity URL host is not 200. Got status 404"
[11:48] <bigjools> awesome
[11:48] <wgrant> No provider set up?
[11:48] <bigjools> some config must have changed somewhere
[11:48] <bigjools> no idea what that might be
[11:59] <wgrant> Can someone please land https://code.edge.launchpad.net/~wgrant/launchpad/faster-and-more-general-getBuildQueueSizes/+merge/28476 ?
[11:59] <deryck> Morning, all.
[12:01] <bigjools> wgrant: nice, I'll land it
[12:02] <wgrant> bigjools: Thanks.
[12:23] <bigjools> wgrant: try again
[12:25] <wgrant> bigjools: Failure continues.
[12:25] <bigjools> gnargh
[12:25] <wgrant> OOPS 20
[12:26] <bigjools> same problem
[12:26] <bigjools> the oops report doesn't do anything useful and print the url it's trying to use
[12:26] <bigjools> that would be too useful
[12:26] <wgrant> Heh.
[12:26] <bigjools> sigh
[12:27] <wgrant> What's the OpenID host it's configured to use?
[12:27] <bigjools> fuck nose
[12:27] <bigjools> the config is so convoluted it's hard to work out
[12:27] <bigjools>   Module canonical.launchpad.webapp.login, line 183, in render
[12:27] <bigjools>     allvhosts.configs[openid_vhost].rooturl)
[12:27] <bigjools> but rooturl doesn't exist
[12:29] <wgrant> bigjools: You need launchpad/openid_provider_vhost set.
[12:29] <bigjools> it is
[12:29] <wgrant> To one of your vhosts.
[12:29] <wgrant> And that vhost has its hostname set?
[12:29] <bigjools> yes
[12:30] <wgrant> Yay...
[12:30] <bigjools> 404 means it's talking to something at least
[12:30] <wgrant> Something, yes.
[12:30] <bigjools> but what....
[12:37] <bigjools> wgrant: please try again, I added some more info to the exception that goes in the oops
[12:37] <wgrant> bigjools: Done. 22.
[12:38] <bigjools> GAR
[12:39] <wgrant> Oh?
[12:39] <bigjools> I picked the wrong egg to hack
[12:39] <wgrant> Heh.
[12:41] <bigjools> try again...
[12:46] <bigjools> nm
[12:52] <wgrant> Any luck?
[12:52] <bigjools> no
[12:53] <bigjools> it's trying to access https://login.dogfood.launchpad.net/ which 404s
[12:53] <wgrant> Right.
[12:53] <wgrant> You could just tell it to use login.launchpad.net...
[12:53] <bigjools> I *could*
[12:54] <wgrant> Unless you want c-i-p fun...
[12:54] <bigjools> trying one last thing before I give up
[12:54] <bigjools> bah no fair, I have to travel on Sunday when the British GP is on
[12:54] <lifeless> wgrant: cip?
[12:55] <wgrant> lifeless: canonical-identity-provider.
[12:55] <wgrant> Crazy Django thing.
[12:55] <lifeless> yup
[12:55] <lifeless> I remembers
[12:56]  * bigjools shovels more coal into dogfood
[12:59] <lifeless> night
[12:59] <wgrant> Night.
[13:00] <bigjools> grar
[13:03] <bigjools> still no dice
[13:05] <wgrant> bigjools: What're you trying to do?
[13:06] <bigjools> point df at staging's openid
[13:07] <wgrant> Hm. It's not working? Firewalled, maybe?
[13:07] <bigjools> changing the config made zero difference
[13:07] <wgrant> There are three OpenID vhosts -- you changed the right one(s)?
[13:08] <wgrant> I've managed to get the wrong one before.
[13:08] <bigjools> there's only one in the DF config
[13:08] <bigjools> FINALY
[13:08] <bigjools> and finally too
[13:09] <wgrant> Yay, it works. Thanks.
[13:10] <bigjools> now, food
[13:10] <wgrant> Is buildd-manager alive?
[13:11] <wgrant> It apparently was before.
[13:11] <wgrant> But it's not dispatching a recipe build now.
[13:11] <wgrant> Ah, there it is.
[13:17] <wgrant> rubidium really is unbelievably slow.
[13:25] <wgrant> jtv: Around?
[13:26] <jtv> wgrant: Around.
[13:27] <wgrant> https://code.dogfood.launchpad.net/~wgrant/+recipe/ivle-test/+build/145 just worked. The i386 build seems to be working fine too.
[13:27] <wgrant> jtv: ^^
[13:27] <jtv> wgrant: \o/
[13:27] <jtv> I'll tell lamont that we can roll out
[13:28] <wgrant> Great.
[20:46] <lifeless> morning
[20:53] <mtaylor> morning lifeless
[20:55] <lifeless> hi mtaylor
[20:56] <lifeless> 'sup ?
[20:57] <mtaylor> lifeless: hanging out in dallas. enjoying sitting by the pool hacking
[20:58] <lifeless> nice
[21:07] <lifeless> mtaylor: hacking on blueprints yet ?
[21:08] <mtaylor> lifeless: not yet
[21:09] <mtaylor> lifeless: currently, actually waiting on some launchpad things to get renamed ... but I'm guessing the losas are busy
[21:11] <lifeless> looks like it
[21:14] <mbarnett> yeah, sorry.  I am a bit behind
[21:14] <mbarnett> should be able to get to it this evening, or first thing in the morning central US time.
[21:18] <lifeless> gary_poster: got a second ?
[21:18] <gary_poster> lifeless, on calls till EoD but can reply for little questions
[21:18] <lifeless> sure
[21:18] <lifeless> its just a 'best way to do' question
[21:19] <lifeless> I have this lsprof patch to extract the code into a dedicated module using an event
[21:19] <lifeless> it needs either a tweaked, or a whole new, zope.app.publication
[21:19] <lifeless> the tweak is adding the event; the whole new would be landing the 2 upstream patches and upgrading to latest upstream
[21:20] <gary_poster> I see
[21:20] <lifeless> or I could add the event in the lp tree and reference it there
[21:21] <lifeless> whats the current, usual, practice when fixing something the long term way requires an upstream change? Do we submit the upstream change and then do /whatever/, or do we fork the egg temporarily ?
[21:23] <gary_poster> will answer within half hour or so (sorry)
[21:23] <gary_poster> (want to ask questions :-) )
[21:23] <lifeless> thats fine
[21:23] <lifeless> given the ec2land latency it won't make much diff to when it lands.
[21:24] <lifeless> In 40 minutes I'm heading out for 2 hours - pre-flight-chores
[21:24] <lifeless> but its not urgent regardless.
[23:38] <gary_poster> lifeless: sorry, calls kept going
[23:39] <gary_poster> lifeless: my preference order:
[23:39] <gary_poster> 1) submit upstream and use upstream (sometimes impractical)
[23:39] <gary_poster> 2) submit upstream and change locally in LP with one of our many existing subclasses
[23:42] <gary_poster> 3) submit upstream and use upstream older egg with change (e.g., we're using 3.4.1 and upstream is at 3.5.0: we can try releasing 3.4.2 in addition to getting patch in trunk
[23:42] <gary_poster> )
[23:43] <gary_poster> 10) (i.e., we really don't wanna do this but sometimes we have to): make our own branch and make our own egg
[23:43] <gary_poster> with (10) and possibly with (2) a LP bug is appropriate
[23:44] <gary_poster> Done, and going


[14:40] <xnox> how does partman-iscsi ends up part of the installation?
[14:40] <xnox> one manually anna-installs it?
[14:41]  * xnox ponders how to hook up s390-zfcp and thought that it should be similar to e.g. iscsi
[14:59] <cyphermox> nope
[14:59] <cyphermox> gets pulled in if you preseed iscsi things
[15:00] <cyphermox> or maybe always there in some specific cases, I need to check
[15:12] <xnox> i guess one must do anna-install=partman-iscsi or some such?
[15:12] <xnox> but i'm struggling to find docs about it.
[15:20] <cyphermox> no need to anna-install it at all
[15:23] <cyphermox> but I suppose I'm missing a part of the magic anyway, I don't see how it gets pulled in either
[15:46] <cyphermox> cjwatson: could you please enlighten us? ^
[15:46] <cyphermox> I'm wondering if it's not just via Priority
[16:30] <cjwatson> Yes, any udeb that's Priority: standard is automatically marked for installation by anna.
[16:30] <cjwatson> (or above)
[16:32] <cjwatson> For the full rules it's easiest to just read through the body of the larger for loop in anna/anna.c:choose_modules - the log messages make the logic reasonably clear.
[16:50] <xnox> cjwatson, aha. so maybe i should stop pointlessly including some of the s390-* things, and bump priority instead.
[16:50] <xnox> (i take that priority:standard udebs get included on the .iso automagically too...)
[16:52] <cjwatson> xnox: IIRC
[16:53] <xnox> ;-)
[16:53] <xnox> cjwatson, btw, would you like to nominate yourself to Ubuntu Developer Membership Board =)
[16:53] <cjwatson> xnox: No.
[16:53] <cjwatson> Not even a little bit.
[16:53] <xnox> =))))))) ok
[16:54] <xnox> cjwatson, even if i bribe you with 100 portal keys?
[16:54] <xnox> =)
[16:55] <cjwatson> I've been there and done that, don't want to do it again.
[16:55] <cjwatson> I wouldn't be able to give it the time it needs for a proper job anyway.
[16:59] <Laney> It is a highly rewarding experience
[17:04]  * xnox ponders why we include block-modules-${kernel:Version} into d-i initrds.
[17:04] <xnox> on s390x, which cannot install without network.
[17:04] <xnox> or rather, can only install over the network.
[17:12] <cyphermox> xnox: what did you mean by 'including', adding to pkglists in d-i?
[17:13] <xnox> yeah.
[17:13] <cyphermox> ah, yeah
[17:13] <xnox> it makes sense on e.g. hd-media, but makes no sense for netboot only s390x.
[17:13] <cyphermox> well, it depends if you want to make it already available in the initrd or not ;)
[17:13] <cyphermox> right
[17:13] <cyphermox> if it can only netboot, all you really need is enough to get on the network and download the rest
[17:15] <cyphermox> makes me think that I still have an enhancement I want to do to anna for the PPA overlay magic
[17:58] <xnox> like install all from overlay?
[19:44] <cyphermox> well, not really, but use any package newer than the archive from the overlay
[19:45] <cyphermox> I'll deal with this tomorrow


[00:24] <thumper> wallyworld: checked the bot recently?
[00:25] <wallyworld> thumper: yep and it's farked. i deleted 100000000 old test processes and restarted and it's been running tests for the 1.17.5 upgrade branch for ages now
[00:25] <wallyworld> so it's still broken
[00:25] <thumper> :-(
[00:26] <wallyworld> thumper: my next step was to beg in #is for more resources to be allocated to that instance?
[00:26] <thumper> wallyworld: we can try, right?
[00:26] <wallyworld> yeah
[01:31] <waigani> thumper: are we standing up?
[01:31] <thumper> yes
[01:31] <thumper> wallyworld: coming?
[09:14] <mgz> morning all
[09:17] <dimitern> morning from blue fin ;)
[10:10] <dimitern> natefinch, \o
[10:10] <natefinch> fwereade, dimitern, mgz, rogpeppe: morning
[10:10] <dimitern> natefinch, we have a camera setup for you
[10:11] <natefinch> dimitern: that is awesome, thanks guys.
[10:12] <mgz> hey nate!
[10:14] <dimitern> natefinch, i've sent you a g+ link as a pm
[10:14] <natefinch> dimitern: oh, thanks, sorry
[10:16] <natefinch> dimitern: one sec, having trouble getting G+ to use my canonical account instead of my gmail
[10:17] <dimitern> natefinch, sure, join when you can, just to check it out and say hi, we're about to have a little break
[10:17] <natefinch> dimitern:  ok
[10:20] <dimitern> natefinch, you're frozen
[10:20] <dimitern> natefinch, can you hear us well?
[10:21] <natefinch> it froze for a while seems better now
[10:21] <natefinch> the sound is pretty soft and somewhat choppy
[10:22] <natefinch> dimitern: seems the connection is not very good
[10:23] <natefinch> dim that's a bit better
[10:23] <natefinch> dimitern: ^
[10:23] <mgz> how mean nate
[10:24] <natefinch> mgz: ug, stupid hangouts
[10:32] <mgz> I have a coffee grinding story for you nate
[10:38] <natefinch> mgz: heh, a story? :)
[10:39] <rogpeppe> natefinch: lp:~rogpeppe/juju-core/507-peergrouper-integration
[10:44] <rogpeppe> natefinch: in worker/peergrouper, go test -gocheck.vv -gocheck.f TestEnsureAvailability
[10:50] <wallyworld> jam: mgz: landing bot is broken. i found it was cpu starved and the on aloja where it was running, there was a high load average. i tried resizing the landing instance to m1.large but that failed. so now the only option is to redeploy with a constraint to force it to use a larger instance. is the landing bot fully charmed or do we still have manual steps?
[10:53] <mgz> yeah, I'm not sure that resize attempt was wise
[10:53] <mgz> I tried sorting it at the end of friday, but the machine was pretty borked
[10:54] <mgz> we probably need to redeploy, which does have several manual steps
[10:57] <Beret> hi
[10:57] <Beret> is there an add-machine API call?
[10:57] <Beret> note I said add machine, not add machines
[10:57] <natefinch> Beret: not sure what the difference is?
[10:57] <wallyworld> mgz: yeah, the resize was a last resort to avoid redeploying
[10:58] <wallyworld> mgz: today, it took about 12 hours for a test run which eventually failed
[10:58] <wallyworld> totally cpu bound
[10:58] <wallyworld> i reckon it needs to be on prodstack
[11:02] <dimitern> wallyworld, so you're sprinting as well this week?
[11:02] <wallyworld> dimitern: no?
[11:03] <mgz> he's just doing the normal wallyworld week, which is sprinting by everyone else's standard
[11:05] <dimitern> ah :)
[11:06] <dimitern> wallyworld, we're told au/nz guys are doing a sprint at the same time
[11:06] <wallyworld> dimitern: nah, we did get together a few weeks back though
[11:07] <wallyworld> i would have preferred london to dunedin :-)
[11:09] <wallyworld> the maas guys are in brisbane this week also
[11:17] <mattyw> dimitern, ping?
[11:20] <natefinch> mattyw: he's in a sprint, only partly paying attention
[11:20] <mattyw> natefinch, ah ok, thanks
[13:46] <mgz> natefinch: we're back! will get on the hangout again shortly, yell when you're around
[14:03] <frankban> hi core devs: am I right assuming the API ServiceDeploy, when called without a ToMachineSpec, uses the following unit placement policy? if clean and empty machines/containers are available, use those, otherwise create a new top level machine for each unit
[14:13] <natefinch> frankban: should be, yes
[14:15] <frankban> natefinch: thanks
[14:52] <rogpeppe> natefinch: a little review for you :-) https://codereview.appspot.com/70770043
[14:52] <rogpeppe> natefinch: hmm, i think you're frozen
[14:53] <rogpeppe> natefinch: oh, no, just immobile :-)
[14:57] <natefinch> rogpeppe: haha
[14:57] <rogpeppe> natefinch: took you a while to see that :)
[14:58] <rogpeppe> natefinch: i'm serious though - a review would be appreciated
[14:58] <natefinch> rogpeppe: sure thing
[15:01] <natefinch> rogpeppe: why is errgo github.com/juju/errgo/errors and not just github.com/juju/errgo ?  Seems like errgo would never clash with anything, and it makes it more clear that it's errgo, not the std errors package
[15:02] <rogpeppe> natefinch: because i think "errors" is a better name for the identifier, and it's a strict superset of the standard errors package
[15:09] <rogpeppe> natefinch: links to your reviews?
[15:09] <natefinch> rogpeppe: https://codereview.appspot.com/69600043/
[15:53] <tasdomas`> I'm having problems constructing a manual environment from lxc containers
[15:53] <tasdomas`> the error I get is:
[15:54] <tasdomas`> Fetching tools: curl -o $bin/tools.tar.gz 'http://<IP_ADDRESS>:8040/tools/releases/juju-<IP_ADDRESS>-saucy-amd64.tgz'
[15:54] <tasdomas`> 2014-03-03 15:50:01 ERROR juju.environs.manual provisioner.go:78 provisioning failed, removing machine 5: rc: 1
[15:54] <tasdomas`> 2014-03-03 15:50:01 ERROR juju.cmd supercommand.go:293 rc: 1
[16:41] <mgz> sinzui: thanks for resolving bug 1286885 - it is indeed deliberate to restore 1.16 compat
[16:41] <_mup_> Bug #1286885: juju 1.17.3 incompatible with tools in canonistack bucket <compatibility> <regression> <juju-core:Won't Fix> <https://launchpad.net/bugs/1286885>
[16:42] <sinzui> mgz, no
[16:42] <sinzui> mgz, I mean NP
[18:07] <marcoceppi> uh, so how do you remove a subordinate?
[19:27] <coreycb> has anyone seen this with juju-core 1.17.4?  https://pastebin.canonical.com/105803/
[20:03] <rick_h_> coreycb: is that with lxc?
[20:05] <coreycb> rick_h_, no it's using kvm
[20:05] <rick_h_> coreycb: ok, but local provider? The local provider doesn't support debug-log yet. I think that's still in progress
[20:14] <coreycb> rick_h_, I'm using openstack
[20:14] <coreycb> rick_h_, I think that means I'm not using a local provider
[20:14] <rick_h_> coreycb: ah ok then not sure.
[20:15] <coreycb> rick_h_, btw this worked last week on 1.17.3
[20:16] <rick_h_> coreycb: k, yea sorry. Can you file a bug with your error and environment details?
[20:17] <coreycb> rick_h_, sure and not a problem.  do you know how I can get back to 1.17.3?  it doesn't appear to be available in ppa:juju/devel
[20:18] <rick_h_> coreycb: no, I'm not sure. sinzui is that possible without going compiling it custom?
[20:20] <sinzui> coreycb, I think the error means the log is not where juju expects it to be. I understand the machine can be configured to put the logs else where...but I think you would remember doing that
[20:22] <sinzui> coreycb, is the env your talking too 1.17.3? If so I think you need to exec "juju upgrade-juju" to bring the server and agents in line with your client
[20:23] <sinzui> coreycb, 1.17.[0-3] were not backwards compatible with 1.16.x, the fix for 1.17.4 made it not work so well with previous devel versions of Juju.
[20:26] <coreycb> sinzui, good question.. I'm not sure what the server is at
[20:27] <coreycb> sinzui, juju upgrade-juju didn't change anything, but I'll look into what the server is at
[20:29] <sinzui> coreycb, juju status will report the server and agent machine versions...and since 1.7.4 shows empty info for 1.17.x, you will know you will need to upgrade-juju
[20:30] <coreycb> sinzui, thanks.  juju status shows 1.17.3.
[20:31] <sinzui> and you are using juju 1.17.4 your local machine?
[20:31] <coreycb> sinzui, yes
[20:32] <sinzui> coreycb, I am surprised you can get that much info out of status. If you upgrade, you will get better debug and logging
[20:33] <coreycb> sinzui, ok.  I'll try to get them both to the same version.  I think I need to do more than juju upgrade-juju to upgrade.
[20:35] <sinzui> coreycb, 1.17.x looks for public versions of the tools...
[20:36] <sinzui> coreycb, oh, I didn't see streams.canonical.com get the new tools. you may be right. I will look into this now
[20:37] <coreycb> sinzui, appreciate it
[20:38] <bodie_> Go newbie here, any recommendations for getting my feet wet?
[20:44] <bodie_> in terms of bugfixes or tasks that need taking a whack at
[21:00] <marcoceppi> bodie_: you can find a list of the bugs here: https://bugs.launchpad.net/juju-core/
[21:00] <marcoceppi> bodie_: and "small" bugs are typically tagged "papercut" https://bugs.launchpad.net/juju-core/+bugs?field.tag=papercut
[21:06] <bodie_> Okay, cool.
[21:07] <thumper> o/ bodie_ marcoceppi
[21:08] <thumper> good luck finding a simple bug
[21:08] <thumper> juju is quite a complicated system
[21:09] <bodie_> heh... I noticed that.  I'm taking a look over a few things on Github before taking the plunge, I think.  :)
[21:14] <thumper> bodie_: what is your background?
[21:15] <sinzui> coreycb, juju-upgrade will work with an open network now. streams.canonical.com has the new tools
[21:16] <bodie_> undergrad CS analysis, math, etc, graduated last year, self taught in a bunch of languages.  Good w/ python, perl, C, java
[21:16] <bodie_> I know my way around linux and such
[21:17]  * thumper nods
[21:17]  * thumper takes a quick look to see if he can find a simple bug
[21:19] <bodie_> Juju, because I was actually thinking about making a similar service and discovered this
[21:19] <thumper> bodie_: nice
[21:20] <bodie_> yeah, the one thing I see as problematic here is being tied to openstack
[21:20] <bodie_> if i read it right
[21:20] <thumper> bodie_: I have found that often a good place to start with new projects is to look at low priority bugs (which the main dev team seldom get to) or tech-debt type bugs
[21:20] <thumper> ?!
[21:20] <thumper> juju isn't tied to open stack
[21:20] <bodie_> ahhh
[21:21] <thumper> open stack is just one provider
[21:21] <bodie_> I must have misread the site then
[21:21] <bodie_> i was at digitalocean for a while and a couple of us were talking about making a platform agnostic cluster deploy tool
[21:21] <bloodearnest> bodie_: I think you just found it :)
[21:21] <thumper> hazmat has a plugin for dealing with digital ocean
[21:21] <bodie_> i'll have to get my head adjusted and re-read ;)
[21:21] <thumper> also first class ec2, azure, soon joyent
[21:21] <bodie_> nice!
[21:21] <thumper> also maas, and a local provider
[21:21] <thumper> local uses LXC containers on the host machine
[21:22] <thumper> we also have manual provisioning
[21:22] <thumper> do work with any machine you happen to have
[21:22] <thumper> bodie_:  this could be a simple(ish) intro bug https://bugs.launchpad.net/juju-core/+bug/1197365
[21:22] <_mup_> Bug #1197365: instance.Instance.WaitDNSName() no longer needed <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1197365>
[21:23] <bodie_> right on
[21:23] <thumper> bodie_: or this one: https://bugs.launchpad.net/juju-core/+bug/1217868
[21:23] <_mup_> Bug #1217868: move from state.D to bson.D <hours> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217868>
[21:23] <thumper> both are easy(ish) tasks that are just refactoring
[21:24] <thumper> and noone else is looking at them
[21:27] <bodie_> good deal, I'll take a look
[21:30] <hazmat> bodie_, http://github.com/kapilt/juju-digitalocean
[21:36] <coreycb> sinzui, I should be able to get that with ppa:juju/devel
[21:36] <coreycb> right?
[21:36] <coreycb> sinzui, upgrade still isn't working for some reason
[21:37] <sinzui> coreycb, no. Ubuntu and the PPA provide command line and local deploy tools. They provide what goes on your computer.
[21:38] <sinzui> coreycb, "juju --show-log upgrade-juju" tells the server and agents to find newer tools in the the current cloud or on streams.canonical.com
[21:39] <sinzui> coreycb, you can also use your local installation to put the tools in the environment...
[21:39] <sinzui> coreycb, "juju --show-log upgrade-juju --upload-tools"
[21:39] <sinzui> coreycb, while the later always works, I prefer letting juju choose the correct origin so that it never think I have to provide more tools
[21:40] <coreycb> sinzui, ok so the good news is that the latter worked.   but the former got "INFO juju upgradejuju.go:120 no upgrades available"
[21:42] <sinzui> coreycb, okay. That means juju isn't finding tools
[21:42] <bloodearnest> hazmat: about to have a play with jlxc
[21:42] <sinzui> in the list of places to work
[21:43] <hazmat> bloodearnest, that one isn't end user polished.. lots of undocumented setup.. i'm doing a talk on thursday.. i'm hoping to polish it up before then
[21:43] <sinzui> coreycb, you are in a private cloud? Someone, perhaps you placed juju-*.tgz into a container?
[21:44] <bloodearnest> hazmat: sure, np, I'm just gonna see if I can get it working, if not no worries
[21:44] <hazmat> bloodearnest, actually with the aufs option, its reasonably straight-forward.. i've had some minor issues with aufs though and some software.
[21:44] <hazmat> nfs in particular
[21:45] <coreycb> sinzui, it's private.. this is on the server team's openstack on openstack deployment (serverstack)
[21:46] <coreycb> sinzui, but anyway not sure.. I'll have to check into that
[21:47] <hazmat> sinzui, if you don't provide tools you have no idea what tools juju will select, and no dry-run mode.. that's terrifying for prod
[21:47] <sinzui> coreycb, okay. they probably seeded the tools. does the cloud have an open network? eg, can you deploy any charm whithout needing to fork and repackage its deps
[21:47] <coreycb> sinzui, hmm, now juju destroy-environment gets "error: no environment specified"
[21:47] <coreycb> sinzui, ah, it may not be open
[21:48] <sinzui> coreycb, I would have thought the "--upload-tools" arg would have works from your 1.17.4 host. The feature works too well
[21:50] <sinzui> coreycb, juju 1.17.x changed the destroy-environment args. You must specify the environment name to be clear you know what you are doing...
[21:50] <sinzui> juju destroy-environment my-env
[22:01] <coreycb> sinzui, I think I'm good to go.  --upload-tools did work, and debug-log works after I successfully upgrade-juju to 1.17.14.  and destroy-environment works as you said.
[22:02] <sinzui> coreycb, great
[22:02] <coreycb> sinzui, oh and there is a juju-1.17.3-precise-amd64.tgz getting pulled down in the bootstrap
[22:02] <coreycb> sinzui, anyway, thanks!
[22:50] <bloodearnest> hazmat: Great success! :)
[22:52] <bloodearnest> hmm, maybe I spoke too early
[22:53] <bloodearnest> but progress, anyway
[23:09] <hazmat> bloodearnest, what's the hangup.. its pretty instaneous if its working.
[23:10] <hazmat> bloodearnest, if you dont have btrfs.. you need a code mod (its already commented) to enable the aufs support... i should toss that into a cli param.
[23:15] <hazmat> bloodearnest, oh.. that install.sh.. i was going to yank it.. doh.
[23:16] <hazmat> i haven't actually used it, its an old artifact from some previous exploration.


[03:34] <canthus13> paultag: The Game. I lost it. :(
[03:37] <yano> crap, I was winning until you said something
[03:48] <canthus13> Heh.
[04:45] <Cheri703> ah craigslist, someone is asking $20 for a framed enrique iglesias poster
[14:09] <thafreak> just got the email that I can order my raspberry pi
[14:09] <thafreak> i wonder how many they'll let me order
[14:09] <canthus13> Heh.
[14:55] <thafreak> Order two, but they're on back order...or just order one in case another vendor lets me order some and they might ship sooner
[14:55]  * canthus13 wants a B.
[14:56] <thafreak> that's what I'm ordering...$35
[14:56] <thafreak> want the link...it'll be on back order
[14:57] <canthus13> Sure.
[14:57]  * canthus13 is thinking it'll make a great file server... just plug in an external drive and go. :)
[15:24] <canthus13> thafreak: t.
[15:29] <canthus13> thafreak: ...thanks.
[15:29] <andygraybeal_> hi people of the internets!!!!!
[15:29] <andygraybeal_> omg omg omg, what a great couple of days!!
[15:29] <andygraybeal_> no power, no internet.
[15:31] <thafreak> oh boy, that sucks
[15:31] <thafreak> been thinking of getting a generator, but not sure how many more years we'll be at this house...family is out growing it
[15:34] <andygraybeal_> ah
[15:34] <andygraybeal_> yea, we are gonna get ourselves a jenny
[15:34] <andygraybeal_> genny :)
[15:35] <andygraybeal_> we are thinking about getting a natural gas powered genny
[15:35] <andygraybeal_> maybe a dual purpose
[15:35] <andygraybeal_> er.. dual fuel.. whatever i mean
[15:38] <canthus13> thafreak: A small generator is a nice idea...


[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [amd64] (eoan-proposed) [0.9.2-1ubuntu1]
[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [armhf] (eoan-proposed) [0.9.2-1ubuntu1]
[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [ppc64el] (eoan-proposed) [0.9.2-1ubuntu1]
[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [arm64] (eoan-proposed) [0.9.2-1ubuntu1]
[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [s390x] (eoan-proposed) [0.9.2-1ubuntu1]
[00:22] -queuebot:#ubuntu-release- New: rejected dmarc-cat [i386] (eoan-proposed) [0.9.2-1ubuntu1]
[00:29] -queuebot:#ubuntu-release- New: accepted hy [source] (eoan-proposed) [0.16.0-0ubuntu1]
[00:35] -queuebot:#ubuntu-release- New: accepted ubiquity [amd64] (eoan-proposed) [19.10.2]
[00:35] -queuebot:#ubuntu-release- New: accepted ubiquity [armhf] (eoan-proposed) [19.10.2]
[00:35] -queuebot:#ubuntu-release- New: accepted ubiquity [ppc64el] (eoan-proposed) [19.10.2]
[00:35] -queuebot:#ubuntu-release- New: accepted ubiquity [arm64] (eoan-proposed) [19.10.2]
[00:36] -queuebot:#ubuntu-release- New: accepted ubiquity [i386] (eoan-proposed) [19.10.2]
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [ppc64el] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [s390x] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [amd64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [i386] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [arm64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [armhf] (eoan-proposed/universe) [0.4.0-1] (no packageset)
[08:35] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [sync] (disco-proposed) [9.1.0-2ubuntu2~19.04]
[08:36] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross [sync] (disco-proposed) [4ubuntu4.1]
[08:37] -queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross-ports [sync] (disco-proposed) [3ubuntu4.1]
[09:11] -queuebot:#ubuntu-release- Unapproved: yaru-theme (disco-proposed/main) [19.04.2 => 19.04.3] (desktop-core)
[09:25] -queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (disco-proposed) [19.04.3]
[09:49] <LocutusOfBorg> any AA can please remove hy 0.16.0-0ubuntu1 from eoan-proposed? I want to do some testing with the old version before updating... never built
[09:50] <LocutusOfBorg> I don't know why but today the old version seems building
[09:58] -queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[10:00] <tjaalton> vorlon: do you want to handle fwupd* et al on bionic queue/NEW? fwupd is still on unapproved for some reason, while libxmlb and fwupd-signed are already on NEW..
[10:01] <seb128> tjaalton, there is no "some reason/while" here, those 2 are packages that don't exist today in bionic so  uploading them hit sourceNEW and not unapproved
[10:02] <tjaalton> seb128: oh, source NEW?
[10:02] <tjaalton> even more reason for an AA to review them in tandem
[10:03] <seb128> tjaalton, yes, the first one is a new library that is needed by the new fwupd version
[10:03] <seb128> right
[10:03] <seb128> I don't expect that to be an easy SRU, maybe best for vorlon to review :)
[10:04] <tjaalton> right, I'll do the easier ones then :)
[10:11] <LocutusOfBorg> apw, please kick hy out from eoan...
[10:12] <LocutusOfBorg> I want to replace with a copy from cosmic
[10:12] <LocutusOfBorg> and then do a no-change rebuild
[10:12] <LocutusOfBorg> and fix failures with single patches on top of 0.12 because the new version requires lots of other library updates
[10:20] <tjaalton> xnox: why is openssl targeted for 'disco-updates' instead of proposed? the sru tooling doesn't see the diff so it's harder to review
[10:24] <Laney> worse than that, that means that when you accept it it'll go straight to -updates
[10:24] <Laney> (AIUI)
[10:30] <tjaalton> sigh
[10:31] <Laney> reject it :>
[10:31] <tjaalton> done
[10:32] -queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (disco-updates) [1.1.1b-1ubuntu2.1]
[10:39] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.1]
[10:39] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (cosmic-proposed) [2.3-3ubuntu11.1]
[10:40] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.3]
[10:40] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [<IP_ADDRESS>-2ubuntu11.7]
[11:16] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [<IP_ADDRESS>]
[12:00] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1007.7] (core, kernel)
[14:00] -queuebot:#ubuntu-release- Unapproved: rejected software-properties [source] (bionic-proposed) [<IP_ADDRESS>.9]
[14:20] <sil2100> Laney: ok, I finally had a moment to sit down on the britney SRU regression thingy - fixed a few things regarding state record and read, but in besides that it seems to be working correctly
[14:20] <sil2100> Laney: for instance yeah, it doesn't send a message for libseccomp for bionic because that upload has no launchpad bugs in its .changes
[14:20] <sil2100> Laney: for bionic at least it seems that for all the others it did the 'right thing'
[14:21] <Laney> sil2100: oh! thanks, I didn't consider that possibliity :-O
[15:06] -queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [<IP_ADDRESS>.8 => <IP_ADDRESS>.9] (desktop-core, ubuntu-server)
[15:13] <Laney> vorlon: Looks like bos02 randomly healed itself... going to turn it back on
[15:24] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [<IP_ADDRESS>.9]
[15:24] <vorlon> Laney: heh ok
[15:25] <Laney> such reliable
[16:09] <LocutusOfBorg> any AA please remove hy from eoan, and let me copy the previous binary from cosmic
[16:09] <LocutusOfBorg> vorlon, ^^ :D
[16:09] <LocutusOfBorg> pleeeeeeease
[16:09] <LocutusOfBorg> (rationale above)
[16:09] <vorlon> mm
[16:09] <LocutusOfBorg> the new release can't build...
[16:09] <LocutusOfBorg> and the old one seems to build fine now
[16:10] <LocutusOfBorg> I spent three days trying to make the new one work, but requires lots of more changes, in other python libs
[16:10] <LocutusOfBorg> better stick with cosmic and cherry-pick fixes
[16:10] <vorlon> removed
[16:10] <LocutusOfBorg> or let debian do it :D
[16:10] <LocutusOfBorg> <3
[16:10] <vorlon> but why was it uploaded to eoan if it wasn't buildable?
[16:11] <LocutusOfBorg> mistake, it was directed to ppa!
[16:11] <LocutusOfBorg> I asked to not accept few times, and I gave up...
[16:11] <LocutusOfBorg> anyway, ./copy-package --from=ubuntu --from-suite=cosmic hy --to=ubuntu --to-suite=eoan-proposed -b
[16:11] <LocutusOfBorg> correct?
[16:11]  * LocutusOfBorg tries and goes catching a train
[16:12] -queuebot:#ubuntu-release- New sync: hy (eoan-proposed/primary) [0.12.1-2]
[16:12] <vorlon> LocutusOfBorg: syntactically correct, but I'm not happy to accept a binary sync from cosmic to eoan of a package that was dropped in disco
[16:14] -queuebot:#ubuntu-release- New: rejected hy [sync] (eoan-proposed) [0.12.1-2]
[16:17] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [amd64] (eoan-proposed) [0.4.0-1]
[16:17] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [armhf] (eoan-proposed) [0.4.0-1]
[16:18] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [ppc64el] (eoan-proposed) [0.4.0-1]
[16:18] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [arm64] (eoan-proposed) [0.4.0-1]
[16:18] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [s390x] (eoan-proposed) [0.4.0-1]
[16:18] -queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [i386] (eoan-proposed) [0.4.0-1]
[16:18] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1007.7]
[16:20] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1039.44] (kernel)
[16:21] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1039.44]
[16:27] <LocutusOfBorg> ok, so better now?
[16:27] <LocutusOfBorg> I or should I upload a build1 version?
[16:28] -queuebot:#ubuntu-release- New sync: hy (eoan-proposed/primary) [0.12.1-2]
[16:28] <LocutusOfBorg> I uploaded both :D
[16:41] <vorlon> LocutusOfBorg: I don't mean that you should sync it from a different release, I mean that I'm not accepting a forward-sync of a package that was dropped in disco.  sourceful upload.
[16:42] <vorlon> LocutusOfBorg: and I only see your sync, not your build1 upload
[16:42] <vorlon> (I did write that in the reject comment before, which I guess you didn't see before re-syncing)
[16:43] -queuebot:#ubuntu-release- New: rejected hy [sync] (eoan-proposed) [0.12.1-2]
[17:00] <LocutusOfBorg> vorlon, I think I did it now, the build1 was "ENONET" interrupted
[17:01] -queuebot:#ubuntu-release- New source: hy (eoan-proposed/primary) [0.12.1-2build1]
[17:02] -queuebot:#ubuntu-release- New: accepted hy [source] (eoan-proposed) [0.12.1-2build1]
[17:03] <LocutusOfBorg> and no, sorry I didn't receive the reject email, even now
[17:06] -queuebot:#ubuntu-release- New binary: hy [amd64] (eoan-proposed/universe) [0.12.1-2build1] (no packageset)
[17:06] <LocutusOfBorg> strange that it built without touching it... meh
[17:07] <LocutusOfBorg> I suppose autopkgtests will be sad
[17:11] <LocutusOfBorg> vorlon, please accept it? :)
[17:12] <LocutusOfBorg> so I can start my weekend having fixed itk4  poppler elastix lintian hy and deken from proposed :D
[17:12] <LocutusOfBorg> acorn is ongoing upstream work
[17:16] -queuebot:#ubuntu-release- New: accepted hy [amd64] (eoan-proposed) [0.12.1-2build1]
[17:18] <jdstrand> sil2100, Laney: note that the libseccomp is there for wider testing before the security team publishes a USN. it isn't a normal SRU
[17:46] -queuebot:#ubuntu-release- New binary: deken [amd64] (eoan-proposed/universe) [0.5.1-1] (no packageset)
[20:18] -queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/universe) [1.0.0-0ubuntu4~18.04.0 => 1.0.0-0ubuntu4~18.04.1] (no packageset)
[20:18] -queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (disco-proposed/universe) [1.0.0-0ubuntu4 => 1.0.0-0ubuntu<IP_ADDRESS>] (no packageset)
[20:18] -queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (cosmic-proposed/universe) [1.0.0-0ubuntu4~18.10.0 => 1.0.0-0ubuntu4~18.10.1] (no packageset)
[20:18] -queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (xenial-proposed/universe) [1.0.0-0ubuntu4~16.04.0 => 1.0.0-0ubuntu4~16.04.1] (no packageset)
[20:28] <rbalint> tjaalton, vorlon could you please accept those packages? ^
[20:28] <rbalint> the diff is tiny :-)
[20:34] <vorlon> rbalint: I don't understand why the test case involves a long-running process. is that to prove that the instance resumed, as opposed to something else (auto-killed by the hypervisor due to networking not coming up?)
[20:35] <vorlon> haha I feel we should really take a closer look at the interaction between this hook, and the hook in lizardfs-chunkserver
[20:36] <rbalint>  vorlon yes, just to prove that the instance is resumed
[20:37] <vorlon> ok
[20:37] <rbalint> i just use screen top
[20:38] -queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (disco-proposed) [1.0.0-0ubuntu<IP_ADDRESS>]
[20:42] -queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (cosmic-proposed) [1.0.0-0ubuntu4~18.10.1]
[20:48] -queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.1]
[23:50] -queuebot:#ubuntu-release- Unapproved: rejected geary [source] (bionic-proposed) [0.12.4-4~ubuntu<IP_ADDRESS>]


[09:46] <mbs1> i am on ubuntu 14.04 and wasnt able to add this ppa:   ppa:neon/kf5
[09:49] <k1l> mbs1: 14.04? this channel is about 14.10 now since that is the development release so far
[11:05] <BluesKaj> 'Morning folks
[18:30] <beardtree> Is there a list of new features for 14.10?


[06:38] <achiang> popey: around? saw your recent mail about qt5.2 and wondering when you think it might land?
[06:40] <achiang> or maybe Mirv knows?
[06:47] <Mirv> achiang: it's testable via PPA:s, but it'd need a huge amount of work still as many packages don't build against it - https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages shows build failures, but not all bugs are filed yet at https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.2
[06:47] <Mirv> achiang: because of the ABI breakage also all ~95 source packages need to be rebuilt against it before it's ok. I've a daily build of around 50-60 set to that PPA
[06:48] <achiang> Mirv: ok. but the plan is to definitely land it for 14.04, right?
[06:48] <Mirv> achiang: yes, definitely so
[06:48] <achiang> Mirv: great, thanks
[06:49] <Mirv> it just might need all hands on it at some rush point to get everything fixed :) but I'm currently preparing the final tarball builds of all Qt modules first before starting to file more bugs on other packages.
[07:04] <achiang> makes sense
[07:04] <achiang> Mirv: also, did that other mail from jani make sense? re: qt + GLES on x86?
[07:04] <achiang> Mirv: for the reason why we want it, that is...
[07:14] <Mirv> achiang: yes, I just don't have much to report on that yet. I started trying to do two builds in case of x86, but then the final 5.2 tarballs came and I've now concentrated on them and moved that work to another WIP directory. I guess doing two builds and then diffing the results might give some picture on if everything changes with that configuration options or such some smaller things.
[07:15] <achiang> Mirv: ok, i don't mean to distract you from your existing work, i was just curious. thanks!
[07:15] <Mirv> achiang: if it doesn't "spread" to other modules from qtbase, then it should be manageable. but if eg. all other modules base their compilations on that qtbase opengl setting, it may be too hard to crack.
[07:16] <achiang> Mirv: mmm.... i see. ok
[09:02] <mzanetti> jkeyes0: hi. you around?
[09:18] <mzanetti> dpm_: o/
[09:19] <mzanetti> dpm_: regarding this: https://code.launchpad.net/~mzanetti/reminders-app/find-notes/+merge/198852
[09:19] <JamesTait> Good morning all; happy Bake Cookies Day! :-D
[09:19] <mzanetti> dpm_: are you having issues with this too?
[09:19] <mzanetti> Good morning you too, JamesTait
[09:21] <mzanetti> oSoMoN_: hi, have time for a question or two on the UbuntuWebView?
[09:22] <oSoMoN_> mzanetti, sure
[09:22] <mzanetti> oSoMoN_: cool. So. I'm using that in the reminders-app to display notes.
[09:23] <mzanetti> oSoMoN: from what I understand, the webview uses it's width as "100%" of the contentHeight
[09:23] <mzanetti> oSoMoN: so that a webpage would be rendered in a way suitable for the display
[09:24] <mzanetti> oSoMoN: however, all my notes are double the screen width which makes them quite bad to use
[09:24] <mzanetti> and also everything is really tiny
[09:24] <mzanetti> am I doing something wrong?
[09:25] <oSoMoN> mzanetti, could you provide me an example note so I can give it a try myself?
[09:26] <mzanetti> oSoMoN: sure. one sec
[09:26] <mzanetti> oSoMoN: this is the branch where I use it btw. lp:~mzanetti/reminders-app/use-webview
[09:26] <mzanetti> oSoMoN: NotePage.qml
[09:27] <mzanetti> here's the merge with the diff: https://code.launchpad.net/~mzanetti/reminders-app/use-webview/+merge/199371
[09:28] <oSoMoN> mzanetti, I see that you’re putting the WebView inside a Flickable
[09:28] <oSoMoN> mzanetti, the WebView itself is already a flickable
[09:28] <mzanetti> oSoMoN: yeah... without that it just does really weird things
[09:28] <mzanetti> but let me try again without it
[09:30] <mzanetti> oSoMoN: can't paste the content :D it gets recognized as spam on all the pasters I've tried :D
[09:30] <mzanetti> oSoMoN: I'll send you a mail
[09:31] <oSoMoN> mzanetti, ok
[09:32] <mzanetti> oSoMoN: removed the flickable. doesn't really change anything on the content representation tho
[09:35] <oSoMoN> mzanetti, ok, I’ll check out the test note that you sent me
[09:35] <mzanetti> oSoMoN: http://i.imgur.com/eXdLPvY.png
[09:36] <mzanetti> oSoMoN: so I would expect width to be smaller and instead the text larger
[09:37] <oSoMoN> mzanetti, not sure what you mean by "the width to be smaller"?
[09:38] <oSoMoN> it looks like it’s flowing to take all the available width, which sounds right to me
[09:40] <oSoMoN> it does the same when opening the sample note in chromium btw
[09:40] <mzanetti> oSoMoN: yeah... I mean it should tell the content that the width is less, and then scale it up again to use all the available width
[09:40] <mzanetti> effectively making the text bigger, but not as much space between the words
[09:42] <oSoMoN> mzanetti, so do I understand it correctly that it’s a only a matter of base font size?
[09:42] <oSoMoN> or is there more to it?
[09:43] <mzanetti> oSoMoN: what I mean is http://i.imgur.com/SXhCe8Y.png vs http://i.imgur.com/48t1Oaj.png
[09:43] <mzanetti> In the app's webview, if I zoom in I need to scroll to the right to see everything. in chrome it does what I'd expect it to do
[09:43] <oSoMoN> got it
[09:44] <oSoMoN> let me see how that can be achieved with a WebView
[09:49] <oSoMoN> mzanetti, the webview has a zoomFactor "property" but it’s not exposed to QML, only available in C++
[09:50] <oSoMoN> mzanetti, I’ll dig further, there must be a way to change the zoom factor
[10:11] <oSoMoN> mzanetti, try adding this to your UbuntuWebView: "experimental.preferredMinimumContentsWidth: width"
[10:12] <oSoMoN> mzanetti, I can’t guarantee it will do exactly the right thing everywhere, but it seems to work here on my desktop
[10:12]  * mzanetti tries
[10:14] <mzanetti> oSoMoN: hmm... doesn't seem to have any effect
[10:15] <oSoMoN> mzanetti, the problem you’re having, is that only on your laptop, or also on devices?
[10:15] <mzanetti> oSoMoN: on the device too
[10:15] <mzanetti> actually I'm only considering the device right now, knowing that my laptop is somewhat special in this regard
[10:16] <mzanetti> although it should be closer to the device actually
[10:18] <oSoMoN> mzanetti, do you control the contents of the notes? i.e. can you modify the html on the fly?
[10:19] <oSoMoN> if so, you could use the viewport meta tag
[10:19] <mzanetti> oSoMoN: yeah.. I converti it from enml to html myself
[10:19] <mzanetti> oh, interesting, tell me more
[10:20] <oSoMoN> not super familiar with it myself, but it looks like it allows you to implement zooming at the CSS level
[10:20] <oSoMoN> see e.g. http://html5hacks.com/blog/2012/11/28/elegantly-resize-your-page-with-the-at-viewport-css-declaration/
[10:20] <oSoMoN> probably worth a try
[10:20] <Mirv> renato: I'd need help compiling qtpim against Qt 5.2.0, could you help at some point?
[10:20] <mzanetti> oSoMoN: ok. I'll check that out. thanks!
[10:21] <oSoMoN> yw!
[10:21] <oSoMoN> I hope this solves your issue somehow
[10:23] <mzanetti> oSoMoN: http://i.imgur.com/j10QcHK.png
[10:24] <mzanetti>  \o/ thanks a bunch!
[10:24] <Mirv> renato: I just pushed to  lp:~kubuntu-packagers/kubuntu-packaging/qtpim-opensource-src what doesn't yet build. so if you apt-add-repository ppa:canonical-qt5-edgers/qt5-beta2 , upgrade to that (if it's ok your desktop Qt gets to WIP 5.2.0, if not maybe do it in chroot or virtual machine?) and try bzr bd you should see the problem
[10:24] <oSoMoN> yay for CSS
[10:24] <mzanetti> oSoMoN: I used this one <meta name="viewport" content="width=320" />
[10:25] <Mirv> renato: so the difference with Qt 5.2.0 is that git snapshot modules need "syncqt" to be run, which I've done also for qtpim now. patching it like that fixes the other git snapshot modules, but in the case of qtpim it still complains about headers.
[10:25] <oSoMoN> mzanetti, this will have to be tested on various devices to confirm it scales correctly everywhere
[10:26] <mzanetti> oSoMoN: sure. I need to calculate the width according to the grid units. but I'm confident I can get there with this
[10:32] <Mirv> renato: and it looks something like private own headers shouldn't be referred to with "<private/foo_p.h>" but just "<foo_p.h>". I'm hacking around, though.
[10:35] <imapados> hey guys! i searched for the Ubuntu Packacking Guide, but it does not exist in https://wiki.ubuntu.com/PackagingGuide/Basic has someone a idea, where i get some specific Ubuntu Software Center Information? And yes i know http://developer.ubuntu.com/publish/
[11:02] <dpm_> imapados, http://packaging.ubuntu.com/
[11:51] <imapados> dpm_, thx. :)
[14:16] <mzanetti> dpm: thanks :)
[14:17] <dpm> mzanetti, well, thank you :) Looking at get-username next
[14:17] <mzanetti> dpm: did you see my work from yesterday night?
[14:18] <mzanetti> dpm: using a WebView now for the read only mode. have been able to inject some scripting in order to toggle the checkboxes for todos. and also it supports 100 of the enml tags (after converting them to html)
[14:18] <dpm> mzanetti, I've tried to test the latest branch, but I think it wasn't actually the latest. In the meantime I've seen your branches for WebView and switch to c-make :)
[14:18] <mzanetti> yeah... cmake is not complete yet. You can build it in qtcreator with it, but things like run_on_device.sh still need updating
[14:19] <dpm> mzanetti, ah, that's really cool, nice to see you found a workaround for the checkboxes
[14:19] <mzanetti> dpm: yeah... actually seems to be a solution, not a workaround ;)
[14:20] <dpm> yeah, it sounds like a proper one and not a hack :)
[14:20] <dpm> mzanetti, in the get-username branch (I've not yet looked at the code, just built it on the device now), am I supposed to see the account username on the first screen? It still appears as an empty list item
[14:21] <mzanetti> dpm: no... it just adds the stuff so we can use it in the accounts plugin
[14:21] <dpm> ah, ok
[14:21] <mzanetti> dpm: but we still need to merge the accounts plugin repo into this
[14:21] <mzanetti> dpm: that's slowly crawling upwards my todo list
[14:22] <dpm> mzanetti, yeah, let's wait for dbarth to come back to us, though. He mentioned this morning that there is a way to unblock the landing of the accounts plugin package by shipping the key in the app and using another Online Accounts API
[14:23] <dpm> and that he might even submit an MP for this
[14:23] <mzanetti> dpm: still we'd need to copy all the c++ code from lp:reminders-app to lp:accounts-plugin-evernote, or merge the two
[14:23]  * mzanetti would prefer the latter
[14:25] <dpm> mzanetti, yeah, I think the latter is what we decided on that e-mail thread
[14:25]  * dpm needs to re-read
[14:26] <mzanetti> dpm: well, I think I managed to mostly convince you guys that it would be the best approach in my opinion. not sure we "agreed" on it yet
[14:27] <dpm> :)
[14:27]  * dpm jumps on the phone and bbl's
[16:07] <mzanetti> fginther: hello
[16:07] <mzanetti> fginther: this seems like a job config issue: http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/501/console
[16:08] <mzanetti> coming from this merge: https://code.launchpad.net/~mzanetti/reminders-app/rework-error-handling/+merge/196987
[16:08] <fginther> mzanetti, looking
[16:08] <mzanetti> or well, rather a executor issue
[16:11] <fginther> mzanetti, I see it, looks like a bad update
[16:13] <mzanetti> fginther: ok. I re-triggered the job. or do you think this requires manual intervention on the machine?
[16:13] <fginther> mzanetti, yes, the package state needs fixing, working on it now
[16:16] <fginther> mzanetti, should be fixed now
[16:47] <mzanetti> fginther: thanks. yeah, works fine again
[16:47] <mzanetti> dpm: regarding this: https://code.launchpad.net/~mzanetti/reminders-app/find-notes/+merge/198852
[16:48] <mzanetti> dpm: do I need to switch to an older API or is it fine to require trusty (or appropriate ppas on saucy) for development?
[16:48] <mzanetti> seems plain saucy doesn't ship a recent enough version of ubuntu-ui-toolkit
[16:49] <daker> mzanetti: yes!
[16:52] <mzanetti> daker: ?
[16:53] <daker> saucy ships an old version of ubuntu-ui-toolkit
[16:53] <mzanetti> ah ok :) thanks for confirming
[16:53] <mzanetti> daker: you don't happen to know if there is a ppa which ships newer versions?
[16:53] <daker> mzanetti: if you find one let me know :)
[16:54] <daker> nik90: ?
[16:55] <timp> mzanetti, daker https://launchpad.net/~ubuntu-sdk-team/+archive/ppa/+packages?batch=75&memo=75&start=75
[16:56] <mzanetti> timp: ah, nice! thanks
[16:56] <daker> timp: thanks!
[17:19] <ahayzen> balloons, ping
[17:19] <balloons> ahayzen, pong
[17:19] <ahayzen> balloons, sry to bother u ...more Jenkins issues....http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/499/console
[17:20] <ahayzen> balloons, we are getting 'The following packages have unmet dependencies'
[17:21] <balloons> ahayzen, ahh.. need to wait for the archive to settle
[17:21] <balloons> ahayzen, what's the merge proposal?
[17:21] <ahayzen> balloons, ok cool (this was last night) https://code.launchpad.net/~andrew-hayzen/music-app/fix-1261926-loader-centre/+merge/199376
[17:22] <balloons> ahayzen, ahh, so likely I can just rerun and it will work
[17:22] <balloons> let's try
[17:22] <ahayzen> balloons, the branch can probably be approved anyway :)
[17:22] <balloons> ahh, I'll top approve if it passes since Victor approved
[17:23] <ahayzen> balloons, thanks
[18:49] <balloons> ahayzen, so no movement on the mp.. wild
[19:23] <ahayzen-mobile> balloons, the trusty slave is down/ paused?
[19:48] <ahayzen> balloons, this one says it is '(pending - mediumtests-trusty-slave is offline )' http://<IP_ADDRESS>:8080/job/generic-mediumtests-trusty/
[19:48] <balloons> ahayzen, yes I saw that as well. I've pinged the ci folks
[19:48] <ahayzen> balloons, cool :) Jenkins has been a bit wild over the past few days lol
[19:52] <balloons> yes indeed it has been actually
[19:52] <balloons> holidays :-)
[19:54] <ahayzen> :)
[21:17] <xtoxicwastx> hello
[23:04] <achiang> has anyone tried porting qtcreator-plugin-ubuntu to qtcreator 3.0 yet?
[23:22] <daker> can anyone confirm this bug 1262414 ?
[23:22] <ubot2`> Launchpad bug 1262414 in webbrowser-app (Ubuntu) "Loading big images shows content of the previous app" [Undecided,New] https://launchpad.net/bugs/1262414


[02:08] <doko> vil: please could you test 68380 and add a comment, so that this can go to edgy-updates?
[02:10] <vil> doko, ok, I will take a look
[04:19] <vil> doko, can we talk a bit about that bug?
[06:31] <erich_> Hi there... I'm having trouble getting jini to execute under jdk6 on ubuntu 6.10... after installing Jini2_1, the 'Launch All' script produces a bunch of libc/libm errors, and none of the services fire up... I've tried reinstalling jini after commenting out instances of 'export LD_ASSUME_KERNEL' to no avail..
[06:32] <erich_> any help will be much appreciated.
[06:38] <man-di> erich_: you need to tell us the errors you are getting, our crystal eyes are broken today.
[06:42] <erich_> sorry -
[06:43] <erich_> erich@Kubunto1:~/jini2_1/installverify$ ./Launch-All
[06:43] <erich_> nawk: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> /bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
[06:43] <erich_> basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[06:43] <erich_> /usr/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
[06:49] <man-di> these are all part of libc6
[06:49] <erich_> perhaps I should mention that I installed jdk manually, did update-alternatives, and pointed jini to the /usr/bin/java
[06:49] <man-di> you are not trying to run 32-bit jdk on 64-bit arch like amd64 without having 32bit compat libs installed?
[06:49] <erich_> librt.so.1 is oart of libc?
[06:49] <erich_> ahsohi
[06:50] <erich_> that may be - thank you for the divination.
[06:51] <man-di> yes, librt.so.1 is part of libc6 too
[06:52] <erich_> got it... I'll go find the compatibility libs... didn't realize that would be an issue...
[06:52] <man-di> erich_: btw: JDK 6 is part of ubuntu already, just apt-get it
[06:52] <man-di> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=sun-java6-jdk
[06:52] <man-di> no need to install it on your own
[06:52] <erich_> thanks... just found that... hence mentioning I did it manually..
[06:52] <erich_> I suppose that would have fixed my dependency problems...
[06:53] <man-di> depends on the dependency problems, but I guess so
[06:53] <erich_> the amd64 compatibility thing..
[06:54] <man-di> ah
[06:54] <man-di> then yes
[06:54] <erich_> lol - I thought I had looked for it.. better check my source list.
[06:54] <erich_> thanks again.
[06:55] <man-di> n.p.
[06:56] <erich_> have a great day, all.
[10:17] <vil> doko_, ping
[10:21] <man-di> vil: he seesm to be offline all day long
[10:21] <vil> man-di, yes, looks like
[10:22] <vil> nice to see you here
[10:22] <man-di> doko forced me to
[10:22] <vil> also nice that you answer questions from ubuntu users
[10:22] <vil> why did he force you?
[10:22] <man-di> and after feisty is out I wanna join ubuntu-motu to be able to sync/merge packages
[10:23] <man-di> he wanted to talk about eclipse here yesterday evening
[10:25] <vil> we all were at #debian-java, but this place is somewhat less crowded :)
[10:26] <man-di> thats what I said to doko too
[10:26] <man-di> doko wanted to talk on freenode instead of oftc
[10:27] <man-di> vil: less crowded == less java people
[10:28] <vil> i don't know oftc much
[10:28] <vil> just that one channel
[10:29] <vil> man-di, but you are now here and maybe will bring more people with you
[10:30] <man-di> I doubt that
[10:30] <vil> man-di, I would like to ask couple of questions
[10:30] <man-di> sure, jast ask
[10:30] <man-di> just
[10:31] <vil> svn for debian dirs at alioth is a nice idea, but it is still not ok
[10:31] <vil> we still use patches etc...
[10:32] <vil> how do you use that svn? just co everytime you work with the package?
[10:32] <man-di> depends
[10:32] <vil> do you use some scripts for that ala dpkg-svn-whatever?
[10:32] <man-di> for eclipse I commit whenever I tested a change
[10:32] <man-di> when enough changes are done: upload
[10:33] <man-di> for smaller packages I normally do all changes, test, etc and then commit all at once
[10:33] <man-di> when uploaded, I tag the svn
[10:33] <vil> do you know bzr in ubuntu, they are trying to use it for whole package including the sources
[10:34] <man-di> you can use svn-buildpackage with svn but I prefer my own small helpers and simple command line tools
[10:34] <man-di> yes, I know
[10:34] <man-di> doesnt really makes the world a better place
[10:34] <vil> ok, i would really like to hear some opinions about it
[10:35] <vil> i personally like it cause i think it simplifies work with patches, but i cannot imagine to use it for eclipse
[10:35] <man-di> I'm very much used to cvs and svn
[10:36] <man-di> but I'm playing with other systems
[10:36] <man-di> currently I play a bit with Mercurial
[10:36] <man-di> for work
[10:36] <man-di> and for openjdk
[10:37] <man-di> git is nice too
[10:38] <vil> i don't mind a particular system but the use of it ... to forget about debian/patches, because vcs handles that
[10:39] <vil> what is your opinion about this?
[10:41] <man-di> I like to have that explicitely
[10:42] <vil> it's also easier to pick patches from fedora, right? :)
[10:42] <man-di> because it makes it easy to see what is from upstream and what is from debian and why, it makes adopting new upstream versions easy and need no VCS see that
[10:43] <vil> for deifferentiating between upstream and debian, you can use 2 repos
[10:44] <vil> but it can be handy to have the patches explicit
[10:44] <vil> next question...
[10:44] <vil> man-di, fedora seems to be a bit further with eclipse
[10:45] <vil> i don't mind specfile editor, but emf, subclipse etc.
[10:45] <vil> any plans for this?
[10:45] <man-di> plans yes
[10:45] <man-di> but time....
[10:47] <vil> understand
[10:47] <vil> i was looking into that a bit, but time...
[10:48] <man-di> are you in the eclipse.linux-distros mailinglist?
[10:48] <vil> yes
[10:48] <vil> couple of new commiters in the last few months
[10:48] <man-di> yes, including me ;-)
[10:49] <man-di> I think doko has still not all papers on file
[10:49] <man-di> otherwise he would be one too
[10:50] <vil> i believe that doko is so busy that he should consider every new task
[10:50] <man-di> vil: this task is only about voting rights in the eclipse.linux-distros project
[10:50] <man-di> so not much to do
[10:51] <man-di> ejb2 is physical torture
[10:51] <man-di> if you still use it you are lost
[10:51] <man-di> ejb3 is very much different from it and much easier
[10:51] <vil> but you still curse
[10:52] <man-di> vil: the problem is that its not so easy to create junit tests that just run
[10:52] <man-di> without an application server injecting the entitiy manager
[10:53] <vil> don't know much about that
[10:54] <vil> do you also use something to test jsf? just currious
[10:55] <man-di> not yet
[10:55] <vil> ok
[10:55] <man-di> but I have some projects that test our jsp output
[10:55] <man-di> httpunit and htmlunit are great for this
[10:56] <man-di> to test functionality of webpages
[11:04] <vil> man-di, thanks for hints
[11:04] <man-di> np
[12:07] <vil> man-di, still alive?