[07:24] <poolie> hi there mgz
[07:40] <vila> hello  there !
[07:59] <mgz> morning!
[08:03] <poolie> hi mgz, jelmer, vila
[08:03] <poolie> shall we talk?
[08:04]  * vila mumbles
[08:04] <mgz> I'm on.
[08:23] <lifeless> jelmer: hi, around /
[08:30] <hrw> hi
[08:30] <hrw> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 23: ordinal not in range(128)
[08:30] <hrw> I got this during merge
[08:31] <hrw> http://pastebin.com/1VqWu9Ag to be exact
[08:41] <mgz> hrw: not a very useful traceback that, sec
[08:42] <hrw> mgz: I know.
[08:42] <mgz> what's merge_changelog.py ? It's not the changelog-merge plugin.
[08:43] <mgz> ah, in bzr-builddeb
[08:43] <hrw> moment
[08:43] <hrw> /usr/share/pyshared/bzrlib/plugins/builddeb/merge_changelog.py
[08:43] <mgz> what's your line 73 in that?
[08:43] <hrw> 2.7.9ubuntu1 version from precise
[08:44] <hrw> gnome-terminal suxx when it comes to copy/paste ;(
[08:45] <hrw>             _logger.warning('%s', stderr)
[08:45] <hrw>             # Relay the warning from dpkg-mergechangelogs to the user.  We
[08:45] <mgz> okay, I have that on the tag too.
[08:46] <hrw> I merged lp:ubuntu/gcc-4.6 into lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes
[08:46] <mgz> hrw: file a bug, looks like the log statement is just slightly borked
[08:46] <hrw> ok, thx
[08:47] <mgz> I think all you lost was the detail output from dpkg-mergechangelogs', base_filename, this_filename, other_filename], stdout=sub
[08:47] <mgz> ...bad paste
[08:47] <hrw> mgz: bzr diff after merge tells me that whole changelog was dropped
[08:50] <mgz> I want to say do `bzr remerge debian/changlog` but I'm not certain that will do the right thing with builddeb
[08:50] <hrw> may try
[08:51] <hrw> did not
[08:51] <mgz> same problem, or different one?
[08:51] <hrw> http://paste.ubuntu.com/745683/
[08:51] <mgz> ta.
[08:51] <mgz> okay, that's good.
[08:52] <hrw> so bug against bzr-builddeb?
[08:52] <mgz> yeah, but I can give you a patch to try now so you can see the output
[08:52] <hrw> ok
[08:54] <hrw> btw - how to tell bzr that I solved conflicts in files?
[08:54] <mgz> ...hm, simplest thing is problably, change the logger line to:
[08:54] <jelmer> hrw: "bzr resolved"
[08:54] <jelmer> lifeless: hi
[08:54] <hrw> jelmer: thx
[08:54] <mgz>     _logger.warning('%s', stderr.decode("utf-8","replace"))
[08:54] <mgz> just for now
[08:55] <mgz> I'll work out how to make the logging module do something sane later
[08:55] <lifeless> jelmer: nvm - see #subunit
[08:56] <mgz> hrw: so, if you want try editing merge_changelog.py with that and then remerge
[08:57] <hrw> debian/changelog is not conflicted
[08:57] <hrw> dpkg-mergechangelogs: ostrzeżenie: /tmp/tmpKJKi6cdeb_changelog_merge/changelog.this(l0): oczekiwano first heading, a znaleziono koniec pliku
[08:57] <hrw> dpkg-mergechangelogs: błąd: ss-970814-1 is not a valid version
[08:57] <hrw> All changes applied successfully.
[08:57] <hrw> shit. forgot LC_ALL=C
[08:57] <hrw> anyway still 10K -
[08:57] <mgz> it's okay, the messages are for your benefit :)
[08:58] <hrw> btw - are there plans for 'bzr diff --stat'?
[08:58] <hrw> bzr diff|diffstat is longer to write ;)
[08:58] <poolie> that would be good
[08:59] <mgz> okay, so one issue is the logging is borked, the other seems to be that a failure from dpkg isn't resulting in a conflict you could try and resolve via other means
[09:00] <mgz> jelmer may know more.
[09:00] <hrw> poolie: and may give 'bzr log --stat' which in git land is one of my favorite
[09:02] <jelmer> are we standing up?
[09:02] <mgz> I am!
[09:03] <hrw> ok, /me -> reporting bug
[09:03] <mgz> ...we did it at 8 I'm afraid jelmer
[09:04] <mgz> hrw: thanks, include all your bits, especially the ostrze◈enie parts
[09:05] <hrw> sure
[09:06] <mgz> jelmer: we need a part 2 to get your update maybe
[09:06] <jelmer> mgz: oh crap, I didn't realize we had a DST change :-(
[09:07] <mgz> we were ignoring it the last few weeks as poolie wasn't around, which was probably confusing
[09:09] <poolie> ah oops
[09:09] <poolie> i can try to be away next tuesday :)
[09:09] <mgz> ehehe
[09:10] <hrw> mgz: bug 893495
[09:12] <vila> jelmer: the pad is at http://pad.ubuntu.com/bdhvpZX7Hn if you want to update it
[09:12] <vila> jelmer: if you don't, just tell me and I'll post it to the ml
[09:13] <hrw> mgz: I hope that I did not forgot anything
[09:15] <mgz> hrw: thanks, that should do (though you used LANG=C so it hides why the logging failed!)
[09:17] <hrw> mgz: no, message is same but now more people may understand it
[09:18] <mgz> hrw: attaching the changelog.this might help understand why dpkg is failing, it gets removed but...
[09:18] <hrw> mgz: there is no 'changelog.this' or changelog.BASE etc
[09:18] <mgz> hrw: yes, that's good, but the reason logging failed was because your locale has non-ascii error messages
[09:18] <mgz> hrw: yes, because the merge wrongly reports it succeeded
[09:19] <hrw> mgz: ok, will add
[09:19] <hrw> added comment
[09:20] <mgz> if you `bzr --no-plugins remerge debian/changelog` what happens?
[09:20]  * mgz hasn't played enough with bzr-builddeb yet to know all its tricks
[09:21] <hrw> debian/changelog is not conflicted
[09:21] <hrw> Text conflict in debian/changelog
[09:21] <hrw> 1 conflicts encountered.
[09:21] <hrw> mgz: cool!
[09:21] <mgz> that's better, do you now have a .THIS?
[09:22] <mgz> just attaching the raw changelog with conflict markers may be useful.
[09:24] <hrw> I have BASE/THIS/OTHER
[09:25] <hrw> attached all of them
[09:25] <mgz> great!
[09:25] <mgz> hopefully you can now manually resolve the conflict and continue working.
[09:26] <hrw> yep
[09:26] <hrw> thx for help
[09:29] <mgz> ...and naturally dpkg-mergechangelog works fine on those files for me, so the bug is somewhere else
[09:30] <hrw> mgz: I will push my branch to LP so you can try it on your system
[09:30] <jelmer> vila: updated
[09:31] <vila> hehe, you mean updat*ing* :)
[09:31] <hrw> mgz: pushed, remember to use r71 not head
[09:32] <jelmer> vila: no, really done now :)
[09:32] <vila> ok :) Thanks !
[09:36] <mgz> I guess changelog.this is 0 bytes in /tmp it's not clear how that happened
[09:37] <mgz> also I get *some* output like that, and one of the three copies has to have content or you wouldn't get the complaint about the version number from 1997
[09:38] <jelmer> vila: hpss-branch-store branch submitted :)
[09:54] <mgz> the great thing about unix tool naming conventions is you can accidentally have your hand over the wrong place on the keyboard, and you'll still end up running something
[09:55] <mgz> I wanted vi back, and got information about my disk usage instead, thanks unix!
[10:04] <jelmer> :)
[10:40] <vila> jelmer: reviewed, small tweaks, but big +1 overall and many thanks
[10:41] <jelmer> vila: that was quick :) Thanks
[10:42] <vila> jelmer: hehe, the context was paged in, it helped ;)
[10:43] <vila> jelmer: and I trust the tests are robust enough :)
[10:45] <jelmer> :-)
[10:45] <jelmer> sigh, this is the last time I'm buying cheap post-it notes. My real-life kanban board is coming apart
[10:47] <mgz> jelmer: I wouldn't blame the post-its
[10:48] <mgz> the number of mps you've submitted would tax any glue
[10:48] <mgz> the board must be about ready to collapse
[10:50] <jelmer> mgz: I hope not. I'm using one of the load-carrying walls here.. ;-)
[10:58] <jelmer> mgz: you seem to have a couple of approved branches, btw
[11:17] <mgz> jelmer: thinking of commit messages is hard?
[11:17] <mgz> I mean, sure, I'll get them landed. :)
[11:18] <LeoNerd> I sometimes find the trick with commit messages is managing to get them brief enough
[11:18] <LeoNerd> I have a tendancy sometimes to waffle on a bit
[11:20] <mgz> jelmer: what's the protocol for unprivating? bug 876511 is interesting and doesn't seem to have any personal info.
[11:20] <mgz> how little you know, ubot5
[11:20] <jelmer> mgz: :)
[11:21] <jelmer> LeoNerd: Hah, I have the opposite
[11:21] <jelmer> LeoNerd: which is also problematic
[11:21] <jelmer> mgz: basically, if it doesn't contain any private info, feel free to unprivatize it
[11:21] <jelmer> I think apport creates private bugs by default
[11:22] <mgz> some part of the testament code is getting a bytestring and thinking it's unicode
[11:23] <jelmer> that's bad
[11:23] <mgz> I'm not sure which though :)
[11:23] <mgz> what does tree.list_files return for paths?
[11:24] <mgz> revision-ids would be possible but... seems unlikely
[11:24] <mgz> revprops is the other candidate
[11:26] <mgz> list_files uses os.listdir which is always a bad sign.
[11:28] <jelmer> vila: I'm not sure I understand your last comment on hpss-branch-store
[11:28] <vila> the one about adding comments ?
[11:29] <jelmer> vila: yeah, about RemoteBranchStack and cmdline overrides
[11:29] <vila> these stacks are... weird/obscure, the comments intend to clarify why they exist at all
[11:29] <jelmer> vila: what kind of comment would you like me to add?
[11:30] <vila> the ones I pasted should be enough to raise awareness that there is something going on with these stacks
[11:31] <jelmer> vila: but do you want me to add comments to hpss-branch-store, or were you just providing context?
[11:32] <vila> just adding comments before the classes
[11:32] <vila> so people don't think they can use them
[11:32] <vila> they are a symptom that something else need to be fixed
[11:33] <jelmer> vila: actually, I'm not sure I understand why the other stores aren't in there
[11:33] <jelmer> vila: it seems like the global and location stores would apply for remote branches too
[11:34] <vila> doing so means the local user can enforce some policies on the remote server
[11:34] <jelmer> vila: the policies aren't sent to the remote server, so nothing will be done that the user isn't already allowed to
[11:35] <jelmer> vila: i.e. I have lines like this in my locations.conf:
[11:35] <jelmer> [bzr+ssh://bazaar.launchpad.net/*]
[11:35] <jelmer> child_submit_to =<EMAIL_ADDRESS>[11:35] <vila> the policy depends on the config option
[11:36] <jelmer> vila: can you give an example of where it would be problematic?
[11:36] <vila> for some options it's ok to give control to the user, for some others, the actual code don't give this control
[11:36] <vila> don't turn the tables :)
[11:36] <vila> I'm merely respecting what the code does ;)
[11:37] <vila> another way to look at it is to think about the *server* locations.conf and bazaar.conf files which lp doesn't define but that other servers can
[11:38] <vila> and think about the (weird and maybe useless) case where a server can be accessed as a smart server *and* as a dumb server
[11:38] <jelmer> vila: The existing code does look at locations.conf
[11:38] <vila> for the options I mentioned in the comments ?
[11:39] <jelmer> vila: no, but for other options - like child_submit_to, or remote_ssh_path
[11:39] <vila> right, these stacks aren't used for the other options :)
[11:40] <mgz> nope, can't repo it, filenames and properties seem fine
[11:40] <jelmer> vila: I don't see how remote_branch.get_config_stack().get("child_submit_to") can look in locations.conf
[11:41] <vila> argh, then your proposal is bogus and I failed to see that
[11:42] <jelmer> vila: how do you imagine it will be able to look in locations.conf ?
[11:42] <vila> it should use a BranchStack but query the branch for the right store
[11:42] <jelmer> vila: that's what I was proposing earlier :)
[11:43] <vila> yeah and I agreed with that, I missed it when reviewing, lack of tests too
[11:43] <jelmer> vila: I still don't really see where your comments about branch_only_stacks come in
[11:43] <vila> you're right in to the trap
[11:43] <vila> you used the wrong stack
[11:43] <vila> well, somehow
[11:44] <jelmer> vila: used the wrong stack where?
[11:45] <vila> RemoteBranch.get_config_stack() should use config.BranchStack(),
[11:45] <vila> and config.BranchStack should ask the branch for the right store
[11:45] <vila> RemoteBranchStack should be used only for stacked_on_location
[11:46] <vila> and I don't know if RemoteBzrdir.get_config_stack() should be defined at all... it's likely to cause the same kind of confusion
[11:47] <vila> jelmer: does that make sense ?
[11:48] <jelmer> vila: yep
[11:49] <vila> jelmer: pfew, thanks :)
[11:49] <vila> these are existing grey areas that concern only those two options afaik
[11:50] <vila> which I why I defined these stacks without using them yet as a reminder that these options are... special
[11:51] <vila> .. in the existing code I mean
[11:51] <jelmer> vila: I think Remote{Branch,Control}Stack is a really confusing name in this case though
[11:52] <vila> yeah, in this other proposal I was naming them control_stack_only and remote_branch_only
[11:53] <vila> or rather control_only_stack and branch_only_stack, anyway, 'only' is the important part ;)
[11:53] <vila> even cmdline_overrides shouldn't apply there... I think :)
[11:55] <vila> the specific aspect that is not clear in the actual config scheme is option policy, stacks helps a bit, but really, what defines an option policy is which stack is used to handle them in the code,
[11:56] <vila> some options are handled with GlobalStack, some are handled with BranchStack for example
[11:56] <jelmer> vila: updated
[11:59] <jelmer> vila: I've now just changed BranchStore to call Branch._get_config_store(), and bzrlib.remote doesn't have anything related to stacks anymore
[11:59] <vila> reading already
[12:13] <vila> right, bzr config -d lp:xxx now displays bazaar.conf content, I should have thought to check that
[12:18] <jelmer> I thought it always did that?
[12:18] <jelmer> that seems right to me
[12:20] <vila> taking your previous example, `bzr config  child_submit_to` would be broken if it was
[12:21] <jelmer> vila: ah, sorry. You mean it only displays bazaar.conf content
[12:22] <vila> no, I mean it now displays branch.conf *and* bazaar.conf (nothing relevant in locations.conf so nothing is displayed) instead of only branch.conf
[12:22] <jelmer> vila: it never displayed just branch.conf
[12:23] <jelmer> vila: if I only have bzr_remote_path set in bazaar.conf it would previously show that too
[12:23] <vila> jelmer: it did with revno 6284 if your proposal
[12:23] <vila> s/if/in/
[12:23] <vila> when doing  ./bzr config -d lp:~jelmer/bzr/switch-colocated
[12:23] <jelmer> vila: r6284 of my proposal is wrong :)
[12:24] <vila> yes
[12:24] <vila> oh, sorry, I was so unclear
[12:24] <vila> what I meant is that I could have use that to see 6284 was wrong
[12:24] <jelmer> ah
[12:24] <vila> because it wasn't displaying bazaar.conf anymore
[12:29] <vila> jelmer: done, some last nits if you feel like taking them into account
[12:29] <vila> well, at least the news entry one :)
[12:29]  * vila lunch
[12:58] <jelmer> vila: merci et bon appetit :)
[12:58]  * jelmer has a somewhat limited French vocabulary
[13:03] <vila> jelmer: you've already got the most important ones :) ... "Je vous aime" can help in many situations too ;-D
[13:07] <jelmer> hehe
[13:08] <jelmer> French is the main language of one of the other projects I'm involved in (OpenChange), so I do read quite a bit of it.
[14:27] <mull> jelmer, hi, thanks for looking at my fastimport patch; I've just proposed a merge.  Feel free to ping me here if you have questions.
[14:48] <jelmer> mull: thanks. I've just followed up
[14:50] <mull> ok.  oops, I had completely forgotten that I left an "assert" in there... that's not ideal
[16:05] <mgz> have, that's a nice suprise,
[16:05] <mgz> 5 second runtime down to 2 second runtime
[16:05] <mgz> that will make a 0.0001% to the build process
[17:06] <GRiD> hm. in general, a bzr import from mercurial (on google code) to launchpad should work? looks like bzr 2.5.0 according to this error log.
[17:09] <jelmer> GRiD: it's still in beta, and far behind git/svn imports
[17:11] <GRiD> jelmer, ok. well, i used the standard launchpad interface for doing the import. is it worth filing a launchpad bug?
[17:15] <GRiD> actually, i see there is one. bug #806904
[18:45] <mull> jelmer, now I know why I wrote the code how I did... when you say "bzr fast-export x..y", revisions up to and including x are _already_ chopped off
[18:45] <mull> so my code was getting the parent of revision x+1
[18:45] <mull> funny that I couldn't remember that 24 hours later, and it took writing the test case to realize
[21:15] <Noldorin> hi folks
[21:15] <jelmer> hi Noldorin
[21:15] <Noldorin> hi jelmer
[21:15] <Noldorin> how's it going?
[21:53] <jelmer> Noldorin: I'm alright. how are you?
[21:55] <Noldorin> jelmer, pretty good. going to have a go at a small patch poolie and i were talking about
[22:19] <poolie> hi all
[22:46] <thomi|work_> wgz: sorry for the delay: http://pastebin.com/Bi1ZseQL
[23:04] <wgz> thomi|work_: thanks, it does look like 0.61 triggered a lot of this pain then, because the 'ours' old and new values are different there
[23:05] <wgz> thomi|work_: <http://float.endofinternet.org/temp/pageant.zip> is a non-debug pageant with the fix


