[07:11] <penghuan> hi, i'm running unity8-desktop-session-mir on ubuntu 14.10, where can i get the log for unity8?
[08:19] <Saviq> penghuan, ~/.cache/upstart/unity8.log
[08:20] <liuxg> does anyone know why I got "terminate called after throwing an instance of 'std::length_error'" when i try to a http request using "request->execute(
[08:20] <liuxg>                     bind(&Client::progress_report, this, placeholders::_1))"??
[08:20] <liuxg> I am actually following the SDK scope template. In the past, the same code did not have the problem.
[08:21] <liuxg> my code is at bzr branch lp:~liu-xiao-guo/debiantrial/chinaweatherbad
[08:22] <penghuan> Saviq, thanks!
[09:46] <seb128> bah, unity-dash segfault on current rtm
[10:56] <Saviq> seb128, got .crash?
[12:36] <seb128> Saviq, yeah, got that
[12:36] <seb128> it worked for once!
[12:37] <seb128>     msg=0xb3ff902c "UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is\nrunning, and the correct socket is being used and is accessible. The shell may have\nrejected the incoming connectio"...)
[12:38] <seb128> that happened after click "back" on the nearby lens, which was taking time to exit, while it was not done yet poping from that one I right edge swiped
[12:42] <seb128> not easily triggerable using those steps though
[12:51] <Saviq> seb128, iiinteresting, wonder what that message actually means (could it time out, too)
[12:51] <Saviq> ugh
[13:39] <mzanetti> does screen backlight control still work for you guys in vivid?
[13:39] <mzanetti> desktop, that is
[13:40] <mzanetti> both, screen and kbd backlight control are gone for me
[13:46] <mterry> mzanetti, doesn't work as well no
[13:46] <mterry> mzanetti, no notifications but I think I notice some dimming happening
[13:47] <mzanetti> no dimming here
[13:47] <mzanetti> makes me blind at night
[13:47] <mterry> mzanetti, oh btw, so what's my best solution to the tag nonsense from yesterday?  Fix the script?
[13:47] <mzanetti> and no keyboard backlight. given I'm already blinded by the scree I then fail to find keys :D
[13:47] <mzanetti> mterry: yeah, fixing the script would be way to go I guess
[13:48] <mterry> mzanetti, Saviq: and we ultimately want to drop any tag with a question mark (any bad tag)?
[13:48] <Saviq> mterry, yeah, if possible
[13:49] <mzanetti> mterry: hmm... not necessarily... there are situations where valid tags have question marks
[13:49] <mzanetti> although not sure if one runs the script in those situations
[14:13] <mterry> Saviq, mzanetti: OK, how about http://paste.ubuntu.com/8987706/ ?  It deletes any bad tag, and avoids the hardcoded list
[14:14] <Saviq> mterry, sounds like something I wanted to do soon, too ;)
[14:14] <mzanetti> looks reasonable
[14:15] <Saviq> mterry, it looks much slower though?
[14:18] <mterry> Saviq, it's slower yes, but takes a second or two on my machine if doing nothing
[14:18] <Saviq> mterry, I mean on remote branches
[14:18] <mterry> Saviq, oh goodness I bet that is slower
[14:18] <Saviq> mterry, it took like 15s to do it on lp:unity8
[14:18] <mterry> Saviq, I tend to run locally
[14:18] <Saviq> mterry, but that doesn't help
[14:18] <Saviq> mterry, once you pushed
[14:18] <Saviq> mterry, you can't push a tag deletion
[14:18] <Saviq> mterry, you need to delete it remotely
[14:18] <mterry> Saviq, well ok this is slower then.  But it seems to be doing the minimum necessary...
[14:18] <mterry> At least I don't know enough about bzrlib to know a more optimal way
[14:18] <Saviq> mterry, yeah, I wonder if you can do something to cache it or something...
[14:21] <Saviq> mterry, if you care, try and see what you can improve on the script, I'll try later as well
[14:21] <mterry> Saviq, or maybe just use this logic to expand the hardcoded list
[14:22] <mterry> "caching the hard way"
[14:22] <Saviq> mterry, it's a per-branch thing, not sure what can we do there, your approach seems the most flexible and future-proof, I just wonder if it can be made quicker
[14:22] <Saviq> especially as I like to run it on all the MP'd branches from time to time
[14:22] <mterry> Saviq, do we know a bzrlib expert?
[14:23] <Saviq> mterry, wgrant comes to mind
[14:23] <Saviq> at least he could point to someone else hopefully
[14:23] <mterry> yar
[14:24] <mterry> Saviq, asked in #ubuntu-devel
[14:25] <Saviq> tx
[14:29] <greyback_> Mirv: what are "qtbase-abi-5-3-0" and "qtdeclarative-abi-5-3-0" ?
[14:34] <dandrader> dednick, ping
[14:34] <dednick> dandrader: hey
[14:34] <Mirv> greyback_: they are imaginary packages provided by libqt5core5a 5.3.0 and libqt5qml5 5.3.0 that get added as dependencies to a package automatically if the package uses private headers/symbols from anywhere qtbase/qtdeclarative. thus they reforce rebuilding all such packages (as included in my Qt landings) when Qt version is updated
[14:35] <Mirv> greyback_: so the vivid's Qt 5.3.2 packages provide qtbase-abi-5-3-2 and qtdeclarative-abi-5-3-2 accordingly
[14:36] <Mirv> optimally as little packages as humanly possible depends on them / uses private headers
[14:36] <Mirv> so I hope eg. webbrowser-app will get rid of those
[14:37] <greyback_> Mirv: I'm not sure what imaginary packages are - there are no such packages in the repo though
[14:37] <dandrader> dednick, that fixed it http://bazaar.launchpad.net/~unity-team/unity8/shellRotation/revision/1445
[14:37] <dandrader> dednick, do you see any potential problems with it
[14:37] <dandrader> dednick, it's the same approach used for the Launcher
[14:37] <greyback_> Mirv: my problem is we've a PPA (unity-team/demo-stuff) and installing anything we built recently fails like "qtubuntu-android : Depends: qtbase-abi-5-3-0 but it is not installable"
[14:38] <Saviq> greyback_, rebuild it
[14:38] <greyback_> Mirv: what do you suggest we try?
[14:38] <greyback_> dandrader: ^ you heard the man
[14:38] <Saviq> greyback_, you need to rebuild against -5-3-2 that got released into vivid now
[14:38] <dednick> dandrader: yeah, i had in one of my initial branches. dont think there were any troubles. as long as it doesnt break anything else, i dont see any prob.
[14:39] <greyback_> Saviq: "apt-cache search qtbase" doesn't list it though
[14:39] <Saviq> greyback_, because it's virtual
[14:39] <greyback_> is that because it's imaginary?
[14:39] <Saviq> greyback_, yes
[14:39] <greyback_> ok
[14:40] <dandrader> greyback_, ok, I will trigger a rebuild of all the stuff in the PPA then...
[14:40] <Saviq> ⟫ apt-cache show libqt5core5a | grep -i Provides
[14:40] <Saviq> Provides: qtbase-abi-5-3-2
[14:40] <Saviq> greyback_, ↑
[14:41] <greyback_> Saviq: yep
[14:41] <greyback_> just not obvious to me
[14:42] <Saviq> greyback_, that's because when we link to private bits, we need more than just "version 5" as there's no ABI guarantees
[14:43] <greyback_> Saviq: sure, I understand why. I just find it hard to detect when packages are virtual
[14:43] <Saviq> greyback_, and well, yeah, `apt-cache search qtbase-abi-5-3-2` will return the correct package
[14:43] <Saviq> greyback_, you were just searching for one that wasn't there any more
[14:43] <greyback_> huh
[14:44] <Saviq> greyback_, -5-3-0 vs. -5-3-2
[14:44] <greyback_> no I see that. But I didn't notice that "apt-cache search qtbase" actually returned libqtcore5a
[14:44] <greyback_> so my bad
[14:44] <Saviq> now you know :)
[14:45] <Mirv> greyback_: that's why they are imaginary :) ie. they are "packages" that are "Provides:" from the real packages
[14:45] <Mirv> greyback_: you need to rebuild qtubuntu
[14:46] <Mirv> greyback_: if it's vivid and it was built before Qt 5.3.2 landed finally yesterday to release pocket
[14:46] <greyback_> Mirv: yep all clear now. Rebuild being done
[14:46] <Mirv> I see, Saviq explained it
[14:47] <Saviq> Mirv, btw, where do those come from when building? is it some hook to dh_shlibs?
[14:47] <Saviq> or in .symbols in fact?
[14:48] <Saviq> couldn't this be solved via .symbols?
[14:49] <Mirv> Saviq: it's black magic. yes, dh_shlibdeps/dpkg-shlibdeps using /var/lib/dpkg/info/*.symbols
[14:49] <Mirv> Saviq: so this is defined in the symbols of qtbase + qtdeclarative - private symbols are marked as such, and they give the dependency
[14:50] <Mirv> it gets even more complicated with rsalveti's true black magic of the gles twin packages on x86. I manage to mess it up a bit every time despite practice.
[14:52] <Mirv> so certain GLES symbols are specially marked as depending on normal libs on non-x86, and the twin packages instead on x86
[14:53] <Mirv> hurray whenever Qt gets runtime switching between GL and GLES
[14:54] <Saviq> indeed :)
[15:07] <mzanetti> mterry: https://code.launchpad.net/~mterry/unity8/we-are-at-least-beta/+merge/241615/comments/594728
[15:08] <Saviq> mzanetti, that doesn't matter
[15:08] <mterry> mzanetti, haha..  hrm
[15:08] <mzanetti> Saviq: yeah, I know... but we should not use the script on trunk if that's what it does now
[15:08] <mterry> mzanetti, you said you didn't want tags!  :)
[15:08] <mzanetti> :D
[15:09] <mterry> mzanetti, let me test latest version of script
[15:09] <Saviq> mterry, already ran it on trunk ;)
[15:09] <Saviq> and is fine
[15:10] <mzanetti> hmm ok :)
[15:10] <mterry> mzanetti, OK I think I updated tags on that branch correctly, using a merge from trunk
[15:10] <mterry> mzanetti, I was using that branch as a guinea pig.  I could imagine one of my interim scripts borked it
[15:10] <mzanetti> mterry: no worries... I just wanted to raise it, in case the script really destroys it
[15:10] <mzanetti> ok
[15:13] <mzanetti> mterry: approved
[15:14] <mterry> mzanetti, w00t!  we're out of alpha!  :)
[15:15] <mzanetti> mterry: after all we're 8.01 already
[15:15] <mzanetti> first bugfix release after stable :D
[15:15] <mzanetti> which I guess is true for the phone
[16:46]  * vila_ is vila from a laptop setup for testing
[16:46] <vila_> swift list --debug hangs
[16:47] <vila_> meh, damn xchat, wrong channel, sorry for the noise >-}
[16:48] <Saviq> lp:~mzanetti/unity8/performanceoverlay: would delete 7.85+14.10.20140428.2-0ubuntu1
[16:48] <Saviq> lp:~mterry/unity8/greeter-profiles: would delete 0.1.16
[16:49] <mterry> fixed
[16:49] <mzanetti> the new script?
[16:49] <mzanetti> or something I should fix in the branch?
[16:50] <mterry> mzanetti, I think just tags that the new script caught
[16:53] <Saviq> mzanetti, I'm just uploading the new script
[16:54] <Saviq> mzanetti, http://people.canonical.com/~msawicz/unity8/strip-tags.py
[16:54] <mzanetti> Saviq: so I should delete that tag?
[16:54] <Saviq> mzanetti, it's an invalid tag on your branch, so yeah
[16:55] <mzanetti> I wonder how that came in though, it's not something we got from uity7
[16:55] <Saviq> om26er, can you please run ↑ on lp:~om26er/unity8/show_password_on_label_tap, and any local unity8 checkouts you have (just pass the different branches as arguments)
[16:56] <mzanetti> done
[16:56] <Saviq> om26er, note you need to run the script on them all, pushing won't help to delete tags
[17:01] <Saviq> @unity ↑ new strip-tags.py script, one that works for any branch (not unity8-specific any more, thanks mterry!)
[17:02] <Cimi> Saviq, what you mean not unity8 specific?
[17:02] <Saviq> Cimi, you can use it for any random branch to clean invalid tags from it
[17:03] <Cimi> Saviq, how do we know when tags are valid/not?
[17:03] <Saviq> Cimi, the invalid ones don't relate to a revision
[17:04] <Cimi> Saviq, moving this to CI?
[17:04] <Saviq> Cimi, not a good place for it, no
[17:04] <Saviq> we've had this discussion and have some ideas
[17:05] <Cimi> yeah, doing it manually for every single branch is not ideal too...
[17:05] <Cimi> Saviq, maybe just having CI checking for tags
[17:05] <Saviq> Cimi, that's the thing, you don't need to do it manually, we should be able to not do it at all once all of us get cleaned up
[17:05] <Cimi> it does not have to remove them, just complain
[17:05] <Saviq> Cimi, basically, don't worry, I'll tell you
[17:05] <Cimi> i like that :P
[21:35] <josharenson> so since gdm doesn't work in 15.04, and lightdm has never worked for me, does anyone have any ideas? My login screen is just black now...
[22:17] <zbenjamin> josharenson: kdm?
[22:17]  * zbenjamin runs
[22:21] <zbenjamin> josharenson: there is also XDM, Slim,lxdm
[22:21] <zbenjamin> josharenson: ssdm also sounds interesting, its using Qt/QML
[22:22] <josharenson> zbenjamin, ill try another dm
[22:32] <zbenjamin> josharenson: you sure that this is not a xserver config/driver problem
[22:34] <josharenson> I can get a desktop to show if I run startx (Xorg was already running), however unity doesn't start when I do this
[22:35] <zbenjamin> meh :/