[00:01] <xnox> sarnold: excellent
[00:02] <sarnold> xnox: of course your little script provides a nice abstraction around when we eventually do that. :) heh
[00:04] <xnox> sarnold: it's a bit shame there is no definitive extension name for the profiles, thus stending time filtering out ".dpkg-new" et. al.
[00:05] <xnox> sarnold: and each location is processed in parallel, however one still does the loop twice =(
[00:07] <sarnold> xnox: heh, perhaps a decade or so back, we did have a .sd ('subdomain') extension on profiles, but we ditched that somewhere along the way as annoyingly redundant. heh.
[00:39] <jjohansen> sarnold, xnox: the parser isn't almost there, it is completely there. What it can't do yet is directly handle caching for multiple policy versions, so the old version is replaced when stale, and it doesn't handle profile removal on restart
[00:40] <jjohansen> it does the filtering for different extensions etc, you can point it at a directory and it loads the profiles from it
[00:41] <jjohansen> it handles the cache management, 90% of what the initscripts do could be dropped
[00:42] <jjohansen> oh I guess it doesn't do parallel compiles
[00:43] <jjohansen> but that is actually minor
[00:44] <jjohansen> when arekm ripped out the initscript stuff for pld it made things go something like 95% faster. /me would have to dig to get the actual figures
[01:03] <sarnold> jjohansen: cripes, that's impressive :)
[01:31] <jjohansen> sarnold: found it, scrapping the bash scripting and doing direct cache load for his 4500 profiles reduced the time from 1m22s to 1.5s
[01:32] <sarnold> jjohansen: omg I want that
[01:33] <jjohansen> yeah, for a small profile count the bash scripting overhead is not so bad, but well its time to fix it
[02:46] <rajat_kapoor> Can anyone please help me , I have started getting "Segmentation fault (core dumped)" on 12.04 desktop terminal?
[03:22] <Unit193> It would appear the auto importer isn't picking up network-manager, it would appear the last run was 2012.  (Also would be nice to have the systemd services installed, but guessing that won't happen any time soon.)
[03:26] <darkxst> Unit193, you mean lp:debian branches? there are loads of branches in there that are pretty much broken
[03:28] <Unit193> darkxst: No, I don't use those.  https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/network-manager/trusty
[04:34] <TheMuso> B/c
[05:24] <pitti> Good morning
[05:36] <pitti> infinity, smoser: meh, doing daily reboot of wolfe-*; seems your magic from Friday didn't last long?
[05:38] <infinity> pitti: Yeah, I didn't expect it to fix it, I'd just hoped. :/
[05:39] <infinity> pitti: If you get a VM in that wedged state and can live with it staying broken for a bit, apw said he'd like to have access to play/debug a bit.
[05:40] <pitti> infinity: sure; I'll take wolfe-05 offline in jenkins, and just reboot/fix the other three?
[05:40] <infinity> pitti: Sure, and give him ssh access to that one then, I guess.
[05:40] <infinity> pitti: I'm heading to bed, but I assume Andy will be up in an hour or two.
[05:40] <pitti> infinity: yep, will talk to him
[05:40] <infinity> pitti: Ta.
[05:46] <pitti> infinity: hmm, seems the other three don't come back from reboot
[05:46] <pitti> infinity: the host might need a reboot again, too?
[05:58]  * pitti sends his daily "screw you" jenkinswards
[06:25] <pitti> @pilot in
[06:26] <dholbach> good morning
[06:27] <pitti> hey dholbach
[06:28] <mvo> hey dholbach & pitt, good morning
[06:28] <pitti> hallo mvo, wie gehts?
[06:30] <mvo> pitti: good, thanks! still not fully awake, but I'm hopeful the tea will help with that :) and you?
[06:30] <pitti> mvo: pretty much the same :)
[06:32] <dholbach> hey pitti, hey mvo
[06:41] <zyga> good morning
[06:42] <zyga> could someone enlighten me about the purpose of incoming.debian.org? I was under the impression that it's a place packages go to be built by all the arch builders
[06:42] <zyga> is my understanding correct?
[06:43] <pitti> zyga: not quite
[06:43] <pitti> zyga: it's the staging area where uploads and built packages are queued after accepting it from the upload queue, and publishing it into the archive
[06:44] <pitti> zyga: i. e. the publisher flushes incoming every 6 hours
[06:44] <pitti> zyga: but buildds look at incoming so that they don't need to wait for the publisher; but they also build sources which are already published
[06:44] <pitti> and then again upload the build (going through incoming again)
[06:49] <pitti> mvo: ah, are you already handling https://code.launchpad.net/~brian-murray/ubuntu-release-upgrader/bug-1302380/+merge/214349 ?
[06:51] <mvo> pitti: yeah, I have a slightly extended version of his branch, I hope he gets a chance to review that soon(ish)
[06:53] <zyga> pitti: so after a package gets accepted it goes to incoming, gets built by buildds, then gets back to incomin ? and then flushes to the archive?
[06:53] <zyga> pitti: and that happens four times a day
[06:53] <pitti> zyga: not "back" to incoming
[06:54] <pitti> zyga: upload -> accept (every 10 mins or so) -> incoming -> publisher -> archive
[06:54] <pitti> zyga: and buildds watch for new sources in incoming and archive -> build -> upload -> same as above
[06:54] <zyga> pitti: ah
[06:55] <zyga> pitti: I'm trying to understand when a few small packages that got uploaded there yesterday will make it into the archive
[06:55] <zyga> pitti: it's almost 24 hours now
[06:55] <pitti> that sounds like a bug
[06:55] <zyga> pitti: there are also packages from 7th of April
[06:55] <zyga> http://incoming.debian.org/
[06:55] <zyga> or do I read that wrong?
[06:56] <pitti> hm; they might be NEW or something?
[06:56] <zyga> pitti: plainbox|checkbox packages aren't new
[06:56] <zyga> NEW I mean
[06:56] <zyga> and I cannot see them in https://ftp-master.debian.org/new.html
[06:56] <pitti>  plainbox | 0.5.3-2 | sid    | source, all
[06:56] <pitti> seems fine
[06:57] <zyga> oh!
[06:57] <pitti> zyga: so it seems incoming has some problems with cleaning up?
[06:57]  * zyga looks if requestsync sees that now
[06:57] <pitti> zyga: it's also already on https://launchpad.net/debian/+source/plainbox
[06:57] <pitti> zyga: so yes, requestsync ought to see it
[06:57] <zyga> right, I see
[06:57] <zyga> great :)
[06:57]  * zyga just saw that versiontools got packaged for python :-)
[06:57] <pitti> zyga: FYI: https://ftp-master.debian.org/dinstall.html
[06:58] <zyga> ohhh
[06:58] <pitti> zyga: dinstall is equivalent to what LP calls "publisher"
[06:58] <zyga> nice!
[06:58] <zyga> thanks
[06:58] <zyga> right
[06:58] <zyga> I know about it
[06:58] <pitti> zyga: after dinstall it usually takes about two hours to get imported into LP
[06:59] <darkxst> pitti, oh no! bug 1302077 will break high contrast theme
[06:59] <darkxst> well mess it up
[06:59] <pitti> darkxst: hm, that previous list actually seemed incomplete
[07:00] <darkxst> (and Adwaita, but I doubt anyone uses that in unity)
[07:00] <pitti> darkxst: I thought we don't want the title bar under unity, period; not just under these two themes?
[07:00] <pitti> darkxst: but anyway, if this causes regressions I'm happy to reject from the queue and revert from the branch
[07:00] <pitti> darkxst: how does it cause regressions/
[07:00] <pitti> ?
[07:01] <Noskcaj> pitti, blueman branch is fixed. I'd just committed without .pc/ last time
[07:02] <pitti> hate hate hate tracking .pc/ in UDD; this is just utterly wrong
[07:02] <pitti> Noskcaj: thanks
[07:04] <darkxst> pitti, that patch is overriding some theming issues with the ubuntu themes
[07:04] <maxb> I'd agree on the .pc/ thing - UDD on v3 source packages needs a serious rethink
[07:04] <darkxst> pitti, there is a seperate patch to bring back titlebar
[07:04] <pitti> darkxst: can you please explain that in bug 1302077 so that Leon can adjust?
[07:05] <pitti> darkxst: I reject the upload
[07:06] <darkxst> pitti, ok
[07:09] <Noskcaj> maxb, My suggestion to fix it would be the ubuntu branches don't have stuff applied by default, and .pc/applied-patches is force added
[07:09] <maxb> force added?
[07:17] <Noskcaj> maxb, always there
[07:17] <Noskcaj> pitti, thanks for the sponsorings
[07:17] <pitti> meh, I sponsor as fast as I can, and yet the queue *increases* :)
[07:18] <Noskcaj> that's my goal.
[07:23] <pitti> 1 out of 1 hunk FAILED -- rejects in file blueman/plugins/applet/DhcpClient.py
[07:23] <pitti> Patch dhcpclient_priority can be reverse-applied
[07:23] <pitti> Noskcaj: ^ still no good :/
[07:23] <Noskcaj> really? wow.
[07:24] <pitti> Noskcaj: nevermind; I got the orig.tar.gz from the failed bzr bd and now use plain debuild
[07:24] <Noskcaj> thanks
[07:24] <pitti> Noskcaj: I don't physically merge this anyway, I just upload and let the auto-importer sort it out
[07:25] <pitti> still, it's a pain
[07:25]  * pitti really prefers plain debdiffs on bugs
[07:25] <Noskcaj> that seems to be the majority opinion. Maybe bzr could be hacked to give normal debdiffs
[07:27] <pitti> not sure if it's the majority; some folks seem to like it the way it is
[07:28] <pitti> zyga: can you handle https://code.launchpad.net/~brendan-donegan/ubuntu/trusty/checkbox/ffe_ui_custom_transport_ubuntu/+merge/214603 ? you seem to do this via debian and upstream
[07:29] <pitti> zyga: or, if you fine with an ubuntu upload, I can have a look at sponsoring, but maybe you'd like to cross-check
[07:38] <ricotz> pitti, good morning :), could you take a look at libcdr 0.0.15 which is/will be the version supported by libreoffice 4.2.4 -- http://people.ubuntu.com/~ricotz/packages/libcdr/
[07:42] <pitti> ricotz: does that new version work with cdr2odg (source: writerperfect)?
[07:43] <zyga> pitti: hey, this is a coordinated ubuntu+debian package set
[07:43] <zyga> pitti: everything except for checkbox-gui is in debian
[07:43] <zyga> pitti: and is a sync of the new package
[07:43] <pitti> ricotz: the dh_autoreconf change is already in Ubuntu, could you mark this as "Merge with Debian unstable, remaining Ubuntu changes:"?
[07:44] <zyga> pitti: checkbox-gui is using ubuntu-sdk so it's not in debian
[07:44] <zyga> pitti: I'll have a sanity-check look but we've been working on that for the past two weeks :)
[07:51] <brainwash> anyone familiar with ubiquity? how can I easily test the installer mode?
[07:52] <brainwash> I want to debug bug 1284910
[07:53] <ricotz> pitti, yes cdr2odg runs and works, will update the changelog in a bit
[07:54] <mwhudson> hello
[07:54] <mwhudson> ah, +1 would be better for this
[07:55] <ricotz> pitti, updated
[07:57] <zyga> mwhudson: hey :)
[08:04] <zyga> pitti: thanks for syncing most of the checkbox stuff over
[08:04] <pitti> zyga: yw; doing your most recent sync now
[08:04] <zyga> pitti: are you also going to sync checkbox-support (ppc64el bugfix) and plainbox-provider-resource-generic (a few fixes)
[08:05] <pitti> zyga: I don't see the latter in the queue yet, but yes, I'll get to it
[08:05] <zyga> pitti: ok, thanks
[08:05] <pitti> zyga: please note that they are in unapproved, so the release team needs to ack those, too
[08:05] <zyga> ok
[08:05] <zyga> https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-resource-generic/+bug/1304850 is the critical one
[08:06] <zyga> https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1304191 less so
[08:06] <zyga> pitti: I'll be in #ubuntu-release, do I need anything else to assist in reviewing/landing those?
[08:06] <pitti> zyga: ah, sponsors aren't subscribed to teh former
[08:06] <zyga> oh, weird? thanks
[08:07] <pitti> zyga: I looked at the linked bugs lists, so it seems bug fix only; so it ought to be fine
[08:07] <pitti> zyga: but syncs don't have a debdiff attached to them, so the release team might have questions about where to see the changes/NEWS/changelog/etc.
[08:07] <zyga> pitti: I see, I'll try to produce those
[08:08] <pitti> zyga: which combinations did you test? the full stack of all new versions together?
[08:08] <zyga> pitti: yes, along with the chcekbox-gui merge request (directly to ubuntu)
[08:10]  * zyga works on debdiffs
[08:11] <zyga> pitti: 'debdiff old.dsc new.dsc > pkg.debdiff' is sufficient?
[08:11] <pitti> zyga: yes
[08:12] <zyga> thanks
[08:12] <pitti> zyga: perhaps put them into a pastebin and point to that in #u-r?
[08:12] <zyga> right
[08:12] <pitti> probably helps to ask around who has time to review the whole stack
[08:13] <pitti> ricotz: uploaded libcdr
[08:20] <pitti> Noskcaj: so in bug 1300521 you said that both (i. e. also gnome-photos) just needs a new grilo-plugins dep, but your branch adds a gnome-online-miners dep?
[08:20] <pitti> Noskcaj: is gnome-online-miners a too big dependency, or does it actually use the miners index?
[08:25] <Noskcaj> pitti, It was requested by darkxst
[08:28] <FourDollars> arges: pitti: Can you help me to do SRU for precise? https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819
[08:28] <pitti> FourDollars: too late, I already uploaded :)
[08:28] <pitti> (and updated the MP and bug)
[08:29] <FourDollars> pitti: haha. I see it. Thanks a lot. :D
[08:29] <jibel> pitti, upgrade to Trusty is still blocked on postgresql-server-dev removal even with the fix of krb5, bug 1304702 is the same on i386
[08:30] <pitti> jibel: hm, that ^ bug is still with the previous krb5
[08:30] <darkxst> pitti, right, gnome-photos does use gnome-online-miners now
[08:30] <pitti> jibel: oh wait, actually not
[08:30] <pitti> jibel: meh, that helped for me
[08:30] <jibel> pitti, 1.12+dfsg-2ubuntu3 is latest version right?
[08:32] <pitti> jibel: yes
[08:32] <pitti> so I'm afraid I ran out of ideas how to fix this; I might need to invoke the mvo joker card..
[08:32] <ricotz> pitti, thanks!
[08:32] <pitti> darkxst: thanks for confirming
[08:34] <mvo> pitti: ok, I have a look (bug 1304702, correct?)
[08:34] <pitti> mvo: right; I tried to fix that yesterday in https://launchpad.net/ubuntu/+source/krb5/1.12+dfsg-2ubuntu3 by adding an additional Replaces: to the Breaks:, to nudge apt
[08:35] <pitti> mvo: that helped in a schroot, but apparenlty not for everyone still
[08:35] <jibel> mvo, 1304702 is from saucy to Trusty and 1304403 is from precise to trusty
[08:35] <jibel> I'll attach new logs for P->T
[08:36] <mvo> ok
[08:39] <pitti> jibel: oh, I missed that; so it does work for p->t now?
[08:39] <pitti> I didn't test s->t in a schroot
[08:40] <jibel> pitti, no it doesn't
[08:41] <jibel> pitti, but the format of apt.log changed, maybe it will be more clear
[08:42] <mvo> jibel: yeah, it should contain more debug info now
[08:43] <Noskcaj> pitti, Would you mind checking the sra-sdk merge i put up?
[08:43] <Noskcaj> Your review is wrong
[08:43] <pitti> Noskcaj: you mean a newer one than https://code.launchpad.net/~noskcaj/ubuntu/trusty/sra-sdk/ftbfs/+merge/214647 ?
[08:45] <pitti> that one is 2.3.3-4~dfsg-1ubuntu1 from Logan_, which is already in teh archive
[08:45] <Noskcaj> pitti, never mind. It didn't commit my changes. I'd tried to merge from debian
[08:46] <Noskcaj> which should fix ftbfs
[08:46] <mvo> jibel: if you get the chance could you run the upgrade with https://launchpad.net/~mvo/+archive/eglibc-trusty/+packages again? I uploaded a new version
[08:46] <pitti> apw: hey Andy
[08:46] <pitti> apw: infinity said you'd like to take a look at the dpkg segfaults on ppc64el?
[08:47] <pitti> apw: it keeps happening a few hours/a day after rebooting; I kept one box in that state (you can ssh) if you want to take a look
[08:48] <pitti> smoser: wolfe-{03,04,06} didn't come back after a reboot (needed to because of the dpkg segfaults); would you mind having a look? thanks!
[08:50] <pitti> @pilot out
[08:54] <jibel> mvo, in progress
[08:54] <mvo> jibel: \o/
[08:55] <mvo> pitti: quick question - its ok to remove postgresql-server-dev-9.1 I assume? its no longer in the archive  so it can be removed on a trusty upgrade?
[09:06] <pitti> mvo: for -server-dev, yes
[09:06] <pitti> mvo: but not for postgresql-9.1, postgresql-client-9.1, postgresql-pl*-9.1, and postgresql-9.1-<extensions>
[09:06] <pitti> mvo: our regexp catches -server-dev as well, we could also limit that to not catch that (but still catch extensions)
[09:07] <mvo> pitti: ok, I look at the krb-dev transition currently if we could get that under control that should fix the issue, but might still be worthwhile to relax the regexp a little bit
[09:07] <pitti> mvo: *nod*
[09:09] <apw> pitti, i would indeed
[09:23] <Laney> pitti: was your change to network-manager supposed to fix the tests?
[09:23] <pitti> Laney: for ppc64 and armhf at least, yes (and that worked)
[09:26] <pitti> Laney: as for the x86 test, it seems the ubuntu5 install broke them; I'm looking at them tnow
[09:27] <Laney> pitti: okay, thanks - interesting that the failures are x86 specific
[09:28] <pitti> Laney: it's not really about the arch, it's about runing in LXC (which doesn't work as the test needs to fiddle with the kenrel) vs. Qemu
[09:28] <pitti> Laney: the "isolation-machine" thing just skips the test on LXC instead of failing
[09:30] <jibel> mvo, no prompt with -0ubuntu4.1
[09:30] <Laney> pitti: aha, so it passes on arm64/ppc64el because the tests aren't actually run there
[09:30] <mvo> jibel: \o/
[09:30] <mvo> jibel: thanks a lot for the test
[09:32] <pitti> mvo: oh, you have an idea about the krb upgrade?
[09:34] <mvo> pitti: yeah, a transitional pkg fixes it, but I'm looking into the resolver right now, its a bit embarassing that it needs so much hand holding :/
[09:34] <pitti> mvo: a transitional package for the old -8 library? eww; but thanks!
[09:34] <mvo> pitti: yes, exactly ewww :/
[09:35] <mvo> pitti: it seems like it needs to penalize packages that disappear much stronger
[09:39] <cjwatson> pitti: UDD> let's not fix it and use git-dpm instead. :-)
[09:39]  * cjwatson trolls gently
[09:40] <pitti> cjwatson: it can't possibly be any more complicated than gitpkg :) (I think I managed to check out the old debian systemd git once, but forgot all about it again)
[09:41] <cjwatson> Not a fan of what I've read of gitpkg's approach
[09:42] <pitti> cjwatson: yeah, I'm quite happy that they replaced it with a standard git-buildpackage tree now
[09:43] <pitti> (or, at least there is one now which is supposed to become "the" tree soon)
[09:51] <ev> pitti: what do we lose if we lose ProcMaps in error reports, post-submission? Isn't this what the Dependencies field ultimately provides?
[09:51] <ev> context: ProcMaps is 71% of all the data in the error tracker :)
[09:51] <pitti> ev: we must have it for retracing
[09:52] <pitti> ev: after we computed the stack trace and the duplicate signature (although that alreayd happens client-side), we can drop it
[09:52] <ev> cool, that seems easy enough to code
[09:52] <pitti> ev: for LP it's occasionally interesting to have it as an attachment, but we can surely kick it out of daisy's db
[09:52] <ev> after retrace, go back to the bucket and drop the ProcMaps in each OOPS
[09:52] <pitti> *nod*
[09:52] <ev> bdmurray: ^
[09:53] <pitti> ev: effectively, you can treat ProcMaps.txt like the core dump; their lifetimes should be quite the same
[09:55] <mvo> pitti: I think I have some idea whats going wrong in the resolver, I will continue further after lunch
[09:55] <ev> pitti: interesting. I wonder if we should store them in much the same way then.
[09:56] <ev> ah, the client doesn't really allow that without some rearchitecting
[09:56] <ev> this aforementioned approach should do for now
[09:56] <pitti> ev: yes, that's what I thought; treat (CoreDump, ProcMaps) as one thing for conditional submitting, and clean them both up after retracing
[09:56] <ev> bdmurray: if you want to investigate both ^
[09:56]  * ev creates an Asana task for this
[09:57] <ev> https://app.asana.com/0/11345516654327/11523893065995
[10:11] <rbasak> cjwatson: around? I'm concerned about bug 1302192. Seems like a critical issue to me, perhaps installer related?
[10:12] <rbasak> Or xnox maybe? ^^
[10:12] <cjwatson> how would that be installer-related?
[10:13] <rbasak> It seems to be that the package is good, but an ISO based install mysteriously ends up with the file capability missing
[10:13] <cjwatson> well, maybe capabilities aren't preserved in squashfs
[10:13] <cjwatson> or maybe ubiquity doesn't copy them, I guess that's possible
[10:13] <cjwatson> let me check
[10:18] <rbasak> Ah. I didn't realise that ping switched from setuid to a file capability in Saucy -> Trusty
[10:25] <cjwatson> /usr/bin/gnome-keyring-daemon /usr/bin/arping /bin/ping /bin/ping6 <- potentially affected programs on my system
[10:27] <cjwatson> squashfs does seem to have xattr support though
[10:27] <cjwatson> and in particular supports the security namespace
[10:28] <cjwatson> so might just be that ubiquity's copying code needs to preserve xattrs
[10:30] <rbasak> I should probably know this, but does the server iso even use ubiquity?
[10:31] <Unit193> Should be debian-installer.
[10:31] <rbasak> That's what I thought, but I am unsure. I use cloud images.
[10:31] <cjwatson> what he said, yes
[10:32] <cjwatson> still copying off squashfs in that case for the base system, but using live-installer instead
[10:32] <cjwatson> anyway, I'll check both
[10:32] <rbasak> OK, thanks.
[10:32]  * rbasak needs to brush up in this area
[10:33] <cjwatson> ah, live-installer uses tar, we'd need to pass --xattrs I think
[10:36]  * mvo wonders what happend to his eglibc upload, no confirmation from the upload since ~1h
[10:36] <cjwatson> mvo: 10:37 -queuebot:#ubuntu-release- Unapproved: eglibc (trusty-proposed/main) [2.19-0ubuntu3 => 2.19-0ubuntu4] (core)
[10:37] <Laney> you should have had a Waiting for approval email
[10:37] <cjwatson> good, "getcap /bin/ping" in a live session returns "/bin/ping = cap_net_raw+p"
[10:39] <mvo> thanks cjwatson and Laney
[10:40] <pitti> cyphermox, Laney: NM> ah,  it seems our apparmor workaround for bug 1244157 stopped working
[10:42] <cjwatson> mvo: accepted anyhow
[10:42] <mvo> thanks cjwatson
[10:52] <rbasak> beisner: ^^ if you're interested. Thanks for your help.
[11:19] <xnox> jodh: slangasek: looks like mounted events block mountall - instead of "--no-wait" =(
[12:00] <jodh> xnox: yes, this is documented in mounted(7) since 'mounted' is a hook-type event (upstart-events(7)).
[12:03] <xnox> jodh: ack. Fair enough, used a different check/event so i'm all good.
[12:35] <GunnarHj> xnox: Anything I can do to help processing bug #1294858? Or will it have to wait?
[12:55] <xnox> GunnarHj: i didn't have time to look into it yet. if not this week, then it would be for U-cycle / SRU into trusty 14.04.1 release =/
[12:56] <GunnarHj> xnox: Ok thanks, then I know.
[13:17] <jdstrand> xnox: thanks for the apparmor job! question: because this is a task, it isn't possible for a console login, lightdm login, *dm login, etc to happen without this first running?
[13:17] <jdstrand> well a task and its start on line
[13:19] <xnox> jdstrand: it's a task, thus "started appararmor-loaded" event will only be emitted after it completes fully.
[13:19] <xnox> jdstrand: thus e.g. another jobs can do "and started apparmor-loaded" or in their pre-start do $ start apparmor-loaded, which will block until it's completed.
[13:20] <xnox> jdstrand: let me check the graphs to see where it's placed... 1sec.
[13:20] <jdstrand> xnox: ok, right. so in order to deploy this properly, we need an apparmor job and then adjust all other login jobs to use "and started apparmor-loaded"
[13:21] <jdstrand> xnox: what happens when apparmor is not installed on the system?
[13:21] <jdstrand> xnox: eg, someone wants to use selinux
[13:23] <smoser> pitti, deal
[13:23] <pitti> smoser: in case you need to reboot the host: apw is currently debugging the segfault on wolfe-05, so can you please wait with that a bit?
[13:23] <pitti> smoser: rebooting the other three VMs is fine at any time as they are essentially dead (at least with ssh)
[13:24] <xnox> jdstrand: there is a better way
[13:24] <jdstrand> xnox: I guess we could solve that by having upstart itself ship the job file
[13:24] <jdstrand> xnox: oh?
[13:25] <jdstrand> xnox: I also think we need something along the lines of: http://paste.ubuntu.com/7226194/
[13:26] <jdstrand> so I can collapse the click-apparmor and apparmor jobs into one
[13:26] <xnox> jdstrand: so if we change it to "start on mounted MOUNTPOINT="/" " then that job will block reaching further significant events (e.g. local-filesystems, filesystems, runlevel, etc.) until apparmor profiles are compiled and fully loaded.
[13:26] <smoser> pitti, i bounced the guests.
[13:26] <smoser> and they should all be up now.
[13:26] <jdstrand> (along with short-circuiting some known situations)
[13:27] <pitti> smoser: cheers; I'll dist-upgrade them while they are still off jenknis, and then plug them back in
[13:27] <xnox> jdstrand: yeah, but will need to add a not-container check in the script itself, since we can't block on an "and" condition.
[13:29] <jdstrand> xnox: I'm not sure I understand the statement. are you saying that we should remove 'and not-container' and then uncomment the '#[ -x /bin/running-in-container ] && /bin/running-in-container && exit 0' ?
[13:31] <xnox> jdstrand: well running-in-container is shipped by upstart =) so yeah, we'd need to add a line which is "! running-in-container"
[13:31] <xnox> to the job.
[13:33] <jdstrand> xnox: ok, here is the updated job: http://paste.ubuntu.com/7226232/
[13:33] <jdstrand> xnox: the 'better way' was referring to making sure console and display managers logins don't have to be modified?
[13:34] <xnox> jdstrand: that's way too much.
[13:34] <jdstrand> xnox: what is too much?
[13:35] <xnox> jdstrand: clicks are already handled by the click-apparmor.conf job
[13:35] <jdstrand> xnox: I know-- I want to remove that job
[13:36] <xnox> jdstrand: ok, "convergence" eh? =)
[13:36] <jdstrand> honestly, I'd like to find a better way than that hack I came up with to know when to run aa-clickhook, but that is for another day
[13:36] <beisner> rbasak - cool, thx. looks like it's just about tackled (ping getcap)
[13:38] <xnox> jdstrand: i don't like the gazzilion checks we do in shell. If the task fails, that's fine and the upstart job will stop, cause it's all running under set -e.
[13:38] <xnox> jdstrand: thus none of the upstart jobs typically do  [ -x /usr/bin/foo ]; exec /usr/bin/foo
[13:39] <jdstrand> ehh
[13:39] <jdstrand> that makes me very unconfortable
[13:39] <xnox> jdstrand: if load_configured_profiles gracefully fails, when apparmor is not available that's all what we need.
[13:39] <xnox> jdstrand: i'd rather be aggressively loading the profiles.
[13:40] <jdstrand> xnox: load_configured_profiles is shell. I can move the checks there, but not sure what difference that would make
[13:40] <xnox> jdstrand: http://paste.ubuntu.com/7226258/ without any checks.
[13:40] <xnox> they are no-op code / asserts.
[13:41] <jdstrand> so, we actually do have these checks
[13:41] <xnox> ... because of $reasons ?! =)
[13:41] <jdstrand> look at /lib/init/apparmor-profile-load
[13:41] <xnox> right.
[13:41] <jdstrand> that is what something like mysql uses
[13:42] <jdstrand> we have these checks because over the years we've found they are needed
[13:42] <pitti> cyphermox, Laney: NM with adjusted tests uploaded; something in the DHCP client stack got slower, so I had to bump the DHCP timeout from 15 to 20 seconds to make them pass again; the other failure was due to the PE change in ubuntu5
[13:42]  * xnox can't wait for "u-cycle" to switch all of these to apparmor stanza =)))
[13:42] <pitti> cyphermox: I disabled the negative test for the temporary IP with PE disabled, as I'm not sure whether that's intended
[13:42] <jdstrand> well, I figured we wouldn't do that too aggressively because of systemd
[13:43] <xnox> jdstrand: having all check in the upstart job is fine. as long as the conditions are correct.
[13:43] <cyphermox> pitti: I think the PE stuff was broken and is now fixed
[13:43] <xnox> jdstrand: e.g. check for /sys/kernel/security manually, as one cannot do "and mounted MOUNTPOINT=" reliable (mounted event blocks mountall and thus other portions of the and condition will not get emitted and deadlock mountall)
[13:44] <pitti> cyphermox: yeah, perhaps; before, you got a temp IP with PE enabled, and no temp IP with PE disabled, which sounded quite plausible
[13:44] <cyphermox> well, no that's the way it should be
[13:44] <xnox> jdstrand: hence "start on mounted MOUNTPOINT="/"" and this point it's past mounting "/sys/kernel/security" or try to mount it again. and all profile loading will block boot.
[13:44] <pitti> that's the way that it was until ubuntu5, now it always gets a temp IP
[13:45] <xnox> jdstrand: and it practice it's lightning quick, here on a typical laptop with an SSD.
[13:45] <cyphermox> pitti: must be that the fixes to some patches got done wrong
[13:45] <cyphermox> pitti: I'll take a look at it
[13:46] <pitti> cyphermox: ok, thanks; I disabled that test in r812 as you told me it's correct now; but please revert that if it passes again
[13:46] <jdstrand> xnox: sorry, you lost me. the apparmor job in my paste (http://paste.ubuntu.com/7226232/) doesn't currently check for /sys/kernel/security/apparmor (I missed that). are you saying it should or should not?
[13:46] <xnox> jdstrand: let me reply with a paste =)
[13:46] <cyphermox> sure
[13:48] <pitti> cyphermox: not sure where the slowdown comes from, but with the increased timeouts they at least pass again
[13:51] <cyphermox> right
[13:51] <cyphermox> pitti: you meant ubuntu6 for the patches no?
[13:51] <cyphermox> ubuntu5 contains a patch, but it should be irrelevant to PE
[13:52] <pitti> cyphermox: could be, yes; I meant reversion of the disabled "no temp IP" test (r812)
[13:52] <cyphermox> ok
[13:52] <pitti> if the previously checked behaviour was in fact right, and the test pointed out an actual regression
[13:55] <xnox> jdstrand: something like this: http://paste.ubuntu.com/7226316/
[13:55] <xnox> jdstrand: changed "start on" and added "/sys/kernel/security" block.
[13:56] <jdstrand> xnox: ack
[13:57] <jdstrand> I wonder if mounting securityfs is enough to get /sys/kernel/security/apparmor
[13:57] <jdstrand> I guess it would be (would have to check)
[13:58] <pitti> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > your eglibc upload keeps my little minions busy :)
[13:58] <jdstrand> xnox: so, because this is 'start on mounted MOUNTPOINT="/"' and it's a task, does that mean other jobs/tasks will block until this is done?
[13:59] <mvo> pitti: hehe
[13:59] <jdstrand> xnox: ie, we don't have to adjust the lightdm job (et al)
[13:59] <xnox> jdstrand: correct it will block, and no changes are required in other jobs.
[14:00] <apaKhelogger> does anyone know under which circumstances /proc/sys/crypto/fips_enabled would be present and get EACCESS on fopen()?
[14:00] <apaKhelogger> I don't seem to have crypto/ at all
[14:01] <jdstrand> xnox: ok, cool. I've got this locally. I guess my team can figure out if we want to push this in 14.04 (it requires a lot of testing)
[14:01] <jdstrand> xnox: thanks for you help! it will definitely be in 14.10
[14:01] <xnox> jdstrand: "in 14.10" as in, in just 9 days ;-) =)))))
[14:02] <jdstrand> :)
[14:04] <apw> stgraber, when we setup lxc environments, what do we use to setup the network brigding for them ?
[14:06] <stgraber> apw: most people just use the bridge that's setup by the lxc-net upstart job, or you can define extra bridges in /etc/network/interfaces or you can use libvirt's own bridges
[14:07] <cjwatson> rbasak: ok, hopefully wheels now mostly in motion - thanks for the heads-up
[14:08] <rbasak> cjwatson: no problem. Thank you for looking at it at such short notice. I certainly wouldn't have been able to figure out all the pieces quickly enough.
[14:08] <cjwatson> I probably can't easily do much about systems that are already broken
[14:08] <cjwatson> dpkg-reconfigure of the relevant packages should sort them out, or possibly even ongoing upgrades
[14:09] <jdstrand> xnox: so, in theory, this upstart job would remove the need for the apparmor stanza?
[14:09] <cjwatson> or sudo apt-get --reinstall iputils-ping etc. (perhaps also iputils-arping, gnome-keyring)
[14:09] <Laney> pitti: thanks!
[14:09] <cjwatson> s/--reinstall/--reinstall install/
[14:09] <rbasak> --reinstall is what I was thinking. dpkg-reconfigure wouldn't fix the delivered binaries, would it?
[14:10] <cjwatson> dpkg-reconfigure has the side-effect of running the postinst and it's the postinst that sets the capabilities
[14:10] <cjwatson> but --reinstall is probably better, rather than perpetuating the meme of using dpkg-reconfigure for things other than debconf :)
[14:10] <brainwash> xnox: please help! =S
[14:10] <rbasak> Ah - I was under the impression that the binary package's archive magically contained the capabilities.
[14:11] <cjwatson> no, in a sane world it'd be that way, but I think it has to be in maintainer scripts because packages need to define fallbacks in the event of filesystems that don't support xattrs
[14:11] <rbasak> I see - thanks.
[14:11] <brainwash> xnox: the xubuntu installer background issue needs to be fixed and I would like to help debugging it
[14:12] <rbasak> A no change rebuild of the affected packages would fix everything then, right? Not worth it?
[14:13] <apw> stgraber, i am more asking by default what interface do you use to add things to the bridge
[14:13] <cjwatson> rbasak: it would, though no way to synchronise it with people who do installs from beta-2 media between now and release
[14:13] <apw> stgraber, do you run external things, or talk netlink, or ...
[14:13] <stgraber> apw: netlink
[14:13] <apw> stgraber, where do i find your netlink bits for that
[14:14] <cjwatson> rbasak: maybe just -devel-announce with a recipe once the installer is fixed
[14:14] <rbasak> Anyone who installed from beta-2 media would have an older version though, and so would end up upgrading and thus fixing?
[14:14]  * rbasak doesn't follow
[14:14] <cjwatson> well, uh, maybe you're right
[14:14] <stgraber> apw: https://github.com/lxc/lxc/blob/master/src/lxc/network.c
[14:15] <cjwatson> yeah, I think you are
[14:15] <cjwatson> still, hold off until the installer's done, I need to get attr in and then I need to write the live-installer code; and we need to upload ubiquity
[14:15] <stgraber> apw: oh, actually, looks like the bridge add is done through an ioctl
[14:15] <rbasak> OK, sure. Thanks!
[14:18] <jamespage> pitti, have you seen anything like bug 1303649
[14:18] <jamespage> pitti, I've hit it on my main laptop, a spare and now on one of our servers in the CI lab
[14:18] <pitti> jamespage: not so far; when did that start, just recently? i. e. with the cgmanager integratino?
[14:18] <jamespage> pitti, might have - its definately in the last week or so I noticed it
[14:18] <pitti> jamespage: yeah; it otherwise hasn't changed for the entire cycle
[14:19] <jamespage> mainly because my fan was being noisy
[14:19] <pitti> jamespage: when that happens, could you attach strace to it, to see what it's spinning on?
[14:19] <jamespage> pitti, sure
[14:22] <jdstrand> xnox: also, this job should also obviate the need to the network-interface-security job, no?
[14:27] <xnox> jdstrand: definately not needed any more for the network-manager and networking, not sure about network-interface
[14:28] <xnox> jdstrand: yeah, it shouldn't be needed. but do test without network-interface-security job.
[14:28] <hallyn> what time does freeze start?
[14:28] <jdstrand> xnox: I haven't tested it, but for network-interface-security it needs to have '/' mounted to load the policy at all
[14:29] <jdstrand> xnox: so if the apparmor task blocks, then network-interface-security should come after it
[14:29] <jdstrand> xnox: but yes, need to test
[14:29] <jdstrand> xnox: if it doesn't work, I guess we could add another condition in the network* jobs to make sure
[14:30] <mvo> does "Apr  9 14:08:19 base-installer: apt-install or in-target is already running, so you cannot run either of" ring a bell? bugreport from a friend of mine installing the server cd on a dell poweredge. if not I will try to reproduce and look into it
[14:30] <mvo> (image from yesterday apparently)
[14:32] <hallyn> d'oh, it's tomorrow.  silly me
[14:43] <rbasak> xnox: may I have your comment on bug 1303717 please? Is a missing init.d script a policy violation? It reads to me that there must be a functional init.d service script, but I thought the plan was to detect and make them non-functional? Thus I'm a little confused.
[14:44] <Daviey> mterry: Hey, your disabled test in duplicity upload... Is there a bug tracking the issue?
[14:45] <mterry> Daviey, not yet, just a TODO on my sticky note  :)  I'll file one
[14:47] <Daviey> mterry: I quite favour putting the bug number in the .skip comment personally.. but I am sure you'll keep an eye on this, right? :)
[14:47] <Laney> Patch headers!
[14:48] <mterry> Daviey, yes.  I have an idea of how to fix already.  Just didn't want to wait given 14.04's imminent release  :)
[14:49] <Daviey> Laney: well yeah, that aswell... but seeing the skip reason when running a build does stand out.
[14:50] <xnox> rbasak: it's a policy violation in Debian.
[14:51] <xnox> rbasak: in ubuntu we have about 220 upstart jobs without init.d scripts shipped.
[14:51] <rbasak> xnox: thanks. We're considering it fine in Ubuntu to continue with upstart jobs with no init.d counterpart then?
[14:53] <ogra_> until systemd comes :)
[14:58] <xnox> rbasak: yes. as long as they are precise and trusty compatible.
[15:03] <mterry> Daviey, bug 1305124 filed btw
[15:15] <LocutusOfBorg1> hi, any ubuntu-sponsor there?
[15:15] <LocutusOfBorg1> I got an ack from release team
[15:15] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+bug/1290253
[15:16] <rbasak> LocutusOfBorg1: try arges. He's listed in the topic as on patch pilot duty today.
[15:16] <arges> rbasak: i am? i can take a look
[15:17] <LocutusOfBorg1> thanks
[15:17] <LocutusOfBorg1> usually I don't bother people, but they asked for "asap"
[15:18] <arges> LocutusOfBorg1: is there a debdiff / bzr associated with this bug?
[15:19] <arges> oh its a sync
[15:19] <LocutusOfBorg1> sync
[15:19] <LocutusOfBorg1> plain sync
[15:22]  * arges looks at it
[15:23] <LocutusOfBorg1> arges, can you please also look at this bug?
[15:23] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1296763
[15:23] <LocutusOfBorg1> seems to be the only way to fix https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1295963
[15:23] <arges> man, i forgot to pilot out from the other day
[15:23] <arges> @pilot out
[15:23] <arges> LocutusOfBorg1: ok let me get to that next.
[15:24] <LocutusOfBorg1> but unfortunately the package is stuck in debian/new queue
[15:24] <LocutusOfBorg1> no problem arges
[15:24] <LocutusOfBorg1> :)
[15:24] <LocutusOfBorg1> I really appreciate
[15:25]  * pitti hugs mvo
[15:25] <pitti> mvo: apt: 10000b years and still not perfect :)
[15:26] <mvo> pitti: very true!
[15:26]  * mvo hugs pitti
[15:28] <arges> LocutusOfBorg1: bug 1296763 needs an FFe... its a really really big jump in versions and I doubt its a 'bug-fix only release'. I'll mark this in the bug
[15:29] <LocutusOfBorg1> yes arges , but the current version seems to be unusable
[15:29] <LocutusOfBorg1> don't know, this isn't a package I care too much
[15:30] <LocutusOfBorg1> but I'm working on libsdl-gfx transition right now
[15:30] <LocutusOfBorg1> and gambas is FTBFS
[15:30] <LocutusOfBorg1> the same for ubuntu https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741789
[15:30] <arges> LocutusOfBorg1: understood. see comment in the bug regarding FFe. Try going through that process.
[15:35] <arges> cjwatson: i'm looking at bug 1290253. i'd like to sponsor this FFe, but its a new package. Which tool(s) do I use to get this package in the upload queue? I have some ideas, but i'd liek to make sure i'm doing this correctly. Thanks
[15:35] <cjwatson> just syncpackage as normal
[15:36] <arges> cjwatson: then I should see it in the trusty new queue?
[15:36] <cjwatson> yep
[15:37] <arges> cjwatson: so acutally i did run this, but didn't get any feedback. I did 'syncpackage can-utils'...
[15:37] <cjwatson> it's in the new queue
[15:37] <cjwatson> $ queue info can-utils
[15:38] <cjwatson> or https://launchpad.net/ubuntu/trusty/+queue
[15:38] <arges> cjwatson: ah there it is : ) ok thought i was going crazy
[15:38] <arges> cjwatson: thanks
[15:38] <cjwatson> np
[15:52] <LocutusOfBorg1> thanks
[16:03] <Riddell> Sweetshark: what's the plan for bug 1300283 ? you will upload with the revert?
[16:08] <cjwatson> Riddell: he already did, I accepted it recently
[16:09] <mvo> slangasek: I was looking at bug #1243090 as it appears on the qa tracker and wonder if http://bazaar.launchpad.net/~mvo/update-notifier/use-pycurl/revision/845 might be something worth considering (needs a real testcase first, but not worth persuing if its too late anyway which I kind of suspect :)
[16:12] <Riddell> cjwatson: nice
[16:13] <jdstrand> slangasek, xnox and infinity: fyi, I just subscribed you to bug #1305108 (I split it from bug 1298539). if you want to peruse the attach job for obvious errors or the description for obvious problems, that's fine, but mostly I wanted to make sure you guys saw in conversations surrounding it.
[16:13] <jdstrand> slangasek, xnox, infinity: the security team hasn't discussed the timing of landing this, so fyi only atm
[16:21] <infinity> jdstrand: I like it.  What are the odds we could band together and test this enough to actually make the change for release?  I know that fails the "conservative changes only" test by a mile, but I can't help thinking the security (and simplicity) win here is worth it.
[16:25] <jdstrand> infinity: it is tempting, isn't it? I need to talk with mdeslaur and the team to see what resources we can put behind it. I plan to do that in a bit when people are online
[16:25]  * jdstrand is coordinating another landing atm
[16:28] <mdeslaur> I personally think it's insane
[16:37] <infinity> mdeslaur: What's insane?  Trying to land the upstart change?
[16:37] <infinity> mdeslaur: Or the current state of affairs?
[16:37] <infinity> mdeslaur: Or both? :P
[16:37] <mdeslaur> trying to land that at this time, in an LTS, blocking boot for policy compilation, not adding it to upstart as a library before other jobs get processed, etc.
[16:40] <zyga> mvo: hey, could you look at checkbox-ng in debian again? we missed a build-dep after one of the dpeendencies droping one of their own dependency. I just commited a one-line fix for that, could you please sponsort that and sync it over to Ubuntu?
[16:40] <zyga> http://paste.ubuntu.com/7227007/
[16:40] <zyga> that's the debidiff
[16:40] <zyga> roadmr: ^^
[16:40] <zyga> pitti: ^^ (perhaps?)
[16:42] <roadmr> zyga: looks ok to me, but we need someone who can sponsor that for us :(
[16:42] <zyga> I know, just letting you know
[16:43] <slangasek> mvo: 1243090> how does switching to curl fix the actual bug?
[16:43] <roadmr> zyga: thanks :)
[16:44] <slangasek> mvo: I'm inclined to say we shouldn't push this before 14.04; but if we know for sure that curl fixes a bug vs. urllib, maybe this should be an SRU?
[16:44] <pitti> zyga, roadmr: yes, can sponsor
[16:45] <zyga> thanks
[16:45]  * zyga needs to figure out how to do clean feeder archive builds locally :-(
[16:48] <pitti> zyga: uploaded
[16:48] <zyga> pitti: thanks, what do we need to do about syncing it to ubuntu now?
[16:48] <zyga> pitti: requestsync again after it clears debian?
[16:48] <pitti> zyga: wait for about 8 hours, i. e tomorrow morning
[16:51] <zyga> pitti: can that still be synced tomorrow? the deadline is 10th of April, is it not?
[16:51] <pitti> zyga: I can also do a fakesync
[16:51] <zyga> what it a fakesync?
[16:52] <pitti> take the Debian .dsc and build an ubuntu source.changes for it (syncpackage --no-lp)
[16:52] <pitti> zyga: uploaded; if the release team doesn't like that, we can sync it properly tomorrow morning
[16:52] <zyga> pitti: thanks, I really owe you one
[16:53]  * zyga will learn and setup proper clean, feeding package build infrastructure at home
[16:53] <slangasek> jdstrand, mdeslaur, infinity: yes, I don't think we should make this change last minute, especially when the driver for this seems to be an issue we have no root causing for and moving apparmor loading up earlier in boot risks making our race condition harder to track down (but no less harmful)
[16:54] <pitti> zyga: sbuild is great; if you combine it with apt-cacher-ng, and symlink /var/lib/schroot/unpack to a tmpfs (I use /tmp), it outright rocks :)
[16:54] <pitti> and mk-sbuild is fairly easy to do
[16:55] <zyga> I'll give sbuild another go, I had issues with getting some of standard tools to build clean debian correctly and I ended up doing custom, broken stuff
[16:59] <pitti> hm, I build all my stuff in a sid sbuild, works quite nicely
[17:05] <cjwatson> ditto, have absolutely no problem with sbuild for Debian.  I think a few Ubuntu releases back it was less good
[17:08] <Laney> my problem is my inability to remember -s
[17:09] <pitti> Laney: heh, me too; I have alias sbuild-sid='sbuild -s -d unstable'
[17:10] <pitti> Laney: and $build_source = 0; in ~/.sbuildrc, as I don't generally want it to (re)build my source, I usually do that with bzr bd or git-buildpackage
[17:10] <Laney> pitti: good idea
[17:10] <Laney> ooh, build_source, that'll help
[17:11] <Laney> hrm, it's supposed to default to 0
[17:14] <pitti> Laney: perhaps; could also be because I copied that from a template
[17:14]  * pitti waves good night
[17:14] <Laney> I'm in the habit of not passing -s for ubuntu because it was doing that ...
[17:14] <Laney> possibly an obsolete habit though
[17:15] <bdmurray> pitti: what about ProcMaps and python crashes - is it useful?
[17:22] <cjwatson> chrisccoulson: is there any chance you could fix the firefox-testsuite -> ttf-arphic-ukai NBS entry (http://people.canonical.com/~ubuntu-archive/nbs.html) in time for release?
[18:05] <bdmurray> jibel: why is bug 1269397 set to high?
[18:14] <chrisccoulson> cjwatson, will get to it later
[18:19] <bdmurray> infinity: Do you have time to look at bug 1296386?
[18:29] <infinity> bdmurray: It seems to rely on a kernel patch that hasn't been accepted yet.
[18:30] <infinity> bdmurray: Err, well, the other bug does.  This one might be harmless to fix regardless.
[18:31] <bdmurray> infinity: ah, well I think the casper one is causing some install failures
[18:32] <infinity> Yeah, we can fix the casper one.  It might break sound on a select few machines in the live environment, but that seems like a fair tradeoff.
[18:35] <infinity> bdmurray: FWIW, it was added in 2006, due to https://bugs.launchpad.net/ubuntu/+source/casper/+bug/27862
[18:36] <bdmurray> woo, a time capsule
[18:38] <infinity> bdmurray: So, the way I see it, fixing casper will make the live session happy, but the world will still explode on reboot into the installed system without fixing bug #1296373
[18:38] <infinity> And fixing that one will leave people without sound entirely until the kernel patch is in.
[18:38] <infinity> Fun.
[18:38] <infinity> Maybe still worth it.
[18:38] <infinity> No sound is better than crashy kernels.
[18:47] <infinity> bdmurray: casper change uploaded, hw-detect change commented on, kernel change still in BenH's hands, but maybe we can get it pulled into 3.13 stable as an SRU.
[20:25] <cjwatson> chrisccoulson: thanks
[20:41] <Sweetshark> Riddell: as noted on the bug: was uploaded today, has finished building on amd64/i386. Note that the libreoffice-kde thing in 4.2.3 is still somewhat shaky, there is a set of additional fixes upstream in for 4.2.4 that were too risky to backport this late.
[20:43] <Sweetshark> Riddell: so while this fixes the immediate issue -- back to the state we had before, 4.2.4 should be better in general, and be quickly SRUed after testing.
[20:47] <Riddell> Sweetshark: great, thanks
[21:17] <rsalveti> slangasek: bug 1305315 (the issue with the i386 android toolchain)
[21:21] <rsalveti> and another one related with the toolchain: bug 1302799
[22:02] <rsalveti> slangasek: for qtbase: http://paste.ubuntu.com/7228323/
[22:03] <rsalveti> slangasek: also had to remove the custom override_dh_makeshlibs rule, as that was causing all the packages to have a runtime dep of (= ${binary:Version})
[22:04] <rsalveti> that was something we got from the 4.8 src package, not sure exactly why that was decided
[22:04] <rsalveti> let me know if you're fine with it and I'll do a src upload
[22:05] <slangasek> rsalveti: fwiw in my own testing, variants 3 and 5 of the symbol dependency were unused and can be safely dropped
[22:05] <rsalveti> slangasek: yup, just had there for reference, but yeah, let me remove it
[22:07] <slangasek> rsalveti: seems ok to me otherwise
[22:07] <slangasek> and pretty closely matches what I had here
[22:07] <rsalveti> great
[22:14] <bdmurray> stgraber: does ubiquity update itself before starting the install?
[22:18] <stgraber> bdmurray: no. The option is however provided to the user if they wish to do so.
[22:19] <bdmurray> stgraber: ah, and do you recall what that updates? just ubiquity?
[22:22] <stgraber> bdmurray: not sure, sorry
[23:11] <xnox> bdmurray: from code, it upgrades ubiquity. but it needs to be service-side triggered (e.g. similarish to how upgrade-manager / manifests are triggered to move people to next lts)
[23:12] <xnox> bdmurray: i've never triggered that, though.
[23:13] <xnox> bdmurray: 'http://changelogs.ubuntu.com/ubiquity/%s-update-available' % _ver is the trigger
[23:13] <bdmurray> xnox: I think the fix for bug 1051935 created bug 127706
[23:14] <bdmurray> er bug 1277706
[23:15] <xnox> bdmurray: not sure what you mean, we respun isos to have everything matching and the bug posted is using  Mythbuntu 12.04.3 "Precise Pangolin" - Release i386 (20130820) - 12.04.3 media
[23:16] <xnox> bdmurray: during sru process we noticed that we both updated on the images, which we did for 12.04.4
[23:17] <xnox> bdmurray: or you think we should be triggering ubiquity upgrade for 12.04.0, .1, .2 and .3 media? we'd need to test them...
[23:17] <bdmurray> xnox: I'm suggesting that ubiquity gets updated and then tries to use code only available in the new version of python-apt
[23:17] <bdmurray> xnox: notice how there are 2 different ubiquity versions in the log
[23:18] <bdmurray> 2.10.26 and 2.10.29
[23:18] <xnox> i see what you mean now.
[23:21] <xnox> bdmurray: right, ubiquity in precise should have a tigher versioned depends on python-apt e.g. >= 0.8.3ubuntu7.2 and we did not do that. This way if somehow, for whatever reason ubiquity is upgraded in the live system (manually that is at the moment) an updated python-apt is also forced to be installed.
[23:22] <bdmurray> ah, yeah that would fix it
[23:24] <xnox> bdmurray: i'll prepare the SRU and test-plan to reproduce the bug.
[23:24] <bdmurray> xnox: I don't think it should be a rush
[23:25] <bdmurray> I mean it would be fine after 14.04...
[23:25] <xnox> bdmurray: well assigning the bug to myself for now. indeed it's not a common code path to hit. Indeed 14.04 tasks are of the most priority at the moment =))))
[23:26]  * xnox needs more vocabulary


[03:02] <qwebirc78094> Hello, Should I go with a dedicated video adapter or will on board video be enough to playback 1080p videos with mythtv?


[07:20] <tsdgeos> Saviq: i was busy with code reviews on thu/fri and have a bunch of stuff on the approved pipeline, do you think we can get a silo today? Otherwise stuff is going to end up conflicting etc
[07:29] <mhr3> Saviq, btw why did you decide against a devel branch?
[07:42] <Saviq> tsdgeos, sure, will try and get it in today
[07:42] <tsdgeos> :)
[07:43] <tsdgeos> Saviq: btw any clue what's wrong with otto?
[07:43] <Saviq> tsdgeos, nope, will talk to ci eng
[07:43] <Saviq> mhr3, because didrocks told us they don't want us to have them, I don't like what it does to the history, I didn't see all that much advantage
[07:44] <mhr3> fewer conflicts?
[07:44] <Saviq> mhr3, also, suddenly it's difficult to cherry-pick into trunk, because all the branches have some of devel in them already
[07:44] <mhr3> and noone likes those :)
[07:45] <Saviq> mhr3, we've been doing fine with those - you just need to release often, and we've been doing fine
[07:45] <mhr3> but yea, perhaps it wouldn't work that great for you
[07:45] <tsdgeos> yeah i think we're doing mostly fine
[07:45] <tsdgeos> and most of the conflicts we end up with are "easy" to solve anyway
[08:16] <tsdgeos> Saviq: it does affect all the tests, but there's no other benchmarks so it doesn't :D
[08:16] <tsdgeos> but yeah need to pass that as variable since we'lk possibly have slower/faster benchmarks in the future
[08:16] <tsdgeos> and a hardcoded value is not going to fly there
[08:21] <Saviq> tsdgeos, k
[08:22] <tsdgeos> Saviq: so when thinking about that list of "things that are upstreamable to SDK", well there's stuff like the whole Card/Previews stuff that personally I don't think they make sense there but they may be upstreamable if designers want to replicate the Dash layouting on some app
[08:23] <Saviq> tsdgeos, yeah, agreed, low prio for upstreaming, though
[08:23] <tsdgeos> so makes it even sense to write it there or?
[08:24] <Saviq> tsdgeos, yeah, add them as "if you want them" or something
[08:24] <tsdgeos> ok
[08:24]  * tsdgeos restarts again then :D
[08:26] <tsdgeos> Saviq: i think https://code.launchpad.net/~macslow/unity8/fix-notification-ap-test-assertions/+merge/212169 is included in https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988 so it should either be discarded or them redone with dependencies or somethimg, no?
[08:27] <tsdgeos> MacSlow: ↑↑↑
[08:27] <Saviq> tsdgeos, doesn't look included, there's more changes in the first branch
[08:28] <Saviq> tsdgeos, but yeah, need to be reconciled
[08:28] <tsdgeos> ah right, they're similar changes but not exactly the same
[08:28] <tsdgeos> sorries
[08:28] <Saviq> don't be, better safe'n'sorry
[08:32] <tsdgeos> karni: no, predictive text is now disabled :D
[08:33] <karni> tsdgeos: hahaah thanks
[08:33] <karni> I thought this was a bad joke
[08:49] <Saviq> tsdgeos, so one thing changed with run-upstart, Alt+F4 or clicking on the window X just results in unity8 respawning...
[08:50] <tsdgeos> trueth
[08:50] <Saviq> tsdgeos, not *sure* that's a problem, though, or how to change that behaviour
[08:50] <Saviq> or that we want to
[08:51] <Saviq> nah, ok, we'll just have to let people know
[08:51] <tsdgeos> not an upstart expert enough to know how to fix that
[08:51] <tsdgeos> but honestly give run is "for us" and that it improves quite a bit the behaviour when run on the phone
[08:51] <tsdgeos> i'll take that over the lock button crashing it on the phone
[08:51] <Saviq> tsdgeos, well, it does improve on desktop, too, e.g. the scope list
[08:51] <Saviq> tsdgeos, +1
[08:55] <Saviq> /food
[09:14] <tsdgeos> guys, an easy one https://code.launchpad.net/~aacid/unity8/remove_acws/+merge/215624
[09:25] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/carousel_test_base_delegate/+merge/215626
[09:25] <Cimi> tsdgeos, I did not write that test :D
[09:26] <tsdgeos> Cimi: i know you didn't, i'm asking you to review the change
[09:26] <Cimi> ah ok
[09:27] <MacSlow> tsdgeos, I'm fixing the issues between lp:~macslow/unity8/modal-snap-decisions and lp:~macslow/unity8/fix-notification-ap-test-assertions
[09:28] <Cimi> seb128, a review would be nice https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[09:28] <Cimi> seb128, when you or your guys have time
[09:29] <seb128> Cimi, sure, not likely to be this week with the lts release
[09:29] <seb128> but it's on my backlog
[09:31] <Cimi> Saviq, greyback I used InputFilterArea in the wizard, I dinamically put blockInput true/false when the notification shows or not, but when it turns false (so should not block input anymore), my interface does not receive any events in any case. What could it be?
[09:32] <MacSlow> tsdgeos, there's one line from lp:~macslow/unity8/fix-notification-ap-test-assertions which slipped into lp:~macslow/unity8/modal-snap-decisions
[09:33] <greyback> Cimi: when you run the wizard (unity-mir compiled with debug mode too), do you see  "Shell depth" message printed?
[09:33] <greyback> Cimi: or a "Default depth" message
[09:33] <tsdgeos> MacSlow: i see, so leave it like that or?
[09:34] <Cimi> greyback, I did see it when I compiled with debug
[09:34] <MacSlow> tsdgeos, no no... I remove the rogue line so they'll cleanly merge
[09:34] <tsdgeos> ok
[09:35] <greyback> Cimi: certain? As if that message ("Shell depth") is not printed, then InputAreas won't work.
[09:36] <greyback> Cimi: as internally in unity-mir, it tried to guess which surface is the shell's surface, so it can place input filter areas on it. If the guess fails, no input to shell/wizard
[09:36] <MacSlow> tsdgeos, fix pushed
[09:37] <Cimi> greyback, it does work
[09:38] <Cimi> greyback, but when I switch blockInput to false
[09:38] <Cimi> greyback, it feels like it's still true
[09:40] <greyback> Cimi: ah I see what's happening. With unity-mir, the shell/wizard surface will *always* get input. What inputFilterAreas do is decide if the input should *also* go to the app surface underneath or not.
[09:40] <MacSlow> tsdgeos, so now the rogue line is gone form https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988
[09:40] <tsdgeos> oki
[09:40] <greyback> Cimi: reason is that shell always wants to listen for edge swipes, even if app on screen. So in that case, an input event goes to *both* shell and the application.
[09:41] <greyback> Cimi: but naturally there are times that shell wants to exclusively take all events, and not let them be copied to the application. That is what Inputareas let shell do
[09:46] <Cimi> greyback, I don't understand why setting it back to false
[09:46] <Cimi> greyback, still my shell doesn't get events
[09:47] <greyback> Cimi: Your shell should always get events. Can you share your code please?
[09:47] <Cimi> greyback, https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[09:49] <Cimi> greyback, http://bazaar.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/view/head:/wizard/qml/main.qml
[09:51] <greyback> Cimi: can you please pastebin me the output of your wizard when you run it?
[09:51] <greyback> Cimi: also, without any input areas in the code, does your wizard get input?
[09:51] <Cimi> greyback, yopu want me unity mir with debug?
[09:51] <Cimi> greyback, of course
[09:51] <greyback> Cimi: yes
[09:51] <Cimi> greyback, works with blockInput: false
[09:51] <Cimi> too
[09:52] <Cimi> greyback, but not with blockInput: height > 0 or other combo
[10:03] <Saviq> MacSlow, what issues?
[10:04] <tsdgeos> Saviq: the fact that they conflict
[10:04] <Saviq> tsdgeos, they don't?
[10:04] <tsdgeos> Saviq: there was one change from one in the other, he's removed one line from a that was in b by mistake
[10:05] <Saviq> hmm there was no conflict, though...
[10:05] <Saviq> anyway, let me rebuild the landing, then...
[10:05] <tsdgeos> interesting
[10:06] <tsdgeos> maybe they had been merged originally and bzr just said "sure this is the same change, carry on"
[10:06] <Saviq> probably
[10:08] <MacSlow> Saviq, there was a line from lp:~macslow/unity8/fix-notification-ap-test-assertions somehow in lp:~macslow/unity8/modal-snap-decisions
[10:09] <Saviq> MacSlow, ok got it
[10:09] <MacSlow> Saviq, no idea how it slipped in there
[10:09] <MacSlow> Saviq, sorted it out now
[10:15] <Saviq> MacSlow, please strip the tags of your branches, as per my email from last week
[10:21] <MacSlow> Saviq, didn't we once wipe all those already?
[10:21] <mhr3> Saviq, anything in unity actually linking to libunity-api?
[10:21] <Saviq> MacSlow, apparently not everyone
[10:21] <Saviq> mhr3, no
[10:22] <Saviq> MacSlow, so we're all contaminated again
[10:22] <mhr3> thx
[10:22] <tsdgeos> Saviq: kill ScopeDelegateMapper, can I?
[10:23] <Saviq> tsdgeos, no, we still have DashApps?
[10:23] <Saviq> tsdgeos, or well, if you move the func up, then yeah
[10:24] <tsdgeos> Saviq: yeah but what it does i can make it in place, not in an item people will get tempted to add stuff to
[10:24] <Saviq> tsdgeos, sure
[10:40] <MacSlow> Saviq, since it's very slow to wipe the tags of remote branches, I'm doing it on lp:~macslow/unity8/fix-notification-ap-test-assertions and lp:~macslow/unity8/modal-snap-decisions only... as these are ready to land... I'll check other unity8-branches later
[10:40] <Saviq> MacSlow, yeah, it's rather slow remotely, thanks
[10:41] <MacSlow> Saviq, thought I could do it locally and then push, but forgot that any tag-change doesn't count as a commit so it would not push anything afterwards.
[10:42] <Saviq> MacSlow, indeed
[10:42] <MacSlow> Saviq, I wonder if that's worth a feature-request :)
[10:42] <MacSlow> but then... one does not do such things frequently enough to justify something like this
[10:42] <Saviq> MacSlow, bzr is in maint-only mode, and I really doubt it's easy to do... tags are just completely disconnected from commits in bzr...
[10:54] <Cimi> greyback, http://paste.ubuntu.com/7249077/
[10:56] <greyback> Cimi: okay, nothing looks wrong.
[10:56] <greyback> Cimi: let me try compiling your code and give it a go
[10:57] <Cimi> greyback, want packages?
[10:57] <Cimi> I have them built
[10:57] <greyback> Cimi: nah, will do myself, thanks tho
[10:57] <Cimi> greyback, you need unity mir
[10:57] <Cimi> greyback, wizard wifi
[10:58] <Cimi> (uncomment the inputfilterarea and copy the upstart job)
[10:58] <Cimi> greyback, and you need unity8 branch too (or just update the upstart file from my branch)
[10:59] <Saviq> Cimi, tsdgeos, elopio, please have a look at your approved MPs and clear the tags as mentioned in the comment
[10:59] <Saviq> (and then all of them, local or remote, as per my email last week)
[10:59] <greyback> Cimi: ok. Gimme a while to get set up
[10:59] <Cimi> Saviq, why we have tags again?
[10:59] <Saviq> Cimi, because someone didn't clear them before
[11:00] <Saviq> Cimi, and they're rather viral
[11:00] <Cimi> Saviq, when did you send this mail?
[11:00] <Cimi> and where?
[11:00] <Cimi> I cannot find it
[11:00] <Saviq> Cimi, last week, on unitynextuiteam ML
[11:01] <Cimi> weird I don't have it
[11:02] <Cimi> Saviq, last mail I have is from daniel "a bit away from computer today"
[11:02] <MacSlow> Saviq, tags cleaned
[11:02] <Saviq> MacSlow, thanks
[11:03] <Saviq> Cimi, "Pruning unity8 branches and tags" is the subject
[11:03] <Saviq> Cimi, ah wait
[11:03] <MacSlow> Saviq, I know check other unity8-branches I have... just to be sure nothing slips in again
[11:03] <Saviq> Cimi, it's probably still in moderation...
[11:03] <Cimi> Saviq, AH OK..
[11:03] <Cimi> ok
[11:09]  * tsdgeos looks at the positionedAtBeginning signal in DashContent
[11:09] <tsdgeos> and realizes we're using it as a function
[11:09] <tsdgeos> :S
[11:55] <Malsasa> Hello. My HUD on Ubuntu 12.04 doesn't work anymore. When I tap ALT, Unity opens menu of focused app, not the HUD. My complete question was in http://askubuntu.com/questions/447587/alt-key-for-hud-doesnt-work. I am sorry for my bad English. Thank you.
[12:24] <Cimi> Saviq, after deleting, shall I push or commit?
[12:24] <Saviq> Cimi, no, tags don't go with revisions, if you ran through them, they're deleted
[12:34] <Cimi> greyback, any luck?
[12:35] <greyback> Cimi: not ready yet, sorry
[12:41] <Malsasa> greyback: Hello. My HUD on Ubuntu 12.04 doesn't work anymore. When I tap ALT, Unity opens menu of focused app, not the HUD. Any idea for me? Thank you.
[12:42] <greyback> Malsasa: open System Settings, open "Keyboard", and in the new window, click the "Shortcuts" tab
[12:43] <Malsasa> greyback: I have did it many times. My complete quesion was here http://askubuntu.com/questions/447587/alt-key-for-hud-doesnt-work
[12:44] <Saviq> MacSlow, hey, can you look into bug #1307489 please?
[12:44] <MacSlow> Saviq, ok
[12:44] <greyback> Malsasa: huh, that's strange. Have you playe around in "ccsm" at all? Keys are also set in there, for hte Unity plugin
[12:45] <Saviq> MacSlow, ideally, would be good to get a reproducer without having to send an sms every time, can we make it somehow with the script as used in ap tests?
[12:45] <greyback> Malsasa: I see "Jos" replied with the same idea as mine. Give it a go
[12:45] <Malsasa> greyback: yes, I believe only I have this problem. It is very strange. I have play around CCSM too. I have set ALT there too.
[12:45] <MacSlow> Saviq, yup
[12:45] <MacSlow> Saviq, I see what I can do there
[12:45] <greyback> Malsasa: otherwise I'll have to point you to #ubuntu-desktop where there's more of the unity7 devs available
[12:46] <Saviq> MacSlow, I suspect this is actually happening on the "starting / focusing an app" front, but would like to have a confirmation
[12:46] <Malsasa> wow, so the developers are there? Thank you for pointing me, Mr greyback.
[12:46] <greyback> Malsasa: good luck!
[12:47] <MacSlow> Saviq, I'll make sure to see if the action attached t othe interactive notification is correctly called to rule out any issues with notifications
[12:47] <Malsasa> greyback: thank you from Indonesia!
[12:52] <tsdgeos> Saviq: all tags killed
[12:52] <Saviq> tsdgeos, cheers
[13:39] <greyback> Cimi: ok, so this /might/ be a mir bug. I've managed to launch the wizard and it gets no input events - didn't matter if I had an InputFilterArea or not.
[13:39] <greyback> Cimi: this is mainly after a fresh boot.
[13:40] <greyback> Cimi: one way to check is to set "MIR_SERVER_INPUT_REPORT=log" <- this turns on Mir's input debug printing
[14:00] <Cimi> greyback, so why I reproduce it with the inputfilterarea?
[14:04] <greyback> Cimi: I can't say. I don't see how your use of unity-mir would cause any different behaviour to unity8 tbh.
[14:05] <Cimi> tedg, hi, who is responsible for location indicator?
[14:06] <tedg> Cimi, me or charles
[14:06] <greyback> Cimi: if you could log a bug against unity-mir (to start), with exact instructions on how to reproduce it (clear enough for the mir folks to reproduce), we can have them look into it
[14:06] <tedg> Cimi, It has a pretty big MR pending though.
[14:07] <tsdgeos> Saviq: the ScopeDelegateMapper removal got a bit out of hand https://code.launchpad.net/~aacid/unity8/DashContentScopeDelegateMapperAndMiscFixes/+merge/215664 :D
[14:07] <tsdgeos> but it's now better!
[14:09] <Cimi> Saviq, ok wizard is pretty much ready but pending reviews... any big thing I can work next?
[14:11] <tsdgeos> Cimi: the review i gave you this morning :P
[14:11] <Cimi> tsdgeos, ok
[14:12] <MacSlow> Has anybody seen this happen to their N4 after updating to r294 -> https://www.youtube.com/watch?v=jE1aYjEC7EU somehow it does no longer mount (even adb fails to find the device)
[14:13] <tsdgeos> MacSlow: do you dual boot or something?
[14:13] <tsdgeos> there was a thread about it in the list
[14:13] <tsdgeos> if you do
[14:13] <MacSlow> tsdgeos, no... just plain Ubuntu nothing else
[14:14] <MacSlow> tsdgeos, remember the subject or part of it?
[14:14] <Saviq> MacSlow, I'm getting a test failure with the modal branch... I think mterry's greeter-ux-fixes might be playing with yours http://pastebin.ubuntu.com/7249940/
[14:14] <tsdgeos> #292 Mako
[14:14] <tsdgeos> but it was only dual boot
[14:14] <Saviq> MacSlow, ugh... I only had that with android...
[14:15] <MacSlow> Saviq, first I need to get my N4 working again...
[14:15] <Saviq> MacSlow, I'm afraid the only way I found is to flash factory android https://developers.google.com/android/nexus/images#occam
[14:15] <MacSlow> tsdgeos, thx... I'll read through it
[14:15] <Saviq> MacSlow, and flash ubuntu again
[14:15] <mterry> Saviq, MacSlow: I can look at the interactions between our branches
[14:16] <MacSlow> mterry, thx... that would be cool
[14:16] <MacSlow> Saviq, hm.. ok
[14:16] <Saviq> mterry, you can branch from http://people.canonical.com/~didrocks/citrain/silos/landing-001/unity8/
[14:17] <Cimi> tedg, I have this page for the wizard, but the location doesn't seem to do anything... can you spot the error? http://bazaar.launchpad.net/~cimi/ubuntu-system-settings/wizard.privacy/view/head:/wizard/qml/Pages/30-phone-settings.qml
[14:17] <MacSlow> Saviq, tsdgeos: well it does boot alright... I just can't seem to get any connection via USB/adb
[14:18] <tedg> Cimi, Yeah, the branches really need for it to land before anything works. There's a bunch of platform API stuff that needs to get in.
[14:18] <Cimi> tedg, eta?
[14:18] <Saviq> MacSlow, I suspect it's reconnecting every 5s or so, I had that (on dual-booted android, though)
[14:19] <MacSlow> Saviq, never setup my N4 to dual boot
[14:19] <tedg> Cimi, It's now our oldest pending MR, at just under 3 months. Hopefully soon :-)
[14:19] <MacSlow> Saviq, I'll flash android and reflash ubuntu... just anything to get it working agin
[14:19] <Saviq> MacSlow, yeah, quickest route I'd say
[14:21] <MacSlow> Saviq, no more factory images for "mako"?!
[14:21] <Saviq> MacSlow, it was never "mako"
[14:21] <Saviq> MacSlow, occam
[14:22] <Saviq> MacSlow, mako is device codename, occam is image codename or so
[14:23] <MacSlow> Saviq, so which of those factory images was the one with the broken networking/phone-driver
[14:23] <Saviq> MacSlow, that's old news
[14:23] <MacSlow> Saviq, no longer an issue?!
[14:24] <Saviq> MacSlow, nope, not since we switched to android 4.4.2
[14:24] <MacSlow> I ran into it so :)
[14:24] <MacSlow> ok
[14:26] <tsdgeos> Saviq: what's your opinion on removing the ifdefs for building with old qt 5.0?
[14:27] <Saviq> tsdgeos, let's wait a bit to have a golden image with 5.2
[14:27] <tsdgeos> ok
[14:41] <dednick> Saviq: what are "spurious tags"
[14:41] <Saviq> dednick, we inherited tags from lp:unity back when
[14:41] <dednick> Saviq: um, where would these show up?
[14:42] <Saviq> dednick, 'bzr tags'
[14:42] <Saviq> dednick, you'll see a lot of tags with ? as their revision number
[14:42] <dednick> Saviq: i do indeed...
[14:43] <Saviq> dednick, so yeah, http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh clears them up
[14:58] <mzanetti> Saviq: I'll drop this, ok? https://code.launchpad.net/~unity-team/unity8/split-surfaces
[14:58] <Saviq> mzanetti, yeah, let's see
[14:58] <mzanetti> we're not doing it this way any more anyways I think
[15:00] <Saviq> mterry, there's one more thing that's not good with the ux fixes - when left-swiping to dash, there's a vertical shadow that's dragging behind the app (and behind finger if there's no app at all)
[15:01] <mterry> Saviq, oh really...  Will investigate
[15:01] <Saviq> mterry, check out the packages from silo 001
[15:01] <Saviq> they exhibit that
[15:03] <Saviq> MacSlow, assign yourself to bug #1307489 please
[15:10] <MacSlow> Saviq, done...
[15:11] <MacSlow> Saviq, btw... even with only Android 4.4.2 on the N4 I get this forest of nautilus windows popping up
[15:11] <Saviq> MacSlow, aah fook wait
[15:11] <Saviq> MacSlow, reboot your host...
[15:11] <Saviq> MacSlow, I think that's what fixed it for me...
[15:12] <MacSlow> hm...
[15:12] <MacSlow> ok...
[15:12] <Saviq> MacSlow, sorry for sending you on a wild goose chase..
[15:12] <MacSlow> back in a moment...
[15:18]  * MacSlow got scared by that reboot...
[15:18] <MacSlow> my screen was all messed up... had to do a second reboot to sort that out....
[15:19] <MacSlow> I hope there are no nasty surprises gfx-driver-wise
[15:20] <mterry> Saviq, OK, trailing shadow fixed in greeter-ux-fixes branch
[15:21] <MacSlow> Saviq, those nautilus-windows are still popping up
[15:21] <Saviq> MacSlow, ouch
[15:21] <Saviq> MacSlow, tried a different cable?
[15:21] <MacSlow> Saviq, it's not as bad... but still some
[15:21] <MacSlow> Saviq, can try
[15:23] <Saviq> MacSlow, I've narrowed the bug down to u8's/unity-mir focusing code, so you're off the hook
[15:23] <MacSlow> Saviq, although I'm not expecting that cable (or usb-port) to be an issue as I also used with with a Nexus5 without any problems
[15:24] <Saviq> mzanetti, I'll throw this one at you, then: bug #1307489
[15:24] <MacSlow> Saviq, regarding the tap or the modal-snap-decision/greeter issue?
[15:24] <Saviq> MacSlow, ↑
[15:24] <mzanetti> Saviq: sure you can. I might dodge tho :P
[15:24] <MacSlow> Saviq, ah ok... thanks for the update
[15:24] <Saviq> mzanetti, you can try!
[15:24] <mzanetti> :D
[15:24] <MacSlow> Saviq, mterry: so I guess I can help out with the ap-failure then?
[15:25] <Saviq> MacSlow, the "conflict" between mterry's and your branch (modal snaps) is still to be looked at, yeah
[15:25] <MacSlow> Saviq, that's what I mean
[15:25] <MacSlow> t
[15:25] <mterry> MacSlow, looking at it, yeah
[15:26] <mterry> MacSlow, so I can reproduce for sure
[15:26] <MacSlow> mterry, I've not had your branches available when writing tests... so I might have overlooked something
[15:27] <mterry> MacSlow, OK, I see the problem
[15:27] <mterry> MacSlow, in my branch, swiping the launcher from left unlocks device and hides launcher
[15:27] <mterry> MacSlow, but your branch is expecting launcher to remain open
[15:28] <mterry> (as it does in trunk)
[15:29] <mterry> MacSlow, but you seem to use the shown status of the launcher as a key part of that test
[15:29] <MacSlow> mterry, yes
[15:29] <olli> alecu, Saviq, greyback in U8, do we cache the reading of *.desktop files
[15:29] <mterry> MacSlow, maybe you could test shown status of the greeter instead?
[15:29] <olli> i.e. if I change a file in a running session, will the change be in effect
[15:29] <olli> or do I need to restart u8
[15:30] <olli> sorry, this is for U8/preview 14.04
[15:30] <Saviq> olli, the change will show up in the dash the next time you search, will be stuck in launcher until you restart, though
[15:30] <MacSlow> mterry, well I need to verify (when the greeter is open) that interaction with it/launcher is possible ... nothing is blocking user-input.
[15:31] <MacSlow> mterry, an test interacting with the infographics would do too
[15:31] <mterry> MacSlow, right.  Do the same thing, but instead of testing that the launcher is visible, just test that the greeter becomes hidden
[15:31] <olli> Saviq, more specifically, if I edit a single .desktop file (add exec/-qt5) will u8 pick that up?
[15:31] <Saviq> MacSlow, please rebase on mterry's branch and verify the modal behaviour is correct?
[15:31] <Saviq> olli, when launching you mean? that should work every time, the file is read on-exec, not earlier than that
[15:31] <Saviq> olli, since it's not actually us but upstart-app-launch reading it, btw
[15:32] <MacSlow> mterry, what's your branch again
[15:32] <Saviq> MacSlow, https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042
[15:32] <mterry> MacSlow, instead of self.main_window.get_launcher() do self.main_window.get_greeter() -- will test myself too
[15:34] <olli> Saviq, thx
[15:34] <MacSlow> mterry, Saviq: first I need to figure out what's up with all the usb/adb issues I have all of a sudden...
[15:37] <mterry> MacSlow, well replacing those two lines with the following works for me
[15:37] <mterry>         greeter = self.main_window.get_greeter()
[15:37] <mterry>         self.assertThat(greeter.shown, Eventually(Equals(False)))
[15:39] <mhr3> tsdgeos, something's broken with carousel, if there's more than two categories in a scope scrolling all the way down and then up results in the carousel to be completely empty
[15:39] <mhr3> known?
[15:40] <mhr3> tsdgeos, well.. might be lvwph + carousel
[15:40] <mterry> MacSlow, or maybe what you want is to just not pull the launcher so far
[15:40] <mterry> MacSlow, just pull it out but not enough to trigger an unlock
[15:41] <tsdgeos> mhr3: not known
[15:41] <mhr3> tsdgeos, do you have bunch on your device?
[15:41] <Saviq> mhr3, tsdgeos, assuming your lvwph thing landed?
[15:41] <tsdgeos> mhr3: how do i get more than one carousel?
[15:41] <mhr3> tsdgeos, eh.. bunch of music...
[15:42] <MacSlow> mterry, again... I just need some check to verify that the input-blocking modal-background (behind the snap-decisioins) isn't used when the greeter is shown
[15:42] <mterry> MacSlow, ok, so unlocking is fine
[15:42] <mhr3> tsdgeos, grab the deb from 015
[15:42] <tsdgeos> Saviq: it did land, i sincerely hope that is not causing it
[15:43] <tsdgeos> mhr3: let me check a test i have here
[15:43] <tsdgeos> first
[15:43] <mhr3> Saviq, tsdgeos, my image isn't completely fresh
[15:43] <mhr3> from this morning
[15:43] <Saviq> mhr3, good enough
[15:43] <mhr3> Saviq, as in official 294
[15:44] <tsdgeos> damn
[15:44] <tsdgeos> ASSERT: "QTest::TestLoggers::loggerCount() != 0" in file qtestlog.cpp, line 242
[15:44] <tsdgeos> mzanetti: when doing tryXYZ
[15:44] <tsdgeos> any idea?
[15:44] <mzanetti> tsdgeos: yes
[15:45] <mzanetti> tsdgeos: you can workaround it by addint "when: windowShown" to all TestCases
[15:45] <mzanetti> tsdgeos: or reorder them to make sure the first one in the file has that
[15:45] <Saviq> mhr3, tsdgeos, confirmed, carousel does not get recreated properly when it's culled
[15:45] <mzanetti> tsdgeos: fixing that would require subclassing QAbstractTestLogger from qttest-private which I haven't done yet
[15:46] <Saviq> mhr3, tsdgeos, well - it seems to work the second time...
[15:46] <mhr3> Saviq, yea, it's pretty random
[15:46] <Saviq> indeed
[15:46] <Saviq> mhr3, file a bug please
[15:46] <tsdgeos> wooo
[15:46] <tsdgeos> something broke there yes
[15:46] <mhr3> Saviq, k
[15:47] <tsdgeos> and it's probably the originY thing :/
[15:47] <Saviq> :|
[15:47] <Saviq> :\
[15:47] <Saviq> :/
[15:48] <tsdgeos> i mean, what else can it be?
[15:49] <Saviq> well, yeah, sounds relevant
[15:49] <Saviq> OTOH we never destroyed carousels before, did we
[15:50] <mhr3> tsdgeos, Saviq, https://bugs.launchpad.net/unity8/+bug/1307578
[15:50] <tsdgeos> we shouldn't
[15:50] <tsdgeos> i'll have a look tomorrow first thing
[15:51] <MacSlow> mterry, so I'll go with this http://pastebin.ubuntu.com/7250338 in test_modal_sd_with_greeter()... no more checks for the launcher
[15:51] <mterry> MacSlow, that worked for me, yeah
[15:52] <MacSlow> mterry, the test_modal_sd_without_greeter() I don't need to change I assume
[15:52] <mterry> MacSlow, correct
[15:53] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/whenGSVtest/+merge/215695
[15:54] <mzanetti> tsdgeos: I was still discussing with Saviq if we should go for this or do the efforts of registering the testlogger. tryLauncher suffers from the same, and probably more
[15:54] <mzanetti> Saviq: did you come to any conclusion? ^
[15:54] <MacSlow> mterry, pushed r774 to lp:~macslow/unity8/modal-snap-decisions so we should be all good now
[15:54] <Saviq> mzanetti, I think if we can avoid it for now - let's
[15:54] <mzanetti> ack.
[15:55] <mterry> Saviq, so MacSlow updated his branch for the test and I updated mine for the shadow.  Should be good to go on both
[15:55] <Saviq> mterry, k, rebuilding now and will test again later
[15:58] <Saviq> o/ ttyt
[15:59] <Cimi> tsdgeos, shall I review this? https://code.launchpad.net/~aacid/unity8/DashContentScopeDelegateMapperAndMiscFixes/+merge/215664
[16:00] <tsdgeos> Cimi: if you have time, please
[16:00] <Cimi> ok
[16:03] <tsdgeos> tomorrow more
[16:03]  * tsdgeos waves
[16:07] <kgunn> Saviq: just to make sure ...so lp:~macslow/unity8/modal-snap-decisions & lp:~mterry/unity8/greeter-ux-fixes corrects... bug 1307489
[16:08] <mterry> ?  let me see
[16:09] <kgunn> mterry: is that "?" for me ?...i was piecing together scrollback, i could be totally wrong
[16:10] <mterry> kgunn, was for you.  Looks like a dup of bug 1267624 which has had a branch extent for a long time, but has been stalled
[16:11] <mterry> kgunn, seems test framework won't let us easily test locking the screen by simulating power button presses -- because the test framework holds a powerd lock
[16:11] <kgunn> mterry: ah...thank you, yeah that does look the same
[16:12] <MacSlow> kgunn, mterry's and my branch are not related to 1307489
[16:12] <kgunn> thanks guys
[16:13] <kgunn> MacSlow: do agree that 1267624 is a dup of 1307489  <- Saviq
[16:15] <mterry> kgunn, so point is I'm looking at it, but it's not there yet.  I'll see if I can do a test workaround today
[16:16] <MacSlow> kgunn, not sure
[16:20] <kgunn> mterry: ok, its the "new blocker"...its==1307489
[16:21] <mterry> kgunn, promotion blocker?  oh my
[16:21] <kgunn> yes, don't go to vegas :)
[16:58] <josharenson> mzanetti: regarding https://bugs.launchpad.net/unity8/+bug/1305885 is the networking setup actually a component/plugin for unity8, or is it a separate application? I looked over the code a lot on my flight home, but can't seem to find where it would live.
[17:00] <mzanetti> josharenson: yeah, the actual networking is in the indicators. However, the issue is in the ui I'd say, which should be in qml/Notifications/
[17:43]  * greyback eod
[18:39] <asac> https://launchpad.net/bugs/1307634
[18:40] <asac> rickspencer reported that (wasnt related to shutdown he thinks)
[18:40] <asac> anyone mind checking if that .crash file is any good?
[18:50] <asac> Saviq: kgunn: i know you are runnin on hot fumes already, but could we motivate someoene from your team to take a look at https://launchpad.net/bugs/1307634 ?
[19:58] <Saviq> kgunn, yeah, seem the same
[20:03] <Saviq> mterry, https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/215749/comments/512044
[20:03] <Saviq> wth does apport not collect package versions and such when it's processing a crash....
[20:04] <mterry> Saviq, working on it as we speak
[20:04] <Saviq> mterry, kk
[20:04] <mterry> Saviq, just wanted to get elopio's merge in first
[20:04] <Saviq> asac, I'll look briefly into it, but will probably have to wait until tomorrow for proper investigation
[20:04] <mterry> Saviq, I'm planning to expose a tiny dbus interface for pretending we got a powerd event that we only expose if testability is on.  sound good?
[20:05] <Saviq> mterry, on one hand - yeah maybe - on the other... I think it's a bug in powerd that it doesn't change the power state
[20:05] <Saviq> mterry, especially when it does turn the display off...
[20:06] <mterry> Saviq, true...  I forgot it turned display off.  Does seem like inconsistent internal state
[20:07]  * mterry looks at why powerd does that
[20:15] <Saviq> mterry, inconsistent, and wrong, IMO, too - even if an app requests display to be on, it should be overridden by power key press
[20:23] <asac> Saviq: ack. thanks
[21:21] <mterry> kgunn, poke about bug 1307489.  https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/215749 should fix, but note that it needs two other component branches to work totally.  Maybe start a silo for it?  <- Saviq
[21:21] <mterry> I have to go afk for a bit, but will leave IRC on
[21:22] <Saviq> mterry, I'll be pushing it through tomorrow, thanks!
[21:22] <kgunn> mterry: thanks...
[21:22] <kgunn> Saviq: o/ thanks!
[21:24] <kgunn> mterry: quick one...what other 2 component branches are needed ?
[21:25] <mterry> kgunn, it's in the description
[21:25] <mterry> kgunn,
[21:25] <mterry>   https://code.launchpad.net/~mterry/autopilot/allow-focus/+merge/215735
[21:25] <mterry>   https://code.launchpad.net/~mterry/powerd/consistent-state/+merge/215761
[21:25] <kgunn> mterry: i should've read...thanks man
[21:26] <thomi_> mterry: I commented on that MP. I plan on running the full test suite later today
[21:26] <mterry> kgunn, those two are only needed to make autopilot work right.  If you do manual testing, just the one branch is fine
[21:26] <thomi_> mterry: but right now I'm not sure we can land anything anyway
[21:26] <kgunn> thomi_: its a blocker
[21:26] <kgunn> so its special
[21:27] <thomi_> hmm, so will the unity 8 team handle the autopilot MP landing?
[21:28] <thomi_> kgunn: because if so, then as long as you guys run the AP test plan, I'm happy for that to land
[21:28] <kgunn> thomi_: well, i would believe yes, it would all need to go into the same silo
[21:29] <kgunn> thomi_: link to AP test plan ?
[21:30] <thomi_> one sec
[21:30] <kgunn> thomi_: kinda curious if it matches this...https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
[21:30] <thomi_> kgunn: https://wiki.ubuntu.com/Process/Merges/TestPlan/autopilot
[21:31] <kgunn> thomi_: ok...that doesn't seem too bad...
[21:31] <thomi_> kgunn: hahaaaaaa
[21:31] <thomi_> kgunn: it takes about 4 hours to run, and then about the same to debug the various failures
[21:31] <thomi_> kgunn: what I'm saying is "have fun with that" :)
[21:31]  * kgunn wonders if we've created an anti-release tool
[21:32] <thomi_> kgunn: you're still wondering? :P
[21:32] <thomi_> kgunn: we have a jenkins job that automates 90% of it though
[21:33] <thomi_> kgunn: http://q-jenkins:8080/job/autopilot-release-gatekeeper/
[21:33] <kgunn> thomi_: should that be on the wiki ?
[21:33] <thomi_> kgunn: run that ^ with the silo PPA in the PPA parameter
[21:33] <thomi_> kgunn: probable, let me edit it
[21:33] <kgunn> i was just about to ask.... where instructions are for desktop
[21:33] <kgunn> "Run the autopilot functional and unit tests"
[21:34] <kgunn> thomi_: desktop is the bitch i take it?
[21:34] <kgunn> in terms of time
[21:34] <thomi_> kgunn: nope, device is the PITA
[21:34] <thomi_> kgunn: desktop takes ~ 15 minutes
[21:34] <thomi_> device takes ~ 4 hours
[21:35] <kgunn> thomi_: no way..i run unity8 & browser all the time...it does eat close to an hour...but 4 ?
[21:35] <thomi_> kgunn: you need to run *all* the AP tests
[21:35] <thomi_> not just unity8
[21:35] <kgunn> ah
[21:35] <kgunn> not how i was reading :)
[21:35] <thomi_> because you're chaning AP code that's used by all the functional test suites
[21:36] <thomi_> luckily, the jenkins job does most of that for you
[21:36] <thomi_> you just need to wait for it to run
[21:36] <thomi_> but then you need to debug the various failures
[21:36] <thomi_> and figure out if they're due to an issue introduced in your code, or bad tests in other projects
[21:36] <thomi_> usually you need to re-run a few suites
[21:37] <kgunn> thomi_: since this is going to take soooo much time...should we just go to silo and test it there ?
[21:37] <kgunn> rather than individually for MP...
[21:37] <kgunn> only to approve and then turn around and do it again ?
[21:37] <kgunn> Saviq: fyi on this ^
[21:37] <thomi_> kgunn: yes, that's wht I'd suggest
[21:37] <thomi_> kgunn: wiki is updated BTW
[21:38] <kgunn> Saviq: mterry ...mind if i queue it up and try ?
[22:30] <mhall119> am I missing something, or has the ability to add scopes as a Favorite to the dash not been implemented yet?
[23:13] <mterry> kgunn, go right ahead!


[09:00] <maxb> Argh
[09:00] <maxb> Why is launchpadlib so utterly careless about API compatibility ?!
[09:00] <wgrant> Yes, it's pretty bad :/
[09:00] <wgrant> But it's too late now :/
[09:02] <wgrant> It is a little disappointing that it goes too far with maintaining compatibility of the exposed API, but the launchpadlib API itself is unstable.