[00:07] <nhandler> nhaines, pleia2: Managed to get $work to send me to Scale 14x/DevOps Days LA \o/
[00:08] <pleia2> nhandler: yay!
[00:08] <pleia2> I'll be speaking at devops days la, but will likely go back to ubucon after my talk
[00:12] <nhandler> pleia2: I'll be sure to attend your talk. Will definitely try to spend time at Ubucon, but will probably have to report back on a few of the devops talks for people at work.
[00:12]  * pleia2 nods
[00:12]  * nhandler adds this to his growing list of trips he has to book flights/hotels for
[00:13] <pleia2> hehe
[00:13] <Adran> Hello!
[00:13] <Adran> I'm back!
[00:13] <pleia2> I'm flying into burbank, a little more expensive than LAX but much shorter cab ride (especially if there's traffic, because LA)
[00:14] <pleia2> and more expensive was like 210 rather than 180, will likely make up for it in cab expenses :)
[00:15] <pleia2> hi Adran
[00:15] <Adran> hi pleia2
[00:15] <Adran> Are you going to be at SCALE again this year?
[00:15] <pleia2> Adran: yep
[00:15] <Adran> sweet
[00:16] <pleia2> you?
[00:16] <Adran> yeah
[00:16] <pleia2> I missed last year, so it'll be nice to be back
[00:16] <Adran> along with 100+ people from my lug
[00:16] <pleia2> woo
[00:16] <Adran> feel free to crash our group photo :P
[00:16] <Adran> we also have a booth, so feel free to say hi
[00:17] <pleia2> haha, let me know where+when!
[00:17] <pleia2> cool, will do
[19:02] <nhandler> pleia2: I'm starting to feel your airline choosing pains (at a much lower level). Debating between United (which I don't really care for) to BUR or Virgin (which I like) to LAX. Decisions, decisions, decisions :)
[19:03] <pleia2> Virgin is nice (only 4 star in the US!), but their FF programs are not awesome (and non-existant for int'l(
[19:04] <pleia2> still, I fly them sometimes as a one off for quick trips sometimes :)
[21:20] <nhandler> Well, United just helped me make up my mind. I only had my middle initial listed, and changing it to use my full middle name will take ~2 weeks. This means no TSA Pre. I guess I'm flying Virgin to LAX :)
[21:21] <ianorlinqt> hmm middle inital could save the tab autocomplete problem ;p
[21:29] <nhaines> nhandler: glad you're making it to SCALE after all!  :)
[22:24] <nhandler> ianorlinqt: Not really. Middle initial is H, so I would be nhhandler (I guess you only need to type 3 letters then tab instead of 4 though)
[22:24] <nhandler> nhaines: So am I. Let me know if there is anything I can do to help out at this late stage.


