[01:30] <hpidcock> wallyworld: just got this bootstrap lxd on 2.8-rc branch
[01:30] <hpidcock> Unable to fetch Juju GUI info: error fetching simplestreams metadata: cannot unmarshal JSON metadata at URL "https://streams.canonical.com/juju/gui/streams/v1/com.canonical.streams-released-gui.sjson": json: cannot unmarshal string into Go struct field Metadata.juju-version of type int
[01:31] <wallyworld> hpidcock: yup, they messed up the metadata
[01:31] <wallyworld> a fix is in progress
[01:31] <hpidcock> awesome
[01:31] <wallyworld> indeed
[02:07] <hpidcock> wallyworld: https://github.com/juju/python-libjuju/pull/412
[02:07] <hpidcock> and anyone else interested in python-libjuju
[02:07] <wallyworld> looking
[02:08] <wallyworld> +43000!!!!!!
[02:09] <timClicks> wgrant: appreciate the time taken to write that response, thanks
[02:09] <wgrant> timClicks: It's possible that I may have some Opinions :)
[02:10] <wgrant> Thanks for starting conversations like this
[02:10] <timClicks> wgrant: am glad that thread was started with a warning ;)
[02:10] <wgrant> Heh, indeed.
[02:14] <wallyworld> hpidcock: ideally we'd use 2.8.0 for the schema not 2.8-rc2 as that reference will be out of date in days. can we add in the remaining schema from the model operator branch and use 2.8.0
[02:16] <hpidcock> wallyworld: rc2 is 2.8.0 at the moment. If stuff hasn't landed in the rc branch it's not 2.8.0 yet
[02:17] <wallyworld> sure, but it seems unfortunate to release a new libjuju with will be out of date in terms of that in a matter of days
[02:17] <wallyworld> i guess we can do a 2.8.1 after 2.8 ships
[02:29] <thumper> hpidcock: reviewed libjuju
[02:41] <wallyworld> thumper: i'm still waiting on fixes/changes to the dashboard tarball, but this works with the one that's currently published. i also need to retest upgrades after changes to accommodate the recent tarball revision https://github.com/juju/juju/pull/11562
[02:48] <thumper> wallyworld: ack
[02:51] <thumper> wallyworld: did you check that the old gui continued to work after the upgrade?
[02:51] <wallyworld> i did
[02:52] <wallyworld> will retest everything though after final tweaks for the new new new dashboard
[04:01] <wallyworld> thumper: everyone else super busy, so sorry, https://github.com/juju/juju/pull/11565
[04:04] <wallyworld> ah balls, targetted to wrong branch, should be 2.7
[04:07] <thumper> wallyworld: did you want me to retarget?
[04:07] <thumper> or do you need to rebase first?
[04:07] <wallyworld> thumper: i just rebased and retargetted
[04:08] <wallyworld> now i need coffee before i hack on the dashboard stuff again to support the new new format
[04:14] <thumper> wallyworld: asked a question...
[04:19] <wallyworld> thumper: answered
[04:20] <wallyworld> previously the offer stirng was a const
[04:20] <wallyworld> now it's built from series, and we also need the sku
[04:25] <thumper> wallyworld: right, but the number at the front is something they increment
[04:25] <thumper> not a fixed 0001
[04:25] <wallyworld> supposedly
[04:26] <wallyworld> it's not something we know ahead of time, it's not something were can query. we could make it a vonfig somewhere but that has its own issues
[04:26] <thumper> which is why I asked can we do a substring match on the offer?
[04:26] <wallyworld> it's an arbirary decision outside of juju
[04:27] <wallyworld> no, becaue it's a param passed to azure
[04:27] <wallyworld> we don't match on it
[04:27] <wallyworld> we pass it to azure
[04:27] <thumper> right
[04:28] <thumper> I understand that
[04:28] <thumper> can we pass a substring?
[04:28] <thumper> is it an exact match?
[04:28] <thumper> because we shouldn't be using 0001
[04:29] <wallyworld> it's used to tell azure to pick a particular image by tag, no substring involved, eg
[04:29] <wallyworld> 	return &compute.StorageProfile{
[04:29] <wallyworld> 		ImageReference: &compute.ImageReference{
[04:29] <wallyworld> 			Publisher: to.StringPtr(publisher),
[04:29] <wallyworld> 			Offer:     to.StringPtr(offer),
[04:29] <wallyworld> 			Sku:       to.StringPtr(sku),
[04:29] <wallyworld> 			Version:   to.StringPtr(version),
[04:29] <wallyworld> 		},
[04:29] <wallyworld> 		OsDisk: osDisk,
[04:29] <wallyworld> 	}
[04:29] <wallyworld> Offer is a straight out arg to an api call
[04:30] <wallyworld> we either have it or we don't
[04:31] <thumper> in which case we have a problem
[04:31] <wallyworld> if they ever chabge it yes
[04:32] <thumper> guarantee that they'll change it
[04:32] <kelvinliu> wallyworld: https://github.com/juju/juju/pull/11566 got this pr to move the retry to initialization function to retry the coping charm request only rather than retrying the whole remote init operation
[04:32] <wallyworld> we need to tell them not to
[04:32] <kelvinliu> could u take a look?
[04:32] <wallyworld> sure
[04:32] <kelvinliu> ty
[04:48] <wallyworld> kelvinliu: lgtm but retarget to 2.8-rc branch
[04:48] <kelvinliu> wallyworld: yep, ty
[04:53] <thumper> https://github.com/juju/juju/pull/11567 for a fix to the full status query tracker tests
[04:53] <wallyworld> hpidcock: kelvinliu: looks like another remote-init issue, bug 1878329 application-mattermost: 15:32:59 ERROR juju.worker.uniter resolver loop error: executing operation "remote init": caas-unit-init for unit "mattermost/0" failed: ERROR failed to remove unit tools dir /var/lib/juju/tools/unit-mattermost-0: unlinkat /var/lib/juju/tools/unit-mattermost-0/goal-state: permission denied
[04:53] <mup> Bug #1878329: stuck k8s workload unit following upgrade-charm with new image <juju:New> <https://launchpad.net/bugs/1878329>
[04:53] <wallyworld> thumper: looking
[04:55] <kelvinliu> that's weird, operator is the root user
[04:57] <wallyworld> thumper: just a small suggestion
[04:58] <wallyworld> thanks for the libjuju relase hpidcock, you've made several folks very happy, including the osm guys
[04:59] <thumper> not to mention solutions qa
[04:59] <kelvinliu> wallyworld:  https://bugs.launchpad.net/juju/+bug/1877935 we still have this bug,
[04:59] <mup> Bug #1877935: operator trys to exec into the workload container but the container is not running yet <juju:New> <https://launchpad.net/bugs/1877935>
[05:00] <wallyworld> yeah we do :-(
[05:00] <kelvinliu> forgot mention in standup, I think this one and the watcher one should have higher priority than the block storage one?
[05:00] <wallyworld> yup
[05:00] <wallyworld> the block storage one is more a guard rail
[05:01] <kelvinliu> ok, im gonna look on these two first
[05:01] <wallyworld> with the init one, maybe we can try looking for the pod a few times, using retry()
[05:01] <wallyworld> or at least query the cluster to see if things are stareting up
[05:02] <wallyworld> and give them time to get done if they are
[05:03] <kelvinliu> i think there might be a upgrade charm flow missing in the init process
[05:04] <wallyworld> could be, i'd need to look at the logic again to see what's been implemented
[05:05] <kelvinliu> also I guess the watcher bug is related operator rather than the watcher itself. It seems the operator is not responding correctly if any uniter got those errors(like 137, etc).
[05:07] <thumper> wallyworld: you think I should just say "FullStatus" without the prefix ?
[05:07] <thumper> I think it would probably match too
[05:08] <wallyworld> thumper: it's more filtering out other method names that contain the one currently being filtered on
[05:08] <thumper> wallyworld: I don't know what you just said
[05:09] <wallyworld> so if the tracer has been set up to look for "FullStatus" and the traceback has "FullStatusVerbose", it would match both with the current code
[05:09] <thumper> FWIW, 	tracker := s.State.TrackQueries("FullStatus") works
[05:09] <wallyworld> we want to exclude "FullStatusVerbose"
[05:09] <thumper> well, then the caller should say "FullStatus("
[05:10] <wallyworld> ok, I wasn't sure if the expectation / desire was for a single method match
[05:10] <wallyworld> to avoid ambiguity
[05:11] <thumper> it is sufficient for now, but we may need to tweak later, I'll add more of a comment on the TrackQueries method to explain so future people will know
[05:11] <wallyworld> sgtm
[05:13] <thumper> wallyworld: added more of a comment to explain on the tracker
[05:13] <thumper> so it shouldn't be a surprise to any future people using it
[05:14] <wallyworld> ty
[05:44] <thumper> wallyworld, or anyone: https://github.com/juju/juju/pull/11568
[05:48] <thumper> tlm, hpidcock, kelvinliu: ^^?
[05:49] <kelvinliu> looking now?
[05:49] <thumper> kelvinliu: thanks
[05:53] <thumper> kelvinliu: generally for things we need to wait on, we use testing.LongWait
[05:53] <thumper> even if we expect them to happen quickly
[05:53] <thumper> there is no real change to the test times for running in that package
[05:54] <thumper> with the patch I had 2.2, 3 and 4s for the package on three different runs
[05:54] <thumper> before it was 2.7  seconds
[05:54] <thumper> so within the realm of ok IMO
[05:54] <kelvinliu> thumper: it's weird to see this errors because we mocked anything in caas provider, so no db or any network access, but the fix lgtm.
[05:54] <thumper> yeah, I'm betting it is just CPU contention
[05:55] <thumper> and the number of concurrent goroutines
[05:55] <thumper> yes it shouldn't take long
[05:55]  * thumper shrugs
[05:55] <thumper> I'm pretty sure this will make the intermittent issues go away
[05:55] <kelvinliu> yeah, thanks for the fix
[06:03] <wallyworld> thumper: that PR should land in the 2.8 branch IMO
[06:04] <wallyworld> not 2.8-rc but 2.8
[06:04] <wallyworld> tlm: your PR ready for another look?
[07:48] <timClicks> an excellent thread has emerged on a charm's error state for anyone who would like a few minutes of procrastination ahead of them https://discourse.juju.is/t/when-to-send-an-application-into-an-error-state/3046
[14:07] <manadart> hml: Cherry-pick to the RC branch of Tim's ENI/Netplan patch: https://github.com/juju/juju/pull/11569
[14:14] <hml> manadart:  looking
[14:15] <hml> manadart:  tick
[14:15] <manadart> hml: Ta.
[15:07] <manadart> hml: Small utility addition. No hurry; I am EoD: https://github.com/juju/juju/pull/11570
[19:26] <cory_fu> petevg: I have a present for you: https://github.com/juju/python-libjuju/pull/415  There are still failing tests, but you can actually see what they are now and they would have caught the open issues with the 2.8 release.
[19:27] <petevg> cory_fu: nice! Thank you :-)
[19:28] <cory_fu> petevg: It would also be nice to see all of those "Event loop is closed" errors when a test fails cleaned up to make the results less noisy, but I'll leave that to you.  ;)
[19:29] <petevg> +1
[19:29] <petevg> :-)
[19:55] <cory_fu> petevg: I see that the Juju repo is also using GH Actions now.  It would be really interesting if a portion of that PR could be ported over to the Juju repo so that breakages to libjuju are caught immediately rather than depending on a change to land in libjuju to find it.  I guess one aspect of that is that you'd need to do the upstream sync as part of the test so that things like facade or definition changes got picked up.  That probably worth
[19:55] <cory_fu> doing on the edge portion of the libjuju tests as well, TBH.
[19:55] <petevg> cory_fu: that makes sense. It'd be nice to catch this stuff right away ...
[19:57] <cory_fu> petevg: Downside is the 20+ minute duration of the integration tests, plus the fact that while the change in Juju might lead to a break, it would likely need to be fixed in libjuju rather than the Juju PR.
[19:57] <petevg> True.
[19:57] <petevg> That would create a chicken and egg issue!
[19:57] <cory_fu> I wonder if GitHub Actions could do a daily run with notifications?  Or since you have a Jenkins already, adding a daily run to that to watch for libjuju breakage.
[19:58] <cory_fu> petevg: I actually thought that last one was planned when the Juju team took over libjuju, but I guess it got dropped.
[20:44] <rick_h> cory_fu:  petevg one of the issues we had was the whole "land the thing that generates the new schema" and then go update the schema in the library chicken and egg issue
[20:44] <rick_h> cory_fu:  petevg I think there is a test that's non-gating in jenkins that checks if things are likely to be broken. You can check with stickupkid on those as he's managed most of that to date
[20:45] <petevg> rick_h: cory_fu made a pr to make that test gating :-)
[20:45] <cory_fu> petevg: Different test
[20:45] <petevg> Aha! Got it.
[20:47] <cory_fu> rick_h, petevg: Would that be this test?  https://jenkins.juju.canonical.com/view/github/job/github-integration-tests-pylibjuju/
[20:48] <cory_fu> Hrm.  Maybe this one?  https://jenkins.juju.canonical.com/job/github-schema-tests-pylibjuju/
[20:50] <petevg> You're showing me red circles and making me sad, cory_fu :-(
[20:50] <cory_fu> petevg: Red circles that haven't been run in months, too
[20:51] <cory_fu> petevg: Maybe this one will make you happier?  https://jenkins.juju.canonical.com/job/github-check-merge-juju-python-libjuju/147/
[20:52] <cory_fu> That is running the unit tests, at least, but that doesn't help with catching any of the stuff that the integration tests caught.
[20:54] <cory_fu> petevg: Thinking about it more, there's a chicken-and-egg issue in the other direction as well.  If we make the libjuju edge tests do the upstream sync and it fails, it wouldn't really be relevant to the PR on that side either.
[20:55] <cory_fu> petevg: It definitely seems like the right thing is instead something like a daily build that uses master of Juju and master of libjuju, syncs and builds them, then runs the integration tests from libjuju.  As long as that actually generated an alert that got paid attention to, it wouldn't block specific PRs but would let you know if there was an issue that would need to be addressed.
[20:57] <cory_fu> Plus the 20 or so minute runtime of the integration tests wouldn't be so onerous if only being run once a day.
[23:42] <thumper> wallyworld: https://github.com/juju/juju/pull/11571


