[03:05] <infinity> pitti: Need those trusty langpacks in updates tomorrowish, if you have time to verify them.
[04:12] <pitti> xnox: hm, -4 still not imported -- LP imports are really slow these days :)
[04:12] <pitti> err, other smiley ..
[04:12] <pitti> infinity: ack
[04:20] <jbicha> pitti: could you retry an autopkgtest of freedombox-setup/0.9.2 triggered by itself and plinth/0.9.4-2 with all-proposed?
[04:32] <pitti> jbicha: done
[04:33] <jbicha> pitti: thanks, did you see that update_excuses hasn't refreshed in a while?
[05:02]  * Mirv causes explosions in autopkgtest infra
[05:03] <Mirv> new KDE Frameworks and Plasma copied to proposed
[05:35] <pitti> jbicha: yes, apw was pointing that out, britney crahsed; I'll look at it ASAP
[06:08] <pitti> infinity: do you know, does this even make sense:
[06:08] <pitti> -Provides: adwaita-icon-theme,
[06:08] <pitti> +Provides: adwaita-icon-theme (= 3.18),
[06:08] <pitti> ^ from lubuntu-artwork in -proposed; I have a gut feeling that this is what makes britney explode
[06:08] <pitti> the real package has version 3.18.0-2ubuntu4
[06:09] <infinity> pitti: That's reasonable.
[06:09] <infinity> pitti: Allows for versioned deps on adwaita-icon-theme to be satisfied by lubuntu-artwork
[06:09] <infinity> pitti: Surely britney understand versioned provides, they've been around a while now.
[06:09] <infinity> s/understand/understands/
[06:09] <pitti> so that doesn't need to be >= ? (I don't know how versioned provides work exactly, but strict equalities look weird)
[06:10] <infinity> No, strict equality is correct.
[06:10] <pitti> infinity: yes, it does in general, it worked for other packages
[06:10] <infinity> You're saying "act as though I'm <package> at <version>"
[06:10] <pitti> (that's what triggered the big merge)
[06:10] <pitti> ah, ok
[06:12] <pitti> so, I'm afraid this isn't a 3-minute fix, I don't know the upgrade_testing logic at all and why it now runs into infinite loop
[06:12] <pitti> to unblock this we could manually copy this to yakkety, or remove it from -proposed for now
[06:12] <pitti> or leave it broken for several days, but I wouldn't want that
[06:19] <pitti> infinity: trusty langpacks tested (up to the degree that I can do it, Eng/Ger in Qemu desktop and some spotchecks with diff -Nur for other langs), and released
[06:20] <infinity> pitti: Ta.
[07:28] <LocutusOfBorg> who did break initramfs?
[07:28] <LocutusOfBorg> :)
[07:28] <LocutusOfBorg> I would blame: apw for the busybox-initramfs part :)
[07:28] <LocutusOfBorg> https://launchpadlibrarian.net/275621714/buildlog_ubuntu-yakkety-ppc64el.libguestfs_1%3A1.32.6-1ubuntu2_BUILDING.txt.gz
[07:30] <LocutusOfBorg> or is that due to some mdadm changes from xnox ?  BTW thanks for the sync :)
[07:31] <pitti> sync? 3.4-4 isn't even imported into LP yet
[07:31] <LocutusOfBorg> 3.4-3 is
[07:31] <pitti> oh, xnox synced -3; that was a bit premature
[07:32] <LocutusOfBorg> do you think it might be the reason for that failures?
[07:32] <pitti> not the -3 vs. -4 difference I think
[07:33] <LocutusOfBorg> well, a kernel not installable seems something we should worry about
[07:42] <LocutusOfBorg> confirmed, on a clean pbuilder yakkety environment, installing linux-image-generic fails
[07:44] <pitti> LocutusOfBorg: it's more likely that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#initramfs-tools is the culprit
[07:44] <pitti> apw: ^ known?
[07:44] <pitti> Not touching package due to block request by apw (contact #ubuntu-release if update is needed)
[07:45] <pitti> interestingly the kernel's own tests do install busybox-initramfs
[07:45] <pitti> the libguestfs build did not
[07:45] <pitti> presumably because it's only a Recommends:
[07:45] <pitti> if it fails on that, it ought to be a hard Depends:
[07:46] <LocutusOfBorg> mmm nack?
[07:46] <LocutusOfBorg> I installed initramfs-tools and then linux-image-generic, everything was fine
[07:47] <LocutusOfBorg> I'll debug it
[07:47] <pitti> LocutusOfBorg: thanks!
[07:47] <LocutusOfBorg> thanks to you
[07:48] <LocutusOfBorg> BTW installing busybox-initramfs works, but I'm not sure why it is needed
[07:59] <LocutusOfBorg> pitti, cryptsetup, when installed linux-image-generic fails
[08:00] <LocutusOfBorg> or one of its dependencies :)
[08:12] <pitti> juliank: new apport just landed, I'll retry it for apt
[08:23] <apw> pitti, not known no, it was blocked just to get it to migrate separately from all the other bits which were blocked for the alpha
[08:32] <LocutusOfBorg> ough
[08:39] <LocutusOfBorg> apw, can you at least reproduce the issue?
[08:40] <apw> LocutusOfBorg, i think i have missed what happened ...
[08:40] <LocutusOfBorg> apw, clean yakkety environment
[08:40] <LocutusOfBorg> apt-get install cryptsetup
[08:40] <LocutusOfBorg> apt-get install linux-image-generic
[08:40] <LocutusOfBorg> fail
[08:40] <LocutusOfBorg> update-initramfs: Generating /boot/initrd.img-4.4.0-33-generic
[08:40] <LocutusOfBorg> E: busybox-initramfs, version 1:1.22.0-17~ or later, is required but not installed
[08:40] <LocutusOfBorg> update-initramfs: failed for /boot/initrd.img-4.4.0-33-generic with 1.
[08:40] <LocutusOfBorg> run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
[08:40] <LocutusOfBorg> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.4.0-33-generic.postinst line 1052.
[08:41] <LocutusOfBorg> installing busybox-initramfs obviously fixes the issue, but it is not a fix obviously
[08:42] <apw> hrm, so did you install initramfs-tools from -proposed manually ?
[08:42] <LocutusOfBorg> apw, also the builders do that
[08:42] <LocutusOfBorg> look at libguestfs build failure
[08:44] <apw> LocutusOfBorg, i guess i get to wait for the publisher to finish its work before i can test properly
[08:50] <LocutusOfBorg> Unit193, ^^^ it might be a problem on cryptsetup
[08:51] <LocutusOfBorg> apw, it fails here http://sources.debian.net/src/initramfs-tools/0.125/mkinitramfs/?hl=95#L95
[08:52] <apw> LocutusOfBorg, yes, i know where it fails ... hrm, it seems we've reduced a dependancy to a recommends, which is likely not appropriate
[08:52] <LocutusOfBorg> indeed, I see the same
[08:52] <LocutusOfBorg> I would make an hard dependency again
[08:53] <apw> yep, i concur, will sort that out
[08:53] <LocutusOfBorg> "In addition, you need to have both initramfs-tools and busybox installed.
[08:53] <LocutusOfBorg> "
[08:53] <LocutusOfBorg> this is from cryptsetup README.initramfs
[08:53] <LocutusOfBorg> thanks apw for fixing
[08:53] <LocutusOfBorg> I would wild guess this problem affects Debian too
[08:54] <apw> LocutusOfBorg, all about whether they install recommends or not
[08:54] <LocutusOfBorg> oh indeed, that's true :)
[08:54] <LocutusOfBorg> but I still prefer explicit rather than implicit
[09:01] <apw> LocutusOfBorg, yes, i am sure we need it a depends, should have spotted that moving in the merge, bah, anyhow testing now will upload shortly
[09:02] <LocutusOfBorg> apw, would you sponsor an upload?
[09:02] <apw> LocutusOfBorg, likely :)
[09:05] <LocutusOfBorg> let me triple check
[10:14] <Mirv> ok, as the whole KDE is also updated in yakkety-proposed, yofel can guide pitti in what can be force-ignored to get Qt + KDE into release pocket. on the Ubuntu side Saviq can comment on Unity 8 (the only package in Ubuntu phone stack that has autopkgtests failures), ie where's the tradeoff to keep struggling with the proposed problems versus getting all the U8 issues fixed.
[10:14] <Mirv> I mean, yofel can guide regarding the KDE packages. but, there is quite a queue in autopkgtests before everything is done
[10:15] <Mirv> pitti: so what's trying to get in is Qt 5.6, KDE Frameworks 5.24 and Plasma 5.7. I'm not sure if the autopkgtests need guidance here to consider all of them together, the latest versions.
[10:20] <pitti> Mirv: is there hope that the new KDE fixes some of the qt 5.6 regressions like kwin?
[10:30] <Mirv> pitti: yes, that was the idea since Kubuntu has been working with their own build of Qt 5.6 and new KDE releases and wanted to the Qt to get into proposed to get their stuff in too. although it seems there's some thinking that there will be autopkgtests broken anyway and they should be forced (I think it'd be a good idea to also disable known broken tests)
[10:31] <cjwatson> LocutusOfBorg: You asked the other day about "cleaning up" the ppc64el builders.  That isn't a thing.  They're scalingstack, and every scalingstack builder is reset from a fresh VM instance between builds.  If a build is running out of space, it's probably being pretty unreasonable all by itself.
[10:31] <pitti> Mirv: yes, we do that; we have a looong hint list of broken tests
[10:31] <cjwatson> s/instance/image/
[10:32] <pitti> Mirv: but we block on new regressions; we can retry failed KDE tests against all of proposed so that they run against 5.6, though; as long as they actually depend on 5.6 they should do that automatically already
[10:34] <LocutusOfBorg> cjwatson, I ended up in removing builddir after dh_install
[10:34] <LocutusOfBorg> :)
[10:34] <LocutusOfBorg> and now I get ENORAM on arm64
[10:35] <LocutusOfBorg> I reduced the parallel to arm64, lets see if it builds in less than 2 days
[10:35] <Mirv> pitti: only a couple of the KDE packages really depend on 5.6 (private ABI users), probably all of them should run with the proposed Qt though
[13:07] <cyphermox> good morning!
[13:55] <dobey> pitti: here?
[15:48] <LocutusOfBorg> wow the autopkgtest queue is huge again, is that a side effect of the freeze end?
[15:48] <LocutusOfBorg> and kde :)
[15:48] <Unit193> LocutusOfBorg: Looked at it again, I didn't drop busybox from depends to recommends.
[15:49] <LocutusOfBorg> Unit193, the fault was in initramfs-tools
[15:49] <LocutusOfBorg> that did the move
[15:49] <LocutusOfBorg> http://launchpadlibrarian.net/275638870/initramfs-tools_0.125ubuntu1_0.125ubuntu2.diff.gz
[15:49] <Unit193> I didn't touch that one. :D
[15:54] <LocutusOfBorg> actually the change was Ubuntu specific, in Debian has no effect and was done in Debian lol
[15:54] <LocutusOfBorg> the ongoing effort to reduce the delta by integrating it in Debian had a bad side effect :o
[16:11] <xnox> doko, i'm planning to upload boost
[16:11] <xnox> but you said it should build against new icu too?
[16:11] <xnox> which one is that?
[16:11] <xnox> or what's the upload order?
[16:12] <xnox> ooh, i see 57.1-1 in experimental, i guess that one.
[16:13] <xnox> but it's built with gcc+5 not 6 as far as i can tell.
[16:37] <LocutusOfBorg> xnox, do I smell, ABI changes?
[16:40] <xnox> LocutusOfBorg, yes, loads =)
[16:42] <chiluk> hey pitti are you around?
[19:25] <chiluk> apw, pitti, can you take a look at https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920 if you get a chance.  I'm pinging you because you guys both have touched it.