[12:27] <CoderEurope> elopio: I'm doing this a_lot today: https://twitter.com/common_squirrel/status/795240102041710592
[12:58] <CoderEurope> Hiya kristbaum o/
[13:57] <kristbaum> Hi CoderEurope o/
[16:57]  * CoderEurope waves
[17:30] <hikiko> hi simosx :P
[17:31] <simosx> hello hikiko
[17:31] <hikiko> how are you?
[17:31] <simosx> I mentioned the talk at ubuntugr. I hope they join.
[17:32] <simosx> Doing well, how are you?
[17:32] <hikiko> good :)
[17:32]  * CoderEurope waves
[17:33] <hikiko> hey CoderEurope
[17:34] <CoderEurope> hikiko: het sup - you doing the plenary summary aswell ?
[17:34] <CoderEurope> **hey
[17:36] <hikiko> CoderEurope, I am not going to join the hangout on air but I will be on irc :)
[17:36] <CoderEurope> hikko, right-h
[17:41] <CoderEurope> Etherpad: http://pad.ubuntu.com/uos-1611-low-graphics-mode-improvements
[17:42] <CoderEurope> 15 minutes to go ,.... https://www.youtube.com/watch?v=WIwI0zFEKqQ
[17:44] <hikiko> thank you, CoderEurope
[17:44] <CoderEurope> hikiko: high five o/
[17:46] <hikiko> :)
[17:47] <popey> hikiko: mic working today? :)
[17:48] <hikiko> yeah popey ... funny thing is it was working yesterday too
[17:48] <popey> oh!
[17:48] <popey> good news then :)
[17:48] <CoderEurope> hikiko:   Some music while we wait ? http://ow.ly/IePs306eJPJ
[17:48] <hikiko> it wasn't muted or disabled and I could verify it works from the ucc
[17:49] <hikiko> it was something related to the pulseaudio daemon, I couldn't restart it after kill
[17:50] <hikiko> I purged the settings rebooted and yeah.. sound was back
[17:50] <CoderEurope> just heard: https://twitter.com/linuxrants/status/798941265043693568
[17:52] <hikiko> popey, there are 8 minutes remaining, should I wait? I can start now if everyone agrees
[17:52] <CoderEurope> hikko, sounds good to me ...
[17:53] <hikiko> 6 to go :)
[17:54]  * CoderEurope arrives by surfboard : https://twitter.com/i/moments/798650934842667008 :)
[17:54] <hikiko> let's wait another couple of minutes and I am going to broadcast :)
[17:57] <CoderEurope> 2 minutes to go .. why not start now ?
[17:58] <hikiko> CoderEurope, people who start watching on the hour might be offset
[17:58] <hikiko> let's wait 1 more minute :)
[17:59] <CoderEurope> well you'll only have 45minutes then - not an hour - anyway the stream says it has started.
[17:59] <hikiko> ok :)
[18:00] <CoderEurope> I see you ...
[18:01] <CoderEurope> QUESTION: Can you put all of the launchpad pages for this in the etherpad please ? x-post...
[18:02] <flexiondotorg> CoderEurope, https://launchpad.net/compiz
[18:03] <simosx> Recent post about this, https://insights.ubuntu.com/2016/09/19/low-graphics-mode-in-unity-7/
[18:03] <flexiondotorg> And here http://www.whizzy.org/2016/09/unity-7-low-graphics-mode/
[18:04] <SebthreeBQM10HD> glad it's working this time hi
[18:09] <teamconvergence1> hi is when we get this on desktop?
[18:09] <flexiondotorg> It is in 16.04.1
[18:09] <flexiondotorg> ANd 16.10
[18:09] <teamconvergence1> Oh this is very good! Am thank you for the respond! :D :D
[18:09] <flexiondotorg> teamconvergence1, It is automatically enabled if software rendering is detected.
[18:10] <flexiondotorg> Or you can manually enable it.
[18:10] <flexiondotorg> See the links above for details.
[18:10] <simosx> My impression is that this is also in the original 16.04 (April) but was just announced much later.
[18:10] <flexiondotorg> simosx, It has evolved since then too.
[18:10] <CoderEurope> "So now ... " that as quick :)
[18:11] <teamconvergence1> who is name of lady nice unity 7 low graphics mode presentation?
[18:12] <flexiondotorg> The presentation is being given by https://launchpad.net/~hikiko
[18:15] <hikiko> start on starting unity7
[18:15] <hikiko> pre-start script
[18:15] <simosx> QUESTION: How do I check if I am running in Low Graphics Mode?
[18:15] <hikiko>     initctl set-env -g UNITY_LOW_GFX_MODE=1
[18:15] <hikiko> end script
[18:15] <CoderEurope> I hear a soft murmur  in the background ...
[18:15] <hikiko> ~/.config/upstart/lowgfx.conf
[18:16] <Trevinho> simosx: echo $UNITY_LOW_GFX_MODE has to be unset
[18:16] <flexiondotorg> simosx, See if the UNITY_LOW_GFX_MODE environment variable is set to 1.
[18:16] <hikiko> UNITY_LOW_GFX_MODE=1 unity --replace ccp&
[18:16] <flexiondotorg> Trevinho, o/
[18:17] <hikiko> /etc/compizconfig/unity-lowgfx.ini
[18:18] <CoderEurope> QUESTION: Are those Warby Parker glasses you are wearing ? Where can I get them ? #random
[18:19] <flexiondotorg> hikiko, Thanks :-)
[18:19] <CoderEurope> bye all
[18:19] <hikiko> thank you everyone for attending the meeting
[18:20] <hikiko> CoderEurope, no :)
[18:20] <hikiko> :p
[18:20] <CoderEurope> hikko, no problem.
[18:20] <hikiko> have a nice evening!
[18:20] <simosx> Thanks for the presentation!
[18:20] <iovi> Thanks for the  presentation !!
[18:21] <hikiko> thanks :)
[18:21] <teamconvergence1> Was interesting session very. Appreciate the presentation.
[18:49] -udsbotu:#ubuntu-uos-convergence- 5 minutes left in this session!
[18:50] -udsbotu:#ubuntu-uos-convergence- 4 minutes left in this session!
[18:51] -udsbotu:#ubuntu-uos-convergence- 3 minutes left in this session!
[18:52] -udsbotu:#ubuntu-uos-convergence- 2 minutes left in this session!
[18:53] -udsbotu:#ubuntu-uos-convergence- 1 minute left in this session!
[18:54] -udsbotu:#ubuntu-uos-convergence- This session has ended.


