[04:30] <Bluefoxicy> you guys should publish something on Google Docs next time you need animal names
[04:30] <Bluefoxicy> holy crap.
[04:30] <Bluefoxicy> there are 42 people looking at my spreadsheet now
[04:30] <Bluefoxicy> Anonymous aardvark
[04:31] <Bluefoxicy> Anonymous ibex
[04:31] <Bluefoxicy> what the hell is a Quagga?
[05:55] <pitti> Good morning
[06:09] <rsalveti> pitti: hey, maybe you know better and is also able to help me :-)
[06:09] <rsalveti> basically, https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/ is failing for amd64
[06:10] <rsalveti> seems like the same failure also happened on the testrun number 55
[06:12] <pitti> rsalveti: hm, that looks like an "honest" failure, or do you think it's an infrastructure problem?
[06:13] <pitti> rsalveti: I can retry the test, it just seems to be a bit flaky?
[06:15] <rsalveti> pitti: yeah, seems so
[06:15] <rsalveti> pitti: that would be nice, thanks
[06:23] <pitti> rsalveti: looks better now
[06:23] <rsalveti> pitti: great, thanks so much
[06:35] <pitti> mvo: argh, one more :( https://launchpadlibrarian.net/179013440/buildlog_ubuntu-utopic-amd64.python-apt_0.9.3.8_FAILEDTOBUILD.txt.gz
[06:36] <pitti> mvo: I gave up enforcing PEP-8 during builds (only run with || true); I run them on release, but found that one runs into eternal pain when doing backports, or with newly appearing pep8 versions
[06:37] <dholbach> good morning
[06:42] <mvo> pitti: thanks, let me have a look
[06:42] <pitti> mvo: I suppose it built in Debian, so that's weird
[06:42] <pitti> oh
[06:42] <pitti>  pep8 | 1.4.6-1.1 | sid     | source, all
[06:43] <pitti>  pep8 | 1.5.6-0ubuntu1  | utopic         | source, all
[06:43] <pitti> we are ahead
[06:44] <mvo> pitti: hrm, hrm, I will fix it, no big deal, but maybe pep8 could start with warning instead of errors for newly added checks
[06:44] <mvo> and only make it a hard error after e.g. 6 month or so
[06:45] <seb128> hum
[06:45] <seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
[06:45] <seb128> "autopkgtest for ubuntu-system-settings-online-accounts 0.3+14.10.20140530.1-0ubuntu1: Regression (Jenkins: public, private) "
[06:45] <seb128> but the jenkins link has green tests?
[06:45] <seb128> is that going to clear itself on next run?
[06:45] <pitti> seb128: yes, I just retried it (flaky autopilot test)
[06:46] <seb128> pitti, thanks
[06:46] <pitti> seb128: see https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/71/ that's what it failed on
[06:46] <seb128> some autopilot issues, I see
[06:47] <pitti> it uses select_single(), probalby needs a wait_select_single() or so
[06:51] <seb128> mardy, ^ is that a known issue?
[07:02] <mardy> seb128: no, a bug report would be welcome :-)
[07:03] <seb128> mardy, k, thanks
[07:03] <seb128> pitti, you didn't open one I guess?
[07:03] <smb> Hm, interesting... not at all related to anything said before. Just had this mild wtf moment when I accidentally (lack of caffeine I guess) tried to "apt-get install ^server" instead of "server^" in Utopic. The command did not respond an equivalent of "what the heck are you thinking" but offered to install apache.
[07:03] <pitti> seb128: no, I didn't
[07:05]  * seb128 opens one
[07:07] <seb128> mardy, pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1336650
[07:09] <mardy> seb128: thanks
[07:09] <seb128> yw!
[07:52] <pitti> xnox: I finally have some time again to work on sysvinit/systemd; sorry to ask again, but I didn't follow this at all: what's left to do for starpar? do you still have the list of tasks which need to be converted to jobs?
[08:34] <LocutusOfBorg1> sil2100, you there?
[08:34] <LocutusOfBorg1> is that "original maintainer" field really needed in lucene++?
[08:35] <LocutusOfBorg1> you have a lintian warning
[08:41] <sil2100> LocutusOfBorg1: hi! I can remove it, no problem - I guessed this wouldn't be a big problem?
[08:44] <mardy> I have a serious issue with bzr (bug 1336682); are there any bzr experts online?
[08:46] <Noskcaj> mardy, #bzr might have better answers
[08:47] <LocutusOfBorg1> sil2100, the package will go through the new queue, so keeping it lintian free avoids many headaches to ftp-masters ;)
[08:47] <sil2100> LocutusOfBorg1: ok, let me remove it in a moment and re-push ;)
[08:47] <LocutusOfBorg1> I already asked to a sponsor to upload it ;)
[08:47] <LocutusOfBorg1> thanks!
[08:48] <sil2100> btw. did you try this package? Since I had to rebase it on a newer version actually
[08:48] <LocutusOfBorg1> (the sponsor will take some hours to upload BTW)
[08:48] <sil2100> Since this was the easiest way to getting rid of waf
[08:48] <LocutusOfBorg1> no, I didn't try it
[08:50] <apachelogger> mvo, pitti, xnox: are there any plans to adopt appstream in the forseeable future? came just up for kubuntu https://lists.ubuntu.com/archives/kubuntu-devel/2014-July/008540.html
[08:53] <sil2100> LocutusOfBorg1: the previous version had waf in its tarball, removing it on get-orig-source was really nasty - and they removed waf in the latest version
[08:53] <xnox> pitti: here are the next steps required to enable startpar https://wiki.ubuntu.com/SystemdMigration
[08:54] <xnox> pitti: i still think we shouldn't have task<->init in standard ubuntu
[08:56] <mvo> apachelogger: we currently have no specific plans for this, there will be apt support to download additional indexes (like app-stream data) though
[08:56] <LocutusOfBorg1> wonderful sil2100  ;)
[08:56] <LocutusOfBorg1> I'm building it right now
[09:03] <apachelogger> mvo: so the idea is to distribute the appstream data via the repo metadata?
[09:10] <mvo> apachelogger: my understand is that this is the goal, yes. the data is gathered at the archive server via some mechanism (package inspection e.g. at build time). then a yaml file is generated and placed next to the Packages file. this is something that I want to support with apt, but there is no plan about integrating the generation of the data into archive.ubuntu.com right now
[09:11] <mvo> apachelogger: I think noone is opposed and we would certainly welcome help, e.g. via support in apt-ftparchive or launchpad
[09:15] <apachelogger> mvo: ok, thanks for the info :)
[09:16] <mvo> yw
[10:37] <LocutusOfBorg1> sil2100, my sponsor asks he can add me as uploader, so he is sure somebody will take care of the package ;)
[10:37] <LocutusOfBorg1> Because I'm already a DM
[10:52] <GunnarHj> Hi infinity
[11:12] <LocutusOfBorg1> hi cjwatson is MoM broken again?
[11:12] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/gccxml
[11:12] <cjwatson> Amazingly, yes.
[11:12] <LocutusOfBorg1> and insighttoolkit4 needs the new version ;)
[11:13] <LocutusOfBorg1> thanks
[11:13] <cjwatson> Although I don't know why you keep referring to Launchpad to support reports of MoM being broken.
[11:14] <cjwatson> I've poked it.
[11:14] <LocutusOfBorg1> where can I see MoM?
[11:14] <cjwatson> merges.ubuntu.com
[11:15] <cjwatson> In this case, it'll still need mitya57 to actually do the merge.
[11:15] <LocutusOfBorg1> I know that page but where is the last run time?
[11:16] <LocutusOfBorg1> just look at the time on the file?
[11:16] <mdeslaur> @pilot in
[11:17] <cjwatson> LocutusOfBorg1: End of https://merges.ubuntu.com/main.html
[11:19] <LocutusOfBorg1> wonderful thanks
[11:26] <ikepanhc> @pilot out
[11:30] <mdeslaur> caribou: have you managed to test your openssl098 package?
[11:31] <caribou> mdeslaur: no, have no clue on how to do it :-/
[11:31] <mdeslaur> caribou: yeah, not an easy thing to do...let me think about it a few minutes
[11:42] <slickymasterWork> dholbach: ping
[11:45] <dholbach> slickymasterWork, pong
[11:45] <slickymasterWork> hi, I pinged you because of this -> https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-docs/trusty-201403200923/+merge/211890
[11:46] <slickymasterWork> I'm Xubuntu Documentation Lead and am wondering why it didn't get merged
[11:46] <slickymasterWork> can you cast any light on it?
[11:47] <dholbach> slickymasterWork, I don't understand
[11:47] <dholbach> the branch you're talking about has this as the content of d/changelog: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-docs/trusty-201403200923/view/head:/debian/changelog
[11:47] <slickymasterWork> what in particular don't you understand dholbach?
[11:47] <dholbach> so that's 14.04.0
[11:48] <dholbach> current in trusty is 14.04.1
[11:48] <dholbach> so what would you like to see in trusty?
[11:48] <slickymasterWork> yes, but it seems it didn't get merged to 14.04.0, did it?
[11:50] <dholbach> slickymasterWork, https://launchpad.net/ubuntu/+source/xubuntu-docs/+publishinghistory
[11:50] <dholbach> slickymasterWork, 14.04.0 landed in trusty 2014-03-21 13:10:11 CET
[11:50] <slickymasterWork> yeah, I see it
[11:51] <slickymasterWork> so, that MP is to forget, right?
[11:52] <infinity> Yeah.  I'll just delete it.
[11:53] <slickymasterWork> ok, thanks for that infinity
[11:53] <slickymasterWork> and thanks for the heads up dholbach
[11:54] <dholbach> anytime
[12:24] <brendand> is there any equivalent of paramiko in python3?
[12:31] <geser> brendand: Python3 support was added to paramiko with release 1.13
[12:35] <brendand> geser, but there's no python3-paramiko package in ubuntu
[12:35] <geser> brendand: not yet, paramiko 1.14.0-2 is stuck in utopic-proposed with DEPWAIT till python3-ecdsa gets promoted to main
[12:37] <brendand> geser, oh interesting, thanks
[12:38] <brendand> now the question is who i need to follow up with to get python3-ecdsa promoted
[12:40] <geser> someone needs to file a MIR for it (didn't happen yet)
[12:45] <geser> brendand: https://wiki.ubuntu.com/MainInclusionProcess if you want to start it
[12:45] <barry> pitti: ping
[12:47] <pitti> hello barry
[12:57] <brendand> should MIRs be filed against ubuntu itself?
[13:01] <LocutusOfBorg1> sil2100, you don't seem to install Lucene.h headers file
[13:03] <arges> slangasek: This one: https://merges.ubuntu.com/r/rsyslog/REPORT
[13:03] <brendand> or against the package to MIR?
[13:03] <geser> brendand: the package itself
[13:05] <geser> brendand: see e.g. bug #1333686 as an example
[13:08] <LocutusOfBorg1> sil2100, also Config.h is missing
[13:11] <brendand> geser, it says something about adding the package to a seed. do i need to do that?
[13:13] <geser> brendand: I don't think so (in this case) as paramiko will keep it in main (once it gets promoted)
[14:17] <GunnarHj> infinity: ping?
[14:20] <infinity> GunnarHj: Pong?
[14:22] <GunnarHj> infinity: Hi Adam. ubuntu-docs is in the trusty queue, and it needs to be built very soon to prepare for an update of trusty translations. Any chance you can approve it?
[14:24] <slangasek> arges: well, that only means that there's a merge /outstanding/, not that it's /pending/ :)
[14:25] <infinity> GunnarHj: Looks good.
[14:26] <sil2100> LocutusOfBorg1: huh, ok, that's odd, let me take a look on what changed then
[14:26] <arges> slangasek: ok, then outstanding is what I meant. So in this case, should I wait for that merge (or work on it), before applying that patch... and is that patch something that makes sense in your case?
[14:26] <GunnarHj> infinity: Yeah, the same thing was successfully built in utopic so it should. ;)
[14:26] <infinity> GunnarHj: Accepted.
[14:27] <slangasek> arges: I don't think it should be tied to the merge at all; the fact that the merge is outstanding doesn't imply any particular timeline on it happening
[14:27] <slangasek> arges: you can talk with xnox about whether he's planning to do the merge, or if you should take it over?
[14:29] <arges> ok. xnox ^^^ are you planning on doing the rsyslog merge; I have a patch for rsyslog and want to know if I should wait/help out/or just patch the current version.
[14:29] <GunnarHj> infinity: Thanks! Now, when I caught an SRU team member... Could you also read the last comment at bug 1308771 and give us your opinion?
[14:30] <xnox> slangasek: arges: let me look.
[14:32] <xnox> arges: i think you should upload the patch. Last proper merge was done by slangasek and that was a jump from 5.8.11-2 to 7.4.4-1ubuntu1. And it's now a jump all the way to 8.2.2-3
[14:33] <xnox> it's defiantly not a pending merge.
[14:33] <infinity> GunnarHj: I have no issues with the two new binaries.  New lang-specific binaries pop up all the time in SRUs of langpacks and firefox, for instance.
[14:34] <infinity> GunnarHj: Does this affect any *other* packages though (like, say, langpacks) that need to adjust deps?
[14:34] <xnox> slangasek: would you be interested in merging rsyslog ? =) (i can try asking, can't I?! =)))))) )
[14:34] <arges> xnox: whats the difficulty wiht the merge? looking at the report didn't seem too bad
[14:34] <slangasek> xnox: heh, not interested, no :)
[14:34] <xnox> slangasek: ack.
[14:35] <GunnarHj> infinity: No, it's not related to langpacks at all. It's language specific language aids for libreoffice. But thank, that's what we wanted to know.
[14:35] <infinity> GunnarHj: In fact, how do these hyphen-* packages get installed?  I have hyphen-en-us installed, but nothing seems to depend on it.
[14:35] <cjwatson> arges: last big merge broke the world in some interesting ways (see 7.4.4-1ubuntu2), so just be careful
[14:35] <arges> cjwatson: gotcha
[14:36] <arges> so probably be better to not do it at this point in the U cycle
[14:36] <xnox> arges: newing or splitting new deps; figuring out splits of -doc packages; i think systemd support stayed the same but need re-verification; plus testing to not break the world after last time...
[14:36] <GunnarHj> infinity: They are simply added to a location where libreoffice will find them.
[14:36]  * xnox meant M.I.R.ing not newing
[14:37] <infinity> GunnarHj: Err, what?  I mean, how do the packages end up installed.
[14:37] <arges> xnox: ok. I'll just patch the version in U : ) thanks
[14:38] <GunnarHj> infinity: They are pulled by pkg_depends in language-selector if that's what you mean.
[14:38] <infinity> GunnarHj: Okay, so does language-selector need updating for this?
[14:38] <GunnarHj> infinity: No.
[14:39] <infinity> GunnarHj: Alright, that's what I was asking.
[14:39] <infinity> GunnarHj: The new binaries aren't an issue at all, IMO.
[14:39] <GunnarHj> infinity: Excellent, thanks!
[14:39] <LocutusOfBorg1> sil2100, the first question was: can I comaintain the package? my sponsor would really like to see me as uploader
[14:41] <bdmurray> pitti: I've updated bug 1336565
[14:41] <LocutusOfBorg1> sil2100, ---> https://github.com/luceneplusplus/LucenePlusPlus/commit/994f03cf736229044a168835ae7387696041658f
[14:42] <pitti> bdmurray: ah ok, so it basically matters in that "rebuild broken/absent SAS" case
[14:42] <pitti> bdmurray: so I believe that fix ought to suffice?
[14:47] <bdmurray> pitti: why is part of uname included at all? wouldn't that create separate buckets for x86_64 and x86?
[14:47] <pitti> bdmurray: yes, because addresses are necessarily different between architectures
[14:47] <pitti> bdmurray: we don't want to accidentally identify an arm with an x86 signature (unlikely of course, but possible)
[14:48] <pitti> bdmurray: but even without the arch you'll have separate buckets per arch
[14:49] <pitti> in many cases even several buckets per error on one arch, as there's apparently some variability in them
[14:49] <pitti> so we map many SAS to one error
[14:49] <bdmurray> pitti: okay, understood. given this issue though it may be possible that we error tracker buckets that have a different SAS than the bugs in Launchpad, right?
[14:50] <pitti> bdmurray: yes, that's possible
[14:50] <pitti> bdmurray: but anyway, that fix to read it from the report's Uname field (if present) should help with that, right? I'll upload that ASAP
[14:51] <pitti> as that's (hopefully) always present from the original device
[14:51] <bdmurray> pitti: thinking about it more the error tracker was rejecting reports without a SAS so the count should be very small / not worth cleaning up
[14:51] <pitti> bdmurray: oh, right
[14:52] <bdmurray> pitti: so, yes switching to Uname sounds good to me
[14:52] <sil2100> LocutusOfBorg1: sorry, had a meeting - anyway, I'm fine with co-maintaining it with you I guess ;) Let me incorporate this patch as a quilt patch then
[14:59] <bdmurray> pitti: by the way did you check to see if your gdb change is still in the debian version of gdb?
[15:01] <sil2100> LocutusOfBorg1: doing a test build of it now, will publish afterwards
[15:03] <pitti> bdmurray: no, I didn't check yet
[15:15] <LocutusOfBorg1> sil2100, I'm also testing it
[15:15] <LocutusOfBorg1> and building
[15:18] <mdeslaur> @pilot out
[15:32] <sil2100> LocutusOfBorg1: looks good to me
[15:32] <infinity> pitti: Err, skimming backscroll, but uname shouldn't relate to backtraces at all.
[15:32] <sil2100> -rw-r--r-- root/root      1845 2014-07-02 17:01 ./usr/include/lucene++/Config.h
[15:32] <sil2100> -rw-r--r-- root/root      9534 2014-04-19 20:26 ./usr/include/lucene++/Lucene.h
[15:32] <sil2100> LocutusOfBorg1: ok, I'm pushing the source package now :)
[15:33] <pitti> infinity: not symbolic stack traces, but to the address signatures; they are already highly arch specific; this just makes it slightly easier to see which arch they are coming from
[15:33] <pitti> (and avoids false identifications)
[15:33] <infinity> pitti: Confusing dpkg/userspace arch and kernel arch is entirely wrong.
[15:34] <pitti> infinity: ah, good point; so they should probably be preceded with the affected package arch
[15:34] <infinity> pitti: If I have i386 packages crashing on an x86_64 kernel, they shouldn't be bucketed as x86_64 crashes.
[15:34] <sil2100> LocutusOfBorg1: uploaded a new version with the patch - btw. should I also add you somewhere in case you want to co-maintain?
[15:35] <infinity> pitti: I think the kernel arch is *interesting* supplementary data, but shouldn't affect the signature, if that makes sense?
[15:35] <pitti> infinity: yes, it does
[15:36] <infinity> pitti: ie: When I drill down, it'd be useful to note that a certain crash only happens on armhf *if* the kernel is actually aarch64, but generally, that won't be true, so shouldn't be involved in bucketing.
[15:36] <LocutusOfBorg1> sil2100, yes please
[15:36] <LocutusOfBorg1> Uploaders: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>
[15:37] <pitti> infinity: the bucketing only happens on the symbolic (retraced) stack traces AFAIK; the SAS is mostly just for client-side dupe detection, so it's not vitally important; but it's still cleaner that way, I'll change it
[15:38] <LocutusOfBorg1> also the debian/control is wrong
[15:38] <LocutusOfBorg1> there is a comma in the last dependency
[15:38] <LocutusOfBorg1> and moreover if you build in a clean environment you get a missing subversion failure
[15:38] <pitti> trailing commas are fine
[15:39] <LocutusOfBorg1> trailing commas are "ugly" :p ;)
[15:39] <pitti> they help to reduce diff noise when adding new build/bin deps
[15:40] <sil2100> LocutusOfBorg1: they are? Oh, we're actually adding them on purpose ;) It makes the diffs smaller when you add new dependencies
[15:40] <pitti> but matter of taste, I gues
[15:40] <pitti> s
[15:40] <LocutusOfBorg1> true ;)
[15:40] <LocutusOfBorg1> yes, but you still have the subversion problem
[15:40] <LocutusOfBorg1> I'm looking at it
[15:41] <sil2100> LocutusOfBorg1: ok, let me build it in my chroot then to see the same
[15:41] <LocutusOfBorg1> ./CMakeLists.txt:find_package(Subversion REQUIRED)
[15:41] <LocutusOfBorg1> what the hell?
[15:41] <sil2100> uh, now that's something I didn't expect - why does it need it suddenly?
[15:42] <LocutusOfBorg1> looking at it right now, btw I sent two pull requests upstream with your changes (the two patches)
[15:43] <LocutusOfBorg1> oh yes, CMakeExternal.txt
[15:49] <LocutusOfBorg1> mmm we can add libgtest-dev as b-d
[16:22] <bdmurray> stgraber: I'm looking at https://errors.ubuntu.com/problem/62db45e470d69292cef07c5bed380a0ddc24e13d which you'd emailed me about as it was identified as a regression.  Looking at a few of the instances in Dependencies they seem to have the new version of cgmanager.
[16:26] <stgraber> bdmurray: hmm, yeah, I see that. That doesn't make any sense though...
[16:29] <stgraber> bdmurray: are the dependencies captured at time of crash or time of report?
[16:29] <bdmurray> stgraber: probably the latter, let me double check
[16:31] <bdmurray> stgraber: at time of report
[16:31] <stgraber> bdmurray: ok, that could explain it then. Because the only way we could get that crash with the right cgmanager being installed is if the cgmanager SRU was wrong and the symbol wasn't present, but if that was the case, it'd be failing for absolutely everyone...
[16:32] <stgraber> ok, so it seems likely that those people upgraded the rest of their system between the time lxc-ls stacktraced and the time they sent the report to errors, meaning that those systems are now fine
[16:33] <bdmurray> so then we'd expect to see a specific SystemIdentifier one time only?
[16:34] <stgraber> assuming people upgrade the rest of their system when they hit the crash the first time around, yes
[16:38] <sil2100> LocutusOfBorg1: doing a test build ;)
[16:39] <sil2100> Thanks for the pointers! I've got so many things on my list today so it's taking a bit longer, sorry for that
[16:44] <bdmurray> stgraber: okay, overridden
[17:50] <dobey> seb128, mvo: hi, i'm wondering what i'm missing in my lxc for clicks to be installable there. i'm getting this error when i try to pkcon install-local a package:
[17:50] <dobey> Fatal error: MIME type 'application/x-click' not supported /home/dobey/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.matiasb-testing.qr-code_0.3.1_all.click
[18:12] <michagogo> What does "posting moderated" mean on https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel?
[18:15] <sarnold> michagogo: emails to the list are quite often held for a human to review the post and make sure it isn't spam
[18:15] <michagogo> Got it.
[18:16] <michagogo> How long do messages generally take to get approved?
[18:16] <sarnold> michagogo: it may be that ubuntu members are unmoderated or something, but all mine are moderated and normally it just takes a few hours before they go through :)
[18:17] <milina> http://adf.ly/q1fx1
[18:25] <mvo> dobey: do you have the packagekit-plugin-click installed?
[18:27] <dobey> mvo: possibly not. i have aptcc installed
[18:28] <dobey> that helped
[18:28] <dobey> mvo: now i get Fatal error: Failed to obtain authentication.
[18:30] <mvo> dobey: hm, thats odd, is there a policykit agent installed? just a bit of a stab in the dark (if that expression makes sense)
[18:30] <mvo> dobey: clicks should be installable without though - and packagekit depends on policykit so that should be available
[18:31]  * mvo scratches head
[18:31] <dobey> mvo: i have policykit-1-gnome installed
[18:33] <dobey> hmm
[18:33] <dobey> installed policykit-desktop-privileges (since it's installed on the phone), but didn't help
[18:33] <mvo> dobey: I haven't seen this error yet, I found /usr/lib/packagekit/packagekit -v helpful
[18:34] <mvo> dobey: I assume you have "unity8-desktop-session-mir" installed also?
[18:34] <dobey> i don't
[18:35] <dobey> is that required?
[18:35] <dobey> hrmm, didn't help to install it either though
[18:36] <mvo> dobey: hm, so no :/
[18:36] <mvo> dobey: anything useful from packagekitd -v ?
[18:41] <dobey> nothing obvious
[18:41] <dobey> 14:39:57	PackageKit          trying to open database '/var/lib/PackageKit/transactions.db'
[18:41] <dobey> maybe that
[18:45] <mvo> dobey: hm, so this is a lxc/utopic? I can try to create one and play around with that tomorrow morning (in ~10h or so) if the problem persists
[18:48] <dobey> mvo: yes a utopic lxc
[18:49] <mvo> dobey: ok, thanks. so please send me a short mail if the issue is found, otherwise I will look for it in my morning
[18:50] <dobey> ok
[18:51]  * mvo calls it a day
[19:43] <dobey> xnox: seen http://pastebin.ubuntu.com/7738360/ before when cross-compiling in sbuild?
[20:48] <cjwatson> dobey: Is it possible you're missing packagekit-plugin-click?
[20:50] <dobey> cjwatson: i've since installed it
[20:51] <cjwatson> dobey: Also see pk-plugin/README in the click source
[20:52] <cjwatson> dobey: You might need to tweak the .pkla if policykit doesn't have enough of a connection to your desktop to be able to prompt you, which it might not
[20:52] <manjo> cjwatson, is there bzr branch debian-installer for utopic ?
[20:53] <dobey> cjwatson: all it should need is a DISPLAY right? though i'm not sure what it would prompt me for. i don't get a prompt on the phone
[20:53] <cjwatson> manjo: lp:~ubuntu-core-dev/debian-installer/ubuntu
[20:53] <manjo> ah
[20:53] <manjo> thanks a ton!
[20:53] <cjwatson> dobey: You don't get a prompt on the phone because of that .pkla
[20:53] <cjwatson> I expect we shouldn't prompt, but we'll need to put the glue in place for that.  In the meantime you can hack it with a local pkla as per that readme
[20:54] <cjwatson> adjusting the username
[20:54] <dobey> cjwatson: is that some special tweak we do during the image build that isn't a part of the standard packages?
[20:54] <dobey> oh it has the username in it? ok
[20:55] <brendand> i'm trying to get a mir in and i've been asked to subscribe 'the team in Ubuntu which will look after the package' - how can i establish which team that should be?
[20:55] <cjwatson> Yup, it's a phablet-specific hack in click for now, ugly
[20:55] <cjwatson> Not proud
[20:57] <dobey> ah, got past that error now
[20:57] <dobey> thanks cjwatson
[20:58] <dobey> but now i just get the apparmor hook failing, because apparmor
[21:00] <jjohansen> dobey: what kind of lxc container are you running it in?
[21:01] <dobey> jjohansen: utopic
[21:01] <dobey> host is trusty
[21:01] <jjohansen> dobey: okay, and its a bog standard lxc container?
[21:03] <dobey> jjohansen: afaik yes. did a plain lxc-create to build it
[21:03] <dobey> jjohansen: added bind mount for /tmp/.X11-unix so i could display things in X
[21:03] <dobey> jjohansen: is nested apparmor supposed to work now?
[21:04] <jjohansen> dobey: okay, so its using external confinement which is causing the problem. Nested apparmor does NOT work atm. It is being worked on but not ready yet
[21:04] <dobey> jjohansen: right. that's what i thought
[21:04] <jjohansen> dobey: you could remove or disable the lxc profiles
[21:05] <dobey> jjohansen: anyway to just disable it inside the container?
[21:07] <jjohansen> dobey: uhmm no, not yet. there are tests in the initscripts to not load profiles inside lxc, but other parts aren't that smart.
[21:07] <jjohansen> dobey: it is possible to provide a custom kernel, but even that requires something setting up the apparmor policy namespace to tell the kernel it isn't there
[21:08] <jjohansen> dobey: another option is to disable the lxc apparmor profile, and setup an apparmor policy namespace for the container. And then apparmor will work within the container
[21:09] <dobey> i just put a sys.exit(0) in the script that was failing for now
[21:09] <dobey> it let the package install at least
[22:58] <Noskcaj> Is there any reason elementary hasn't been moved to -release?