[07:31] <ricotz> didrocks, hi, i hope you can take a look at this https://code.launchpad.net/~ricotz/gnome-control-center-signon/fix-packaging/+merge/150422
[07:32] <didrocks> ricotz: approved! Thanks :)
[07:32] <ricotz> thanks
[07:58] <MCR1> Is Jenkins ill ? I am sure this works: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix808909-addhelper-autostart-fails/+merge/150474
[08:01] <MCR1> mmrazik: Hi :) Can you answer this ? ^^
[09:54] <sil2100> Only 3 failures for ibus \o/
[10:02] <didrocks> nice sil2100 :)
[12:07] <mmrazik> didrocks: just looking on the dir structure in cupstream2distro-config and I think we will need sth like stacks/head/jenkins-templates dir
[12:08] <mmrazik> in the past we have been changing the templates and it would be good to keep the old version for old stacks
[12:08] <didrocks> mmrazik: didn't we say that the templates are per "job type" rather?
[12:08] <didrocks> like daily-release and so on?
[12:09] <mmrazik> didrocks: I fear it will be per job type and per release
[12:09] <mmrazik> but the truth is we can split it once we have an immediate need
[12:09] <mmrazik> which we don't have ATM
[12:10] <didrocks> mmrazik: or the deploy tool can be per release
[12:10] <didrocks> mmrazik: like giving a template directory
[12:10] <mmrazik> didrocks: ack
[12:10] <didrocks> mmrazik: btw, rev9 is the last one for now, I'm changing my tools to support this
[12:11] <didrocks> (out of tree config stacks)
[12:11] <didrocks> the deploy tool is already functional
[12:12] <mmrazik> ok
[13:03] <didrocks> mmrazik: ok, I think I've updated all the tools and write tests for the automated part to the new config and template locations in a flexible manner
[13:04] <mmrazik> didrocks: ack. I'm a bit stuck trying to generate the yaml from our current configs (its progressing just a bit slower than I thought)
[13:05] <didrocks> ack, good luck! :)
[13:54] <mhr3> mterry, ping
[13:54] <mterry> Mirv, can you explain your request for compiz <IP_ADDRESS> again?  I don't think I have that code anymore on my hard drive.  But I didn't upload that, just provide a patch for it
[13:54] <mterry> mhr3, hi
[13:54] <mhr3> mterry, morning, i'd like to ask about the unity stack
[13:55] <mhr3> mterry, we'd like updated dee in raring so ppas building related stuff continue working
[13:55] <mhr3> which they don't atm
[13:56] <mterry> mhr3, sure
[13:56] <mterry> mhr3, the stack failed to build last night, let me see
[13:56] <Mirv> mterry: I mean that the packaging branch is out of date, doesn't have the exact version that is in archives. if it's not found, I need to manually mimick the archive version in my branch before making additional changes
[13:57] <Mirv> mterry: who uploaded it eventually?
[13:57] <mterry> Mirv, I think you'll have to do that.   You did, it looks like
[13:57] <mhr3> mterry, yea, i was talking to didier yesterday he said it's not there cause something down the line failed
[13:57] <Mirv> mterry: I don't have upload rights :P
[13:57] <mterry> Mirv, maybe I sponsored your patch then
[13:58] <Mirv> mterry: anyhow, if you don't have it, then I'll just grab the archive version and put it on top of my bzr branch
[13:58] <mterry> Mirv, yup, I did
[13:58] <mterry> Mirv, OK, thanks.  Sorry for the trouble
[13:58] <Mirv> mterry: no problem, the hunt for the distro branches is commonplace.. (a rock solid process/system for that would be welcome)
[13:59] <mterry> Mirv, though really, lp:ubuntu/precise/compiz *should* be up to date.  I see that it isn't, but that's the fault of a script
[13:59] <mterry> Mirv, in future, hopefully it's just trunk  ;)
[13:59] <mterry> In this post-inline world
[14:01] <mterry> mhr3, OK, I've restarted the stack.  Hopefully it will publish this time
[14:01] <mhr3> mterry, and if it fails again?
[14:02] <mterry> cyphermox, what's the story with the indicator stack
[14:02] <mterry> ?
[14:02] <mhr3> do you an override "but publish this part anyway"?
[14:02] <mhr3> *do you have an
[14:02] <mterry> mhr3, it shouldn't.  The build failures were transient.  Another failure is likely to be transient as well.  I can publish manually if I can't get things working as they are
[14:03] <mhr3> mterry, ok, let's see what happens then :)
[14:05] <Mirv> mterry: yes, the post-inline world is much more sane
[14:29] <cyphermox> mterry: do you mean the ido build failure?
[14:30] <mterry> cyphermox, the whole thing is yellow/red.  I just didn't know if it was serious (i.e. if my unity stack looks OK, is the indicator stack a reason for me not to release)
[14:30] <cyphermox> heh
[14:30] <cyphermox> is there anything in unity that depends on new indicators, aside maybe for hud stuff?
[14:36] <mterry> cyphermox, I don't think so...  mhr3: do you know of anything in recent unity commits that needs anything special from the indicator stack?
[14:36] <cyphermox> just finishing up checking but it doesn't look like there is anything
[14:37] <mterry> cyphermox, looks like indicator stack is yellow at least in part because hud has a distro release that needs to land back in trunk
[14:38] <cyphermox> yeah, I just need to approve your hud merge, and fix up ido by fixing xorg-gtest's mess
[14:38] <cyphermox> yeah
[14:39] <cyphermox> mterry: hud done --
[14:40] <cyphermox> xorg-gtest was in progress because I still need to finish up some changes in the m4 and then talking to upstream about it, but I should be able to complete that today
[14:41] <cyphermox> or if not, at least you know, fix ido temporarily enough that it will be happy to build
[14:44] <mhr3> mterry, nope, larsu might know about indicators
[14:46] <mterry> cyphermox, ah, thanks for approving the bustle one too
[14:48] <didrocks> cyphermox: mterry: kenvandine: robru: FYI, I've changed cupstream2distro to support out of tree config
[14:48] <robru> didrocks, cool
[14:48] <didrocks> meaning now that the deployement tools are in lp:cupstream2distro-config
[14:49] <didrocks> robru: already awaken? jetlag? :/
[14:49] <robru> didrocks, yeah, jetlag really bad. ;-)
[14:49] <didrocks> robru: waow, I hope you won't need yet-another-week of adjustement :)
[14:49] <kenvandine> didrocks, awesome
[14:49] <didrocks> so the stacks are in the stacks directory of lp:cupstream2distro-config
[14:50] <didrocks> and cu2d-update-stack in the daily-release directory
[14:50] <kenvandine> didrocks, is that dee fix still blocked by the unity stack?
[14:50] <didrocks> kenvandine: yeah, see the discussion above between mhr3 and mterry ^
[14:50] <didrocks> kenvandine: but hopefully, the new run will all go smoothly :)
[14:50] <kenvandine> great
[14:51] <didrocks> so all, FYI, I changed some parts of the scripts (with tests) to support this new layout
[14:52] <didrocks> it can impact the publishing and copy2distro part
[14:52] <didrocks> those are under tests, so it should work
[14:52] <didrocks> but if you see anything weird, ping/harass me :)
[14:52] <didrocks> (I redployed earlier today the new version on prod machines)
[14:52] <mterry> didrocks, OK.  This is general cleanup, or do we get new features with this?
[14:53] <didrocks> mterry: out of tree with support of subdirectories :-)
[14:53] <didrocks> + the 2 fixes from yesterday:
[14:53] <didrocks> - support the UNRELEASED case for a one commit only with a changelog content
[14:54] <didrocks> - don't use pull-lp-source but use our own process and launchpad credentials supporting multiple LP connection at a time
[14:54] <mterry> cool
[14:56] <didrocks> also I moved some of jibel's tool in trunk and remove some hardcoded bits in the template in a default configuration
[14:56] <didrocks> like system path and so on
[15:03] <cyphermox> mterry: your bustle branch was including all the changes currently in distro, right?
[15:04] <mterry> cyphermox, yeah
[15:05] <cyphermox> oops
[15:05] <cyphermox> it was in fact missing your change for debian/hud-tools.install
[15:07] <cyphermox> grr there are lots of differences between the two diffs
[15:11] <mterry> cyphermox, it was?  I thought I fixed that
[15:12] <cyphermox> mterry: yeah, the file wasn't included in that merge
[15:12] <mterry> cyphermox, that's intentional
[15:12] <cyphermox> oh ok
[15:12] <cyphermox> there are also some differences in the build-depends, I guess that's another different merge?
[15:12] <mterry> cyphermox, so distro commented out that line in the .install.  But my branch fixed the need for the commenting, so I didn't include that change
[15:13] <cyphermox> ah
[15:13] <mterry> cyphermox, yeah, the build-depends were dropped in distro to prevent it running the tests
[15:13] <cyphermox> alright
[15:13] <mterry> cyphermox, but the fix allows the tests, so...
[15:13] <cyphermox> sure
[15:13] <cyphermox> mterry: makes total sense, I'll just get back to my other stuff
[15:13] <mterry> Hopefully the only change that's worth taking was the changelog
[15:13] <cyphermox> yep
[15:26] <mterry> didrocks, sil2100: looks like this latest unity run is passing checks fine.  ~20 test failures per config.  I'm inclined to ratchet down the allowed tests these days, now that ibus and some other great test fixes have landed (thanks sil2100!!).  We currently allow 33 failures, 14 regressions.  How about we ratchet down to 25 failures, 10 regressions?
[15:26] <sil2100> mterry: hi! Let me share a doc with you
[15:27] <didrocks> mterry: I like this spirit! :-)
[15:27] <sil2100> mterry: np. for the fix - still need to polish the rough edges, since I still see 3 ibus failures
[15:27] <cyphermox> mterry: you running the current compiz?
[15:27] <mterry> sil2100, yeah, I saw you had a follow-on fix.  But it's good progress  :)
[15:27] <mterry> cyphermox, yeah
[15:27] <sil2100> mterry: I made a document that lists the failures and tries to guess if they're regressions or not
[15:27] <mterry> sil2100, oh!  You're the best
[15:27] <cyphermox> mterry: ok ;) last week we had surprises
[15:27] <didrocks> cyphermox: I think you can relaunch indicators :)
[15:28] <cyphermox> didrocks: beh
[15:28] <cyphermox> indicators is actually having ido fail to build...
[15:28] <didrocks> cyphermox: is it a real one? not transien/timeout?
[15:28] <sil2100> mterry: it's based on build 96, so I have to re-do it for the newest one though ;)
[15:28] <cyphermox> oh, definitely a real ftbfs
[15:28] <sil2100> mterry: but some more fixes are landing! Mine just got approved, andyrock prepared another one which I'm reviewing now
[15:28] <cyphermox> I'll file a merge now to fix this, but it's going to be a temporary fix until I can finish up with xorg-gtest
[15:29] <mterry> sil2100, so counting worse case (the maybes in both categories), we have 13 regressions, 19 failures in that doc
[15:30] <mterry> well, 13 regressions, 26 failures I guess
[15:30] <mterry> I assume those will go down if the doc is updated though
[15:31] <mterry> sil2100, do you think 25 failures, 10 regressions is a reasonable new threshold for failure?  Or do you want less/more wiggle room?
[15:31] <mterry> Actually, a lot of these entries are marked FIXED
[15:35] <andyrock> mterry, sil2100 unity.tests.launcher.test_icon_behavior.LauncherIconsTests.test_unminimize_minimized_immediately_after_show_windows (Single Monitor) should be fixed in trunk
[15:35] <andyrock> unity.tests.launcher.test_keynav.LauncherKeyNavTests.test_launcher_keynav_cancel_on_click_icon(Single Monitor) too
[15:38] <sil2100> mterry: hm, let's maybe wait for tomorrow, and if it's still so low, then let's lower the treshold
[15:40] <mterry> fginther, a check job just failed with:
[15:40] <mterry> [workspace] $ /bin/bash -u /tmp/hudson1642251030477968427.sh
[15:40] <mterry> Calculating results for card ati
[15:40] <mterry> /tmp/hudson1642251030477968427.sh: line 22: BASEDIR: unbound variable
[15:41] <fginther> mterry, looking
[15:41] <mterry> didrocks, is there a way to ask the publishing job to run again, but not in a manual-publish way?
[15:42] <mterry> ah... looks like I can in the web interface
[15:42] <didrocks> mterry: hum, what's the use case?
[15:42] <didrocks> yeah, the web interface should give you that :)
[15:42] <mterry> didrocks, here, we passed all the tests in the check job.  But looks like  a script malfunction marked the job as a failure.  I'd still like the publish job to run to show me all the packaging diffs and such
[15:43] <mterry> And then I'd manually publish if I liked the changes
[15:43] <didrocks> mterry: hum, I don't see the failure in the publishing job. That can be due to my changes today
[15:43] <didrocks> which run?
[15:43] <mterry> didrocks, no, the publishing job never bothered, since the check failed
[15:43] <mterry> check job 91
[15:44] <mterry> http://<IP_ADDRESS>:8080/job/cu2d-unity-head-2.2check/91/console
[15:44] <mterry> didrocks, ^
[15:44] <didrocks> ahah, so it's my fault :)
[15:44] <mterry> fginther, ^ didrocks says he did it
[15:44] <didrocks> mterry: yeah, that was hence the "warning, I changed a lot of things and deployed"
[15:44] <mterry> didrocks, :)
[15:44] <didrocks> now, you see it for real :)
[15:44] <fginther> mterry, ack
[15:45]  * didrocks grr on the templates not being able to test easily
[15:46] <didrocks> mterry: found the typo
[15:47] <didrocks> ok, further grep sounds like everything should be in shape, let me redeploy with the right template
[15:47] <didrocks> mterry: don't run the publisher again now
[15:49] <didrocks> mterry: deployed, you can go back to a normal life :)
[15:49] <didrocks> cyphermox: your turn, doing the same for the indicator stack
[15:52] <mterry> didrocks, cyphermox : I'm inclined to manually publish the unity stack.  Any objections?
[15:53] <didrocks> mterry: if the packaging changes looks cool, yeah, the only error was on my side, everything pass :)
[15:53] <didrocks> cyphermox: indicators ready
[15:53] <mterry> didrocks, are you using the desktop-team screen?
[15:54] <didrocks> mterry: I don't
[15:54] <didrocks> I'm not even ;)
[15:54] <didrocks> webapps/webcreds done
[15:57] <mterry> hrm...  someone was in python/bzr.  They seem done
[16:01] <mterry> didrocks, I updated the unity stack to not include unity-scope-video-remote anymore.  For that change to go live, I'd have to re-deploy right?
[16:03] <mterry> kenvandine, mhr3: dee published
[16:03] <mhr3> mterry, yey! :)
[16:15] <mterry> didrocks, how long does it take for the published packages to appear as pushes to the archive?
[16:16] <kenvandine> mterry, thanks!
[16:19] <mterry> ah, there it goes
[16:28] <didrocks> mterry: publish is a few minutes, then the daemon, is running every 15 minutes on the archive admin box
[16:28] <mterry> didrocks, k.  I was just impatient  :)
[16:28] <MCR1> Could someone please re-approve https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix808909-addhelper-autostart-fails/+merge/150474
[16:28] <MCR1> ?
[16:29] <MCR1> It seems panda-pbuilder was somehow failing to build...
[16:33] <sil2100> MCR1: indeed, I see the failure is somewhere else - let me reapprove
[16:33] <MCR1> sil2100: thx :)
[16:54] <mhr3> mterry, how much published is dee? :)
[16:54] <mhr3> mterry, http://s-jenkins:8080/job/libunity-ferrets-mbs-autolanding/build=pbuilder,distribution=raring,flavor=amd64/11/console
[16:56] <mterry> mhr3, https://launchpad.net/ubuntu/+source/dee shows it uploaded, but not in raring proper yet
[16:56] <mterry> mhr3, so not published from a distro sense.  But published from a jenkins sense
[16:58] <mhr3> i knew there'd be a gotcha
[17:00] <mhr3> mterry, so when can i actually re-approve that branch and expect it to land?
[17:01] <mterry> mhr3, when the +source/dee page shows the version in raring (not just -proposed)
[17:02] <mhr3> mterry, can i get an approximate delta in some SU units? ;)
[17:03] <mterry> mhr3, less than 30 min, but likely less than 15min?
[17:05] <mhr3> ah, cool
[20:10] <mterry> mhr3, btw, dee landed in raring a few hours ago
[21:45] <MCR1> smspillaz: First performance optimizations are already awesome, even on ATI :) Top job !!!


