[00:00] <cjwatson> actually, mawson has a sufficient python-apt version
[00:00] <cjwatson> it'll have trouble with the multiarch-translations branch until we get it upgraded, but it'll be good enough for dpkg-xz-support
[00:01] <cjwatson> so it can be QAed on dogfood
[00:01] <StevenK> cjwatson: If this branch lands, it should be fine to test on mawson on Monday -- prod myself or wgrant before you start so we can update its code.
[00:02] <cjwatson> in that case, can I get https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 landed too?  we can test it on mawson then too
[00:02] <cjwatson> (I don't know what the procedure for QAing db-devel branches is)
[00:03] <StevenK> I think you might need to change the DB patch number. lifeless: ^
[00:03] <lifeless> cjwatson: that needs to be split
[00:03] <lifeless> its got both code and schema
[00:03] <lifeless> and we only deploy schema from db-devel
[00:04] <cjwatson> hm?  I already split out a schema branch for that
[00:04] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[00:04] <lifeless> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 ? i see changes to lib/lp/archivepublisher/model/ftparchive.py, to [00:04] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema which has landed
[00:04] <lifeless>  etc
[00:05] <cjwatson> multiarch-translations was supposed to be just the code bit
[00:05] <lifeless> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 has a db patch in it - = added file 'database/schema/patch-2208-79-0.sql'
[00:05] <lifeless> so this need to go to devel
[00:05] <lifeless> and it can't land until we've deployed the schema change
[00:06] <lifeless> thats blocked on the losas finishing pgbouncer migration
[00:06] <cjwatson> I'm confused about why LP is showing that, if you look at https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema/+merge/67992 then it has the same schema patch
[00:06] <cjwatson> and it's merged
[00:06] <lifeless> which is blocked on them sprinting
[00:06] <lifeless> its certainly not deployed
[00:06] <cjwatson> I was told a couple of weeks ago that multiarch-translations needed to go to db-devel :-(
[00:06] <lifeless> the schema did
[00:06] <cjwatson> I would appreciate a consistent story here
[00:06] <lifeless> the other part, *if* you land on db-devel, will sit there until you cherrypick it across to devel post deploy of the schema change.
[00:07] <cjwatson> I can't cherrypick anything to devel personally, no access
[00:07] <StevenK> 79-0 is already on db-devel
[00:07] <lifeless> well, you would do it by preparing another branch which we can land via ec2 at the right time
[00:08] <lifeless> cjwatson: if you want to flush your queue, you can land this on db-devel yes. But we can't deploy it from there,
[00:08] <lifeless> cjwatson: I'm sorry that this feels inconsistent to you
[00:08] <lifeless> cjwatson: particularly if its my fault :)
[00:08] <cjwatson> 2011-07-14.log:12:54 <lifeless> cjwatson: for your branch, you'll need to land both components on db-devel (because we're not live on the incremental deploy steps yet)
[00:09] <lifeless> cjwatson: ah yes, so thats up to me to be more clear
[00:09] <cjwatson> so right now I am completely confused as to what I need to do.  I don't care about flushing my queue, I care about getting things deployed
[00:09] <lifeless> ok
[00:10] <StevenK> I can see the schema is already on db-devel
[00:10] <lifeless> so right now, this is blocked on losa work: we have no way to deploy schema changes until the pgbouncer migration is completed.
[00:10] <lifeless> thats stubs and the losas top priority ticket
[00:10] <lifeless> as soon as thats done we'll start doing fastdowntimes, one per day, with one db patch per day
[00:10] <cjwatson> that's fine.  what I'd like to know is (a) how I know when to proceed (b) what I should do next
[00:11] <cjwatson> oh and (c) what if anythng I should do to the multiarch-translations branch
[00:11] <lifeless> so - nothing.
[00:11] <cjwatson> merge it from db-devel maybe?
[00:11] <lifeless> the bug for the schema change should be sitting in fix committed now
[00:12] <lifeless> when we have the patch deployed that will toggle to fix released
[00:12] <lifeless> and we can continue with the rest of the work
[00:15] <cjwatson> bug for the schema change> is that https://bugs.launchpad.net/launchpad/+bug/809123 ?
[00:15] <_mup_> Bug #809123: we cannot deploy DB schema changes live <fastdowntime> <qa-ok> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/809123 >
[00:15] <lifeless> that too; no I meant the one linked to your schema patch
[00:16] <lifeless> (there is one, isn't there? it may be the main one for your translations support)
[00:16] <cjwatson> there isn't onoe
[00:16] <lifeless> ah
[00:16] <lifeless> ok
[00:16] <beuno> hm
[00:16] <lifeless> so i suggest picking this up when 809123 is fix released
[00:16] <beuno> I'm getting an oops when searching for someone (trying to add a new ubuntu member)
[00:16] <lifeless> at that point we'll be a few days out from your thing being live
[00:16] <beuno> OOPS-2057DX
[00:16] <cjwatson> ok, subscribing to that
[00:18] <cjwatson> I basically just want to make sure that any delays in the process are not down to me - it's felt very much like there've been serial multiple-day delays so far
[00:19] <cjwatson> and I appreciate the assistance in deployment but the feature in general is important enough that I need to report on t
[00:19] <lifeless> cjwatson: welcome to LP dev :)
[00:19] <cjwatson> *it
[00:19] <cjwatson> heh
[00:20] <lifeless> cjwatson: this is one of the things that we're working on reducing - dev friction is insanely high atm
[00:20] <cjwatson> right, understood
[00:20] <cjwatson> and FWIW non-db stuff has clearly been getting better from my POV
[00:20] <lifeless> thanks!
[00:32] <cjwatson> I've merged db-devel into multiarch-translations so that it now clearly only contains code.  Do I need to resubmit that against devel (presumably after 809123 is fix released)?  Can I do that without losing approvals or will it need re-rubber-stamped?
[00:35] <lifeless> yes, an dyes, and probably needs a rubber stamp at that point. Use the 'resubmit' button.
[00:35] <lifeless> (at the right time)
[00:36] <cjwatson> ok
[02:19] <jtv> Hi wallyworld__
[02:19] <wallyworld__> jtv: yellow
[02:20] <jtv> ?
[02:20] <wallyworld__> jtv: hello
[02:20] <jtv> Ah.
[02:20] <wallyworld__> one review just popped up recently
[02:20] <wallyworld__> doing it soon
[02:20] <jtv> OK
[02:20] <wallyworld__> just finishing off a ^@%%@!& yui test
[02:21]  * jtv shudders in sympathy
[03:35] <jtv> StevenK, are you hammering dogfood?
[03:38] <StevenK> Not any more
[03:40] <jtv> Ah.  I just updated the code/schema as well.
[03:42] <jtv> And now it's failed to come up.
[03:42] <jtv> Ah.  Not that again.
[03:43] <jtv> Fixing it.
[04:07] <nigelb> wallyworld__: I thought my feelings to yui was isolated. apparently not ;-)
[04:08] <wallyworld__> nigelb: it's not that bad actually. just a bit tedious sometimes
[04:08] <nigelb> I know!
[04:08] <wallyworld__> to mock everything needed to allow the tests to run in isolation
[04:08] <nigelb> that's one of the things I'm stuck at because I lack time.
[04:08] <wallyworld__> how is your branch?
[04:08] <wallyworld__> yeah, i can understand that
[04:08] <nigelb> needs tests
[04:09] <wallyworld__> well you are not alone there
[04:09] <nigelb> hehe
[04:09] <nigelb> and work's been busy, so I get very little time
[04:09] <wallyworld__> what do yiu do for work?
[04:10] <nigelb> er, what? :)
[04:10] <wallyworld__> what's your day job?
[04:10] <nigelb> ah, I work as a systems engineer at a local startup :)
[04:11] <wallyworld__> sounds cool. i worked for a startup once, about 11 years ago
[04:11] <wallyworld__> but they went bust
[04:11] <wallyworld__> is everything working apart from the tests?
[04:11] <nigelb> heh
[04:11] <nigelb> yeah, the code's working for anon as well as non-anon user
[04:11] <nigelb> and I tested with private bug too
[04:12] <nigelb> so I want to catch alll that i my tests
[04:12] <nigelb> I put some ground work in there
[04:12] <wallyworld__> sounds good.
[04:14] <nigelb> the javascript bits doesn't have a test right now
[04:14] <lifeless> booyah
[04:14] <lifeless> I have oopses from gpgverify.
[04:14] <nigelb> So, I'll probably write a test for the entire code.  Also, because I want to learn how to do it
[04:19] <wallyworld__> nigelb: well, yes it will be educational to do it for sure
[04:20] <StevenK> s/educational/brain-damaging/
[04:21] <nigelb> lifeless: congrats!
[04:21] <nigelb> wallyworld__: yeah, that was my thinking :)
[04:21] <nigelb> StevenK: bwahaha
[04:25] <wgrant> lifeless: Paste?
[04:29] <lifeless> web.py
[04:30] <lifeless> doing $anything on thursday is daft.
[04:30] <lifeless> rule 1.
[04:30] <wgrant> I thought you'd discounted it.
[04:30] <wgrant> Hah.
[04:30] <wgrant> Right.
[04:30] <lifeless> http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/revision/11?start_revid=11
[04:32] <wgrant> text/html... ew.
[04:32] <lifeless> meh
[04:32] <lifeless> that was cargo cloned; I should change.
[04:33] <wgrant> It must not be used frivolously.
[04:33] <wgrant> Like Twisted Web.
[04:33] <wgrant> (it defaults to text/html... what could possibly go wrong)
[04:33] <lifeless> or $all $web $frameworks
[04:33] <lifeless> so does flask
[04:33] <lifeless> and paste IIRC
[04:33] <wgrant> Kill it.
[04:33] <lifeless> for their errors
[04:33] <mwhudson> so does django
[04:33] <wgrant> Kill them all.
[04:33] <mwhudson> +1 wgrant
[04:34] <wgrant> Yes, let's just default to the most dangerous content type in the world.
[04:34] <wgrant> Nothing bad could come of that.
[04:37] <lifeless> fixed in 12
[04:40] <wgrant> Thanks.
[04:40] <wgrant> Although 'OOPS-ID' is not a standard HTTP header, AFAIK :P
[04:41] <nigelb> picky :P
[04:46] <wgrant> lifeless: We can't have some generic WSGI container launcher thing that does OOPS stuff, rather than having all this stuff in the core code of every service?
[04:46] <wgrant> Like our scripts, it seems silly to have all these boilerplate wrapper scripts rather than a parameterised launcher.
[04:49] <wgrant> I guess twistd is already a similar sort of thing.
[04:49] <wgrant> But I think we should do it for more than just daemons :)
[04:59] <lifeless> wgrant: well, if we have two * web.py services, we can have python-oops-webpy
[04:59] <lifeless> wgrant: it should be!
[05:00] <lifeless> wgrant: the problem is, as I said yesterday, web.py isn't actually wsgi
[05:00] <lifeless> its kindof wsgo
[05:01] <lifeless> same goes for flask.weurkzeug
[05:01] <lifeless> s/\.////
[05:01] <wgrant> :(
[05:01] <lifeless> they both want to stop exceptions bubbling out
[05:01] <lifeless> so they error handle themselves rather than as layers
[05:01] <wgrant> Yay
[05:02] <lifeless> by the time you're sniffing start_response for 500's and trying to reconstruct a long-gong sys.exc_info you've lost.
[05:02] <lifeless> I think hooking in in the preferred for for any given framework is best.
[05:02] <lifeless> thats the point of having a simple, flexible core, after all.
[05:02] <lifeless> its just a shame that wsgi is so micro that few things use it.
[05:03] <wgrant> It would be nice if there was a standard.
[05:03] <lifeless> e.g. werkzeug uses request and response objects, which wsgi has no knowledge off (and response puns as a wsgi app... which is actually quite good)
[05:03] <lifeless> but its request objects are thread local meta things
[05:05] <lifeless> anyhow
[05:05] <lifeless> I'm going to setup a project for gpgverify
[05:05] <lifeless> shove the current code in there
[05:05] <lifeless> teach it to handle detached sigs and use a regular form object at the same time
[05:05] <lifeless> and then next week, deploy the biatch.
[05:06] <lifeless> jamesh is playing with python-oops-wsgi, which django manages to have a sane way to integrate in
[05:06] <wgrant> Excellent.
[05:06] <lifeless> which is - huge - brownie points for django IMO
[05:07] <wgrant> (are you keeping a reasonably small backlog of in-progress work now, given your impending incapacitation?)
[05:07] <lifeless> we have two very modest features identified there to make it have parity with the used features of wsgi-oops
[05:07] <lifeless> wgrant: as much as I can yeah
[05:07] <wgrant> Great.
[05:07] <lifeless> I wanted to unblock SOA before my life changes forever
[05:07] <wgrant> Yes.
[05:08] <lifeless> the one key thing for oops remaining is to teach oops-tools to use a repo interface rather than parsing itself
[05:08] <lifeless> then we could switch it over to a different backend
[05:08] <wgrant> That interface gives back a dict?
[05:08] <lifeless> yes
[05:08] <wgrant> The current repo implementation is just a directory containing date dirs?
[05:09] <wgrant> So oops-tools would need lots?
[05:09] <lifeless> we'd want to shuffle a bunch of stuff like getOopReport(id) from lp into python-oops-datedir-repo
[05:10] <lifeless> we could model oops-tools needs as either a collection of repos
[05:10] <lifeless> or as a repo with knowledge of many root dirs.
[05:10] <wgrant> Right.
[05:10] <lifeless> the main thing is to lift the conceptual stuff out of rfc822 parsing and up to useful types
[05:10] <lifeless> with that done, we can switch to bson and iterate on things like messages and extra keys easily enough
[05:11] <lifeless> which is a totally separate project.
[05:11] <lifeless> relatedly, moving to cassandra might be unblocked if we take a map-reduce search approach rather than a pre-indexed one (for finding oopses by non-id)
[05:12] <wgrant> Why can't we pre-index?
[05:12] <lifeless> we can, with e.g. solandra
[05:12] <lifeless> but if we want anything more sophisticated map-reduce is probably a good idea anyway
[05:12] <wgrant> Yeah.
[05:12] <wgrant> Killall solr
[05:12] <lifeless> so starting with map-reduce would deliver the necessary conditions
[05:13] <lifeless> whereas starting with solandra doesn't really.
[05:13] <lifeless> þ
[05:16] <lifeless> anyhow
[05:16] <lifeless> thats for tomorrow^Wmonday
[06:40] <poolie> lifeless, hi, could we have a short supplementary chat?
[06:41] <nigelb> g31
[06:41] <nigelb> argh
[06:42] <poolie> :)
[08:07] <henninge> Anybody merging stable into db-devel currently?
[08:14] <henninge> No, that's not trivial for me.
[08:14] <henninge> ^ Looks like something jelmer_ and bigjools could do.
[08:17] <bigjools> seriously?
[08:17] <henninge> rvba: I will request a deploy. If your QA is quick it can still be included. ;-)
[08:18] <henninge> bigjools: I looked at bzr annotate and found your name and jelmer's for safe_open
[08:18] <rvba> henninge: if you're talking about 820452 then I'm afraid the QA won't be quick. :(
[08:18] <henninge> rvba: ok, np
[08:19] <henninge> one more reason to request the deploy asap ;)
[08:19] <rvba> Right :)
[08:22] <jelmer_> henninge, I'll have a look
[08:23] <henninge> bigjools, jelmer_ : I have a branch ready, so if you want to tell me how to fix it, I can do the mechanics.
[08:23] <bigjools> henninge: have you fixed the conflicts?
[08:23] <henninge> no ;)
[08:23] <henninge> just done the merge and looked at them
[08:24] <henninge> it's just one in each file, so it might be easy
[08:24] <bigjools> ok
[08:29] <StevenK> henninge: I'm a little concerned about deploying now, TBH.
[08:29] <henninge> StevenK: why is that?
[08:29] <henninge> StevenK: because it's Friday?
[08:29] <StevenK> henninge: Because most of IS are going to be on a plane over the weekend
[08:30] <henninge> oic
[08:30] <wgrant> It's Friday and everyone will be in the air for the weekend.
[08:30] <wgrant> And we don't have APAC LOSAs on Monday.
[08:30] <wgrant> The first LOSA will appear in 72 hours.
[08:30] <bigjools> do not deploy today, please
[08:30] <StevenK> The earliest we can deal with problems is Monday UK
[08:30] <henninge> good reasons ;-)
[08:30] <bigjools> we never deply on Fridays
[08:30] <henninge> I thought mornings are ok
[08:31] <henninge> but the "in the air" issue is a neck breaker.
[08:31] <henninge> I will re-visit this on Monday
[08:31] <bigjools> mornings are not ok
[08:31] <bigjools> some problems will only occurr overnight
[08:31] <henninge> so I learn ;-)
[08:32] <StevenK> henninge: Friday morning *in Australia* can be okay, since then we have LOSA coverage for another long while
[08:32] <wgrant> (we will occasionally deploy up to early afternoon my time, but I normally try to stick to mornings)
[08:34] <bigjools> henninge: for the test_notification conflict, take the second, larger chunk
[08:34] <henninge> bigjools: I will
[08:34] <bigjools> I dunno about the other
[08:36] <henninge> jelmer_: any insight on the merge?
[08:36] <henninge> for safe_open.py
[08:37] <allenap> henninge: I just emailed the list that I would sort out the stable -> db-devel conflicts, but bigjools says you're on it, and so I shall leave you to it :) Thank you.
[08:38] <henninge> allenap: you're welcome
[08:47] <jelmer_> henninge: what's the conflict like?
[08:47] <henninge> jelmer_: let me paste it
[08:48] <henninge> jelmer_: http://paste.ubuntu.com/669867/
[08:51] <jelmer_> henninge: you'd want the second chunk in that case
[08:51] <jelmer_> (bzr resolve --take-other)
[08:58] <jelmer_> is there a wiki page that describes what branch gets deployed where, when, how often, etc?
[09:01] <henninge> jelmer_: thanks
[09:06] <lifeless> poolie: sure
[10:22] <cjwatson> argh, why does launchpad-dependencies hate me
[10:23] <StevenK> cjwatson: It isn't just you, sadly.
[10:23] <cjwatson> turns out that the upload target isn't a reliable way to test which version it's being built for either
[10:24] <StevenK> cjwatson: I think I've just figured why your branch failed in ec2, too.
[10:24] <cjwatson> so it's broken in lucid right now
[10:24] <cjwatson> I suspect it might be related?
[10:24] <cjwatson> I mean, I noticed while trying to upgrade my LP dev VM, but ...
[10:24] <StevenK> cjwatson: The ec2 images are not updated for newer dependencies, they need to be done manually.
[10:25] <cjwatson> I could have sworn I saw an apt-get dist-upgrade in the test setup
[10:25] <cjwatson> ./lib/devscripts/ec2test/instance.py:134:aptitude -y full-upgrade
[10:25] <cjwatson>  launchpad-dependencies (0.97~lucid1) natty; urgency=low
[10:25] <StevenK> Hmm
[10:25] <cjwatson> anyway, that's why it's going wrong
[10:25] <cjwatson> bloody recipes
[10:26] <StevenK> Hah
[10:27] <cjwatson> while the IS builds are more like "launchpad-dependencies (0.97~0.IS.10.04) lucid-cat; urgency=low"
[10:54] <cjwatson> Could somebody review/merge https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 ?  Reasonably urgent since launchpad-dependencies is currently broken in the LP PPA for lucid
[10:54] <cjwatson> StevenK: maybe you could?
[11:02] <StevenK> cjwatson: You mean distroseries, not distribution
[11:03] <StevenK> But perhaps we should fix that
[11:03] <StevenK> Either way, r=me
[11:08] <cjwatson> StevenK: well - it's called Distribution in dpkg-parsechangelog output
[11:08] <cjwatson> so I was mirroring that
[11:08] <cjwatson> I can rename if you feel it necessary
[11:09] <cjwatson> StevenK: can you land it for me?
[11:29] <jtv> gary_poster: hi!  Say, do you know how I can enumerate all of Launchpad's registered utilities?  getGlobalSiteManager().registeredUtilities() gives me nothing.
[11:30] <gary_poster> hi jtv.  Thanks for looking at that.  Lemme look, one sec.
[11:32] <cjwatson> ... maybe somebody else can land https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 for me?  I've made the distribution -> distroseries substitution as suggested by StevenK
[11:33] <gary_poster> jtv, I'm surprised that registeredUtilities is giving you nothing.  It looks like it does all the right things.  Could it be that you called it before zcml was processed?
[11:34] <jtv> gary_poster: unlikely—I'm calling it from a LaunchpadScript and one of the reasons was that zcml would be processed for me.  :)
[11:34] <gary_poster> jtv, could you verify by trying to look up a utility?
[11:34] <jtv> You mean using zope.component.getUtility?
[11:35] <jtv> Or using getGlobalSiteManager().getUtility or something?
[11:35] <gary_poster> jtv, both, either.
[11:37] <jtv> gary_poster: Hmm... componentlookuperror
[11:37] <gary_poster> jtv, that's what I would expect.  registeredUtilities really does look in some integral data structures. :-)
[11:38] <jtv> Arrh… I think I needed to script.run() instead of script.main()
[11:38] <jtv> Now it takes the requisite 20 minutes to start up.
[11:38] <gary_poster> :-/
[11:38] <gary_poster> cjwatson, that needs ec2 land I assume?
[11:38] <jtv> gary_poster: it fails later now, so that gets us past the first hurdle.  Thanks.
[11:39] <gary_poster> cool jtv, np
[11:39] <cjwatson> gary_poster: no, AFAICS it's just direct-commit
[11:39] <gary_poster> cjwatson, you mean, you can verify that all tests pass, and if buildbot fails you will be shocked, awed, and at least mildly embarrassed? :-)
[11:39] <cjwatson> lp:meta-lp-deps is owned by ~launchpad-committers and the commits are all just direct
[11:40] <gary_poster> of duh
[11:40] <cjwatson> meta-lp-deps has no tests ...
[11:40] <gary_poster> s/of/oh/
[11:40]  * gary_poster was not looking closely enough
[11:40]  * gary_poster goes to look at mp
[11:40] <cjwatson> I wasn't suggesting direct commit to launchpad :-)
[11:40]  * cjwatson is nowhere near that brave
[11:41] <gary_poster> heh :-)
[11:42] <gary_poster> cjwatson, ok, I'm giving it a whirl
[11:43] <cjwatson> great, thanks
[11:46] <gary_poster> cjwatson, please approve/adjust commit message: "[r=StevenK] fix target detection so that it works for both recipe builds and the CAT repository"
[11:46] <jtv> gary_poster: next of my hurdles.  The docs I saw "on the internet somewhere" said UtilityRegistration had members "provides" and "provided."  But no.
[11:47] <jtv> Maybe it's just a typo.
[11:48] <gary_poster> jtv, according to code, it has "self.registry, self.provided, self.name, self.component, self.info, self.factory"
[11:48] <cjwatson> gary_poster: ack, that's fine
[11:48] <gary_poster> cool cjwatson
[11:48] <jtv> gary_poster: yup, the provides was a typo.  I'm getting further now.
[11:49] <jtv> Funny.  Some of them have empty names.
[11:50] <gary_poster> cjwatson, done
[11:50] <gary_poster> jtv, sure, those are utilities you just look up with an interface
[11:50] <gary_poster> ILaunchBag, for instance
[11:50] <cjwatson> gary_poster: thanks!
[11:50] <jtv> Well lots of them give an interface name as the utility registration's name.
[11:50] <gary_poster> welcome
[11:52] <gary_poster> jtv, yes, that's something you will probably want to filter out.  IIRC, something or other registers all interfaces that it encounters as a utility.  So that it can do something else.  Later.
[11:52] <gary_poster> s/all interfaces/each interface/
[11:53] <jtv> gary_poster: it looks as if the ones _with_ names are the ones I'm supposed to skip.
[11:54] <gary_poster> jtv, that's what I would expect to be the common case, yes.  I'd instead say that if the utility provides IInterface, skip it.  That might be equivalent, but it is more careful.
[11:55] <jtv> Oh, OK
[12:01] <jtv> gary_poster: checked 347 interfaces, 238 failed.  :/
[12:01] <gary_poster> jtv, ow.  :-(
[12:01] <jtv> Probably a bug in my code.
[12:01]  * gary_poster hopes so, practically speaking :-)
[12:02] <gary_poster> jtv, are you using the zope.interface-provided interface checker, or rolling your own
[12:02] <gary_poster> ?
[12:03] <jtv> gary_poster: I was lazy and grabbed our own test matchers' Provides.
[12:05] <gary_poster> jtv, ah ok.  I think I looked at that once but I forgot how that works.  I meant zope.interface.verify.verifyObject FWIW
[12:06] <jtv> Well, I'll just give it a whirl.
[12:07] <gary_poster> cjwatson, we've got a problem.  Don't know if it is related... https://launchpadlibrarian.net/77594282/buildlog.txt.gz
[12:08] <cjwatson> I just asked #is about that
[12:08] <cjwatson> it's not related to my change
[12:08] <gary_poster> ok thanks cjwatson
[12:08] <cjwatson> I suspect badness due to puppet deployment but that's just a guess ...
[12:09] <gary_poster> heh, puppet is getting a lot of bad press lately
[12:09] <cjwatson> I may be blaming it unfairly, it's just that I think I heard of a previous instance of this problem and I only started hearing about it this wewek
[12:09] <cjwatson> *week
[12:10] <jtv> gary_poster: getting better — 109 failures (out of 347)
[12:11] <jtv> I just wonder why so many raise DoesNotImplement.
[12:11] <gary_poster> jtv, I suggest you change the checker to lambda *args: True
[12:12] <jtv> What checker?
[12:12] <gary_poster> jtv, sorry, trying to make a joke.  verify your interface with an "everything passes".  Hee.  Hee.
[12:13] <jtv> Ah.  You are… American, right?  Might I suggest you check with a European first?  It may prevent misunderstandings.  :-P
[12:13] <gary_poster> jtv :-P
[12:13] <jtv> But the lambda idea is good too.  :)
[12:15] <jtv> gary_poster: I wonder if I need to do this differently for classProvides than for implements.
[12:15] <gary_poster> jtv, ah, quite possibly.
[12:16] <gary_poster> jtv, so you mean that we are registering some classes as utilities, yes?
[12:16] <jtv> And I'm pretty sure the component isn't supposed to be "security proxied __builtin__.type instance"
[12:16] <jtv> Yes, we use both in LP.
[12:16] <gary_poster> jtv, as a separate issue, you may need to rip off security procxies, if you have not already.
[12:17] <jtv> With disturbing pleasure.
[12:17] <gary_poster> lol
[12:18] <gary_poster> jtv, FWIW, I suspect you are right that neither verifyObject nor verifyClass will do what you want for class utilities.  You may need to make your own verification for that.
[12:19] <jtv> Seriously?
[12:19] <jtv> But I've verified them in the past as verifyObject(II, getUtility(II))
[12:22] <gary_poster> jtv, ah, then...I thought you implied it was not working? ("I wonder if I need to do this differently for classProvides than for implements.")  If it is working, then, uh, I suggest you keep using it.  I was just not confident that verifyObject would do what you need without digging into it.
[12:23] <jml> why would you remove security proxies?
[12:24] <jtv> gary_poster: I'm not sure if it's working or not.  I'm getting a bunch of DoesNotImplement exceptions (besides some other exceptions that I did expect)
[12:30] <gary_poster> jml, primarily because security proxies will only let someone with the proper authority look at the value.  I suppose another approach would be to log in as a Launchpad admin (if I remember correctly that they have all permissions in all contexts).  Secondarily because the verification machinery might not expect them generally, and it's a good first pass to ignore them.
[12:32] <gary_poster> jtv, ok.  In your shoes, I'd simply investigate some seemingly representative reports and see if the complaints seem to have merit.
[12:32] <jml> gary_poster: oh, of course. I was thinking only of the security proxies other duty as JIT interface validators (e.g. raising ForbiddenAttribute because you spelled 'displayname' incorrectly)
[12:33] <jtv> gary_poster: I guess I could try to verify the result of getUtility instead of the component.
[12:33] <jml> maybe some of those utilities don't have correct implements() lines.
[12:33] <jtv> Since 93 of the 124 failures I have now are DoesNotImplement, I think I'm verifying the wrong object.
[12:34] <jtv> jml: wouldn't that be noticed immediately?
[12:40] <jtv> gary_poster, jml: checked out a first case of DoesNotImplement… the implements() is in a base class.
[12:40] <jtv> I suppose that would also apply for all these vocabularies that are giving me the same error.
[12:42] <jtv> If I check getUtility(interface) instead of utility_registration.component, I only get 11 instances of DoesNotImplement.
[12:42] <gary_poster> huh
[12:43] <gary_poster> I have not worked with utility registrations enough to know how unexpected that might be
[12:43] <gary_poster> I'd say stick with whatever spelling seems to reflect reality and move on, myself.  That might be stating the obvious.
[12:53] <Ursinha> is is just me or launchpad has performance issues today?
[12:53] <Ursinha> scripts are timing out
[13:05] <gary_poster> Ursinha, I haven't experienced any problems myself, but graphs seem to suggest that we had increased db load and an increased number of errors starting about six hours ago.  I have no idea what that might be: we have not had a rollout since the 16th.
[13:06]  * gary_poster tries to find page performance report, and tries to remember other tools for this.
[13:06] <Ursinha> gary_poster: I'm not able to generate ubuntu reports for a while; in general it takes about 6 minutes and now it's timing out
[13:07] <StevenK> cjwatson: Sorry about that, I was picking up my wife and having dinner. Did you find someone?
[13:07] <gary_poster> StevenK, hey, I did it for him
[13:07] <StevenK> gary_poster: Excellent, thanks.
[13:08] <gary_poster> StevenK, do you happen to have an idea of something that might have changed six hours ago to make our db load and errors increase?  It is not an increased number of requests, according to the graphs.
[13:09] <StevenK> And the recipe fails due to chroot problem? Awesomeness
[13:09] <gary_poster> (number of requests: https://lpstats.canonical.com/graphs/AppServerRequestLpnet/ ; 5xx s : https://lpstats.canonical.com/graphs/AppServer5XXsLpnet/ ; db load : https://lpstats.canonical.com/graphs/DBCpuLoadAppServers/)
[13:09] <gary_poster> heh, yeah StevenK. :-/
[13:09] <StevenK> gary_poster: That isn't your fault, though.
[13:10] <gary_poster> StevenK, yeah, cjwatson thought it might be puppet
[13:10] <StevenK> gary_poster: The only thing I can think of that I did six hours ago was finish work. :-)
[13:10] <cjwatson> lamont is looking at it
[13:10] <gary_poster> StevenK, that's it! ;-)
[13:10] <StevenK> Aw, man. Now I have to work the weekend. :-P
[13:10] <gary_poster> :-)
[13:12] <StevenK> gary_poster: Just thinking about it, check with the LOSAs, mizuho and cocobanana were brought under the iron fist of puppet around that time
[13:12] <gary_poster> ok thanks StevenK, I'll ask them (do we even have any?)
[13:12] <gary_poster> I'll find out :-)
[13:18] <Daviey> Ursinha: yeah, i am seeing timeouts aswell.
[13:19] <Ursinha> Daviey: all of our scripts are failing, desktop team as well
[13:23] <jtv> gary_poster: any feedback on lp:~jtv/launchpad/audit-utilities would be most welcome.  Run utilities/audit-utilities.py to see what I get so far.
[13:23] <jtv> Not now though; I'll be off!
[13:24] <gary_poster> jtv, cool.  working on emergency; please ask Monday and will be happy to
[13:24] <gary_poster> Have a great weekend
[13:24] <jtv> same to you!
[13:30] <stub> Cool. fiera is doing recursive queries now. Didn't realize anyone was using them yet.
[13:31] <bigjools> Oo
[13:31] <deryck> henninge, ping for standup
[13:31] <henninge> oh, yeah
[13:31]  * henninge boots phone, looks for headset
[13:37] <jelmer> Hmm, qastaging is giving me a "Internal Server Error" for loggerhead - is there an easy way to see the actual error?
[14:25] <henninge> abentley: Hi!
[14:25] <abentley> henninge: hi!
[14:26] <henninge> abentley: can we mumble about iorecorder?
[14:26] <abentley> henninge: 1 sec
[14:43] <cjwatson> Does anyone know how to make https://code.launchpad.net/~launchpad/+archive/ppa/+recipebuild/73739 (from https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand) try again?
[14:43] <cjwatson> lamont tells me that the buildd problem is fixed now
[14:43] <cjwatson> maybe people in the ~launchpad team get more buttons there than I dod
[14:43] <cjwatson> *do
[14:44] <bigjools> looks like the build page has a bug
[14:44] <bigjools> says it's finished but offers me a link to cancel it still
[14:44] <cjwatson> me too
[14:44] <cjwatson> maybe if we cancel it will try again later?
[14:44] <bigjools> mebbe
[14:45] <bigjools> don't know much about this stuff
[14:45] <cjwatson> I can't rescore it either
[14:45] <cjwatson> who does?
[14:45] <bigjools> I can :)
[14:45] <bigjools> abentley does
[14:45] <cjwatson> I get the link, but it says "Cannot rescore this build because it is not queued."
[14:45] <bigjools> huh
[14:45] <bigjools> yes the page is buggy
[14:46] <bigjools> I bet it thinks "chroot problem" is not a real error
[14:47] <abentley> cjwatson: you request a build from https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand
[14:49] <cjwatson> abentley: I'm not sure I have the right team access to request a build that goes into ~launchpad/+archive/ppa
[14:50] <cjwatson> (if I did, that would probably be a bug)
[14:50] <cjwatson> abentley: can you?
[14:51] <abentley> cjwatson: I see the "request build(s)" link on the page, so I assume I do.
[14:51] <abentley> cjwatson: Do you not see it?
[14:53] <cjwatson> I do, but surely I only have access to request builds into PPAs owned by myself or teams I'm a member of; I am not a member of launchpad
[14:53] <bigjools> cjwatson: I'll request a build, is it just lucid you need?
[14:53] <cjwatson> yeah, the others look done
[14:53] <bigjools> done
[14:54] <cjwatson> thanks
[14:57] <allenap> adeuring, bac: Have you got time for a short-ish review? https://code.launchpad.net/~allenap/launchpad/librarian-log-bug-828151/+merge/72097
[14:57] <bac> allenap: i do
[14:57] <allenap> bac: Thanks :)
[14:57] <bac> np
[14:59] <deryck> bigjools, there's an lp question about sudo error and busted builds I'm working through....
[15:00] <bigjools> deryck: should be fixed
[15:00] <deryck> bigjools, ok, thanks.
[15:00] <bigjools> :)
[15:00] <deryck> easy peasy :)
[15:29] <bac> allenap: done
[15:29] <allenap> Thanks bac.
[15:30] <deryck> sinzui, ping.
[15:30] <sinzui> hi deryck
[15:31] <deryck> sinzui, hi there.  Do you think you could spare a minute to help kate in:  https://answers.launchpad.net/launchpad/+question/168164 ?
[15:31] <deryck> sinzui, you could probably directly answer her as quickly as walk me through how to answer her :)
[15:32] <sinzui> This might be a permission issue. Lots of attr are only setable by LOSAs because Ubuntu one made 100s of members project owners
[15:32] <sinzui> investigates
[15:33] <deryck> sinzui, thanks!
[15:34] <sinzui> s/Ubuntu one/Ubuntu once/
[15:39] <deryck> sinzui, can I assign the question to you and note that you're looking into it?
[15:39] <deryck> sinzui, ah, never mind.  I see you did assign it.  Sorry.
[15:40] <deryck> stupid page reloads.
[15:40] <sinzui> deryck, datereleased is not directly setable. it is implicitly set by the Web UI when the series status is set to current.
[15:41] <sinzui> deryck, since the releases are being done by API, there is no way that the date is set. the field is not exposed in the UI either
[15:41] <deryck> ah, ok.
[15:42] <sinzui> deryck, I think we need to choose a) push the rule into the model so that the status attr also updates the datereleased attr or b) expose the datereleased attr over the api to let owners change it anytime they like.,
[15:44] <deryck> sinzui, I like b personally.  Makes sense to me an owner might want to set this themselves, if doing everything else over the API.
[15:44] <sinzui> I see datereleased is exported over the API. I think someone can set it
[15:45] <sinzui> deryck, the rule is in place to ensure the field is not set in an impossible status. field validator is needed
[15:46] <jcsackett> sinzui: mumble?
[15:46] <deryck> sinzui, can't the validator kick in, even if set over the API?  But it sounds like this is possible anyway, if it's exposed.
[15:47] <sinzui> ah, the field is editable over the api by anyone with LP moderate, which hopefully includes the series RM
[15:48] <jcsackett> oh, sorry, i see you're in the middle of a conversation. :-P
[15:48] <sinzui> deryck, the validator will kickin if we define a new field or update the existing date field to use constraint=???
[15:52] <cjwatson> StevenK: do you think you could run dpkg-xz-support through again, once you see this?  I'd like to establish whether it has anything to do with the launchpad-dependencies breakage (which seems not unlikely) before doing further manual investigation
[15:52] <deryck> sinzui, ah, I was thinking of the old bugs way of having a mutator in the model that does the validation in Python. This doesn't work if there are db constraints doing the validation now.
[15:56] <sinzui> deryck, The answer to the question is the jeremy is not an admin or registry expert. I think we want to change the security checker so that the series.driver (RM) or all ubuntu drivers can change (version name status nominatedarchindep changeslist datereleased)
[15:57] <sinzui> I will update the question and link it to the really old bug we have been trying to fix by changing the Ubuntu team structure
[16:06] <deryck> sinzui, ok, cool.  Thanks much!
[16:51] <sinzui> jcsackett, I sorted out the distro stuff. I can talk now
[16:51] <jcsackett> sinzui: i just grabbed lunch. ping you when i'm done?
[16:52] <sinzui> yes
[17:00] <jcsackett> sinzui: i'm getting on to mumble now.
[17:06] <henninge> help!
[17:06] <henninge> I am totally stuck in trying to get a js test to run.
[17:06] <henninge> Something to do with loading, I think
[17:08] <henninge> hm, just solved one thing but there was more ...
[17:11] <henninge> Which js file do I need to load to have the "LP" object defined?
[17:13] <jml> henninge: lib/lp/app/templates/base-layout-macros.pt?
[17:13] <henninge> oh
[17:13]  * henninge looks
[17:13] <jml> it's just a grep-informed guess.
[17:15] <henninge> I only searched js files.
[17:15] <henninge> jml: yeah, it's there
[17:15] <henninge> but that's no use for a test, so I will have to create a dummy I guess.
[17:17] <jml> henninge: grep also points me at lib/lp/code/javascript/tests/test_branchrevisionexpander.html:
[17:17] <jml> henninge: which, at a guess, declares a dummy.
[17:18] <henninge> yes it does
[17:18] <henninge> jml: thanks
[17:18] <jml> henninge: don't thank me, thank 'bzr grep "var LP"'
[17:19] <henninge> ;-)
[17:36] <deryck> henninge, do you want LPS object or the js web service client?
[17:37] <henninge> deryck: LP.cache
[17:37] <henninge> but I got it figured out now.
[17:37] <deryck> henninge, ok.
[18:01] <flacoste> sinzui: you might interested in bug 829678
[18:02] <_mup_> Bug #829678: Person picker widget to add a member says it fails but really didn't <person-picker> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/829678 >
[18:03] <sinzui> flacoste, no I am not. It is a dupe of the bug that jcsackett is working on
[18:03] <flacoste> sinzui: a cool, then!
[18:04] <sinzui> I will update the master bug because I reported nothing happen because the spinner failed.
[18:13] <benji> jam: is there a particular person I should ask to review a small bzr MP?  (https://code.launchpad.net/~benji/bzr/bug-702914/+merge/72239)
[18:15] <benji> darn, I bet jam is quite AFK at the moment
[18:22] <jelmer> benji___: hi
[18:22] <benji> hi jelmer
[18:23] <jelmer> benji___: it's really nice to see tests for the lazy import threading issue
[18:23] <jelmer> benji: have you seen bug 396819
[18:23] <jelmer> ?
[18:23] <_mup_> Bug #396819: AttributeError: _factory - lazy imports are not threadsafe <lazy-imports> <oops> <Bazaar:Confirmed> <loggerhead:Triaged> < https://launchpad.net/bugs/396819 >
[18:25] <benji> jelmer: nope, I hadn't seen that; it looks like a dupe of the other (or rather, the other is a dupe of 396819)
[18:25] <jelmer> benji: yeah, indeed
[18:28] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/upgrade-not-branch-error/+merge/72242 ?
[18:28] <bac> abentley: sure
[18:28] <abentley> bac: thanks.
[18:31] <benji> jelmer: do you know if the bzr guys look at their review queue regularly (i.e., will they find my MP lying there and pick it up) or should I email one or more of them?
[18:33] <abentley> benji: they have one guy assigned to the review queue, called the "patch pilot", every week.
[18:33] <bac> looks good abentley
[18:33] <benji> abentley: great, thanks
[18:33] <abentley> benji: from their topic, looks like it's Riddell this week;.
[18:33] <abentley> bac: thanks.
[18:34] <benji> abentley: cool, I'll anticipate hearing from him then
[18:35] <jelmer> benji: I was actually just doing a review :)
[18:35] <benji> jelmer: yay!
[18:36] <jelmer> benji: I'd like to get some input from jam too though, as he's probably most familiar with lazy_import and all its corner cases.
[18:37] <benji> makes sense
[19:04] <jelmer> benji: do you know if there's any way to find out why loggerhead on qastaging is failing? It's just giving me a "Internal Server Error" without referencing an OOPS or anything like that.
[19:05] <benji> jelmer: not off the top of my head... but I'll look at it in a minute and see if I can think of anything
[19:08] <jelmer> benji, thanks
[19:23] <nigelb> what's the correct alternative to EDGE_SERVICE_ROOT these days?
[19:24] <abentley> nigelb: production.
[19:25] <abentley> nigelb: i.e. LPNET_SERVICE_ROOT
[19:25] <nigelb> aha
[19:25] <nigelb> abentley: thanks!
[19:26] <abentley> nigelb: no problem.
[20:04] <benji> jelmer: it looks like it's having an error trying to report an error that it's having: https://pastebin.canonical.com/51493/
[20:20] <henninge> abentley: maybe you'd enjoy reviewing this? https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting/+merge/72255
[20:20] <henninge> abentley: but I can also ask the OCR
[20:21] <abentley> henninge: I'm happy to look at it.
[20:21] <henninge> abentley: thanks
[20:21] <nigelb> flacoste: aww, I wish I could see those graphs
[20:26] <abentley> henninge: in some browsers (IE), the last element in a list must not have a comma following it.  Please fix that before landing.
[20:31] <abentley> henninge: It also looks like you've made changes that will break the existing use of IORecorder, i.e. renaming success -> response.
[20:32] <henninge> abentley: I added "respond" and made "success" use that.
[20:33] <henninge> but  I just found something else, so expect another revision.
[20:33] <henninge> abentley: I also ran test_lp_client with that new iorecorder.
[20:34] <abentley> henninge: okay, cool.  I didn't see the new success.
[20:34] <flacoste> nigelb: i can't give you access, but I can copy them in a public location
[20:35] <nigelb> flacoste: that would work, thanks!
[20:36] <jelmer> benji: sorry, was away for a bit for dinner
[20:36] <jelmer> benji: that error looks odd
[20:36] <jelmer> benji, out of curiosity, where did you look to find that log?
[20:37] <benji> jelmer: note that I'm not sure that that error is the result of requests, but it's the only error in the logs
[20:37] <benji> jelmer: from /srv/launchpad.net-logs/qastaging/asuka/launchpad.log on devpad.canonical.com
[20:42] <jelmer> benji: ah, thanks
[20:42] <henninge> abentley: screenshots in the MP! ;-)
[20:43] <abentley> henninge: cool.
[20:45] <henninge> abentley: I also pushed a new revision
[20:46] <abentley> henninge: r=me
[20:46] <henninge> abentley: thanks! ;-)
[20:47] <nigelb> I forget, how is it that I run only one test?
[20:55] <flacoste> nigelb: http://people.canonical.com/~flacoste/LPProjectCriticalClosed-2011-04-01_2011-0820.png
[20:55] <flacoste> and http://people.canonical.com/~flacoste/LPProjectCriticalFiled-2011-04-01_2011-0820.png
[20:55] <nigelb> flacoste: yay, thanks!
[21:08] <deryck> Have a nice weekend, everyone.
[21:20] <bac> sinzui_: you still around?
[21:20] <sinzui_> I am
[21:20] <sinzui> irc was lying
[21:20] <bac> sinzui_: mvo is reporting he cannot see private bugs for a source package he is the maintainer
[21:21] <bac> has anything changed around private bug visibility?
[21:21] <sinzui> No
[21:21] <sinzui> You still need to be subscribed
[21:21] <bac> he's also indirectly in the team that is the bug supervisor for the distro
[21:22] <sinzui> but is the supervisor subscribed to those bugs?
[21:22] <sinzui> marking a bug private does not subscribe the supervisor, though I hope to fix the 6 year old bug in 4 weeks
[21:23]  * bac looks at userCanView
[21:24] <sinzui> bac: which distro? Ubuntu?
[21:24] <bac> yes
[21:24] <bac> update-manager package
[21:24] <bac> mvo
[21:25] <bac> sinzui: i thought the bug supervisor was subscribed to bugs when they are made private
[21:26] <nigelb> bac: I just tested on qastaging. Only security supervisor is sub'd for private bugs.
[21:27] <sinzui> bac: Consider the changes made by structural subscriptions. User can be very specific about what they subscribe to and about the team that is subscribed. When a bug is made private, the structural subscribers are converted to bug subscribers. In the past, the bug supervisor could not control which email he got...he was subscribed to every bug, so he was always in the set of people subscribed. Now that the team can filter
[21:27] <sinzui>  the notifications, the team is implicitly opting out of private bug subscriptions
[21:28] <bac> oi
[21:28] <sinzui> There is only one code point where a bug supervisor is explicitly subscribed to a bug, and it was written by statik 4 years ago. When a bug is created for a project with private bugs, the supervisor is subscribed
[21:29] <bac> ah, right, that's why a project must have a bug supervisor before 'private by default' is enabled. that bit is what was confusing me.
[21:36] <sinzui> bac, Since I can see mvo's +participation page, I assume his membership in ~ubuntu-bugs is correct. Can other members of that team see the bugs? Are then only subscribed via that team
[21:36] <sinzui> bac: there is a small chance that something else private on that page could cause a 403 oops for him as we have seen on branch pages
[22:21] <nigelb> anyone around?
[22:28] <nigelb> gah, monday then.