[04:58] <Chris__> hi
[04:58] <Chris__> my audio is not working after installing lubuntu
[04:58] <tsimonq2> Chris__: Audio in a certain application (Firefox) or in everything?
[04:59] <Chris__> in everything thanks
[05:00] <tsimonq2> Chris__: Hm, I'm unsure
[05:00] <tsimonq2> Is your hardware connected properly?
[05:01] <Chris__> its an old laptop, it was working before i switch to this
[05:03] <tsimonq2> Ah ok.
[05:03] <tsimonq2> Interesting...
[05:04] <Chris__> everything else seems to be working fine except audio
[05:04] <tsimonq2> The people in #ubuntu might have a better answer for this than me
[05:04] <tsimonq2> Apologies, I don't know where to start in helping you irt that...
[05:05] <Chris__> is there anyway to manually update drivers?
[05:05] <tsimonq2> I'm assuming using apt, but I don't know audio devices well
[05:06] <Chris__> ok thanks tho.
[18:48] <whathtle> hello, what's the package to enable java from browser in chrome or firefox?
[20:12] <LuMint> think u need to install a browser plugin for that.


[00:16] <ashtin> hey all i have some questions about this tech i have xubuntu on?
[00:17] <ashtin> its this https://www.reddit.com/r/GatewayUSA/comments/txokch/gwtc1162_installing_linux_mint_and_ubuntu_almost/
[00:19] <ashtin> i have it all happ mostly, i would like to scroll with the screen any ideas fo xfce? cause goo search basicly says no.
[00:20] <ashtin> thanks and stuff too :)
[16:14] <Godcorp> Hi all
[23:45] <nik0n> Anyone around?
[23:56] <tomreyn> nik0n: please ask your actual question directly next time, you'll see whether or not someone is around to answer.