[01:16] <josharenson> I am getting the following error when calling launch_click_package
[01:16] <josharenson> http://pastebin.ubuntu.com/7739626/
[01:17] <josharenson> The app launches just fine, but it seems the return value is bad?
[03:47] <veebers> thomi: when you have a moment would you be able to review this please: https://code.launchpad.net/~veebers/autopilot/adding_screenshots_to_details/+merge/225423
[03:52] <thomi> veebers, looking now
[03:52] <veebers> awesome, cheers
[03:53] <thomi> veebers: want feedback here, or in the MP?
[03:53] <veebers> thomi: in the MP please so I don't lose it :-)
[04:19] <thomi> veebers: you *really* need to mock/patch waaaay less
[04:22] <veebers> thomi: fair enough, do you have any suggested for that MP?
[04:22] <thomi> veebers: yes, lots
[04:22] <thomi> you might want to get a drink
[04:23] <veebers> thomi: heh, I'm ready when you are :-)
[04:26] <thomi> veebers: review posted
[04:26] <thomi> veebers: I'm happy to talk about it in person, if you need
[04:27] <veebers> thomi: sweet, I'll take a look and ping you in a couple of minutes once I've digested it?
[04:27] <thomi> sure
[04:27] <veebers> thomi: also, could I get you to eyeball this pre-req please: https://code.launchpad.net/~veebers/autopilot/logging-binary-attachments-1336109/+merge/225098
[04:31] <veebers> thomi: all your comments make sense I don't think there is need for a call. I'll hit those points now
[05:08] <veebers> thomi: for detecting if the display is x11/mir and the platform module. That currently only gives us details like Desktop/device/tablet etc. I don't think it's enough to say "if is device then it's mir, desktop is x11"
[05:08] <veebers> thomi: do you have any better ideas than either the tests in that MP or the desktop==x11, not desktop=mir?
[05:09] <thomi> veebers: so, however you do the detection, the public api should be in the platform module....
[05:10] <thomi> regarding detection for X11, is checking for $DISPLAY enough? Presumably your screenshot function needs that in order to work
[05:11] <thomi> WRT detecting mir, have you asked the mir team? My personal bet would be to try and find the mir socket, but that really only tells you that it's running *somewhere*, not necessarily in the current session
[05:11] <veebers> thomi: rats, I've lost the link, but I read a SO that said "xset q" was good, if a xset query fails than X isn't around
[05:12] <veebers> ah right: http://stackoverflow.com/questions/637005/x-server-running
[05:14] <thomi> veebers: xset reads $DISPLAY internally, and you have access to the X python bindings, I think we can do soemthing nicer than spawning a new process...
[05:14] <elopio> thomi: can you review this one please?
[05:14] <elopio> https://code.launchpad.net/~elopio/ubuntu-autopilot-tests/fix_packaging/+merge/225426
[05:14] <veebers> thomi: ok, I'll look further
[05:15] <thomi> veebers: it'd be interesting to see what xset does under the hook
[05:15] <thomi> *hood
[05:15] <elopio> it seems that without the pybuild name, it tries to install in python3, instead of dist-packages.
[05:15] <thomi> veebers: but *at least* please protect that subprocess call with a functools.lru_cache :)
[05:15] <thomi> elopio: ahh, ok
[05:16] <thomi> elopio: approved
[05:16] <elopio> thomi: thanks.
[05:16] <elopio> now we have jenkins tests :D Lets see if they like it.
[20:16] <josharenson> elopio, I was able to modify all the templates to fit my project, but it still can't find my project's MainView
[20:16] <josharenson> the only thing that is different is directory structure... any insight on how the search works? It can find other objects just fine if I commend out the MainView search part
[20:17] <elopio> josharenson: can you put a import pdb; pdb.set_trace() just before selecting the main view?
[20:17] <elopio> and then open autopilot vis
[20:17] <josharenson> sure
[20:17] <elopio> it might be that you are extending main view, and it gets a different QML class name.
[20:21] <josharenson> elopio, it hit the break point and I see the contents in vis
[20:21] <josharenson> looking around
[20:21] <josharenson> says object name is "mainView"
[20:23] <elopio> josharenson: here we are not using the objectName to select the item, onlye the class name
[20:23] <elopio> what you see on the left side of the autopilot vis, on the tree.
[20:23] <elopio> is it MainView?
[20:26] <josharenson> elopio, no its my app name
[20:26] <balloons> o hai josharenson :-
[20:26] <josharenson> The object in my QML is MainView type though...
[20:26] <josharenson> hii
[20:27] <josharenson> I'll try renaming the qml file to MainView.qml?
[20:27] <elopio> josharenson: no
[20:27] <balloons> josharenson,what does the qml look like?
[20:27] <josharenson> yeah that seems dumb
[20:27] <elopio> that's one of the weird things that QML + autopilot have.
[20:28] <elopio> josharenson: can you send a screenshot of the qml tree from autopilot, just to be sure I send you the right code to add?
[20:28] <balloons> josharenson, the main qml file will have MainView specified
[20:28] <josharenson> http://pastebin.ubuntu.com/7743793/
[20:28]  * josharenson getting screenshot
[20:28] <balloons> josharenson, is that the entire file or just the top?
[20:28] <elopio> josharenson: what's the name of that file?
[20:28] <josharenson> the top... filename is SimplePerf.qml
[20:29] <balloons> josharenson, kk :-) yep, that looks like what we want to see
[20:29] <elopio> josharenson: yes, I think that if you remove
[20:29] <elopio> property real main_view_padding: units.gu(50)
[20:29] <elopio> the tree will show MainView instaed of SimplePerf.
[20:29] <elopio> I think you will have to do this:
[20:30] <elopio> on @property main_view, change it to
[20:30] <elopio> self.app.select_single(SimplePerf)
[20:30] <elopio> and under that, define a new class
[20:30] <elopio> class SimplePerf(emulators.MainView):
[20:30] <elopio>     pass
[20:30] <josharenson> https://dl.dropboxusercontent.com/u/12477656/Screenshot%20from%202014-07-03%2013%3A29%3A29.png
[20:31]  * josharenson trying that
[20:31] <elopio> josharenson: now, to see if I should modify the templates, did you change the MainView.qml file?
[20:31] <elopio> and what template are you using?
[20:32] <josharenson> Using the QML w/ Qt extension template
[20:32] <josharenson> elopio, what is the MainView.qml file? like the file that contains main view?
[20:33] <elopio> oh, right, it's called SimplePerf.qml, not MainView. Sorry.
[20:33] <elopio> josharenson: I'll make sure to update that template next week.
[20:33] <elopio> for now, lunch break.
[20:33] <josharenson> sure, thanks for the help
[20:35] <elopio> np.
[20:37] <josharenson> elopio the new class doesn't seem to work.. I'll keep messing with it... (same error except replace MainView with SimplePerf)
[20:57] <elopio> josharenson: hum hum.
[21:01] <elopio> it should work, according to your screenshot.
[21:02] <elopio> josharenson: if you push your project to a branch, I can give it a tyr.
[21:02] <elopio> *try
[21:02] <josharenson> ok
[21:03] <josharenson> elopio lp:~josharenson/+junk/SimplePerf/
[21:19] <elopio> josharenson: you re defining the SimplePerf class inside the ClickAppTestCase
[21:19] <elopio> delete the leading spaces of that class, and you should be good to go.
[21:20] <elopio> almost
[21:21] <elopio> you are also missing the return on the @property method.
[21:21] <elopio> http://paste.ubuntu.com/7744035/
[21:21] <josharenson> ah
[21:22] <josharenson> elopio, woot works.. thanks a lot
[21:23] <elopio> josharenson: no problem.
[21:23] <elopio> I'll be away for a while, but ping if you need more help with the tests. I'll check the backlog.
[21:27] <josharenson> elopio I'm about to head into the wilderness w/o internet for the weekend so no worries..