[00:44] <gunndawg> Question before I attempt this. Would installing Synaptic packager manager interfer with Muon?
[00:51] <darthanubis> no
[00:56] <gunndawg> is synaptic the prefered package manager? I'm just not real thrilled with Muon
[01:02] <genii> gunndawg: Muon is what Kubuntu currently ships with, but you can install any package manager you want. I generally just use the command-line
[01:03] <gunndawg> genii: fair enough. Thanks.
[01:03] <genii> np
[01:05] <gunndawg> I went ahead and installed it. Kind of interesting that when I launch synaptic thru the Konsole it opens and uses my current theme, but if I go thru the K Menu and click on the Synaptic icon it opens synaptic with its default white/grayish theme
[01:05] <genii> Sounds like a bug
[01:06] <gunndawg> not a big deal
[01:22] <darthanubis> gunndawg: it's not  abug
[01:23] <gunndawg> it's not? Whats the reason for it? out of curiosity
[01:24] <darthanubis> http://pasteboard.co/2uXCpLHF.png
[01:24] <gunndawg> correct thats what it looks like when I open thru the K-Menu
[01:25] <gunndawg> but if I open thru the TErminal then it fits my theme (dark blue, etc)
[01:25] <gunndawg> all that white that you see is dark blue, the text is teal, etc
[01:25] <darthanubis> When you call synaptic from the menu, it call root. The proper link is not set in the /root dir to allow for gui consistency
[01:25] <gunndawg> ah makes sense
[01:25] <darthanubis> I know, I ran into the same issue
[01:25] <gunndawg> Thanks for the clarification
[01:25] <darthanubis> np
[01:27] <gunndawg> dar
[01:27] <gunndawg> darthanubis: how did you get the Installed, Installed (manual), and Not Installed links on the left
[01:28] <darthanubis> I'm looking for it now
[01:28] <gunndawg> mine just shows categories
[01:28] <gunndawg> games, Development, databases, etc
[01:28] <darthanubis> it has nothing to do with the menu
[01:28] <gunndawg> Would be nice to be able to access that "Installed" section though
[01:28] <darthanubis> call synaptic from the menu and then take a screenshot of it?
[01:30] <gunndawg> http://i.imgur.com/BleYa1j.png
[01:31] <darthanubis> ahh, that's your theming
[01:32] <darthanubis> the window border is using kde, but the them is using gtk
[01:32] <darthanubis> not even gtk3
[01:32] <gunndawg> the theme alone will alter the sub sections inside of a program?
[01:32] <darthanubis> no
[01:32] <darthanubis> well, all that blocky grey
[01:32] <darthanubis> yes
[01:32] <darthanubis> it's be smooth like mine
[01:32] <darthanubis> but not quite, I'm using plasma5
[01:33] <gunndawg> ah ok
[01:33] <gunndawg> I'm using default Kubuntu 14.04 with some ghost themes installed
[01:33] <gunndawg> its mostly all ghost themed
[01:33] <darthanubis> http://askubuntu.com/questions/179322/gtk3-theme-in-kde
[01:33] <darthanubis> sudo apt-get install gtk2-engines-oxygen gtk3-engines-oxygen kde-config-gtk
[01:34] <gunndawg> can I carry my current theme over to a gtk3 config?
[01:34] <darthanubis> Install those packages
[01:34] <gunndawg> I quite like the way it looks with the colors and windows, etc
[01:34] <gunndawg> ok
[01:34] <darthanubis> see if that makes the difference you are looking for
[01:36] <gunndawg> the first 2 says I already have up to date
[01:36] <gunndawg> it cant find kde-config-gtk
[01:36] <darthanubis> ok
[01:37] <gunndawg> so i already have gtk3 installed but you say I'm not using it?
[01:37] <gunndawg> I'm still rather new with this, so I wouldnt know one way from the other
[01:38] <darthanubis> I know, I'm looking for a more concise way to direct you
[01:38] <gunndawg> appreciate it
[01:38] <darthanubis> np
[01:38] <darthanubis> https://www.kubuntuforums.net/showthread.php?67826-GTK-themes-or-QT-themes&highlight=gtk3
[01:38] <darthanubis> chew on that will I look for something else
[01:40] <darthanubis> if you go into system settings >> Application Appearance >> Gtk
[01:40] <gunndawg> yeah
[01:40] <gunndawg> I'm using Oxygen-gtk
[01:40] <darthanubis> Note that most things would be using gtk3, but some still use gtk2, so there are two sections there.
[01:41] <gunndawg> ah ok
[01:41] <gunndawg> so I'm using both gtk2 and 3?
[01:41] <gunndawg> because oxygen-gtk is set in both gtk2 and 3 theme
[01:42] <darthanubis> what are your options there?
[01:42] <gunndawg> For GTK3 I have default, emacs, and Oxygen-gtk
[01:43] <gunndawg> for GTK2 its just default and oxygen-gtk
[01:43] <gunndawg> I'm sorry
[01:43] <gunndawg> for GTK2
[01:43] <darthanubis> ok
[01:43] <gunndawg> Raleigh and oxygen-gtk
[01:44] <gunndawg> Dogs are acting up. Need to step away a few mins. Mind PMing me related info so I can see when I get back in 10 - 15mins? I'd like to fix this. And thanks for the help
[01:44] <darthanubis> sure
[01:45] <gunndawg> much appreciated
[01:45] <darthanubis> http://askubuntu.com/questions/87037/gtk-in-kubuntu-apps-look-bad
[01:45] <darthanubis> p
[01:45] <darthanubis> np
[08:57] <lordievader> Good morning.
[09:12] <MoonUnit`> morning
[09:19] <lordievader> Hey MoonUnit`
[09:26] <MoonUnit`> nice, will have to boot into windows to flash a firmware file.
[11:22] <amari> Hi
[11:22] <amari> Is kde5 stable for daily use in Kubuntu 15.04?
[11:37] <MoonUnit`> that would depend on your hardware and use, some of the big problems have been ironed out but still some to go.
[11:37] <MoonUnit`> current bug list http://tinyurl.com/kh2pxbb
[11:38] <MoonUnit`> only real problem for me is not being able to logout, shutdown and reboot properly.
[11:38] <lordievader> I'd wait at least till it is released.
[11:38] <lordievader> MoonUnit`: Even after the updates of yesterday?
[11:39] <MoonUnit`> yup, when i logout the desktop goes black apart from programs on the desktop are mostly still on screen.
[11:40] <MoonUnit`> pidgin, thunderbird, firefox and conky
[11:40] <lordievader> Hmm, I thought that got fixed with yesterday's updates.
[11:40] <xen> yo
[11:42] <MoonUnit`> i'll have to try installing to a different drive and see if it works ok, maybe something i've done/installed is breaking something.
[11:44] <lordievader> o/
[11:48] <soydemadrid> hi can anyone please help. I added a customised xorg.conf file to try get a second display to work and ended up with just a black screen when kubuntu booted.  Does anyone know how I can reset my displays and re-autodetect them please?
[11:48] <lordievader> soydemadrid: What graphics card and driver are you rocking?
[11:49] <soydemadrid> lordievader: Nvidia but not sure what the card is
[11:49] <lordievader> soydemadrid: Do you have a shell?
[11:49] <soydemadrid> lordievader: yes got the shell and already did RM on the xorg file but it hasn't helped...
[11:50] <lordievader> soydemadrid: What is the output of 'lspci -k|grep -A2 VGA'?
[11:51] <soydemadrid> lordievader: that gives me Nvidia GF108 GeForce GT 630
[11:51] <soydemadrid> lordievader: (rev a1)
[11:52] <lordievader> That's all? No driver?
[11:53] <soydemadrid> lordievader: sorry yes driver just says nvidia
[11:53] <soydemadrid> lordievader: "Kernel driver in use: nvidia"
[11:53] <lordievader> Ah, good. What does /var/log/Xorg.0.log say?
[11:53] <lordievader> !paste
[11:57] <soydemadrid> lordievader: I'm not sure how to show you it as I'm talking to you on a laptop, but the other computer has no GUI anymore. I've opened it in Nano and there is 600 lines. The bottom few lines say "NVIDIA(GPU-0): Unable to read EDID for display device CRT-1
[11:57] <lordievader> soydemadrid: Does it have an active internet connection?
[11:57] <soydemadrid> lordievader: yes
[11:58] <lordievader> soydemadrid: sudo apt-get update && sudo apt-get install pastebinit && pastebinit /var/log/Xorg.0.log
[11:58] <soydemadrid> lordievader: thanks! doing it now
[12:00] <soydemadrid> lordievader: http://paste.ubuntu.com/10808164
[12:02] <MoonUnit`> kde also saves it's monitor setup to .local/share/kscreen/ you may need to clean it out too if you still have problems.
[12:04] <lordievader> soydemadrid: You have two displays attached?
[12:04] <soydemadrid> MoonUnit`: ok I've rm-ed the Kscreen directory too but it still gives a black screen on login...
[12:04] <soydemadrid> lordievader: yes two displays
[12:04] <lordievader> soydemadrid: Does it work when you disconnect crt-0?
[12:05] <MoonUnit`> maybe clean out the .cache folder?
[12:05] <soydemadrid> lordievader: they were working great. But the CRT-1 display was wrong resolution so I added a few lines to xorg and then when rebooted had a black screen. so i deleted xorg.conf but still stuck with black screen
[12:06] <soydemadrid> lordievader: ok disconnected the second screen and rebooting to see if it works
[12:07] <lordievader> Yes, one of the two doesn't output EDID.
[12:08] <soydemadrid> lordievader: just rebooted and i have a mouse pointer but black screen and blank empty task/window panel at bottom. can't click or do anything...
[12:08] <soydemadrid> lordievader: that's with just one screen plugged in...
[12:08] <lordievader> Is lightdm setup to do autologin?
[12:09] <soydemadrid> lordievader: yes. but if I restartx and the screen has locked, it lets me login again and the progress bar moves up and I'm just back at a blank screen again.
[12:10] <soydemadrid> lordievader: if I reinstall Kubuntu it will be fine again. but one monitor then has the wrong resolution...
[12:10] <lordievader> Could you disable the autologin?
[12:11] <soydemadrid> lordievader: it doesn't seem to be down to that. As if I reinstall it works ok, I just reinstalled this morning. it is when I try change the display resolution of the second screen it then breaks both of them
[12:11] <soydemadrid> lordievader: is there a way to just go back to as if you've first installed kubuntu and have it redetect the displays?
[12:11] <lordievader> What I want to know if lightdm is shown correctly. From there we can pin point the problem better.
[12:12] <soydemadrid> lordievader: yes that will show fine. it is once I get in to the desktop that is when I get a black background instead of wallpaper. I get the panel at the bottom but nothing on it and a mouse pointer
[12:13] <lordievader> Right, make a new user and see if that one has the same problem.
[12:13] <soydemadrid> i can also press alt and f2 and the top panel program runner appears but if i type anything in there nothing comes up and i can't launch anything
[12:13] <soydemadrid> lordievader: how do i make a new user though now I've logged in?
[12:14] <lordievader> soydemadrid: Run useradd or adduser in your shell. (I allways forget which one was the frontend)
[12:14] <soydemadrid> lordievader: ok what I'll do is I'll just reinstall kubuntu again
[12:14] <MoonUnit`> have you tried renaming .cache and restarting, solved most of my black screen problems.
[12:15] <soydemadrid> lordievader: then maybe you can help me get the right resolution on second screen once everything is back how it was?
[12:15] <lordievader> soydemadrid: Hmpf, that is one way to go about it.
[12:16] <soydemadrid> lordievader: well i have a clean install anyway just about, it was only when i tried to get my second monitor to the right res that the problem occured.
[12:33] <soydemadrid> lordievader: ok i've reinstalled and using nvidia 346.59 recommended latest driver - all works well but my second display is not 2048x1152 like it should be. both monitors are same type and should use that display but the second one is just 1024x968 or something like that...
[12:35] <lordievader> soydemadrid: Allright, what does xrandr say?
[12:37] <soydemadrid> lordievader: xrandr says the first one is 2048x1152 but the second one is 1024x768
[12:39] <lordievader> soydemadrid: I'd like to see the full output.
[12:40] <soydemadrid> lordievader: http://paste.ubuntu.com/10808405
[12:42] <lordievader> soydemadrid: http://www.linuxjournal.com/content/guerrilla-tactics-force-screen-mode-ubuntu
[13:56] <jonah> hi is anyone any good with Display settings or xorg.conf? I'm having really bad problems. I have two Samsung Syncmaster 2343nw monitors. one is connected via DVI and the other VGA as I have two ports on my graphics card. But the VGA connected one isn't in 2048x1152 resolution as it should be... I've tried adding it in to xorg.conf but it seems to break things. Can anyone help at all?
[13:58] <BluesKaj> Hey folks
[13:58] <lordievader> jonah: Are you the soydemadrid of earlier?
[13:58] <jonah> lordievader: Hi yes that is right! But I'm now on the main computer, not the laptop
[13:59] <jonah> lordievader: I tried your Bruteforce link but couldn't get it working.
[13:59] <lordievader> jonah: Have you looked at the link I gave you?
[13:59] <jonah> lordievader: yeah, I just got an error message.
[13:59] <lordievader> jonah: Could you specify that in more detail>
[13:59] <jonah> lordievader: the weird thing is that I used to have to add  ModeLine "2048x1152_60.00_rb"<PHONE_NUMBER> 2096 2128 2208 1152 1155 1160 1185 +hsync -vsync
[13:59] <jonah> lordievader: to my xorg.conf to get the second screen to work
[14:00] <jonah> lordievader: but when i do that now in Kubuntu 15.04 I just get the black screen again...
[14:01] <jonah> lordievader: https://www.kubuntuforums.net/showthread.php?64421-Can-t-get-two-Samsung-SyncMaster-2343nw-monitors-to-display-2048x1152-dual-screen
[14:01] <jonah> lordievader: bottom of that post was last time I installed the previous Kubuntu. at the bottom I posted that I managed to fix it
[14:02] <jonah> lordievader: but adding that line in this time just breaks plasma and things go black again. plus I'm not sure if I'm adding it in the right place...
[14:02] <lordievader> jonah: The first step fails.
[14:02] <lordievader> jonah: What happens when you do that without sudo?
[14:03] <lordievader> Also, do the cvt yourself. I get different values here.
[14:04] <jonah> lordievader: hi sorry what do you mean do the CVT yourself? How do I do this?
[14:04] <lordievader> jonah: The very first step out of the link I gave you.
[14:04] <lordievader> http://www.linuxjournal.com/content/guerrilla-tactics-force-screen-mode-ubuntu
[14:05] <lordievader> jonah: http://www.linuxjournal.com/content/guerrilla-tactics-force-screen-mode-ubuntu
[14:06] <jonah> lordievader: the first step doesn't show my screen resolution though on the output?
[14:07] <lordievader> jonah: With the first step I ment "cvt 1280 1024 60" as show on the web site.
[14:12] <jonah> lordievader: Hi I've got the second monitor now into that resolution! it works. but how do I then keep it that way? My xorg file looks a lot different to his example due to being a twinview setup...
[14:18] <donniezazen> Kamoso freezes as soon as you hit video recording button.
[14:46] <xennex81> so is vivid vervet moved to "udev" for mtab?
[14:46] <xennex81> utab I mean
[14:47] <MoonUnit`> shame, made a video wallpaper but the cpu usage was too high, plasmashell 60%
[14:49] <xennex81> :)
[17:45] <victor__> hello!
[19:13] <darthanubis> gunndawg: you get your theme sorted?
[22:31] <gunndawg> 0/
[22:59] <gunndawg> darthanubis: 0/


[00:46] <FreeB3ar> hello
[05:35] <valorie> hi FreeB3ar
[05:35] <valorie> happy 2016
[07:40] <FreeB3ar> Hello valorie
[07:40] <valorie> how are you, FreeB3ar?
[07:40] <FreeB3ar> Cold,you?
[07:40]  * valorie is enjoying 2016 so far
[07:41] <valorie> we were at our cabin in the mountains for the new year, and it was COLD there
[07:41] <valorie> warmer here
[07:41] <valorie> are you in the Seattle area?
[07:41] <FreeB3ar> That sounds splendid.
[07:41]  * valorie lives about an hour south
[07:41] <FreeB3ar> Nah, I'm in Gray's Harbor County.
[07:42] <valorie> beautiful country down there
[07:42] <valorie> cold blowing in, eh?
[07:42] <FreeB3ar> My room has no heat aside from a candle and my computers which don't put out that much when it's cold.lol
[07:42] <valorie> yikes
[07:42] <valorie> time to compile something big!
[07:43]  * FreeB3ar giggles
[07:43] <valorie> my old laptop would get so warm compiling amarok
[07:43] <FreeB3ar> Perhaps I should. Hmm. But what?
[07:43] <valorie> something you want to test, or work on?
[07:43] <FreeB3ar> I used to adore amarok. Now I mainly use Clementine.
[07:44] <FreeB3ar> As if I have time..
[07:44] <valorie> I got started working in KDE by testing and then writing for Amarok
[07:44] <FreeB3ar> oh wow. :)
[07:44] <valorie> play on your strengths
[07:45] <valorie> mine were: being a beginning, and being a good writer
[07:45] <FreeB3ar> I never figured out KDE 4 so that's when I switched to XFCE.
[07:45] <valorie> so you run xubuntu?
[07:45]  * valorie is a kubuntero
[07:46] <FreeB3ar> With 15.10 I actually switched from that to regular Ubuntu and hated Unity still so I've only installed Cinnamon so far to check it out VS my LMDE netbook.
[07:47] <valorie> I don't like unity either, but I've been a KDE fan from linux day one
[07:47] <valorie> which was Mandrake, back in the day
[07:48] <FreeB3ar> Ah,I remember Mandrake.
[07:49] <FreeB3ar> I think I used KDE with Sabayon nearly a decade ago. Wow, it's been that long,eh?
[07:49] <valorie> I'm loving plasma 5
[07:50] <FreeB3ar> 5
[07:50] <FreeB3ar> ?!
[07:50] <FreeB3ar> muhstaguts...when did that come out? I'm so out of the loop.lol
[07:51] <valorie> I've been using it as a beta for almost a year before Kubuntu released it by default
[07:51] <FreeB3ar> hm.Well then..
[07:51] <valorie> first I used the neon repo which installed in /opt
[07:52] <valorie> we're about to release 5.5
[07:53] <valorie> a bit late, but we'll get there
[07:53] <FreeB3ar> Maybe I should check it out again.
[07:53] <valorie> costs nothing to burn a liveUSB
[07:53] <FreeB3ar> Any idea if KDE runs smooth-ish-ly on Win7/8.1/10?
[07:53] <FreeB3ar> If you've got one that is. :P
[07:54] <valorie> sure
[07:54] <valorie> Qt 5 is lighter on the system
[07:55] <valorie> well, you can burn a DVD then
[07:55] <valorie> I think it's always good to "try before you buy"
[07:55] <valorie> so to speak
[07:55] <valorie> make sure that your equipment works, etc.
[07:56] <FreeB3ar> Good! My old beaver beast box only has 4GB.Eventually I may max it out at 32GB if I've got the money to spare.
[07:56] <FreeB3ar> Hey,My equipment is working well thank you.
[07:56] <valorie> I mean in a Kubuntu session
[07:56] <valorie> nothing against your equipment
[07:57]  * FreeB3ar giggles.
[07:59] <FreeB3ar> So tell me about these meetups.
[07:59] <valorie> we usually meet in Seattle, unfortunately
[07:59] <valorie> long drive for ya
[08:01] <FreeB3ar> I hear it's about five hours...and I drive an Explorer so lol@gas
[08:01] <valorie> sometimes we meet in a makerspace, and have presentations
[08:01] <valorie> sometimes just at a pub and eat and drink beer
[08:01] <FreeB3ar> hey that's pretty cool. I used to go to the nyc2600 meetings but it was never anything fancy.
[08:02] <valorie> coolest thing about it is that somebody else started it
[08:02] <valorie> :-)
[08:02] <FreeB3ar> hahah
[08:02] <valorie> oh, were you asking about the KDE meetups?
[08:02] <valorie> or ubuntu
[08:02] <FreeB3ar> I didn't even know about the KDE meetups.
[08:03] <valorie> because the local KDE folks are active
[08:03] <FreeB3ar> I'm fresh in WA.  My buddies have gone.I've only been to a few HOPEs.
[08:04] <valorie> http://lfnw.org
[08:05] <valorie> every april in Bellingham
[08:05] <valorie> we (KDE) had a table at HOPE when it was in Seattle
[08:05] <valorie> a year or so ago
[08:05] <valorie> that was fun
[08:05] <FreeB3ar> That's a false HOPE if it's not at Hotel Penn.
[08:06] <valorie> oops, I meant LISA
[08:06] <valorie> I've never been to HOPE
[08:06] <FreeB3ar> It's awesome.
[08:08] <valorie> SCALE is coming up in a few weeks, but somehow I can't make myself go down for it
[08:08] <valorie> family stuff happening here
[08:09] <FreeB3ar> awh
[08:09] <FreeB3ar> There are so many events I've never heard of.
[08:11] <valorie> https://www.socallinuxexpo.org/scale/13x/its-scale-13x-slated-february-2015
[08:12] <FreeB3ar> Ohh CraigsList...giving away free horse manure..
[08:13] <FreeB3ar> Free kids too.


[16:19] <smoser> blackboxsw: if you had a minute
[16:20] <smoser>   - bug 1770712 fixes for ubuntu package branches.
[16:20] <smoser>     devel https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347380
[16:20] <smoser>     bionic https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347381
[16:20] <smoser>     artful https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347382
[16:20] <smoser>     xenial https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347384
[16:20] <smoser> that'd be good to land into cosmic today... just get those all in and an upload would be good.
[16:23] <blackboxsw> +1
[16:23] <blackboxsw> will do
[18:05] <blackboxsw> smoser: we're good on the devel portion of those branches, because PACKAGED_VERSION exists in cloudinit/version.py. in bionic and older branches we haven't yet pulled back 5446c788160412189200c6cc688b14c9f9071943
[18:05] <blackboxsw> shouldn't we pull that back too ?
[18:05] <blackboxsw> I realize the packaging change doesn't break currently, but it also doesn't do anything yet
[18:08] <smoser> blackboxsw: well, the next new-upstream-snapshot will get it
[18:08] <smoser> so at this point it is just "staged".
[18:08] <smoser> you're correct though in that it basically adds dead code.
[18:09] <smoser> (the daily builds *would* have it )
[18:09] <blackboxsw> ok just wanted to make sure this was intended, they are decoupled from each other kindof, so I wanted to confirm that we are staging it and know that we are not yet expecting to report full pkg version number in <= Bionic ok I'm good
[18:12] <blackboxsw> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347380 with nit on UNRELEASED -> cosmic
[18:12] <blackboxsw> going through the rest now
[18:12] <blackboxsw> to approve
[18:12] <smoser> blackboxsw: if i uploaded to cosmic i think i'd just do a new-upstream-snapshot
[18:13] <smoser> whicih would then dtrt
[18:13] <blackboxsw> +1 good dela
[18:13] <blackboxsw> deal
[18:13] <smoser> so same there... rwe're just "staging" a change basicalkl.  i think that is generally the flow we'd have on all changes to the packaging branches.
[18:15] <blackboxsw> smoser: want me to queue a new-upstream snapshot then for cosmic.
[18:15] <blackboxsw> ?
[18:15] <blackboxsw> and you can merge in your existing branches?
[18:15] <smoser> you can if you'd like. or i can just do it.
[18:15] <smoser> i'll pull existing.
[18:16] <smoser> merged devel
[18:17] <blackboxsw> ok putting up MP
[18:17] <smoser> i'll grab the others too
[18:18] <smoser> ok. all pacikaging branches have it now.
[18:21] <blackboxsw> smoser: testing this now https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347396
[18:21] <blackboxsw> I didn't push the tag
[18:23] <blackboxsw> ok package built and proper _package_version is showing up
[18:26] <smoser> blackboxsw: doing 'build and push' so that willl land in cosmic-proposed shortly
[19:06] <blackboxsw> rharper: have 5 mins to chat about https://trello.com/c/Uk7OA71K/798-cloud-provided-network-configuration-openstack-azure-aws ?
[19:06] <blackboxsw> specifically the azure portion
[19:34] <rharper> blackboxsw: here now;  still need to chat?
[19:43] <blackboxsw> cool rharper yeah just for a couple mins
[19:43] <blackboxsw> *-mtj
[19:43] <rharper> ok, lemme get setup
[19:44] <blackboxsw> headphone trouble here. coming
[19:56] <blackboxsw> rharper: lost you at 'wouldn't really'
[20:33] <vila> hi there,
[20:34] <vila> I'm encountering an issue that is hard to debug :-/
[20:35] <vila> A few months ago I did install cloud-init on scaleway images (17.1 was the cloud-init version) then.
[20:35] <vila> Booting from these images worked fine.
[20:36] <blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1775074 filed.
[20:36] <blackboxsw> hi vila, yeah just explain the prob as best you can, maybe someone can help
[20:36] <vila> I'm now using the exact same scripts to install cloud-init (18.2) on more recent images and things break:
[20:37] <vila> 2018-06-04 19:37:35,378 - stages.py[DEBUG]: cache invalid in datasource: DataSourceScaleway
[20:37] <vila> 2018-06-04 19:37:35,378 - handlers.py[DEBUG]: finish: init-local/check-cache: SUCCESS: cache invalid in datasource: DataSourceScaleway
[20:38] <vila> on top of that, then run finished by creating /var/lib/cloud/instance/boot-finished at a time where /var/lib/cloud/instance does not exist (i.e.the '/var/lib/cloud/instance' symlink), so a dir is created instead
[20:39] <vila> further runs of cloud-init then fail because then can't delete the dir (a symlink is expected)
[20:41] <vila> any hints on how such issues can be debugged highly appreciated
[20:42] <blackboxsw> vila: hrm looking. That specific log message on "cache invalid", means that the datasource will attempt to re-run  metadata collection again because it appeared that that instance cache was invalid (and needed a refresh).
[20:42] <vila> blackboxsw: Where and how is the cache said to be invalid ?
[20:42] <vila> blackboxsw: I was able to unpickle it from python
[20:43] <blackboxsw> specifically in /usr/lib/python3/dist-packages/cloudinit/stages.py
[20:43] <blackboxsw> it checks datasource.check_instance_id
[20:43] <vila> yeah, opened already
[20:44] <blackboxsw> in Scaleway it looks like that always returns False *I think*
[20:44] <blackboxsw> which means always re-run get-data
[20:44] <vila> when I unpickled it, I check hasattr(ds, 'check_instance_id')
[20:44] <vila> but I was unclear about inferring self.cfg
[20:45] <vila> I guessed it was the instance-id and as far as I could see it was the same instance (I did a reboot)
[20:45] <vila> blackboxsw: I have a vague feeeling it may related to /var/lib/cloud/instance being deleted at that point but I don't where to look for that
[20:45] <blackboxsw> from the base class cloudinit/sources/__init__.py:DataSource.check_instance_id  is just a dummy function returning False and I don't see that Scaleway is overriding that
[20:46] <vila> nope indeed
[20:46] <vila> and it used to work
[20:46] <vila> let's rewing a bit may be
[20:46] <vila> rewind
[20:46] <vila> starting from a booted image, I run apt-get install cloud-init --no-install-recommends
[20:47] <blackboxsw> please do.
[20:47] <vila> anything I need to do for c-i to behave at next boot (same instance or different one)
[20:47] <blackboxsw> A way to test a clean boot scenario  from cloud-init would be hrm so 'sudo cloud-init clean --logs --reboot' would perform a
[20:47] <blackboxsw> 'greenfield' install as if the system had never run cloud-init before
[20:47] <vila> \o/
[20:47] <blackboxsw> it's what we use for upgrade testing and fresh boot validatin
[20:47] <blackboxsw> validation
[20:48] <blackboxsw> that will blow away /var/log/cloud* /var/lib/cloud/* with the exception of a /var/lib/cloud/seed  subdir if applicable (as that seeds some metadata on some clouds)
[20:49] <vila> blackboxsw: done
[20:49] <vila> cloud-init analyze show
[20:49] <blackboxsw> http://cloudinit.readthedocs.io/en/latest/topics/capabilities.html#cloud-init-collect-logs for more details
[20:50] <blackboxsw> yeah analyze show is good for quick inspection of what cloud-init performed.
[20:50] <vila> says no cache found but fails to find the scaleway ds
[20:51] <vila> and cloud-init.log shows the scaleway datasource is not seen nor used
[20:51] <blackboxsw> cloud-init status --long?
[20:52] <vila> detail:
[20:52] <vila> ('ssh-authkey-fingerprints', KeyError('getpwnam(): name not found: ubuntu',))
[20:52] <vila> but that's a fallout from not using the ds and not finding the user-data
[20:52] <blackboxsw> hrm, ok so we have a couple errors looks like
[20:52] <blackboxsw> right
[20:52] <blackboxsw> hmm
[20:52] <vila> so, red herring
[20:52] <vila> why is the datasouce missed ?
[20:53] <vila> I have datasource_list: [ Scaleway, None]
[20:53] <vila> and disable_root: false
[20:53] <vila> (right, forgot to mention that I added the later because scaleway default login is on root)
[20:53] <vila> which was a first hint that things behave differently
[20:54] <blackboxsw> that's good at least. mind doing a 'sudo cloud-init collect-logs' and sending an email to<EMAIL_ADDRESS>I can glance at it quickly here
[20:54] <blackboxsw> collect-logs will dump cloud-init.tar.gz in your cwd
[20:54] <blackboxsw> it'll contain all logs and potentially your user-data
[20:55] <vila> no worries, nothing secret there
[20:55] <blackboxsw> good deal
[20:59] <vila> sent
[20:59] <blackboxsw> checking thanks
[21:01] <vila> I've tried various workflows giving different results, for example, after installing, running 'systemctl start cloud-final && cloud-init status --wait' find the datasource and process properly, but the next boot fails
[21:02] <vila> right now, for the logs I sent, I have a broken /var/lib/cloud/instance (a dir rather than a symlink)
[21:02] <blackboxsw> vila: hrm, normally in cloud-init logs I
[21:03] <blackboxsw> am accustomed to seeing init-local stage, then init   then modules:config, but your logs skip the 'init' stage
[21:03] <blackboxsw> can you cloud-init analyze show | pastebinit
[21:03] <blackboxsw> can you 'cloud-init analyze show | pastebinit'
[21:04] <vila> https://paste.ubuntu.com/p/ZwG4BnnJRd/
[21:04] <blackboxsw> normally I'd see an Starting stage: init-network after init-local and before modules-config
[21:04] <blackboxsw> hrm
[21:05] <blackboxsw> can you cat /etc/cloud/cloud.cfg | pastebinit
[21:05] <vila> https://paste.ubuntu.com/p/Gb6Mzxms9q/ <- that one worked
[21:05] <vila> like ~2 hours ago
[21:06] <vila> blackboxsw: /etc/cloud/cloud.cfg is untouched, but I add:
[21:06] <vila> cat <<EOC > /etc/cloud/cloud.cfg.d/99_byov.cfg
[21:06] <vila> # Generated by byov at $(date)
[21:06] <vila> datasource_list: [ Scaleway, None]
[21:06] <vila> apt_preserve_sources_list: true
[21:06] <vila> disable_root: false
[21:06] <vila> EOC
[21:07] <vila> https://paste.ubuntu.com/p/zVQDMtmG65/ <-  cat /etc/cloud/cloud.cfg
[21:08] <vila> but yeah, it's the missing init-network that I'm tracking indeed
[21:09] <blackboxsw> interesting. so your cloud-init.log mentions 2018-06-04 20:48:32,448 - __init__.py[DEBUG]: Searching for local data source in: []
[21:09] <blackboxsw> that list should have represented Scaleway in it
[21:09] <blackboxsw> something is modifying that datasource list
[21:09] <vila> exactly, sometimes it's there sometimes it's not
[21:09] <blackboxsw> any other files int /etc/cloud/cloud.cfg.d
[21:10] <vila> and it seems the invalid cache somehow mark the datasource entirely wrong
[21:10] <blackboxsw> like /etc/cloud/cloud.cfg.d/90_dpkg.cfg ?
[21:10] <vila> blackboxsw: nope, I used to have datasource_list: [ NoCloud, OpenStack, Scaleway, None] when that was working
[21:10] <vila> right, that one is overriedn... oh, let me check
[21:10] <vila> nope, standard content:
[21:11] <vila> # to update this file, run dpkg-reconfigure cloud-init
[21:11] <vila> datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, None ]
[21:11] <vila> and scaleway is there
[21:11] <blackboxsw> ok that's good. yeah and your ds-itentify.log in the cloud-init.tar.gz also shows ds-identify properly detected Scaleway as an option
[21:11] <vila> Also, I could find when ds-identify is run, but I noticed it's run more than once in some scenarios
[21:11] <blackboxsw> ds-identify rather
[21:12] <vila> Also, I could NOT find when ds-identify is run, but I noticed it's run more than once in some scenarios
[21:13] <vila> so, I keep 'cloud-init clean --logs --reboot' in my notes for the future, but it failed here
[21:14] <vila> which reproduces my issue so it still a good recipe but it doesn't give the result you expected I think
[21:16] <blackboxsw> vila: on the failed case, 'systemctl list-dependencies | grep cloud' this is what I see http://paste.ubuntu.com/p/TQM8RWbwkP/
[21:17] <blackboxsw> I'd expect a cloud-init.server job/unit listed in systemd. it's what runs 'cloud-init init' which is the network stage that we are missing in your failed case
[21:17] <blackboxsw> not sure I'm going down a rat hole there
[21:17] <blackboxsw> not sure *if*
[21:18] <vila> blackboxsw: right, I can rebuild the instance without installing cloud-init and restart from there may be ?
[21:19] <vila> blackboxsw: once cloud-init is installed, I'm running https://paste.ubuntu.com/p/xtGNYpfzZT/
[21:19] <blackboxsw> sounds like a good plan, installing the new cloud-init deb in your environment after the fact should take care of creating the right systemd generators to queue cloud-init stages during boot (if something got mangled across the upgrade path)
[21:20] <blackboxsw> vila: running cloud-init init-local; and cloud-init init 'naked' outside of the standard boot process on an instance is not exactly what we intended (and could be rife with some error condtions)
[21:20] <vila> blackboxsw: I used to run nothing and all was rosy ;-)
[21:20] <blackboxsw> yeah nothing is what we hope is always rosy (and intended).    Just booting normally should take care of ordering all cloud-init stages appropriately (including module configuration etc).
[21:20] <vila> blackboxsw: what *is* the intended workflow ? install, save image, boot ?
[21:21] <blackboxsw> yes vila, boot clean image, install cloud-init, power off, copy clean image, let cloud-init boot in user-configured environment to collect and config based on metadata/user-data
[21:21] <blackboxsw> trying to look more at your latest paste
[21:22] <vila> damn it, that was I did and I thought may be I missed a step
[21:27] <blackboxsw> vila, yeah something smells funky, (I don't have a scaleway acct unfortuntately), I'll try to bisect the diffs on Scaleway datasource from 17.1 -> 18.2 I didn't think we have anything significant in that upgrade path other than some exception handling changes on url retries  in that space
[21:28] <vila> blackboxsw: yup, went there saw that, could find a link either (but I'm not the expert ;-)
[21:29] <blackboxsw> I'd like to see a /var/log/cloud-init.log in the case where cloud-init was upgraded and only a reboot run. (not manual run of cloud-init init --local and 'cloud-init init').
[21:29] <vila> just got the instance without cloud-init installed
[21:29] <vila> so, apt-get cloud-init --no-install-recommends
[21:29] <vila> *install
[21:32] <vila> reboot
[21:33] <vila> https://paste.ubuntu.com/p/HDhH8hWpmd/
[21:34] <vila> yet https://paste.ubuntu.com/p/z6wXtF6Jtx/
[21:35] <vila> blackboxsw: you said "in the case where cloud-init was upgraded" s/upgraded/installed/ otherwise, nothing from my script
[21:38] <blackboxsw> ok so Scaleway ordered before Ec2, Ec2 considered maybe, that shouldn't break anything specifically.for Scaleway's datasource. reading your cloud-init.log
[21:38] <blackboxsw> 2018-06-04 21:31:31,651 - stages.py[DEBUG]: no cache found    [21:39] <vila> right, so the cache itself is not the root cause, well done
[21:40] <blackboxsw> line 74 of your first paste is showing us we are properly attempting  the discover Scaleway (and many other datasources) in python (instead of ds-identify which is just a shell script (for speed)
[21:40] <vila> and https://paste.ubuntu.com/p/PJ2C5tQsSJ/ should cover all the datasource inputs
[21:40] <blackboxsw> line 78 rather
[21:41] <blackboxsw> ohh wait
[21:41] <vila> right
[21:41] <blackboxsw> no Scaleway in line 78
[21:41] <vila> while still there in line 77
[21:42]  * vila thinks
[21:42] <vila> could it be that /var/run/scaleway is created too late (aka race ?)
[21:42] <blackboxsw> I had thought Scaleway datasource was defined as FILESYSTEM only. checking the DataSourceScaleway.py again
[21:42] <blackboxsw> my bad
[21:42] <blackboxsw>     (DataSourceScaleway, (sources.DEP_FILESYSTEM, sources.DEP_NETWORK)),
[21:43] <blackboxsw> that means Scaleway datasource is init-network stage detected only ... ok so we expect to filtered out of init-local stage
[21:43] <blackboxsw> ok so we're still good in init-local stage (not detecting scaleway)
[21:44] <blackboxsw> but the fact that init-network (otherwise called via CLI as 'cloud-init init') should not be skipped,
[21:44] <blackboxsw> that's what should have detected scaleway....
[21:44] <blackboxsw> reading down past init-local in your cloud-init log now. sorry for the noise
[21:45] <vila> no no ! very helpful
[21:45] <vila> (and entertaining ;)
[21:45] <blackboxsw> 2018-06-04 21:31:32,137 - handlers.py[DEBUG]: finish: init-local: SUCCESS: searching for local datasources
[21:45] <blackboxsw> 2018-06-04 21:31:34,280 - util.py[DEBUG]: Cloud-init v. 18.2 running 'modules:config' at Mon, 04 Jun 2018 21:31:34 +0000. Up 16.05 seconds.
[21:45] <blackboxsw> heh
[21:45] <vila> (don't get derailed but line 136 : 2018-06-04 21:31:31,963 - util.py[DEBUG]: dmi data /sys/class/dmi/id/sys_vendor returned Scaleway)
[21:46] <vila> There is a comment that dmi is not implemented IIRC...
[21:46] <vila> * check DMI data: not yet implemented by Scaleway, but the check is made to
[21:46] <vila>       be future-proof.
[21:48] <blackboxsw> vila: what's systemctl list-dependencies | grep cloud tell you?
[21:48] <vila> https://paste.ubuntu.com/p/7SSDVB7ZsG/
[21:49] <blackboxsw> that's ok on the dmi read, as it was something cloud-init did to determine that it's not running on DigitalOcean.
[21:49] <vila> ha
[21:51] <blackboxsw> meh. something is causing cloud-init to skip init-network stage in that environment. (like a systemd job falling over maybe?) I see no tracebacks indicating why that is skipped. lemme see if I can digup the format of the systemd job
[21:51] <blackboxsw> do you have a /lib/systemd/system/cloud-init.service  ?
[21:51] <vila> yes
[21:52] <vila> https://paste.ubuntu.com/p/JgDkpMCy5v/
[21:55] <blackboxsw> bah. ok I think we need a bug here. I'll have to get a scaleway account setup to checkit out. nothing should have changed w.r.t. 17.1->18.2 and the systemd startup jobs/units. but skipping init-network stage is broken and that's why things are falling over.  I'll have to get a scaleway acct setup to triage more
[21:55] <blackboxsw> what ubuntu release was this instance?
[21:55] <vila> xenial
[21:55] <blackboxsw> bionic? xenial?
[21:55] <blackboxsw> ok
[21:56] <vila> blackboxsw:
[21:56] <blackboxsw> would you kindly 'ubuntu-bug cloud-init' vila and file a bug per instructions?
[21:56] <blackboxsw> it'll dump your collect-logs output into a bug attachement
[21:57] <vila> blackboxsw: from inside the instance ?
[21:58] <vila> -bash: ubuntu-bug: command not found, installing
[21:58] <blackboxsw> vila: yes please (if it has outbound connectivity). otherwise  you could just file a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach a the cloud-init.tar.gz from your latest run to the bug
[21:59] <blackboxsw> all ubuntu-bug does is ask a question or two about your cloud platform and collate that data when filing output from 'sudo cloud-init collect-logs'
[21:59]  * vila installs apport
[22:00]  * vila thinks about giving access... should be a matter of adding an ssh key on my account ?
[22:01] <blackboxsw> yeah in the nearterm your sudo cloud-init init --local; sudo cloud-init init;  sudo cloud-init modules --mode config,  sudo cloud-init modules --mode final    I *think* should get you 90% of the way there
[22:01] <blackboxsw> vila: right you could add ssh-import-id chad.smith to the instance
[22:01] <blackboxsw> vila: right you could run 'ssh-import-id chad.smith' to the instance then I'd be able to login as whatever user you did that under
[22:02] <vila> blackboxsw: root ! what else ? :-D
[22:02] <blackboxsw> hah! but that said, I'm going to have to disappear shortly so I may not get to it until tomorrow morn my time
[22:02] <blackboxsw> <--- and file your back acct and social security number here ;)
[22:03] <blackboxsw> it may be good to have a reference bug so the others on the team can peek at the triage/respose too
[22:03] <vila> hehe
[22:04] <vila> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1775086
[22:06] <blackboxsw> thanks again. vila I have to bail for a while. will check it out
[22:07] <vila> blackboxsw: thanks to you, at least I'm not mad and something is going on that is worth fixing ;-)
[22:07] <vila> blackboxsw: if only for /var/lib/cloud/instance being a dir...
[22:19] <blackboxsw> thx vila on the not being a dir issue I'll track a separate bug on 'cloud-init collect-logs' cmd being more resilient of failure cases
[22:22] <blackboxsw> added that content to https://bugs.launchpad.net/cloud-init/+bug/1775074
[22:22] <blackboxsw> will try to kill 2 birds with 1 stone there
[22:31] <blackboxsw> vila: comment for you on your bug. ok systemd has removed the cloud-init.service job for some reason and I need to dig into why
[22:44] <vila> haaaa


[22:08] <Gorg> How do I do the checksum with the windows Winmd5free.exe? I downloaded edubuntu from edubuntu.org.
[22:11] <Eickmeyer> Gorg: We don't have MD5sums, so you'll have to verify using the sha256sum. See https://ubuntu.com/tutorials/how-to-verify-ubuntu#1-overview
[22:13] <Eickmeyer> Also this might help: https://www.incredigeek.com/home/verify-ubuntu-iso-on-windows/