[13:25] <jeoj> i just installed ubuntu one on my mint 14 and the sync progress isn't starting up at all.. it keeps saying file sync in progress, then file sync is disconnected
[13:25] <jeoj> anyone had the same issue using mint?


[02:55] <larsks> rharper: that looks better, yes.
[03:05] <larsks> rharper: although I note that I get KeyError: 'r' when trying to run 'make srpm'...
[03:08] <larsks> ...because I needed PYVER=python2, right.
[03:09] <larsks> Although: I would call it a bug if something declares "template: cheetah" and we continue without producing an error message...
[14:46] <rharper> larsks: thanks for the feedback, we're looking to drop cheetah as a template (there is some code which does fallback if you don't have cheetah but those messages go to logging, which isn't configured for the tool)
[14:46] <rharper> so you're right w.r.t the error; and we're looking to drop cheetah soon
[17:50] <blackboxsw> hiya larsks, do you have any idea what meta package I'd need in centos/7 to setup repositories which would give me access to download python3 system package for oauthlib? I've got epel-release installed, but it doesn't yum search is coming up empty.
[17:51] <blackboxsw> sorry larsks, I should introduce myself. I'm Chad Smith, a recent join to Canonical's cloud-init/curtin team.
[17:52] <larsks> blackboxsw: hi there!
[17:53] <larsks> I know that oauthlib is not available in RHEL.  It may not be in CentOS either.  Let me look.
[17:54] <larsks> blackboxsw: yeah, there is no generally available oauthlib package.
[17:55] <blackboxsw> ok thanks for the confirmation larsks.
[17:55] <larsks> It is available in the openstack repositories (e.g., centos-release-openstack-newton), but you wouldn't normally expect those to be enabled where people are running cloud-init.
[17:56] <rharper> http://oauthlib.readthedocs.io/en/latest/installation.html  says it has a python3 oauthlib
[17:56] <rharper> for redhat
[17:56] <rharper> but that doesn't seam right, I would expected python34 or something
[18:10] <larsks> rharper: we actually include a patch in our cloud-init package specfically to fail gracefully if oauthlib is missing.
[18:10] <rharper> ah, ok
[18:10] <larsks> (we catch the importerror, and then raise an exception later on if something actually tires to call the oauth_headers method)
[18:10] <rharper> we probably want that then
[18:11] <larsks> http://chunk.io/f/c756394a7c91432f8a92fdbad2682fda
[18:12] <rharper> cool
[18:13] <blackboxsw> thanks larsks that works for me. I was just working on setting up a make ci-deps-centos target and I didn't want to rule out installing any dependencies I could get together if they are reasonably available for setting up our test environments.
[18:14] <blackboxsw> so not having python3-oathlib isn't a deal breaker for our CI
[18:14] <larsks> fwiw, it's a good idea not to depend on anything not available in the stock centos repositories.  E.g., don't rely on EPEL.
[18:18] <blackboxsw> +1
[18:52] <rharper> https://bugzilla.redhat.com/show_bug.cgi?id=1417025
[18:52] <rharper> that's going to be "fun"
[19:57] <larsks> rharper: looks like that was fixed.
[20:10] <rharper> larsks: ok;  I was looking at ubuntu and our dbus.service doesn't depend on After=sysinit.target ;  was going to test with that
[20:11] <larsks> rharper: I finally threw up my hands and completely abandoned the systemd units in the source tree.
[20:11] <rharper> =/  ok, I can look at the changes;  we may need to template the units as well
[20:11] <larsks> There were too many weird edge cases where ubuntu and redhat had different dependencies.
[20:11] <rharper> yeah
[20:12] <larsks> Well, I had another suggestion:
[20:12] <larsks> Using systemd drop-ins for the distribution specific stuff.
[20:12] <rharper> ah, yes
[20:12] <rharper> that is a good idea
[20:12] <rharper> I need to play with those some more
[20:12] <larsks> THe model would be: cloud-init units only have dependencies on other cloud-init units, and dependencies on anything else would be configured in drop-ins.
[20:19] <rharper> yes, that makes sense