[07:00] <rick_> hi all, is there a cpuburn tool that support cortex-a9 without neon?
[09:00] <hrw> cpuburn is using neon?
[13:31] <shadeslayer> ogra: question, can we keep the image building stuff simple? like we did with the Nexus 10? where I just debootstrapped a base ubuntu rootfs, put that onto the data partition, compiled the kernel and packed that with the standard ubuntu initrd
[13:31] <shadeslayer> ( for the Nexus 7 )
[13:31] <shadeslayer> only with the Nexus 7, I preseed the chroot with https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra3 and the desktop kernel
[13:34] <shadeslayer> ( the desktop kernel being this one : http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=summary _
[13:34] <shadeslayer> )
[13:35] <ogra> who is "we" ?
[13:35] <ogra> do you mean you create an image locally ?
[13:39] <pbcw> i have a BeagleBoard Black that I want to throw Ubuntu on.  I downloaded the ubuntu-13.04-console-armhf-2013-05-29.tar.xz, and the md5 comes out correct.  When I try to use 7-Zip (Windows) to extract the .xz file, it says it is not an archive.  Is the xz file actually image, and I should use that file when creating my SD card?
[13:42] <shadeslayer> ogra: we = kubuntu team :)
[13:42] <shadeslayer> ogra: yes
[13:42] <shadeslayer> for now
[13:42] <ogra> this isnt an official ubuntu image, find the person who created it and ask him/her
[13:43] <shadeslayer> which image are you talking about :S
[13:44] <pbcw> thanks ogra
[13:45] <shadeslayer> oh that was for pbcw
[13:45] <ogra> that beaglebone thingit
[13:45] <ogra> right
[13:45] <shadeslayer> roger
[13:45] <ogra> well, for your kubuntu image, just create a tarball, make sure abootimg is in it as well as the graphics driver
[13:45] <ogra> i assume that should suffice
[13:46] <shadeslayer> uhhhh I'm not going through the whole reflash kernel method :P
[13:46]  * ogra hasnt touched desktop images in ages ... have a look at the build scripts in livecd-rootfs
[13:46] <ogra> you have to
[13:46] <shadeslayer> why?
[13:46] <ogra> you *need* to rebuild the initrd
[13:47] <shadeslayer> right, but *why*
[13:47] <ogra> if you use a proper bootimg with tarball installer at least
[13:47] <ogra> because it will not boot
[13:47] <shadeslayer> can't it work like we did with the Nexus 10?
[13:48] <ogra> i have no idea what you did with the N10
[13:48] <shadeslayer> compile kernel , pack it with a standard ubuntu initrd, set rootfs=/dev/mmcppblk
[13:48] <ogra> apart from hacking it to get X up
[13:48] <ogra> sure, you can do that as a hack
[13:49] <shadeslayer> if I understand it correctly, the way it's done in the desktop image currently is to allow for kernel upgrades?
[13:50] <shadeslayer> so when there's a new kernel in /boot the device flashes itself again?
[13:50] <ogra> no
[13:50] <shadeslayer> oh, so why is it done like that?
[13:50] <ogra> anything that uses a trigger for initramfs will re-flash
[13:50] <ogra> has nothing to do with /boot
[13:51] <shadeslayer> I see
[13:51] <ogra> but with dpkg triggers
[13:51] <shadeslayer> roger
[13:53] <shadeslayer> anyway, I'll take the hacky way for now ;)
[13:53] <shadeslayer> ogra: FWIW I still don't have X on then N10, because I can't find the right X11 exynos 5250 drivers :(
[13:54] <shadeslayer> I heard there's a simplefb driver in the kernel now, going to look at that once I'm through with the N7
[13:54] <ogra> well, if your kernel works correct it should just start
[13:54] <ogra> using xfbdev
[13:54] <ogra> (which is the default on arm)
[19:23] <ValDuare> hey guys I'm trying to compile libavg for arm, I am getting some configure errors, the pkg-config script could not be found or is too old make sure it is in your PATH   any ideas?
[19:23] <ValDuare> I am not sure how to set the flags
[19:27] <infinity> ValDuare: Did you try installing pkg-config?
[19:28] <ValDuare> doing that now heh
[19:28] <ValDuare> retesting
[19:29] <ValDuare> got a new error now
[19:29] <infinity> I'm sure you did.
[19:29] <infinity> Out of curiosity, what's wrong with the libavg in the archive?
[19:30] <ValDuare> pangoft2
[19:30] <ValDuare> apt-cache search libavg shows nothing?
[19:30] <infinity> python-libavg
[19:31] <infinity> And it's in universe, do you have only main enabled in your sources.list?
[19:31] <ValDuare> checking
[19:32] <ValDuare> hah if that works I'm going to crack   spent all morning fulfilling dependancies to compile libavg haha
[19:32] <infinity> On, wait.  What release are you running?  It was arch-restricted to x86-only in precise and quantal. :/
[19:33] <infinity> Build on armhf in raring and saucy.
[19:33] <infinity> s/Build/Built/
[19:33] <ValDuare> 12.10 picuntu on an mk808
[19:34] <infinity> Ahh.  Why 12.10?
[19:34] <infinity> If you upgrade to 13.04, you might be a bit happier. :)
[19:34] <ValDuare> I haven't tried updating yet
[19:35] <ValDuare> main restricted universe multiverse is enabled in sources
[19:35] <infinity> Yeah, but like I said, it's not built in quantal.
[19:35] <infinity> And this is why:
[19:35] <infinity>   * Change architecture to any
[19:35] <infinity>   * Make some x86 specific debug code conditional (replacing it with a
[19:35] <infinity>     deliberate segfault) (patch accepted upstream) (Closes: #683105)
[19:36] <infinity> ^-- Before that change (which was made in raring), it wouldn't have worked on ARM.
[19:36] <ValDuare> k
[19:36] <ValDuare> ok
[19:36] <ValDuare> i'll work on updating tonight
[19:36] <ValDuare> are you familiar with mk808 and picuntu?
[19:37] <infinity> Nope.
[21:55] <sigs> Hello all, I am trying to install Ubuntu Precise 12.04 on my PandaboardES. I have followed the instructions here: https://groups.google.com/forum/#!topic/pandaboard/vKunvhMNV8k Just wanted to know if there has been an update on this known issue: * Black screen issue on some HW - workaround: Ctrl+Alt+F1 then Ctrl+Alt+F7 or boot with screen un-plugged, plug it after 1 minute. Issue under investigation.