[17:12] <wxl> elfy: present for your team— bug 1362555
[17:14] <elfy> wxl: nope - all fine here
[17:15] <wxl> elfy: how so?
[17:15] <elfy> doesn't affect me
[17:16] <elfy> I thought I remembered this bug - ochosi commented - must have shown up in #xub-dev
[17:17] <wxl> i think we need to get ochosi and rafaellaguna together
[17:22] <wxl> elfy: also, ochosi's comment is quite old.
[17:23] <elfy> even so - not apparently affecting me
[17:26] <elfy> wxl: I've not seen any notify issues like that ever
[17:26] <elfy> and I get notifications when music changes - and I listen to that for hours and hours at a time
[18:31] <pvsenan> balloons: Hi
[18:35] <balloons> pvsenan, hello
[18:36] <pvsenan> balloons, few days back, there was a mail chain for creating test for ubuntu help app
[18:36] <pvsenan> balloons, can you give me some more details
[18:38] <balloons> pvsenan, certainly. Have you pulled the app sources?
[18:39] <pvsenan> balloons, I am just pulling it from here bzr branch lp:help-app
[18:39] <pvsenan> balloons, is it correct ?
[18:39] <balloons> pvsenan, yes that's correct
[18:39] <pvsenan> balloons, just finished
[18:40] <balloons> this is the original bug Daniel filed: https://bugs.launchpad.net/help-app/+bug/1456924
[18:42] <pvsenan> balloons, I've seen this but it doesnt have much details
[18:42] <balloons> the bug also links to the tutorial, which helps a little bit if you need info on setup
[18:42] <balloons> but basically, I can help by writing down some user stories so you know what tests to write :-)
[18:43] <balloons> I was going to get that from Daniel today, but didn't get a chance. I can take a first stab at it though
[18:48] <pvsenan> balloons, that will be great
[18:49] <pvsenan> balloons, I've installed selenium and i am reading the tutorial now
[18:55] <balloons> pvsenan, the first mp I would propose is basically to copy the template to the app so we can launch it and introspect it
[18:55] <balloons> then it will be easy to add tests.
[18:57] <pvsenan> balloons, How do I do that ?
[18:58] <balloons> pvsenan, create a new html5 application in the ubuntu sdk. You should get the new template. It's what's discussed in the tutorial
[19:00] <pvsenan> balloons, I'm sorry, still confused
[19:04] <pvsenan> balloons, the app is already there right ? why should I create a new one ?
[19:05] <balloons> pvsenan, sorry I don't mean to be confusing. I'm just saying the current application doesn't have any functional tests. The template however has an example testsuite you can copy into the project to make it easier
[19:06] <balloons> perhaps I should just propose what I'm talking about so I don't confuse you :-)
[19:06]  * balloons creates mp
[19:14] <pvsenan> balloons, I should use ubuntu SDK GUI right ?
[19:16] <balloons> pvsenan, for test writing you don't have to, but it's handy. Feel free to use your favorite editor
[19:16] <balloons> i personally use it and geany
[19:16]  * balloons tests mp
[19:18] <pvsenan> balloons, this is my status, I have launched ubuntu sdk and now Run Click is running and retrieving files
[19:19] <balloons> pvsenan, ahh right, building a root
[19:20] <balloons> in the interim, you can build the app in the terminal. Have a read of the HACKING guide, but basically  'make app' in the root will buld it
[19:22] <balloons> pvsenan, ok, so I'm pushing my quick version with a basic template in place
[19:23] <balloons> pvsenan, https://code.launchpad.net/~nskaggs/help-app/functional-test-template/+merge/260206
[19:25] <pvsenan> balloons, I am branching it
[19:25] <balloons> that should allow you to easily add testcases now and they will run via autopilot
[19:28] <pvsenan> balloons, i have managed to launch the app
[19:29] <balloons> awesome :-) With my branch you should be able to follow the notes in HACKING and run the basic testcase. It has no asserts, heh, just launched the app
[19:33] <pvsenan> balloons, should I copy the functional test folder to the original source ?
[19:35] <balloons> pvsenan, ? if you want to play with things now, merge my branch locally with what you've been working on, or just start modifying from it and push something new
[19:35] <balloons> make sense?
[19:36] <pvsenan> balloons, how do I merge it locally ?
[19:36] <balloons> pvsenan, so if you did bzr branch lp:help-app, you can merge my branch on top by bzr merge lp:~nskaggs/help-app/functional-test-template
[19:39] <balloons> or simply just bzr branch lp:~nskaggs/help-app/functional-test-template and modify it from there
[19:45] <pvsenan> balloons, http://paste.ubuntu.com/11376527/
[19:48] <balloons> pvsenan, looks like launchpad isn't happy atm, I can't access it
[19:48] <balloons> did you branch my changes already?
[19:49] <balloons> pvsenan, also if you are new to bzr, here's the quick info you need to know: https://wiki.ubuntu.com/QATeam/DevelopmentToolsUsage and https://wiki.ubuntu.com/QATeam/DevelopmentToolsSetup
[19:55] <balloons> pvsenan, ok looks like I can connect to launchpad again. Everything get branched ok?
[19:58] <pvsenan> balloons, I think so
[20:01] <balloons> pvsenan, ok, sorry for the initial trouble. So what questions do you still have? We can write a first testcase together now; would that help?
[20:03] <pvsenan> balloons, can you give me some time..I am going for dinner and will be back in 30 mins
[20:08] <balloons> pvsenan, ofc ofc.. I'm here to help with whatever. I want to make sure you have a good understanding of things
[20:31] <dkessel> balloons: good evening. i filed bug 1458314 about the unity8 live session issues the other day. do you think it needs more information for someone to work on it?
[20:31] <balloons> dkessel, howdy.. I too had some fun with unity8 the other day! I finally got a few mins on friday to have a play
[20:32] <balloons> I encountered the same issue with the image. The lxc session worked, but i couldn't install anything, that failed
[20:32] <balloons> things in general with wily were a bit off
[20:33] <balloons> dkessel, you got an oops id? did it file I wonder?
[20:36] <dkessel> balloons: i got the oops after plugging in the ethernet cable and reading the ID in the syslog file
[20:36] <dkessel> the network connection availability triggered the upload i think
[20:37] <dkessel> i don't know how to find out what happened with that oops
[20:39] <balloons> bdmurray, ^^
[20:39] <dkessel> oh, errors.ubuntu.com i guess :)
[20:40] <bdmurray> right, e.u.c/oops/xyz
[20:42] <balloons> nice so it's there: https://errors.ubuntu.com/oops/5db6880c-0200-11e5-b05b-fa163e4ccdf2
[20:42] <dkessel> mkay. not publicly accessible. i guess that is a good idea, though
[20:43] <dkessel> but good that you encountered the same problems balloons
[20:44] <balloons> yes, I'll probably carve out some time again this week to have another go and review what's landing in wily
[20:44] <bdmurray> its not publicly accessible because it may contains private data
[20:44] <balloons> the wily change broke a lot of things
[20:53] <pvsenan> balloons, I have a few questions
[20:57] <balloons> pvsenan, ok
[21:00] <pvsenan> balloons, the initial tests you updated in the bug, in all the scenarios a browser will open and how do we validate that
[21:06] <balloons> pvsenan, I would suggest the first test to be simply loading the app and opening each page
[21:06] <balloons> for opening a browser, I have to confer with Daniel about expectations. I don't think we should be leaving the app . . .
[21:07] <pvsenan> balloons, OK. I'll try to do that. I
[21:07] <balloons> It's unclear to me. However if we should indeed be leaving, we can figure out how to test the browser was launched
[21:07] <balloons> I don't know offhand, we'll have to figure it out :-)


