[03:29] <pitti> Good morning
[03:48] <pitti> Laney: "Jenkins Fixed - saucy-adt-glib2.0 19" -- nice job!
[05:09] <thumper> hi pitti
[05:09] <thumper> pitti: I have a question for you
[05:09] <thumper> I want to have my executable be elevated to root permissions after doing some initial messing around
[05:10] <thumper> so don't want to run the executable with sudo
[05:10] <thumper> but instead have it ask for sudo password part way through
[05:10] <thumper> is this possible?
[05:10] <pitti> thumper: no, not really
[05:10] <thumper> bugger
[05:10] <thumper> hmm...
[05:11] <pitti> thumper: you could split your program into a privileged part and an unprivileged one, and call the privileged one through sudo or pkexec
[05:11] <thumper> pitti: the program is juju :)
[05:11] <pitti> thumper: otherwise I suggest you start it as root, drop privileges at the beginning, and re-claim them only if you need to
[05:11] <thumper> pitti: hmm.. how do you do that?
[05:12] <thumper> a problem in particular is that some files which are created and should be owned by the user, are being owned by root
[05:12] <pitti> thumper: create a system user, find out its UID with getpwname(), then drop privs with setresuid(uid, uid, uid)
[05:12] <thumper> but I do need to write to /etc/init and /var
[05:12] <pitti> and when you need root, setresuid(0, 0, 0) temporarily
[05:12] <thumper> hmm.. can I do that in go?
[05:13] <pitti> that's a pretty basic posix call; I sure hope so
[05:13]  * thumper goes digging
[05:13] <thumper> pitti: thanks
[05:13] <pitti> thumper: eww, you start this as a user and write into /etc/ ?
[05:13] <pitti> thumper: maybe that should be re-designed first :)
[05:13] <thumper> pitti: it is to create a local provider
[05:13] <pitti> like, writing into ~/.config/juju instead, or creating a per-user dir in /var/lib/juju/
[05:13] <thumper> so it creates two services for the mongo db and agent
[05:14] <thumper> these need to be started by upstart
[05:14] <thumper> and it also needs to create lxc containers in precise
[05:14] <thumper> so no user space
[05:14] <pitti> thumper: can't you ship a generic upstart job which tests for the existance of a particular file and only starts then?
[05:15] <thumper> hmm...
[05:15] <thumper> the thing is there could be multiple
[05:16] <thumper> if you had multiple local environments
[05:16] <thumper> I'm open to ideas
[06:23] <Mirv> didrocks: to your queue,  lp:~kubuntu-packagers/kubuntu-packaging/qtsystems-opensource-src + https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+files/qtsystems-opensource-src_5.0%7Egit20130614.orig.tar.gz would be ready (again, with the fixes)
[06:23] <Mirv> qml plugins separated and license files added
[06:24] <didrocks> Mirv: ah, thanks! :)
[06:24] <didrocks> Mirv: will have a look later today
[06:28] <Mirv> merci
[06:46] <jibel> good morning
[07:58] <Laney> hey
[07:58] <Laney> pitti: yeah - cool isn't it?
[07:59] <pitti> Laney: it sure is
[07:59] <pitti> Laney: so that's now with the proper runner?
[07:59] <Laney> yep
[08:07] <seb128> good morning desktopers
[08:07] <seb128> hey Laney, pitti
[08:07] <mlankhorst> g'day mate
[08:07] <pitti> hey seb128
[08:07] <seb128> hey mlankhorst
[08:09] <Laney> hey
[08:10] <mlankhorst> more merge window fun, hopefully this nvd7 will work in 3.11
[08:10] <mlankhorst> :D
[08:16] <seb128> nothing like starting the day on a non working session
[08:16] <seb128> mlankhorst, I though for a bit that the new xorg was broken :p
[08:16] <seb128> gnome-session was complaining about errors loading the intel driver or something
[08:17] <seb128> but it turned out that it was a stalled .Xauthority in my userdir breaking things
[08:21]  * Laney remembers that he probably ought to fix his microphone
[08:21] <mlankhorst> seb128: everything's an xorg bug ;)
[08:21] <mlankhorst> but hey lets do it
[08:27] <seb128> Laney, if that's for the settings meeting you have another week, but yeah, would be nice ;-)
[08:30] <Laney> seb128: oh really? I thought it was today :P
[08:30] <seb128> Laney, we said every second week, though it would maybe be good to do it weekly now that things are quite active
[08:31] <seb128> Laney, but mardy is not there this week so...
[08:31] <Laney> yeah I knew that but thought it was two weeks already
[08:31] <seb128> could be
[08:31] <seb128> let me check :p
[08:31] <seb128> Laney, shrug, you are right ;-)
[08:32] <Laney> fixed anyhow
[08:32] <Laney> don't mind if you want to defer it since mardy isn't here
[08:33] <seb128> Laney, I made it bi-weekly in google calendar
[08:33] <seb128> Laney, well, we can have a quick round with those who are around, would be good to keep the cadence ;-)
[08:33] <Laney> k, cool
[08:33] <seb128> and we can discuss making it weekly
[08:33] <seb128> so we can have one with mardy next week as well :p
[08:35] <seb128> Laney, speaking of which, how much fun do you have with qml? ;-) want to pick another panel to work on?
[08:36] <Laney> yeah I was going to do some other bit of UI, maybe the security one?
[08:36] <seb128> Laney, well, in addition I mean ... or for when you are done with yours, or if you feel like doing a bit more "standard UI"
[08:36] <seb128> Laney, I think didrocks wanted to do security, what about bluetooth?
[08:36] <seb128> https://wiki.ubuntu.com/Bluetooth#phone
[08:36] <seb128> it seems like mostly standard UI
[08:37] <seb128> at least less crazy that the background one ;-)
[08:37] <seb128> and cyphermox seems to be overbusy
[08:38] <seb128> larsu, or check with didrocks if he wants help on the privacy UI
[08:41] <Laney> I could do the basic bits for bluetooth
[08:41] <Laney> the specialist / advanced stuff would be best left for cyphermox though
[08:43] <Laney> oh interesting, this is one which is enabled dynamically
[08:44] <Laney> do we have a way of doing that?
[08:45] <Laney> using the entry component I guess
[08:46] <mlankhorst> seb128: but at what time do you want to start uploads
[08:47] <seb128> mlankhorst, now? ;-)
[08:47] <mlankhorst> do itt
[08:48] <seb128> mlankhorst, wait
[08:48] <seb128> Laney, can we put a britney lock on X*?
[08:48] <Laney> haha, not like that
[08:48] <Laney> if you give me a list of packages sure
[08:48] <seb128> right :p
[08:48] <seb128> mlankhorst, ^
[08:48] <seb128> Laney, I think britney will not stop it because it Breaks: unity (<< new)
[08:48] <Laney> don't think it handles breaks like that
[08:48] <seb128> so we better put a manual lock there and wait to have things in place
[08:48] <mlankhorst> yeah
[08:49] <mlankhorst> just in case
[08:50] <seb128> seems like didrocks is busy with the Mir guys and I want to hear from him&Mirv before uploading
[08:50] <seb128> didrocks, Mirv: please ping back about new xorg when you are done being busy on other things
[08:50] <Laney> hmm, maybe it does though
[08:50] <Laney> infinity: does britney consider Breaks when determining installability?
[08:51] <didrocks> seb128: just coordinate with Mirv, he's dealing with the transition AFAIK
[08:51] <didrocks> mlankhorst: ^
[08:51] <seb128> didrocks, ok
[08:51] <seb128> Mirv, hey
[08:51] <Mirv> there was something wrong still with https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1/+merge/150175 I think?
[08:51] <mlankhorst> Laney: everything from https://launchpad.net/~canonical-x/+archive/x-staging?field.series_filter=saucy except the unity and -omap-revert packages
[08:51] <mlankhorst> Mirv: perhaps, unity needs to hard build-depend and depend on the version from that ppa, that should fix it.
[08:52] <Laney> can you give me a list? :(
[08:52] <Laney> the format is block package1 package2 ...
[08:52] <seb128> Mirv, not really, he forgot the commit message ... and it requires the new xorg which is in a ppa and going to be uploaded to saucy-proposed soon
[08:52] <Mirv> mlankhorst: from seb128's comment I'd guess something like libxfixes-dev (>= 1.6.99.1)
[08:52] <seb128> Mirv, do you guys build on top of saucy or saucy-proposed?
[08:53] <mlankhorst> Mirv: the epoch too..
[08:53] <mlankhorst> Laney: libxfixes libxi mesa-demos nvidia-graphics-drivers-tegra3 nvidia-tegra-codecs-cardhu unity x11proto-fixes x11proto-input xf86-input-mtrack xf86-input-multitouch xf86-input-tslib xf86-input-wacom xf86-video-omap xf86-video-omap-revert xorg xorg-server xorg-server-omap-revert xserver-xorg-input-acecad xserver-xorg-input-aiptek xserver-xorg-input-elographics xserver-xorg-input-evdev xserver-xorg-input-evdev-omap-revert xserver-xorg-input
[08:53] <Laney> ty
[08:53] <mlankhorst> let me know where it truncates
[08:53] <Laney> xserver-xorg-input-evdev-omap-revert xserver-xorg-input
[08:53] <seb128> mlankhorst, pastebin?
[08:54] <Laney> splitlong.pl!
[08:54] <seb128> no truncate on pastebin, and no flooding of this channel :p
[08:54] <mlankhorst> ok ill pastebin
[08:54] <Laney> :-)
[08:54] <Mirv> seb128: if I haven't understood something wrongly, proposed (for example https://launchpadlibrarian.net/144130366/buildlog_ubuntu-saucy-amd64.unity_7.0.1%2B13.10.20130704-0ubuntu1_UPLOADING.txt.gz)
[08:54]  * seb128 shouldn't tell people about flooding about the "incident" where he flooder the channel recently :p
[08:54] <Mirv> seb128: which would mean Xorg to -proposed, accept brandon's branch, rebuild stack after merged in
[08:55] <mlankhorst> http://pastebin.com/JNHgkG9Y
[08:55] <Laney> if you build-depend on the right version it'll wait automatically
[08:55] <seb128> Mirv, sounds like a plan, we will get Xorg updated and then ping you for the accept brandon's patch/rebuild stack
[08:56] <Mirv> seb128: ok, as mlankhorst pointed out, actually the brandon's branch is missing epoch also for libxi-dev, so I'll branch from there and add the 2:
[08:56] <seb128> Mirv, thanks
[08:58] <Mirv> mlankhorst: so should the libxfixes-dev dependency be >= 1:5.0.1-1 ?
[08:58] <Mirv> seb128: thanks
[08:58] <mlankhorst> Mirv: yeah, and perhaps an explicit depends on libxfixes3 and libxi6 too
[08:59] <infinity> Laney: If it doesn't, it should.  But ask Colin, he'd know for sure.
[08:59] <mlankhorst> so symbols won't be messed up
[08:59] <Mirv> mlankhorst: ok. that shouldn't be necessary, the -dev packages pick up the same version dependency automatically.
[08:59] <Laney> infinity: Yeah. I see mention of it in source so guess that it does. I did ask in #-release already. Thanks.
[09:00] <mlankhorst> Mirv: not in this case, the xi2 symbols were introduced before
[09:00] <mlankhorst> but we patched those out
[09:00] <infinity> Laney: Yeah, right after I wrote that, I read an email from Colin saying that he's out sick.  So maybe don't ask him. :P
[09:00] <Laney> Heh
[09:00] <Laney> FINE. I'll ask #debian-release.
[09:02] <Mirv> mlankhorst: interesting, ok.
[09:03] <Laney> sounds like we're safe
[09:03] <seb128> Laney, infinity: from IRC logs and discussion with Colin in the past, Britney checks for installability of ubuntu-desktop
[09:04] <seb128> but not including recommends
[09:04] <seb128> we had CD builds failing because of that
[09:04] <seb128> but that's ok, xorg and unity are both strong depends ;-)
[09:05] <mlankhorst> seb128: yeah but for example libxi and libxfixes need to be held back manually
[09:05] <mlankhorst> and the proto stuff too
[09:05] <Mirv> now at https://code.launchpad.net/~timo-jyrinki/unity/move-pointer-barries-to-xi-1.6.99.1_try2/+merge/172975
[09:05] <seb128> Laney, please put the big lock in place manually, better safe than sorry
[09:06] <seb128> Laney, mlankhorst: then we can start on uploads ... are those uploads a ppa copy, or manual upload or...?
[09:06] <mlankhorst> ppa copy
[09:07] <seb128> mlankhorst, do you know the magic incantation that should be run?
[09:07] <seb128> is that basically copying the list of packages you just pastebined?
[09:07] <Laney> it's done
[09:07] <seb128> Laney, thanks ;-)
[09:07] <mlankhorst> seb128: no idea what the magic invocation is
[09:08] <Laney> the answer is that it's enforced if the packages are required to be coinstallable
[09:08] <Laney> i.e. if there's a dependency relationship there
[09:08] <seb128> k
[09:09] <Laney> so if you can install unity without whatever-package-gets-the-breaks then it won't work
[09:10] <seb128> that makes sense, so it would block the server in this case
[09:10] <mlankhorst> but not the libs
[09:10] <seb128> right
[09:10] <seb128> but updating the libs without the server should work
[09:10] <seb128> or you forgot some depends/breaks :p
[09:10] <mlankhorst> copied from debian
[09:10] <seb128> anyway, let's get going
[09:11] <mlankhorst> indeed
[09:11] <seb128> Laney, do you know if we can pocket copy including binaries from x-staging's ppa?
[09:12] <seb128> it has armhf builds
[09:12] <seb128> so I guess we can?
[09:12] <Laney> no
[09:12] <Laney> they're virtual arm builds aren't they?
[09:13] <tjaalton> copying has been used before
[09:13] <mlankhorst> for 1.12 and 1.13
[09:13] <seb128> infinity, ^ do you know?
[09:13] <tjaalton> he's asleep
[09:13] <tjaalton> RAOF: ^
[09:13] <tjaalton> probably EOD
[09:13] <seb128> tjaalton, he commented 10 minutes ago, did he just feel asleep?
[09:13] <tjaalton> oh :)
[09:14] <tjaalton> in that case..
[09:15] <mlankhorst> Laney: but why wouldn't virtual arm work?
[09:15] <Laney> Oh, looks like it is non-virt but doesn't build for ppc
[09:15] <seb128> oh, ppc...
[09:15] <mlankhorst> hm
[09:15] <Laney> it's known to be shaky
[09:15] <seb128> shrug
[09:15] <seb128> we need ppc binaries
[09:15] <seb128> so I guess we need rebuilds
[09:15] <Laney> the missing build records should be created when you copy
[09:15] <mlankhorst> ok
[09:15] <seb128> Laney, should we try one on source to see how it goes?
[09:16] <Laney> go on then ...
[09:16] <mlankhorst> try xorg metapackage
[09:17] <seb128> mlankhorst, is that arch: any?
[09:17] <mlankhorst> not xserver-xorg
[09:17] <mlankhorst> which is built from xorg
[09:17] <seb128> mlankhorst, I was going to try libxfixes
[09:18] <mlankhorst> seb128: yeah that one will fail because it needs the new protos first
[09:18] <Laney> Then again a lot of these packages were built back in May which might be on an older toolchain
[09:18] <Laney> so you might want rebuilds anyway
[09:18] <infinity> seb128: Please never, ever, ever copy from a virt PPA.  Ever.
[09:18] <mlankhorst> Laney: shrug just upload the proto first in that case
[09:19] <mlankhorst> rest should be ok
[09:19] <seb128> infinity, is https://launchpad.net/~canonical-x/+archive/x-staging virtual?
[09:19] <Laney> mlankhorst: don't you have upload to these anyway? :P
[09:19] <mlankhorst> infinity: can you enable ppc on that ppa?
[09:20] <infinity> seb128: Nope, that's non-virt.  You can tell from which builders it uses.  But (and this is a big but), non-virt PPAs still aren't, by default, built the same was as the distro.
[09:20] <infinity> seb128: As far as translation stripping, etc.
[09:20] <infinity> s/was/way/
[09:20] <mlankhorst> https://launchpad.net/~canonical-x/+archive/x-staging/+build/4766545
[09:20] <mlankhorst> oh indeed
[09:20] <seb128> let's just rebuild those
[09:21] <infinity> mlankhorst: We could do an X-staging PPA that meant for copying, but no harm in just doing source copies this time.
[09:21] <mlankhorst> it should be ok to rebuild, in that case x11proto first, then wait until it's done and the libxi/xfixes
[09:21] <mlankhorst> then*
[09:22] <tjaalton> can you not dump all at once, libx* should have sufficient b-dep checks to prevent them from building before proto?
[09:22] <infinity> Interestingly enough, in most ways, that PPA seems to be correct already, except for the missing PPC.  You should probably get that enabled.
[09:22] <infinity> (for next time)
[09:23] <seb128> sanity check
[09:23] <seb128> Laney, infinity: does that looks correct?
[09:23] <seb128> $ ./copy-package -s saucy --ppa-name canonical-x/x-staging --to-primary --to-suite=saucy-proposed x11proto-input
[09:24] <Laney> I think it's --ppa=canonical-x --ppa-name=x-staging
[09:24] <mlankhorst> yeah
[09:24] <infinity> seb128: Does owner/name work?  I always use --ppa= ... What Laney said.
[09:24] <seb128> ok, let me try that
[09:24] <Laney> You'll get a confirmation anyway
[09:24] <seb128> I'm new to those ppa to archive copies :p
[09:24] <infinity> Though I like yours.  Someone should make the tool take that. :P
[09:25] <mlankhorst> infinity: how do you specify what release to use for copy_package?
[09:25] <infinity> mlankhorst: Hrm?
[09:25] <mlankhorst> (to take the saucy packages in there)
[09:25] <infinity> mlankhorst: -s saucy
[09:25] <mlankhorst> in there -> from the ppa
[09:25] <infinity> mlankhorst: And if extra paranoid '-e $version' too.
[09:25] <mlankhorst> hmz
[09:26] <mlankhorst> no need for that I hope, ubuntu0.3 will fail to build on saucy due to toolchain changes
[09:26] <mlankhorst> and the raring versions are mostly older, so they won't work anyway
[09:27] <Laney> -s saucy will get the right thing
[09:27] <mlankhorst> ok
[09:27] <infinity> It will, yes.
[09:27] <infinity> The "extra paranoid" bit was if you were doing some scripting or something and trying to avoid races with other people.
[09:27] <infinity> In this case, I assume you know no one will upload to the PPA while you're doing this. :P
[09:33] <seb128> tjaalton, mlankhorst: I guess it's normal some of those have raring in their changelog target? e.g https://launchpad.net/ubuntu/+source/x11proto-input/2.3-0ubuntu1 ?
[09:33] <tjaalton> yeah, doesn't matter
[09:34] <mlankhorst> yeah the x1.14 stack was originally created for raring, can just be carried over :)
[09:34] <tjaalton> or could that be pulled from debian now?
[09:34] <tjaalton> synced
[09:34] <mlankhorst> hm actually.. it could
[09:34] <seb128> can I ppa copy for somebody else? that upload has my mine on it...
[09:34] <seb128> tjaalton, mlankhorst: which ones can be synced from debian?
[09:35] <seb128> I guess the one without ubuntu revision can be syncpackaged?
[09:35] <Laney> why don't I just extend the xorg packageset (mlankhorst requested this a month ago) and mlankhorst can self service?
[09:36] <seb128> Laney, that would be good
[09:36] <tjaalton> that would work, also the lts-*
[09:36] <Laney> ok
[09:36] <Laney> I think we had some discussion about it and then forgot to do it
[09:36] <mlankhorst> maybe i could finally do the lts raring sru uploads myself then :>
[09:37] <mlankhorst> but I guess if we don't need to do a binary copy I can do it myself
[09:38] <mlankhorst> tjaalton: please don't do uploads :)
[09:38] <Laney> give me a minute to remember how to drive the tool
[09:39] <mlankhorst> oops
[09:39] <Laney> laney@iota> edit-acl -P xorg -S precise -s libxrandr-lts-raring add                                                                   ~/temp
[09:39] <Laney> Added:
[09:39] <Laney> libxrandr-lts-raring
[09:39] <Laney> cool
[09:40] <tjaalton> mlankhorst: harhar
[09:41]  * mlankhorst wonders why it said your name
[09:41] <seb128> mlankhorst, I did 2 syncs and used tjaalton for -s ... sorry if that created confusion
[09:41] <seb128> I tried to match the ppa uploaders
[09:42] <mlankhorst> ah :-)
[09:42] <seb128> mlankhorst, well anyway, I just put x11proto-input/fixes and libxi/xfixes in so far, I will let you do the rest
[09:42] <mlankhorst> I'll have to wait for libxi/libxfixes to fail first
[09:44] <seb128> mlankhorst, libxfixes built fine...
[09:44] <Laney> okay then, try that
[09:44] <seb128> mlankhorst, https://launchpad.net/ubuntu/saucy/+source/libxfixes/1:5.0.1-1
[09:44] <Laney> edit-acl -P xorg -S saucy query lets you see what's in it
[09:45] <mlankhorst> libxi did not :-)
[09:46] <seb128> mlankhorst, ^ did you see Laney's line? are you set for those copies/uploads? ;-)
[09:47] <mlankhorst> should be good
[09:47] <seb128> mlankhorst, I did the first copies with "./copy-package -s saucy --ppa=canonical-x --ppa-name=x-staging --to-primary --to-suite=saucy-proposed <name>"
[09:47] <mlankhorst> except the arm stuff, but I can ask tjaalton for that
[09:47] <seb128> if that's useful
[09:47] <mlankhorst> yeah
[09:52] <mlankhorst> unity can be uploaded at this point, btw
[09:57] <seb128> mlankhorst, better to wait a bit, the binaries are not published yet and I'm not sure their merger/jenkins does depwait
[09:58] <mlankhorst> ah
[10:15] <mlankhorst> now I just need to wait for xorg-server to show up in proposed then before I can do the rest, it's mostly a rebuild bump from here on
[10:25] <seb128> mlankhorst, if you have updated build-depends those will depwait ... if not, you better wait yes ;-) it's built on i386/amd64, depending if armhf and ppc finish before :30 you might need to wait 1 or 2 extra publisher cycles
[10:25] <seb128> e.g ~1h
[10:26] <seb128> if the past build times are any indicator there is still a good half an hour of build on armhf, so you can go for lunch easily ;-)
[10:26] <mlankhorst> can I create a version number lower than 0~ ?
[10:26] <mlankhorst> would 0~~ work?
[10:27] <Laney> yep
[10:27] <mlankhorst> oh good
[10:27] <seb128> try dpkg --compare-versions 0~ gt 0~~; echo $?
[10:27] <Laney> laney@iota> dpkg --compare-versions 0~~ lt 0~ && echo yep                                                                             ~/temp
[10:27] <Laney> yep
[10:28] <mlankhorst> ah great, it should be possible to force an upgrade then :P
[10:28] <seb128> force an upgrade of what?
[10:31] <didrocks> seb128: mind approving? https://code.launchpad.net/~didrocks/libusermetrics/simplify-packaging/+merge/172994
[10:31] <didrocks> (while I'm are it :p)
[10:33] <seb128> didrocks, done
[10:33] <didrocks> thx
[10:34] <seb128> Mirv, bah, the CI doesn't use proposed... https://jenkins.qa.ubuntu.com/job/unity-saucy-amd64-autolanding/75/console
[10:34] <seb128> going to be fun :p
[10:35] <seb128> that's about https://code.launchpad.net/~timo-jyrinki/unity/move-pointer-barries-to-xi-1.6.99.1_try2/+merge/172975
[10:35] <seb128> it's one of those cases here it would be easier to just upload the patch to saucy-proposed manually and merge back
[10:35] <seb128> but didrocks is not going to like that suggestion I'm sure :p
[10:36] <didrocks> seb128: we can push it to trunk directly rather
[10:36] <didrocks> and merge manually
[10:36] <didrocks> then quick a daily
[10:36] <didrocks> the tests are using proposed
[10:37] <didrocks> kick*
[10:37] <seb128> didrocks, right
[10:37] <seb128> Mirv, ^ can you do that?
[10:40] <Mirv> seb128: ok.. feels evil to push something to trunk but ok :) the cu2d will run all the tests anyhow that's true
[10:41] <seb128> Mirv, thanks
[10:51] <Mirv> ok, it's there, launching a build of unity in cu2d
[10:57] <Mirv> built successfully, it's running autopilot now (1h)
[10:59] <Mirv> I mean prepared successfully, building + autopilot next :)
[11:10] <seb128> Mirv, sorry, I was grabbing a bite
[11:10] <seb128> Mirv, great, let's see how that goes
[11:14] <Mirv> amd64 built https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4769091 , dependencies seems correct. powerbc built as well.
[11:23] <seb128> Mirv, great
[11:29] <Laney> mlankhorst: what does 'Xlib:  extension "NV-GLX" missing on display ":0".' mean and is it caused by new X? :-)
[11:30] <Laney> I noticed that I was getting weird corruption in QML apps: http://ubuntuone.com/7ibGVZ0LQ1yt1SqQohjkMb and that message appears on the console
[11:35] <mlankhorst> Laney: your nvidia drivers are messedup, mostly
[11:35] <mlankhorst> did you manually install them, by any chance?
[11:35] <Laney> dunno!
[11:36] <seb128> Laney, why do you hate Ubuntu, why not using the packages!
[11:36] <seb128> ;-)
[11:36] <ogra_> use Mir !
[11:36] <Laney> I appear to have nvidia-319 installed
[11:37] <seb128> ogra_, hey; I think I forgot to say it yesterday, congrats on getting the container flip by default landed ;-)
[11:37] <ogra_> hey, thanks :)
[11:41] <Laney> mlankhorst: looks much better using nouveau :P
[11:41] <seb128> mlankhorst, xserver-xorg-core | 2:1.14.1-0ubuntu0.8 | saucy-proposed | amd64, armhf, i386, powerpc
[11:41] <seb128> mlankhorst, you can upload the drivers I think
[11:41] <Laney> lightdm does not, however - that has the wrong resolution and is mirrored
[11:42] <seb128> (that's "rmadison -S xorg-server -s saucy-proposed")
[11:42] <seb128> Laney, right, we default to mirror...
[11:42] <Laney> maybe it was always mirrored :P
[11:42] <Laney> but it had the right res with nvidia
[11:42] <Laney> oh well
[11:42] <seb128> nvidia has its own config no?
[11:42] <Laney> moar freedom for me
[11:43] <seb128> Laney, cp .config/monitors.xml /etc/gnome-settings-daemon/xrandr/monitors.xml
[11:43] <Laney> I don't know how to configure lightdm
[11:43] <seb128> that's what I did here
[11:43] <Laney> did I ever do that?
[11:44] <Laney> seb128: ah yes, very nice - that's how it looked before
[11:44] <seb128> ;-)
[11:44] <Laney> what voodoo was nvidia doing ...
[11:44] <seb128> is their config tool running as root?
[11:44] <seb128> did it write config in /etc?
[11:44] <seb128> or maybe they default to non-mirror
[11:45] <Laney> anyway, system-settings looks right again
[11:45] <seb128> great
[11:45] <Laney> do you ever see it segfault on start btw?
[11:45] <seb128> yes
[11:45] <seb128> like one every 10 start or something
[11:46] <Laney> just did it three times in a row
[11:46]  * Laney gets qt debug symbols
[11:46] <seb128> seems rather a qt bug than a system-settings one though
[11:48] <seb128> Laney, is the stacktrace for your also loading an icon?
[11:48] <Mirv> the rebuilt unity would seem to segfault for me and autopilot test seem like concurring (at least it's respawning, no segfault message) http://10.97.0.1:8080/job/autopilot-saucy-daily_release/329/label=autopilot-intel/console
[11:48] <Laney> #0  QPMCache::createKey (this=this@entry=0x7fffd0024560) at image/qpixmapcache.cpp:396
[11:48] <Mirv> I update the minimal amount required to manually install the unity from daily-build PPA
[11:49] <Mirv> d
[11:49] <seb128> Mirv, crap, do you have a stacktrace of the segfault?
[11:49] <Mirv> seb128: http://pastebin.ubuntu.com/5843267/
[11:50] <seb128> Mirv, can your ldd -r /usr/lib/compiz/libunityshell.so and pastbin it?
[11:50]  * seb128 has a deja vu here
[11:52] <Mirv> seb128: right, http://pastebin.ubuntu.com/5843270/
[11:52] <seb128> undefined symbol: XFixesSelectBarrierInput	(/usr/lib/compiz/libunityshell.so)
[11:52] <seb128> Mirv, dpkg -l | grep xfixes?
[11:53] <Mirv> seb128: http://pastebin.ubuntu.com/5843275/
[11:53] <seb128> mlankhorst, ^ do you have any idea on that?
[11:54] <seb128> Mirv, are you sure you have the patch?
[11:54] <seb128> Mirv, https://code.launchpad.net/~timo-jyrinki/unity/move-pointer-barries-to-xi-1.6.99.1_try2/+merge/172975 has
[11:54] <seb128> - XFixesSelectBarrierInput(dpy, DefaultRootWindow(dpy), 0xdeadbeef);
[11:54] <seb128> + barrier_ = XFixesCreatePointerBarrier(dpy,
[11:54] <mlankhorst> seb128: sounds like you were using old unity, still
[11:56] <seb128> Mirv, dpkg -l | grep unity?
[11:56] <seb128> Mirv, https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=unity&field.status_filter=published&field.series_filter=saucy has
[11:56] <seb128> unity - 7.0.1+13.10.20130704.1-0ubuntu1
[11:56] <Mirv> just a second
[11:56] <seb128> Mirv, it should be 7.0.2
[11:57] <Laney> I thought the Breaks was supposed to prevent that happening
[11:57] <Mirv> ah, so it should, argh (7.0.2)
[11:57] <seb128> Laney, he didn't update xserver
[11:57] <seb128> Laney, just libxi and libxfixes
[11:57] <seb128> Laney, I guess those libs should have a break as well
[11:58] <Mirv> and interestingly, I had downgraded unity already, but getting back that 0704.1, I get another symbol missing http://pastebin.ubuntu.com/5843289/
[11:58] <Laney> does that mean the breaks is on the wrong package?
[11:58] <Mirv> yeah I tried to upgrade the minimal amount forced by dependencies, to see what happens
[11:58] <Laney> also if it's dropping symbols shouldn't it bump soname?
[11:58] <seb128> Mirv, that's because you updated libxi
[11:59] <seb128> Laney, it's a bit of a special case, we had an early implementation of the barrier stuff that went upstream, only unity uses it
[11:59] <seb128> Laney, we don't really want to carry a different soname over Debian only for that
[11:59] <Mirv> seb128: actually I did not, since the specified dependency was >= 1.6.99.1 and the old one was that, the new is 1.7.x
[11:59] <seb128> Mirv, hum, k, in any case it seems the ppa doesn't have your merge in
[11:59] <Mirv> seb128: now after upgrading libxi6 to 1.7.x, the new unity starts, so I guess the dependency should be that 1.7 instead of 1.6.99?
[12:00] <seb128> right
[12:00] <Laney> interesting
[12:00] <Mirv> seb128: the PPA has, I just reverted the changelog since I thought I'll let cu2d add the changes, but of course I shouldn't have reverted the version number part
[12:00] <seb128> Mirv, right, please add it back, xorg-xserver breaks unity << 7.0.2
[12:00] <Mirv> so bumping the 7.0.2 again + the xi dependency to >= 2:1.7.1.901-1 ?
[12:00] <seb128> Mirv, yes
[12:01] <seb128> Mirv, libxi >= 2:1.7 should be enough
[12:02] <seb128> but you can as well specify >= 2:1.7.1.901
[12:02] <seb128> since that's what we have anyway...
[12:02] <Mirv> ok. and actually I just checked that my or brandon's branch didn't have the changelog bump to 7.0.2 either, just the cmake version bump
[12:03] <seb128> Mirv, we need the changelog update since that's how we set up things to make sure xorg and unity are upgraded together
[12:03] <seb128> Mirv, sorry for not catching that earlier
[12:08] <Mirv> seb128: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3408
[12:08] <Mirv> seems to match how bump to 7.0.1 was handled
[12:08] <seb128> Mirv, great
[12:09] <seb128> Mirv, you should probably have added a new changelog entry rather than changing the one from the previous upload though
[12:09] <seb128> Mirv, can you take the changelog from saucy and dch -v 7.0.2-0ubuntu1 over it rather?
[12:10] <Mirv> seb128: are you sure? it wasn't released to the archives, so the next changelog entry should be the same as before but with cu2d stamped 7.0.2+date?
[12:10] <seb128> Mirv, the way you did it will probably make cu2distro think we are missing https://launchpad.net/ubuntu/+source/unity/7.0.1+13.10.20130703-0ubuntu1
[12:10] <seb128> Mirv, it was release to saucy
[12:10] <seb128> see https://launchpad.net/ubuntu/+source/unity/7.0.1+13.10.20130703-0ubuntu1
[12:10] <Mirv> seb128: oh.. ok, fixing and then running a new build
[12:10] <seb128> great
[12:14] <Mirv> going with that, restored the released version http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3409
[12:15] <Mirv> now I've a good feeling, as I'm already running the new unity here
[12:16] <seb128> Mirv, yep, looks right
[12:18] <mlankhorst> how can i see if binaries are published?
[12:18] <seb128> mlankhorst, the xorg-xserver ones are published, didn't you see my comment before?
[12:19] <seb128> mlankhorst, rmadison -S xorg-server -s saucy-proposed
[12:19] <mlankhorst> ah
[12:19] <mlankhorst> can someone else do a rebuild bump for virtualbox and upload mesa-demos? I lack permission to upload either. :P
[12:20] <seb128> tjaalton, ^? ;-)
[12:21] <seb128> mlankhorst, if tjaalton doesn't pick them I can have a look in a bit (just finishing something else first)
[12:21] <mlankhorst> hm need nvidia-graphics-drivers-tegra3 and nvidia-tegra-codecs-cardhu too
[12:21] <mlankhorst> tseliot: can you upload those? :)
[12:22] <tjaalton> I can in a bit, eating atm
[12:22] <tjaalton> or tseliot :)
[12:22] <tseliot> mlankhorst: didn't I upload those? Maybe it was in a PPA?
[12:23] <tjaalton> oh sorry, i'll handle vbox & mesa-demos
[12:23] <mlankhorst> tseliot: not sure, it's in the x-staging ppa, dno if it's in the archive
[12:23] <tseliot> let me check
[12:24] <mlankhorst> doesn't seem to be atm
[12:24] <tseliot> yep, it was me
[12:25] <tseliot> mlankhorst: where shall I upload them?
[12:25] <mlankhorst> -proposed
[12:25] <mlankhorst> or whereever those blobs go
[12:26] <tseliot> mlankhorst: I don't see nvidia-tegra anywhere in the archive. I guess you mean in saucy?
[12:27] <mlankhorst> yeah
[12:27] <mlankhorst> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra3
[12:31] <tseliot> ogra_: do you mind if I update nvidia-graphics-drivers-tegra3 and nvidia-tegra-codecs-cardhu in Saucy?
[12:31] <tseliot> ogra_: you can review them in this PPA: https://launchpad.net/~canonical-x/+archive/x-staging/+packages
[12:33] <ogra_> tseliot, well, we dont use them anywhere anymore
[12:33] <ogra_> so feel free to do what you want :)
[12:34] <tseliot> ogra_: oh, ok, thanks
[12:34] <ogra_> note that xorg will not be upgraded to 0.14 in saucy arm
[12:34] <mlankhorst> ogra_: it may, there's a xserver it could use
[12:34] <ogra_> so if they are not backwards compatible to the old ABi it will break
[12:35] <ogra_> mlankhorst, so you got new PVR drivers for panda ?
[12:35] <mlankhorst> no, but I could build a x1.14 for arm that was backwards compatible enough with all abi reverts
[12:36] <ogra_> well, as long as panda desktop does still work with compiz, just go ahead
[12:36] <mlankhorst> if you install xserver-xorg-core-omap-revert from the ppa things work
[12:36] <ogra_> erm
[12:36] <ogra_> that would break
[12:37] <ogra_> unless we will force that thing onto all arm users
[12:37] <ogra_> (you would have to seed it in ubuntu-desktop ... we dont have any subarch support in seeds)
[12:38] <mlankhorst> sort of.. you can add it separately, it's similar to the lts stack
[12:39] <mlankhorst> in fact it's identical :-)
[12:41] <tseliot> mlankhorst: maybe I should hold off the upload until a transition path is available?
[12:43] <Mirv> unity 7.0.2+13.10.20130704-0ubuntu1 built at the daily-build, installs and runs fine
[12:44] <mlankhorst> ogra_: but I tested on my pandaboard, I could install xserver-xorg-core-omap-revert, not install anything and only cause the other drivers to be uninstalled, while pvr kept running
[12:44] <ogra_> mlankhorst, so how would you make sure this is installed on a panda but not on any other ubuntu-desktop installs ?
[12:45] <mlankhorst> add it to the panda image
[12:45] <mlankhorst> it needs pvr anyway
[13:00] <mlankhorst> ogra_: would that work for you?
[13:01] <ogra_> well, not sure i will have to look into the lvecd-rootfs code if there is special casing for panda
[13:01]  * ogra_ doesnt really work on desktops anymore ... so i dont have such stuff in the top of my head
[13:01] <seb128> ogra_, do we still care about panda out of "having it working for testing apps"?
[13:02] <ogra_> seb128, not more than that, no
[13:02] <ogra_> but it is our only arm desktop image we have left
[13:02] <seb128> well, we can seed the right xserver there and be done then?
[13:02] <ogra_> so it is essential to keep it running (unless someone decides for another arch or so)
[13:02] <ogra_> seb128, there are many community ports, i wouldnt want to break u-desktop for them
[13:03] <seb128> ogra_, well, ubuntu-desktop would depends on the right server
[13:03] <ogra_> we usually have some special casing code for subarches in livecd-rootfs, should be doable to do something panda specific there
[13:03] <seb128> ogra_, the users who remove ubuntu-desktop are on their own
[13:03] <ogra_> thats what i mean, ubuntu-desktop shouldnt depend on any server :)
[13:03] <mlankhorst> well either the image installs powervr, in which case it is already special, or it doesn't, in which case there's no acceleration and the new xserver could be used just fine, and installing powervr means swapping out the xserver..
[13:03] <ogra_> it doesnt on x86
[13:04] <mlankhorst> either way I don't see a blocker :-)
[13:05] <ogra_> how about making the xseerver package just a dep of pvr
[13:05] <ogra_> :)
[13:05] <ogra_> that should be the easiest ... and reflects the problem (only because of pvr we actually need that xserver rollback)
[13:06] <mlankhorst> replaces: xserver-xorg-core, list of all video/input drivers, depends: xserver-xorg-core-omap-rename, xserver-xorg-video-omap-rename, xserver-xorg-input-evdev-omap-rename ?
[13:06] <mlankhorst> oh god that's so nasty it might just work..
[13:06] <ogra_> yeah
[13:06] <ogra_> haha
[13:06] <mlankhorst> anyway that would need some fixing, is it ok not to block the general xorg-stack for that? :P
[13:07] <ogra_> sure
[13:08] <ogra_> tseliot, do you by chance also have ventana drivers (tegra2) ?
[13:08]  * ogra_ isnt sure anymore if cardhu was backwards compatible to tegra2 or not 
[13:09] <tseliot> let me check
[13:10] <ogra_> our biggest userbase on arm is still the ac100 (this thing seems to survive forever) ... so having something for them that works with recent xorg would be good
[13:14] <tseliot> ogra_: there is a driver for Ventana too: https://developer.nvidia.com/linux-tegra
[13:15] <tseliot> the last release which will support ventana
[13:15] <ogra_> yes, and teher is a package in ubuntu, would you mind updating that alongside the cardhu ??
[13:15] <tseliot> ogra_: sure
[13:16] <ogra_> tseliot, thanks :)
[13:16] <tseliot> np
[13:38] <mlankhorst> tseliot/tjaalton: is the rest uploaded?
[13:39] <tseliot> mlankhorst: no, sorry not yet
[13:43] <Laney> seb128: can you subscribe the system settings team to bugs for the package?
[13:43] <seb128> Laney, sure
[13:43] <seb128> Laney, done
[13:44] <Laney> merci
[13:48] <Mirv> seb128 / didrocks: unity 7.0.2+13.10.20130704-0ubuntu1 built all fine, but autopilot failed (26 failures, 14 with the last successful build)
[13:48] <Mirv> so not total failure, just more failing test cases
[13:48] <seb128> Mirv, :-( what tests started failing?
[13:50] <Mirv> seb128: diff is at http://pastebin.ubuntu.com/5843573/
[13:50] <Mirv> (combined ati+intel results, different results for both)
[13:51] <seb128> Mirv, can you get bregma or brandon to look at those?
[13:52] <Mirv> seb128: you just highlighted bregma, brandon is having independence day
[13:52] <seb128> ok
[13:52] <Mirv> I need to EOD ~now
[13:52] <seb128> yeah, I meant to ring him ;-)
[13:52] <seb128> Mirv, I will track that from there, thanks
[13:52] <tjaalton> mlankhorst: not yet
[13:53] <Mirv> one option would be to just re-run the tests with cu2d-run, to see if anything changes, second option to get someone to fix those new failures, third option to lax the failure restrictions
[13:53] <Mirv> seb128: thanks
[13:53] <seb128> Mirv, seems like the issues have to do with the barrier ... which is not a surprise :/
[13:54] <Mirv> yeah probably legit findings, at least partially, so cu2d doing its job
[13:54] <bregma> yeah, already getting complaints about barrier stuff working in unexpected ways
[13:56] <tjaalton> what kind of ways?
[13:58] <seb128> tjaalton, https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/330/testReport/
[13:59] <tjaalton> i've no idea what those mean in practise :)
[13:59] <seb128> there is supposed to have videos of the tests
[13:59] <seb128> but I can't find them
[14:00] <seb128> need to be away for a meeting
[14:00] <seb128> bbiab
[14:00] <bregma> got a complaint you can't move the mouse between monitors if sticky edges are enabled
[14:01] <seb128> weird, I had that before upgrading my xserver
[14:01] <seb128> not after
[14:01] <seb128> Laney, cyphermox, https://plus.google.com/hangouts/_/d05e1507618eb7fc780cc7b581f2d5840f7874ee
[14:01] <Laney> coming, just double checking mic works :P
[14:03] <seb128> bah, firefox hates me
[14:03] <tjaalton> huh, barriers don't work at all for me atm
[14:03] <Laney> wtf
[14:03] <Laney> just got randomly logged out while i was in the hangout
[14:04] <seb128> Laney, works?
[14:04] <Laney> trying to get back, sec
[14:09] <tjaalton> background on extended monitor doesn't update
[14:09] <tjaalton> who broke all this :)
[14:11] <didrocks> bregma: seb128: would be interesting to see what version of xservers was installed
[14:12] <didrocks> maybe not all deps are pulled?
[14:12] <tjaalton> dist-upgrade right now would remove unity
[14:12] <didrocks> tjaalton: you do have -proposed, right?
[14:12] <tjaalton> no
[14:13] <tjaalton> though I have the ppa enabled
[14:13] <seb128> Laney, graa, sorry, hangout too my firefox down, I'm rejoining from chromium
[14:13] <didrocks> ah, making sense :)
[14:13] <tjaalton> might mess things
[14:13] <Laney> HAHA
[14:13] <didrocks> tjaalton: yeah, don't dist-upgrade, the breaks is there to protect you normally
[14:13] <tjaalton> didrocks: right
[14:16] <seb128> Laney, cyphermox: sorry, my laptop is swapping I'm having an hard time to join back
[14:16] <seb128> yeah for tech...
[14:18] <seb128> Laney, cyphermox, mpt, larsu: I need to reboot, my laptop is screwed, end up if there is nothing else to talk about, we will do another one next week with tu.s guys + mardy
[14:25] <tjaalton> mlankhorst: virtualbox uploaded
[14:28] <tjaalton> mesa-demos too
[14:29] <Laney> hangouts work pretty well from my phone
[14:29] <cyphermox> Laney: "How do I quit?" :D
[14:29] <Laney> :D
[14:29] <Laney> turns out you just press the big button
[14:29] <cyphermox> heh
[14:30] <cyphermox> I wouldn't even have the luxury of trying on the phone now, just running Ubuntu
[14:30] <cyphermox> we totally need someone to write a hangout client
[14:30] <Laney> it's so inexplicable that the mic doesn't work on the pc
[14:30] <Laney> like, i can record myself in audacity
[14:30] <Laney> but hangouts are just silent
[14:30] <cyphermox> Laney: have you tried applying the trick that didrocks was recommending before?
[14:30] <cyphermox> something about auto mic level balance in a dotfile
[14:30] <mlankhorst> tjaalton: thanks
[14:30] <Laney> I thought I did
[14:31] <Laney> let me check
[14:31] <cyphermox> http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring
[14:31] <cyphermox> maybe that can help ?  ^
[14:32] <Laney> i've definitely done that before but maybe not on this installation?
[14:32] <Laney> laney@raleigh> grep audio-flags options                                                                    ~/.config/google-googletalkplugin
[14:32] <Laney> audio-flags=1
[14:32] <Laney> :(
[14:33] <Laney> ah well
[14:33] <didrocks> waow I didn't know that trick was popular :)
[14:33] <Laney> it is an excellent trick
[14:34] <didrocks> (written on 31 december, you will note :p)
[14:34] <Laney> new years hangout
[14:34] <cyphermox> didrocks: yeah, it's very helpful
[14:35] <didrocks> happy it helps (or not in this case for Laney though)
[14:35] <Laney> it did help before
[14:35] <Laney> had some problems during vUDS
[14:37] <tseliot> mlankhorst: so nvidia-tegra3 and cardhu are in. I'll need some more time for tegra2
[14:39] <Laney> cyphermox: http://pad.ubuntu.com/uds-1305-client-s-touch-system-settings
[14:39] <Laney> it'd be good to reference https://wiki.ubuntu.com/Bluetooth#phone and explain what can be done from the qmenumodel and what needs to be written
[14:40] <Laney> and/or in https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Avv0-oHGVtjAdGRpUUpua2F0OU9RSzhhZ0hOcGJlWmc#gid=0
[14:40] <didrocks> ii  xserver-common                            2:1.13.3-0ubuntu13                      all          common files used by various X servers
[14:40] <didrocks> ii  xserver-xorg                              1:7.7+1ubuntu4                          i386         X.Org X server
[14:41] <didrocks> mlankhorst: bregma: shouldn't the latest xorg be pullsed by unity dependencies? ^
[14:42] <seb128> back
[14:42] <seb128> sorry, had to power off the laptop for a bit, it wouldn't go back to normal speed
[14:42] <seb128> like booting was 1m30 instead of 15s
[14:42] <didrocks> seb128: wb
[14:42] <didrocks> FYI:
[14:42] <didrocks> ii  xserver-common                            2:1.13.3-0ubuntu13                      all          common files used by various X servers
[14:42] <didrocks> ii  xserver-xorg                              1:7.7+1ubuntu4                          i386         X.Org X server
[14:42] <didrocks> shouldn't the latest xorg be pulled by unity dependencies? ^
[14:42] <mlankhorst> the xorg isn't important, except perhaps on arm
[14:43] <seb128> didrocks, I guess, I though it needed the new libxi/libxfixes
[14:43] <didrocks> mlankhorst: what package should I check?
[14:43] <seb128> mlankhorst, it is, the barriers don't work if you update the libx without the server
[14:43] <seb128> didrocks, xserver-xorg-core?
[14:43] <didrocks> ii  libxi6:i386                               2:1.7.1.901-1                           i386         X11 Input extension library
[14:43] <didrocks> ii  xserver-xorg-core                         2:1.13.3-0ubuntu13                      i386         Xorg X server - core server
[14:43] <didrocks> (as the -common)
[14:44] <seb128> that's the issue
[14:44] <seb128> we need an updated depends on or a break somewhere
[14:45] <didrocks> seb128: FYI: I looked at the dpkg after the upgrade in the job artefact
[14:45] <didrocks> yep
[14:45] <didrocks> (you have before upgrade, after upgrade)
[14:45] <didrocks> I was surprised, because the -check job would have failed without "check strict dependencies". But yeah, it's not pulling latest
[14:46] <seb128> it's pulling the new libs
[14:46] <seb128> which is enough to build
[14:46] <didrocks> I mean during check
[14:46] <seb128> right
[14:46] <didrocks> I guess libxi should breaks or deps on latest xorg-server
[14:47] <seb128> not sure if it's libxi or unity that should
[14:47] <seb128> the lib seems to work
[14:47] <didrocks> unity already takes latest libxi
[14:47] <seb128> unity doesn't do what you expect though
[14:47] <seb128> right
[14:47] <didrocks> and it's using the barrier throught libxi, right?
[14:47] <seb128> but unity should perhaps depends on xorg >>
[14:47] <didrocks> so it means libxi is using a broken feature?
[14:47] <didrocks> (that's my bare understanding)
[14:47] <seb128> tjaalton, mlankhorst: ^
[14:47] <seb128> didrocks, I've no idea how the barrier work
[14:47] <didrocks> seb128: from the code, the barriers are just accessed through libxi
[14:48] <mlankhorst> it's complicated, it's an abi mess because of the earlier versions of libxi/libxfixes
[14:48] <didrocks> accessed*
[14:48] <seb128> I guess we can make libxi Breaks: xorg-server <<
[14:48] <mlankhorst> but the ones in the archive should work
[14:49] <tseliot> ogra_: do you happen to have the sources of nvidia-tegra-ventana-codecs somewhere (I need the packaging scripts)? I can't find them on launchpad
[14:49] <seb128> mlankhorst, the issue is that if you have xorg 1.13, upgrade libxi, restart unity, your barriers are broken
[14:50] <seb128> mlankhorst, can you make libxi Breaks: xserver << new
[14:50] <seb128> mlankhorst, so upgrading libxi forces a server upgrade
[14:50] <didrocks> yeah, the only include is libxi
[14:51] <mlankhorst> seb128: hm, I guess. Would it need to be kept until saucy is released or could we just sync to next libxi/xfixes afterwards?
[14:52] <Laney> in theory you should keep it until the release
[14:53] <seb128> right
[14:53] <seb128> it's not like it was a big diff to merge
[14:53] <seb128> libxi doesn't change every week either
[14:55] <mlankhorst> hm ok
[14:55] <mlankhorst> I guess libxfixes and libxi both need an explicit break on unity and xserver then
[14:56] <seb128> they don't on unity
[14:56] <seb128> just on the server
[14:56] <seb128> the new server already breaks unity
[14:56] <mlankhorst> just to be paranoid
[14:57] <seb128> no need
[14:58] <mlankhorst> well it's unity that those libs break, not xserver :P
[14:59] <seb128> the libxi barrier code has a xserver side no?
[14:59] <seb128> well, feel free to break on unity as well if you want
[14:59] <mlankhorst> it breaks old unity because it fails to link correctly
[14:59] <seb128> ?
[14:59] <Laney> what if you have new libx*/unity and old xserver?
[14:59] <mlankhorst> impossible, due to breaks
[14:59] <seb128> new unity + new libxi + new libfixes + old xserver = non working barrier
[14:59] <seb128> possible
[15:00] <seb128> that's what we just tested and that is broken
[15:00] <seb128> barriers are solid
[15:00] <seb128> you can't go through
[15:00] <mlankhorst> oh
[15:00] <mlankhorst> doesn't unity have a breaks on old xserver then?
[15:00] <seb128> no, why should it?
[15:00] <seb128> it just use libxi
[15:00] <seb128> if new libxi is incompatible with the old server it should force a server upgrade
[15:01] <seb128> which seems to be the case
[15:01] <seb128> which is why we are suggesting to make new libxi breaks xserver << new
[15:01] <mlankhorst> new unity needs a break on xserver << 1.14
[15:02] <mlankhorst> but fine I'll do it by proxy
[15:12] <xnox> firefox-globalmenu is moving into universe is that correct?
[15:12] <xnox> or is it back to our discussion of where to seed it?!
[15:14] <mlankhorst> ok uploaded libxi/fixes
[15:15] <seb128> mlankhorst, thanks
[15:15] <seb128> didrocks, ^
[15:16] <didrocks> great ;)
[15:16] <didrocks> tests with forcing dist-upgrade running
[15:17] <mlankhorst> oops, should have used dch -r
[15:18] <mlankhorst> now it shows jcristau as uploader, can it be undone? :P
[15:20] <seb128> lol
[15:21] <desrt> seb128: good morningish
[15:21] <seb128> desrt, good preafternoonish
[15:21] <seb128> ;-)
[15:22] <seb128> Laney, https://code.launchpad.net/~seb128/ubuntu-system-settings/backend-for-about-and-storage/+merge/173043
[15:22] <seb128> Laney, if you could review it, I would welcome ... it's mostly a copy of yours with some rename and a bit less code (I don't need signal/updates, there is no way the OS is going to change while the panel is open)
[15:23] <Laney> I was mainly thinking of desktop there
[15:23] <seb128> Laney, desktop?
[15:24] <seb128> Laney, is that a reply to my "there is no way the OS is going to change"? ;-)
[15:24] <Laney> yeah
[15:24] <seb128> Laney, well, if you dist-upgrade with the info panel update and you don't get the version updating live that's not going to be the end of the world :p
[15:24] <seb128> Laney, I doubt gnome-control-center does refresh dynamically like that either ;-)
[15:25] <seb128> with the info panel *open*...
[15:25] <Laney> yeah, proabably not
[15:25] <Laney> and that's read-only anyway
[15:26] <Laney> ah, QSettings, that's cool
[15:26] <Laney> was wondering what that was about
[15:30] <xnox> Laney: the same/different background transitions look awesome in the backgrounds settings!
[15:31] <Laney> xnox: thanks, was quite ... interesting to figure that one out
[15:31] <Laney> got some review comments on my SDK widget to include that there earlier
[15:31] <Laney> hopefully will be reusable soon
[15:45] <Laney> seb128: feel free to tell me you don't want to do those nitpicks. I only push back a bit because this is the best time to get little things like that tidied up.
[15:47] <seb128> Laney, those comments are welcome
[15:47] <seb128> Laney, where would you suggest getting the infos? in the constructor function?
[15:47] <Laney> no, Kaleo advised me to do that in the getter
[15:48] <Laney> do something like if (m_OsVersion.isEmpty() || m_OsVersion.isNull()) // get the stuff
[15:48] <seb128> oh ok
[15:49] <mlankhorst> seb128: should be ok with the new versions
[15:49] <seb128> mlankhorst, great, unity tests are running, let's see how that goes
[15:49] <seb128> Laney, I guess constructor/getter is a question of start time hit against lazy loading
[15:51] <Laney> exactly
[16:01] <seb128> Laney, ok, updated, thanks for the review ;-)
[16:01] <Laney> thanks!
[16:01] <Laney> I can't think how to do the dynamic icon thing
[16:01] <seb128> Laney, what dynamic icon?
[16:02] <Laney> for bluetooth
[16:02] <Laney> like it has to be dimmed in some situations
[16:02] <Laney> and get an overlay in others
[16:03] <seb128> seems like somebody to bother the toolkit guys about :p
[16:03] <Laney> let's see if just providing a PageComponent lets it go into the grid
[16:03]  * Laney suddenly remembers to push gsd
[16:03] <seb128> Laney, http://developer.ubuntu.com/api/ubuntu-12.10/qml/mobile/qml-ubuntu-components-popups0-defaultsheet.html
[16:04] <seb128> Laney, isn't that working for the popups?
[16:04] <Laney> what popups?
[16:05] <seb128> Laney, https://wiki.ubuntu.com/Bluetooth?action=AttachFile&do=get&target=phone-bluetooth-pair.png
[16:05] <seb128> Laney, I though that's what you called "overlay"
[16:05] <Laney> no
[16:05] <seb128> the pin dialog
[16:05] <seb128> oh ok
[16:05] <Laney> this: In the System Settings overview, the “Bluetooth” item should be dull if Bluetooth is off, glowing if Bluetooth is on, and have a headset emblem if any headset is paired.
[16:05] <seb128> oh!
[16:05] <seb128> seems like we need 3 icons
[16:05] <Laney> yeah
[16:06] <seb128> and a bit of smartness in entrycomponent.qml
[16:06] <Laney> I was looking to see if it could be done in the .settings somehow
[16:06] <seb128> I doubt it
[16:06] <Laney> we don't have any EntryComponents which insert into the grid currently
[16:06] <seb128> oh, good point
[16:06] <Laney> let me check that it works
[16:06] <seb128> well, I think you can have one
[16:06] <seb128> the default is just to not have it since it's not required
[16:07] <seb128> you can specify an entry in the .settings
[16:07] <Laney> I guess so too
[16:07]  * Laney tries it
[16:09] <Laney> seb128: did you push your branch?
[16:11] <seb128> Laney, I did, and I hate bzr not using --remember by default :p
[16:11] <seb128> Laney, pushed to the right one this time
[16:11] <Laney> as long as you didn't push to trunk :P
[16:12] <seb128> Laney, no, that part is ok ;-)
[16:12] <Laney> http://ubuntuone.com/5RkzGARfpzefaSQ2shCayj
[16:12] <Laney> I think I get this bug much worse than you ...
[16:14] <Laney> (yes, having that EntryComponent works)
[16:16] <seb128> shrug
[16:16] <seb128> Laney, did you report it? that seems an ubuntu toolkit bug to me
[16:16] <Laney> it's the two I filed on u-s-s
[16:22] <seb128> Laney, I pinged #ubuntu-app-devel for triaging guidance on the product at least
[16:24] <seb128> ogra_, how do I check if my image is flipped or not?
[16:25] <seb128> hum, that seems like unflipped image
[16:37] <Laney> if adb shell gives you an ubuntu environment is one way
[16:41] <m4n1sh> jbicha: please try out the 0.9.6 release
[16:42] <m4n1sh> I disabled the checkbox in it, hopefully
[16:42] <m4n1sh> it worked on my side atleast
[16:42] <jbicha> m4n1sh: https://launchpad.net/ubuntu/+source/activity-log-manager/0.9.6-0ubuntu1
[16:43] <jbicha> I tested with 0.9.6 and the box was disabled but visible; I didn't want it visible because it's confusing
[16:43] <m4n1sh> jbicha: I spent the last hour trying top package it
[16:44] <m4n1sh> jbicha: https://code.launchpad.net/~zeitgeist/ubuntu/saucy/activity-log-manager/update-to-0-9-6/+merge/173060
[16:44] <m4n1sh> I just missed it
[16:44] <jbicha> I'm sorry, I didn't realize you didn't know I was working on it
[16:44] <m4n1sh> jbicha: never mind, this was tough. It is still a learning experience for me
[16:45] <m4n1sh> took me more than an hour actually to package it, learnt a lot
[16:45] <m4n1sh> jbicha: can you push your changes to lp:ubuntu/activity-log-manager ?
[16:46] <jbicha> m4n1sh: that should happen automatically in the next hour or so
[16:48] <m4n1sh> jbicha: do you suggest to move to valac 0.20?
[16:48] <m4n1sh> right now it is on 0.16
[16:48] <jbicha> m4n1sh: hmm? it builds fine against vala 0.20
[16:49] <m4n1sh> in the build system it requires 0.16, I didnt check the deps
[16:49] <jbicha> as long as it builds against the default vala in distros (Debian & Ubuntu both use 0.20) I wouldn't worry about it
[16:50] <m4n1sh> jbicha: nautilus needs to be moved to zeitgeist-2.0 too https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1197569
[16:50] <ubot2`> Ubuntu bug 1197569 in upstart-app-launch (Ubuntu) "Move from zeitgeist-1.0 to zeitgeist-2.0" [Undecided,New]
[16:51] <m4n1sh> I would work on it now. Would submit the MP in a few hours
[16:53] <mhr3> seb128, ping?
[16:53] <seb128> mhr3, hey
[16:53] <mhr3> seb128, hola, i have a tough question for you
[16:54] <mhr3> seb128, how do i make `bzr bd` build me a armhf deb on my amd64 machine? :)
[16:54] <seb128> mhr3, you better ask #ubuntu-devel about cross compiling
[16:54] <seb128> xnox/doko/cjwatson
[16:54] <jbicha> mhr3: do you use sbuild?
[16:54] <mhr3> jbicha, no
[16:55] <jbicha> you should ;)
[16:55] <mhr3> jbicha, or maybe... i just let bzr bd do what it wants
[16:56] <xnox> mhr3: bzr bd --builder debuild -aarmhf
[16:56] <xnox> mhr3: but you should have cross-toolchain and cross-builddeps installed
[16:57] <mhr3> xnox, wow, it really is that simple?
[16:57] <xnox> mhr3: sudo apt-get -aarmh build-dep $pkg
[16:57] <xnox> mhr3: plus enable armhf foreign arch in dpkg & sources.
[16:57] <mhr3> xnox, awesome, will try, thx
[16:57] <xnox> mhr3: most of it is one time setup.
[16:57] <xnox> mhr3: that's given that your package is cross-buildable.
[16:58] <xnox> mhr3: Here are the auto-cross-builder results of main-ish packges
 seb128, how do i make `bzr bd` build me a armhf deb on my amd64 machine? :)
[16:58] <xnox> mhr3: t
[16:58] <xnox> mhr3: http://people.canonical.com/~cjwatson/cross/armhf/saucy/
[16:58]  * xnox looks at my fingers for typing badly today.
[17:03] <seb128> Laney, want to review my update that addresses your review comment? ;-)
[17:04] <Laney> yeah
[17:04] <Laney> trying to think about how to send data from one EntryComponent to another :-)
[17:04] <Laney> might resume that tomorrow now
[17:10] <Laney> there you go
[17:10] <Laney> now I think it's the perfect weather for a bike ride
[17:10] <Laney> see you
[17:10] <seb128> Laney, enjoy!
[17:18] <mlankhorst> seb128: is there anything missing now for transitioning?
[17:19] <seb128> mlankhorst, still unity, but I guess we will check tomorrow morning and unblock then
[17:19] <mlankhorst> ok
[17:19] <seb128> mlankhorst, we need Laney to unblock anyway and he's biking atm
[17:19] <seb128> mlankhorst, so good time to call it a day ;-)
[17:20]  * mlankhorst was toying some with wine anyway
[17:20] <mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=47824 to be exact
[17:20] <ubot2`> Freedesktop bug 47824 in Other "osmesa using --enable-shared-glapi depends on libgl" [Normal,New]
[17:20] <mlankhorst> not being part of the wine source code increases the chance a lot that it will get accepted..
[17:42] <m4n1sh> jbicha: activity-log-manager SRU for quantal is LP  #1197904
[17:42] <ubot2`> Launchpad bug 1197904 in activity-log-manager (Ubuntu) "[SRU] Fix activity-log-manager 0.9.4 in quantal for wrong usage of GtkApplication" [Undecided,New] https://launchpad.net/bugs/1197904
[17:42] <m4n1sh> wel, changelog has to be updated to add 1197904
[17:45] <jbicha> m4n1sh: and raring?
[17:45] <m4n1sh> jbicha: working on it too
[17:45] <jbicha> you could have repurposed an existing bug for the sru
[17:45] <m4n1sh> this one for quantal is old
[17:46] <m4n1sh> yes, but I thought a clean new bug would be better
[18:11] <Saviq> jbicha, thanks for the line in the SimpleSbuild wiki, problem with that is it uses QEMU, which we've had problems repeatedly when testing / pbuilding
[18:14] <Saviq> jbicha, I'll try now and see what's my mileage
[18:25] <m4n1sh> jbicha: done for raring too https://code.launchpad.net/~zeitgeist/ubuntu/raring/activity-log-manager/fix-1197904-wrong-gtkapplication-usage/+merge/173073
[23:36] <m4n1sh> Ubuntu GNOME is not listed under distributions in launchpad - https://launchpad.net/distros
[23:36] <m4n1sh> how to log a bug specific to this distro?
[23:43] <jbicha> m4n1sh: Ubuntu GNOME is an Ubuntu flavor, not a full-fledged separate distro
[23:44] <m4n1sh> jbicha: so launchpad.net/ubuntu-gnome is the place to log the bugs for flavor specific bugs/wishlist?
[23:44] <jbicha> just report bugs the same way you'd report against anything else in Ubuntu
[23:45] <jbicha> there's also #ubuntu-gnome
[23:45] <m4n1sh> you asked for standalone activity-log-manager for ubuntu-gnome
[23:45] <m4n1sh> but it isnt installed in ubuntu-gnome
[23:46] <jbicha> you can report that against ubuntu-gnome-meta