[20:31] <mhall119> AlanBell: ping
[20:31] <mhall119> AlanBell: I need to send a list of new IRC channels for UOS 14.06, what's the right email to send that to?
[20:31] <mhall119> clarity: I have a list of channels I need created (and old ones that can be closed)
[20:32] <Pici> mhall119: just send it off to<EMAIL_ADDRESS>and one of us will take care of it.
[20:32] <Unit193> I'd say irc-council @ lists.ubuntu com
[20:33] <mhall119> thanks
[20:38] <mhall119> sent, thanks again


[00:32] <^Phantom^> Hi
[00:32] <^Phantom^> I come back to recieve word on my ban.
[00:55] <elky> ^Phantom^, can you describe what happened please. Remembering that you will always be held responsible for what others do with your login, etc.
[00:56] <^Phantom^> It was discussed a few days ago, and I was asked to return for the final decision.
[04:59] <bazhang> ^Phantom^, why were you banned in the first place
[05:00] <^Phantom^> posting xchat crash codes
[05:01] <bazhang> ^Phantom^, why would you do that
[05:04] <^Phantom^> a friend and i were trolling all over irc networks with it
[05:05] <bazhang> ^Phantom^, who did you discuss removing the ban with
[05:06] <^Phantom^> I think it was AlanBell
[05:07] <^Phantom^> I don't have it in the xchat backlog for this os :S
[05:07] <^Phantom^> I think DJones is the one that had me come here to talk about it
[05:07] <bazhang> ^Phantom^, why do you need back into #ubuntu ? if you see it as a place to troll
[05:07] <^Phantom^> It was a 1-2 day stint
[05:08] <^Phantom^> It won't happen again
[05:08] <bazhang> that doesnt answer my question. and you have had issues in #ubuntu in the past as well, so you know the channel guidelines by now
[05:55] <Myrtti> ^Phantom^: hello?
[06:07] <Tm_Tr> Myrtti: I recall he said before he did that on many channels (and networks), staff comment on DoS behaviour appreciated as usual
[06:12] <Myrtti> sadly I personally have very little to say on the subject
[06:30] <^Phantom^> Hi
[06:30] <^Phantom^> Sorry I went afk for a bit
[07:43] <DJones> That was Amador, removed from channel
[09:23] <ikonia> ^Phantom^: are you still there please ?
[09:23] <AlanBell> ^Phantom^: the attemt to crash the clients of other users is a huge problem. I have no inclination at all to let you back into our larger channels
[09:23] <^Phantom^> I am here
[09:23] <^Phantom^> I guarantee it won't happen again.
[09:24] <AlanBell> there are plenty of channels that are not #ubuntu and there is the rest of the internet available for you to enjoy
[09:33] <ikonia> ^Phantom^: you now have your answer, could you please leave the channel
[14:09]  * Pici slides ikonia a coffee
[14:10] <ikonia> thank you
[14:45] <bazhang> :0
[14:46]  * knome doesn't like nick-games
[15:06] <bazhang> a PPA that breaks dpkg?
[15:07] <Pici> eh?
[15:37] <bazhang> no means NO!
[15:40] <bazhang> Mr UOBTTU!
[15:40] <bazhang> whoops
[15:42] <ikonia> what dell blockade of ubuntu is AGrinsPaul on about ?
[15:43] <Pici> no idea
[15:43] <Pici> I'm done with good_samaritan.
[15:43] <Pici> Hopefully he'll stop now.
[15:44] <ikonia> good
[15:45] <Fuchs> ikonia: just out of interest, why pointing him to defocus and not your offtopic channel?
[15:45] <ikonia> Fuchs: because it's just nonsense
[15:45] <Pici> hah
[15:45] <Fuchs> ikonia: then that is not a nice thing to do, just passing the nonsense over to us to handle :(
[15:46] <ikonia> the same way he's desperate to tell people in #ubuntu rather than join #defocus suggests he wants to shout in #ubuntu
[15:46] <ikonia> Fuchs: that wasn't the intention
[15:46] <Fuchs> okay
[15:46] <Pici> #defocus is more moderated than it used to be, its not the melting pot of nonsense that it used to be
[15:46] <ikonia> the guy just appears to want to vent
[15:47] <ikonia> it's still more flexible than #ubuntu-offtopic
[15:47] <ikonia> (unless it's now not)
[15:47] <Pici> Is Aline making any sense?
[15:47] <ikonia> of course not
[15:47] <Fuchs> Pici: thanks, and that costs us lots of manpower, thats why i am happy to not collect everyone that other chans dont want :)
[15:47] <Fuchs> anyway, sorry for ot and read you later, train awaits
[15:48] <ikonia> Fuchs: lets see what he says in #defocus
[15:48] <ikonia> Fuchs: it's a reasonable question, no need to apologise
[15:48] <Pici> oh, its a bot. how nice.
[15:48] <Pici> 11:48:09 <?Aline> One toilet space could be found on boot options?
[15:48] <ikonia> ahhh it's the EFI OS lock from windows he's ranting about
[15:51] <GrueGRUUUUUUuue> Nobody responded in defocus so I had to ask in -offtopic instead. It's no spam; just a youtube vid of discussion.
[15:51] <ikonia> it's tedious and just hitting random channels with it
[15:52] <GrueGRUUUUUUuue> ikonia, they're off-topic... -_-
[15:52] <ikonia> the fact that you are still trying to push it in defocus as some sort of political agenda doesn't make me want to allow it in #ubuntu-offtopic
[15:52] <GrueGRUUUUUUuue> What am I gonna do if no one responds?
[15:52] <ikonia> GrueGRUUUUUUuue: nothing
[15:52] <ikonia> GrueGRUUUUUUuue: it means no-one wants to talk about it - so stop
[15:52] <GrueGRUUUUUUuue> I just want to find the right room to talk about it then.
[15:53] <ikonia> GrueGRUUUUUUuue: go and find one then
[15:53] <GrueGRUUUUUUuue> suggestions for which channels?
[15:53] <ikonia> none
[15:54] <ikonia> either way, if you change the topic of your discussion you are welcome back in #ubuntu-offtopic
[15:54] <ikonia> GrueGRUUUUUUuue: if you're done here could you please /part the channel
[15:55] <GrueGRUUUUUUuue> ok then.
[15:55] <ikonia> thanks
[15:59] <Myrtti> here's a GIF for all of you; please remember it when you need to play whack-a-troll. http://imgur.com/gallery/xUHdw
[16:02] <ikonia> please can someone watch Chuck_Norris
[16:03] <ikonia> he's just joined and I expect his quality support will start soon
[16:03] <Pici> watch mah channel.
[16:03] <ikonia> ha ha ha ha
[16:03] <ikonia> genuinly laughing, very nice
[16:29] <astraljava> Myrtti: lovely :)
[19:00] <Gentoo64> is this the right channel to request an unban?
[19:02] <ikonia> sure
[19:02] <ikonia> so what's changed since you got banned ?
[19:03] <Gentoo64> got banned ages ago, cant remember why
[19:03] <ikonia> really,
[19:03] <ikonia> pretty annoying and bad behaving
[19:04] <ikonia> and then trying to ban evade multiple times over the following weeks so you could join and say "ikonia you are a shit" and other such things
[19:04] <ikonia> none of that sound familer ?
[19:04] <Gentoo64> nope lol
[19:04] <Gentoo64> when you banned me i might have called u something
[19:05] <ikonia> this went on for a couple of weeks
[19:05] <Gentoo64> it cant have
[19:05] <ikonia> trying to dodge the ban so you could post offensive/stupid things into the channel and /part
[19:05] <Gentoo64> well that werent me
[19:05] <ikonia> really, so someone else was using your nikckname and account ?
[19:05] <Gentoo64> i doubt it
[19:05] <ikonia> so it was you then
[19:06] <Gentoo64> no...
[19:06] <Gentoo64> i never do stuff like that
[19:06] <ikonia> oh, really
[19:06] <ikonia> ok so parking that for a moment
[19:07] <ikonia> what's changed with you ?
[19:07] <Gentoo64> brb dinner
[19:07] <ikonia> Gentoo64: please /part then
[19:07] <ikonia> come back when you are free
[19:08] <ikonia> @mark #ubuntu-ops Gentoo64 requesting unban appears to have the same attitude as before when he was banned
[19:33] <mneptok> Gentoo64: are you actually available to discuss your ban?
[19:38]  * mneptok flicks the lights on and off
[19:38] <mneptok> Gentoo64, over.
[19:42] <mneptok> for the record, a CTCP version failed to summon.
[19:52] <ikonia> I suspect he's just trying to annoy....as he was when he actually got banned
[20:34] <IdleOne> @mark #ubuntu-server RoyK PM'ed Royk reminding them of the language policy in ubuntu channels.
[20:57] <ikonia> IdleOne: again.....
[20:58] <IdleOne> ikonia: He and tmb are often the offenders (repeat)
[20:58] <ikonia> I know, it's getting tiresome
[20:59] <IdleOne> so I sent them both on different days friendly PM's and next time I will remove/ban for a few days.
[21:39] <ikonia> hello RoyK thank you for joining
[21:40] <ikonia> RoyK: I didn't want to take up any more space in #ubuntu-server for this short discussion
[21:40] <ikonia> RoyK: I just wanted to ask you to use common sense in the ubuntu channels about swearing, there is no pre-defined set of words, however if your unsure of what is acceptable in polite conversation, I suggest you stick to using words you would use in a job interview
[21:41] <ikonia> is that clear/acceptable ?
[21:58] <ikonia> RoyK: you there ?
[23:30] <Jordan_U> !clone
[23:32] <Jordan_U> I would expect that most users would have some multiarch packages, does it really make sense to keep the factoid instructions as-is if it might (will?) break with the majority (maybe I'm wrong about that) of configurations?


[04:37] <StevenK> wgrant: Finally, but the code is *HORRIBLE*
[04:38] <StevenK> wgrant: http://pastebin.ubuntu.com/5886428/
[04:41] <wgrant> StevenK: That looks quite reasonable.
[04:46] <StevenK> wgrant: I haven't shown you the auditor code yet
[04:47] <wgrant> I have read approximately two lines of auditor code ever
[04:47] <StevenK> wgrant: http://pastebin.ubuntu.com/5886439/
[04:49] <wgrant> Why are OBJ and OPER in ALLCAPS, and why is the SQL not formatted? :)
[04:49] <wgrant> Oh
[04:49] <wgrant> They're replaced, I see...
[04:49] <wgrant> Are you sure you can't do something more sensible?
[04:50] <StevenK> I'm not sure, no.
[04:55] <StevenK> wgrant: A quick googling shows even more hideous solutions, so it works
[05:48] <StevenK> wgrant: So I should release auditor{,fixture,client} and push my changes for export-pu-auditor?
[05:51] <wgrant> StevenK: How is the test situation?
[05:52] <StevenK> wgrant: http://pastebin.ubuntu.com/5886563/
[05:54] <wgrant> [05:55] <wgrant> 'distinct' might be better called 'latest'
[05:58] <StevenK> wgrant: Blah, that requires changes to auditor{,fixture,client}
[05:58] <wgrant> Sure
[05:58] <wgrant> But 'distinct' really doesn't say anything at all
[06:00] <StevenK> wgrant: So it does address your concerns about a test?
[06:00] <wgrant> StevenK: I'm more wondering about testing the divergent postgresql and sqlite3 implementations
[06:00] <StevenK> I'm not sure how to test the postgresql implementation
[06:01] <StevenK> Requires having postgres around and configured so $USER can create a db
[06:07] <StevenK> wgrant: Not sure if I can reach into Django's innards and convince it to change the default db. Or if I can configure a postgres db in runtests.py with things like 'user': environ['USER']
[06:07] <wgrant> I'm not sure
[06:07] <wgrant> But having a way to test that the production code works might be nice...
[06:08] <StevenK> I've tested it by hand, at least, but I know that isn't what you mean.
[12:27] <pindonga> hi,  I'm trying to troubleshoot an issue with a user getting a different openid from launchpad than from Ubuntu SSO
[12:27] <pindonga> is it possible to check if this user has merged accounts recently?
[12:27] <pindonga> is this the right channel for that?


[19:18] <rockclimbuk> Hi all
[19:18] <rockclimbuk> I'm looking at packaging Gephi for ubuntu, and am making a start on the dependencies
[19:18] <rockclimbuk> Is it best to get these committed to ubuntu, or to get them into debian first?
[21:07] <persia> Best to get them into Debian, as it means they work for both Debian and Ubuntu for half as much work.
[21:10] <rockclimbuk> Thanks


[13:51] <ricotz> so do we want a dedicated nvidia ppa? aka "ppa:graphics-drivers/nvidia"
[13:51] <mamarley> I set that version a long time ago to keep my own packages ahead of other packages of the same driver version so I didn't need to recompile and reboot multiple times when a new driver was released.
[13:51] <mamarley> Back then, it was just a personal thing and I never expected anyone else to actually use it.
[13:52] <mamarley> ricotz: I think so.
[13:52] <tjaalton> why driver specific ppa's?
[13:52] <ricotz> not sure, that is why I am asking ;)
[13:52] <tjaalton> I don't see a point
[13:53] <ricotz> "ppa:graphics-drivers/ppa" is fine for me
[13:53] <mamarley> I guess I don't have any logic behind my opinion, so just one PPA is fine.
[13:53] <tseliot> ricotz, mamarley: I've just pushed my 355 code
[13:54] <mamarley> I had also been packaging the latest version of libvdpau and vdpauinfo.  Should that go in the same PPA or a different one?  Or not under this team at all?
[13:54] <tjaalton> if this place will also get backported mesa + llvm, then I hope we could ditch the stupid renaming business on lts-stacks
[13:54] <tseliot> still on github
[13:54] <tjaalton> which is nothing but pain
[13:55] <tjaalton> assuming enough people use it and file issues which get fixed early enough for "blessed" backports in the main lts repo
[13:55] <tseliot> mamarley: where does come from? (debian?)
[13:56] <mamarley> tseliot: The VDPAU packages?  I based those on what is already in Ubuntu, just new upstream releases.
[13:56] <tseliot> and yes, a non-driver-specific ppa would be better
[13:56] <ricotz> I am going to copy libvdpau from edgers too
[13:57] <mamarley> So should I create a separate PPA under this team for VDPAU stuff then?
[13:57] <ricotz> tseliot, vdpau is pretty much connected since it will be removed from the blob soon
[13:57] <tjaalton> mamarley: imo no
[13:57] <ricotz> mamarley, no
[13:57] <mamarley> OK
[13:57] <tjaalton> if it's supposed to be a one-stop place for "everything" driver related
[13:57] <tseliot> yes, using the same PPA makes sense
[13:57] <mamarley> OK, that works.
[13:59] <tseliot> ricotz: https://github.com/tseliot/nvidia-graphics-drivers/tree/355
[13:59] <ricotz> tseliot, got it
[13:59] <tseliot> ricotz: you might want to rebase on that
[13:59] <ricotz> i know
[14:01] <ricotz> jcastro, could you ask for more ppa space and armhf support?
[14:01] <ricotz> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages
[14:01] <jcastro> sure, how does that work, I file a bug?
[14:01] <tseliot> 352 is still stuck in NEW in wily...
[14:02] <ricotz> jcastro, a question against "launchpad"
[14:02] <ricotz> jcastro, or ask wgrant ;)
[14:02] <jcastro> ack
[14:02] <jcastro> on it!
[14:02] <ricotz> thanks
[14:02] <jcastro> feel free to task me with all the administrative work
[14:03] <mamarley> Are we going to keep using the "-0ubuntu0~xedgers15.10.1"-style version string?  (Just wondering for when I upload new versions.)
[14:03] <ricotz> jcastro, a nice ppa desciption too? ;P
[14:04] <jcastro> ok, I'm on it
[14:05] <ricotz> mamarley, no, i guess "-0ubuntu0~gpu15.10.1", to simplify is a bit
[14:05] <mamarley> ricotz: OK, got it.  Thanks!
[14:07] <mamarley> If you guys want me to handle the day-to-day uploads of new driver releases, that would be fine.  I check for updates every morning, so my response time is quite fast.
[14:07] <tseliot> that would be nice
[14:07] <jcastro> https://answers.launchpad.net/launchpad/+question/270278
[14:08] <mamarley> OK, great.  I will handle that then.
[14:08] <tseliot> thanks
[14:09] <ricotz> mamarley, alright, let us know when you before you start to avoid clashes
[14:10] <mamarley> ricotz: OK, sure thing.
[14:10] <tseliot> good
[14:10] <ricotz> mamarley, you know how to create a proper package?
[14:11] <mamarley> ricotz: I think so, but now I am doubting.
[14:11] <tseliot> do you mean a new flavour?
[14:11] <ricotz> mamarley, you didnt use a orig-tarball iirc
[14:11] <tseliot> as in -355, -390, etc
[14:12] <tseliot> oh, that (.orig) would save bandwidth
[14:12] <mamarley> ricotz: I wasn't.  What is the procedure for that?  I had only used .orig tarballs before when upstream actually shipped one.
[14:13] <ricotz> look into one e.g. for 355 and recreate it like that, and use it as usual
[14:14] <ricotz> of course include amd64, i386 and armhf bins
[14:14] <ricotz> bbl
[14:15] <mamarley> But PPA uploads are source-only right?
[14:15] <tseliot> what do you mean?
[14:15] <ricotz> the "bins" provided by nvidia should be in the orig tarball
[14:15] <tseliot> the .run installers
[14:16] <mamarley> OK
[14:16] <mamarley> But the current packages don't include armhf, do they?
[14:16] <tseliot> they do
[14:16] <tseliot> there's an easy way to do it
[14:17] <tseliot> 1) enter the directory with the source (e.g. nvidia-graphics-drivers-355)
[14:17] <tseliot> 2) download the installers by doing: debian/rules get-orig-source
[14:18] <tseliot> 3) create a tarball that only contains the 3 installers and excludes the debian and .git directory
[14:18] <mamarley> So the .run files should be in the root directory of the archive?
[14:20] <tseliot> the archive will contain a directory e.g. nvidia-graphics-drivers, which, in turn, contains the .run files
[14:20] <mamarley> OK
[14:21] <tseliot> mamarley: follow the name scheme of the other orig tarballs and you'll be all set
[14:22] <mamarley> Thanks!  That does sound easier than what I was doing.
[14:22] <tseliot> :)
[14:22] <mamarley> And soon I will likely be getting Google Fiber so I won't have to wait hours for the packages to upload either!
[14:22] <jcastro> rub it in!
[14:23] <jcastro> so hey guys, where's the git source to the packages? I'd like to refer them in the description
[14:23] <tseliot> mamarley: then, only for your first upload, build with "debuild -S -sa" (so as to include the orig tarball). For the next uploads that use the same tarball you can create the sources using just "debuild -S", so that you won't have to reupload the orig tarball
[14:23] <mamarley> tseliot: OK, but I will still need to reupload the orig.tar for new upstream releases, right?
[14:24] <tseliot> my sources are here: https://github.com/tseliot/nvidia-graphics-drivers  (look for the different heads, not master)
[14:24] <tseliot> mamarley: correct
[14:25] <tseliot> mamarley, ricotz: you might want to set up a git repository (you choose where) for the packaging scripts, so that you can pull in my changes and add yours
[14:28] <mamarley> Sure, I can just fork that repository.
[14:31] <mamarley> tseliot: ricotz: OK, I forked it to https://github.com/mamarley/nvidia-graphics-drivers/ and added push access for ricotz.
[14:32] <tseliot> mamarley: thanks
[14:44] <mamarley> tseliot: Should I put my vdpauinfo 1.0 package in ppa:graphics-driver/ppa too?
[14:45] <tseliot> mamarley: sure
[14:46] <mamarley> OK, will do.
[14:46] <ricotz> tseliot, did you tested and built the kernel module of 355 on i386?
[14:46] <ricotz> (with you packaging)
[14:46] <tseliot> ricotz: probably not (I can't remember) but those changes mostly come from NVIDIA
[14:47] <ricotz> tseliot, i could be wrong but this likely fails
[14:47] <tseliot> ricotz: where exactly?
[14:47] <ricotz> while it will try to build the uvm module on i386 too
[14:47] <jcastro> ricotz: space sorted, thanks to wgrant
[14:47] <ricotz> jcastro, great
[14:48] <tseliot> ricotz: let me check
[14:48] <ricotz> tseliot, the module source is taken from the amd64 pack
[14:49] <ricotz> passing -jX isnt useful imo
[14:50] <ricotz> tseliot, also please tweak the kernel 3.18 patch as i suggested
[14:52] <tseliot> ricotz: right, the new build system builds all modules by default. I need to use NV_EXCLUDE_BUILD_MODULES=''
[14:53] <tseliot> ricotz: can you point me to that change (for 3.18) again, please? (too much stuff on my plate...)
[14:53] <ricotz> tseliot, look at the edgers package
[14:53] <tseliot> ricotz: ok
[14:54] <ricotz> regarding the uvm problem too
[14:55] <tseliot> ok
[14:56] <tseliot> ricotz: do you have a git repository too?
[14:58] <ricotz> tseliot, just a local private one
[14:59] <tseliot> ok
[14:59] <ricotz> I won't rebase/update the 355 packages then ;)
[15:03] <mamarley> Also, were we going to make some sort of staging PPA to upload things to initially and then copy them once they are built and tested?
[15:04] <tseliot> ricotz: I've just downloaded nvidia-graphics-drivers-355 (355.06-0ubuntu0~xedgers15.10.1), and I don't see the uvm work
[15:05] <tseliot> mamarley: a staging ppa sounds like a good idea
[15:05] <mamarley> Is there any way to make it hidden so people don't try to use it?
[15:06] <tseliot> that would have to be a private PPA. jcastro ^^
[15:06] <jcastro> is private the best thing to do?
[15:06] <jcastro> or just really big warnings?
[15:07] <tseliot> whatever you're more comfortable with, guys
[15:07] <mamarley> Either one is fine with me.
[15:07] <jcastro> I would prefer to keep everything open, with just clear warnings that the staging area is for developers and not end users
[15:08] <mamarley> Sure
[15:08] <tseliot> ricotz: oh, you meant to say that you didn't do that kind of work, and that pulling in the new work will break it. I'll fix and test that soon
[15:08] <ricotz> tseliot, a plain diff http://paste.debian.net/plain/291679
[15:09] <ricotz> "nv-kernel.o_binary" is correct I think
[15:09] <ricotz> mamarley, jcastro, warnings dont help
[15:10] <jcastro> yeah that's fine
[15:10] <ricotz> mamarley, testing things locally as good as possible
[15:10] <jcastro> unless you really think the other way is better
[15:10] <tseliot> ricotz: ok, I'll have a look at it tomorrow, thanks
[15:10] <jcastro> I don't feel strongly about it either way
[15:10] <mamarley> ricotz: Of course, but I don't have much in the way of hardware on which to test yet.
[15:10] <ricotz> maybe disable ppa publishing before starting a new upload
[15:11] <mamarley> That would make it harder to test on my own systems.
[15:11] <ricotz> mamarley, meaning check the kernel modules and such, and a runtime check
[15:11] <mamarley> I always install them on my laptop before uploading.
[15:12] <ricotz> much more isn't possible and this ppa is meant to get things tested
[15:12] <ricotz> user won't be automatically transitioned to newer beta series
[15:12] <mamarley> So no staging PPA then?
[15:13] <ricotz> e.g. make sure to drop all "transitional" packages before uploading
[15:13] <ricotz> mamarley, i dont see much of a point for one
[15:13] <mamarley> OK.  I never put transitional packages between major releases.
[15:14] <ricotz> the ubuntu package contains some, so those should be stripped
[15:14] <mamarley> OK.
[15:14] <ricotz> tseliot, alright
[15:15] <mamarley> Which are they?  I am looking at 346 and 352 and not seeing any transitional packages.
[15:17] <ricotz> mamarley, http://launchpadlibrarian.net/212442914/nvidia-graphics-drivers-352_352.21-0ubuntu1_source.changes
[15:17] <ricotz> tseliot, make sure those don't land in the archive http://launchpadlibrarian.net/214273992/nvidia-graphics-drivers-legacy-340xx_340.76-6_amd64.changes
[15:17] <mamarley> Ah, OK.  It looks like those have already been removed for the PPA builds though.
[15:18] <ricotz> right, as I said
[15:18] <mamarley> Sorry
[15:18] <ricotz> alright, so much for x stuff today
[15:22] <tseliot> ricotz: I don't see how they could end up in the archive, since I'm not going to upload 355, and I'm the only maintainer ;)
[15:22] <tseliot> ricotz: oh, that
[15:22] <ricotz> tseliot, I am talking about the syncs from debian
[15:22] <tseliot> :/
[15:24] <ricotz> mamarley, use https://launchpad.net/ubuntu/+source/vdpauinfo/1.0-1
[15:24] <tseliot> ricotz: I've just asked in #ubuntu-release
[15:24] <mamarley> ricotz: Yeah, I just realized my dependencies are goofed up.  Just a sec...
[15:25]  * ricotz really gone now
[15:34] <ricotz> mamarley, :\ dont override existing ubuntu packages
[15:35] <ricotz> in this case "1.0-1~gpu14.04.1"
[15:36] <ricotz> mamarley, don't hesitate to ask and wait a bit
[15:36] <mamarley> I'm really sorry.
[15:37] <ricotz> and still there is also precise ;)
[15:38] <mamarley> OK, I will fix the version and upload for Precise.
[15:38] <ricotz> mamarley, you cant fix the version
[15:38] <ricotz> it would be lower which doesnt work anymore now
[15:38] <mamarley> I should be able to for precise because I haven't uploaded the incorrect version yet.
[15:39] <ricotz> for precise yes
[15:39] <mamarley> So I have "vdpauinfo (1.0-1~gpu12.04.1) precise; urgency=medium", is that OK to upload?
[15:39] <ricotz> yes, and still works in regard of the other versions
[15:40] <ricotz> but wait until the libvdpau is published to avoid a failure/dep-wait
[15:40] <mamarley> OK, I will upload it after lunch.  Sorry for the trouble.
[15:40] <ricotz> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages?field.name_filter=vdpau&field.status_filter=published&field.series_filter=
[15:40] <jcastro> so hey guys, will kind of brings up a good point
[15:41] <jcastro> if we want to convince the TB to allow a GUI hook from the driver tool to a PPA, they're going to want to know it's tested
[15:41] <jcastro> so maybe doing a staging thing would be a good idea, if anything to show that we break there first?
[15:59] <mamarley> That's fine with me; I don't have a strong opinion one way or another.
[21:37] <tjaalton> filed https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279
[21:37] <tjaalton> feel free to modify [Changes]
[21:39] <tjaalton> or anything really


[03:33] <fonz> why is there an amazon icon in 16.04
[08:59] <lordievader> Good morning
[12:28] <BluesKaj> Hiyas all