[05:00] <Unit193> pitti: guten Morgen
[05:01] <pitti> Good morning
[05:03] <pitti> hey Unit193
[05:05] <pitti> bdmurray: yeah, so far we never talked about click support in apport; a lot of concepts are quite different (e. g. they don't necessarily have an LP project, don't have source packages, can't be retraced), so we need to invent some new fields and teach the error tracker about it (Click: and SystemImageVersion:, and it wouldn't have Package:/SourcePackage:/Dependencies?)
[06:28] <zbenjamin> jdstrand: but wouldn't the debug policy allow me to read the ~/.local/share directory as well?
[06:51] <mardy> Saviq: hi! Thanks for the report, I'll remove the --desktop_file_hint
[06:52] <Saviq> mardy, cool, any idea why it would restart the ui?
[06:52] <mardy> Saviq: but we don't respawn it... Did you start the U1 account creation from the System Settings, or from where?
[06:52] <Saviq> mardy, it got spawned by the pay ui
[06:52] <Saviq> as we now can do prompts in prompts
[06:53] <mardy> Saviq: then most likely the pay UI has a loop like "while (!accounts) { createAccount() }"
[06:53] <Saviq> mardy, well, it restarted outside of the trusted session, though
[06:53] <Saviq> mardy, which is why it ended up a separate app
[06:54] <Saviq> mardy, I'll report bugs with steps to repro
[06:55] <mardy> Saviq: that is weird, I'll investigate (though I suspect a bug with the "trust session in trust session" thing, maybe the second session cannot be restarted)
[06:55] <mardy> Saviq: excellent, thanks
[06:55] <mardy> Saviq: speaking of bugs, I got this one yesterday, which I don't believe is really mine: bug 1365097
[06:56] <mardy> Saviq: do you have any idea if that could be unity8 or qtmir or...?
[06:59] <Saviq> mardy, right, when that happens I have a lingering /usr/bin/online-accounts-ui
[06:59] <Saviq> mardy, same happened to me when I cancelled the pay ui before it was able to trigger the accounts ui
[07:00] <dholbach> good morning
[07:00] <Saviq> mardy, I can't get another prompt until I restart the service, though
[07:02] <mardy> Saviq: I'll see if I get some notification from mir about the trust session state, maybe I can cancel it
[07:02] <Saviq> mardy, but it is also true that we shouldn't be closing the prompt on unfocus, which we do
[07:02] <Saviq> mardy, you can reproduce the same situation by just swiping from the right to switch to the dash
[07:07] <Saviq> mardy, and yeah, I can't reproduce the respawning with settings app, so must be pay doing something indeed
[07:07] <Saviq> but why would it start outside of a trusted sesssion...
[07:10] <mardy> Saviq: I'll investigate, it may be that we don't clear our session properly
[07:12] <Saviq> mardy, yup, I'll go through and file some bugs with steps then
[07:16] <mardy> Saviq: so, when we get unfocused, we do get a signal that the prompt session has been stopped; I'll make sure that we clean it up, then
[07:16] <Saviq> mardy, coolz
[07:26] <Saviq> mardy, yeah, confirmed, the respawned one is actually a second session, filing a bug against pay-ui
[07:34] <mardy> Saviq: cool, thanks
[07:40] <Saviq> mardy, bug #1365346
[07:48] <Saviq> tvoss, can we get your opinion please https://bugs.launchpad.net/qtmir/+bug/1355173/comments/15
[08:14] <penghuan> cjwatson, hi, can you help to do the merges  of   https://code.launchpad.net/~laney/ubuntu-archive-publishing/kylin/+merge/232828   and   https://code.launchpad.net/~laney/ubuntu-cdimage/kylin/+merge/232829
[08:59] <He4dShOt> hi
[09:00] <He4dShOt> i upgraded to utopic and now X won't start automatically
[09:00] <He4dShOt> can't understand why
[09:07] <He4dShOt> any help?
[09:19] <didrocks> hey doko_, I have an issue with our system python version and coverage report on subprocess. If I used the same coverage library, but within a virtualenv python3, everything works fine, not if I use our system python3 though (the subprocess isn't covered)
[09:20] <didrocks> doko_: is that known, want a more detailed bug report?
[09:37] <zbenjamin> jdstrand:  i tried you suggestion but i can read the dir when the debug policy is enabled :/
[09:39] <didrocks> doko_: barry: after more investigation, it's init_cov_core.pth which is missing in the system path dir. That's why subprocess coverage report isn't enabled at all. Any reason why it's not shipped?
[09:39] <didrocks> doko_: barry: it seems to be controlled by an env var to enable/disable coverage, so shouldn't impact (apart from the extra .pth file import) perfs
[09:51] <LocutusOfBorg1> thanks dholbach
[09:51] <LocutusOfBorg1> :)
[10:46] <LocutusOfBorg1> He4dShOt, are you sure using utopic is the best thing to do at this moment? :)
[10:49] <cjwatson> penghuan: thanks, I just got back from conference/vacation, can you give me a while to get through my mail pile?
[10:49] <cjwatson> penghuan: those MPs are in there ...
[11:07] <penghuan> ok, cjwatson, if the code does not have any problem, can you help merge it, then we can go the next step for ubuntukylin seeds
[11:09] <cjwatson> penghuan: I'm not sure you read what I wrote :)
[11:14] <penghuan> cjwatson, you mean you are doing it? sorry for my bad English:)
[11:15] <cjwatson> penghuan: I mean please give me a while to get through my mail archive, which contains the merge proposals you are asking about
[11:15] <penghuan> cjwatson, ok, thanks!
[11:22] <coderus> hello! o/
[11:23] <coderus> can i get help about ubuntu sdk for ubuntu touch here?
[11:35] <ogra_> coderus, try #ubuntu-app-devel
[11:35] <coderus> ogra_: yep, sorry, already asked here :)
[12:41] <doko> jamespage, mysql-5.5 blocking gcc-4.9 again ...
[12:43] <jamespage> doko, ok - I'd not realized that  main.mysqlhotcopy_myisam was also failing
[12:43] <jamespage> let me see
[13:05] <doko> didrocks, so, the python-coverage is a non-issue?
[13:06] <didrocks> doko: the issue is that nose-cov doesn't ship init_cov_core.pth. I think barry packaged it.
[13:06] <didrocks> python-coverage by itself doesn't support subprocess coverage tracking
[13:06] <doko> ahh, ok. waiting for him
[13:24] <barry> doko, didrocks hi
[13:24] <didrocks> hey barry!
[13:24] <barry> what's up?
[13:25] <didrocks> barry: so, I was wondering why my subprocesses (once outside my virtualenv) were not reported in the coverage report
[13:25] <didrocks> I'm using nose-cov
[13:26] <didrocks> I see that this is because init_cov_core.pth isn't shipped in the python3 system path
[13:26] <didrocks> would you think of any bad reason to avoid doing that?
[13:26] <didrocks> (it seems code coverage activation is controlled by an env variable, so apart from python opening this file, the penalty for people installing it doesn't seem high)
[13:27] <barry> didrocks: i don't remember this case in particular, but very often .pth files do evil things
[13:28] <barry> didrocks: like, they get "auto" imported when python initially scans for sys.path.  they show up in sys.modules before any explicit import.  yuck.
[13:28] <didrocks> barry: however, without this, subprocesses coverage is broken
[13:29] <didrocks> barry: import os; os.environ.get("COV_CORE_SOURCE") and __import__('cov_core_init').init()
[13:29] <didrocks> so yeah, it will import os anyway
[13:29] <barry> didrocks: i initially packaged nose2-cov and cov-core.  i guess nose coverage also uses cov-core?  there's a new upstream i haven't gotten to yet for cov-core.  i got subproc coverage working properly in systemimage (which uses nose2) without cov-core because cov-core was causing too many problems.
[13:30] <didrocks> barry: I did package nose-cov, and yes, it's using cov-core.
[13:30] <didrocks> which kind of problems?
[13:31] <barry> didrocks: the question is whether you have control over the subprocs.  if so, you *can* instrument them to invoke coverage when you want
[13:31] <jdstrand> zbenjamin: can you paste the output of 'apparmor-parser -p /var/lib/apparmor/profiles/click_<your app policy with debug policy group>
[13:31] <jdstrand> '
[13:31] <didrocks> barry: I don't have control over it in some tests that are using docker containers
[13:32] <barry> didrocks: i can point to and explain the systemimage code that makes this work in its vcs of course
[13:32] <barry> didrocks: hmm.
[13:32] <jdstrand> zbenjamin: I see the problem: /**/ r,
[13:32] <barry> didrocks: that code snippet is what's in the .pth file?
[13:32] <didrocks> barry: yep
[13:32] <jdstrand> zbenjamin: but please paste that and I can come up with a better path
[13:32] <zbenjamin> jdstrand: ok :)
[13:33] <didrocks> barry: not sure why it's not in the source package though, I got it with pip install in my virtualenv
[13:33] <barry> didrocks: the problem isn't os, since you'll effectively always get that anyway, it's that if you start up python, you'll always get the .pth file "imported" and thus sys.modules will always have cov_core_init
[13:33] <jdstrand> zbenjamin: can you also paste the checking code?
[13:33] <didrocks> barry: well, only if you export the env var
[13:34] <barry> didrocks: hmm
[13:34] <barry> didrocks: let me look at the new upstream for cov-core today
[13:35] <didrocks> sure, thanks!
[13:35] <barry> didrocks: in general i'm not a fan of cov-core and nose2-cov (i greatly prefer nose2 over nose but whatevs :)
[13:36] <zbenjamin> jdstrand: like this? http://pastebin.ubuntu.com/8233495/
[13:36] <barry> didrocks: i'll let you know how it goes ;)
[13:36] <didrocks> barry: thanks a lot :)
[13:36] <zbenjamin> jdstrand: the python code is basically doing this:
[13:36] <zbenjamin>     test_dir = os.path.expanduser('~')+"/.local/share"
[13:36] <zbenjamin>     os.listdir(test_dir)
[13:37] <didrocks> barry: yeah, I investigated some time already on it, so I won't switch right away :)
[13:37] <didrocks> (as other people I guess)
[13:37] <jdstrand> zbenjamin: yes, thanks, give me a sec
[13:37] <barry> didrocks: i offer to help with a nose->nose2 :)  nose2 is the futchah!
[13:37] <barry> (plus it has an awesome plugin architecture)
[13:38] <didrocks> barry: if that can work as well on trusty without backporting the world, I'm happy for this (but would prefer first to go the easy road, then, accepting your offer ;))
[13:39] <didrocks> barry: the .pth is generated in setup.py
[13:39] <barry> didrocks: i'm pretty sure it does, given systemimage has used it forever :)
[13:39] <barry> didrocks: gotcha.  i think i'll add a dep-8 test for this
[13:40] <didrocks> barry: excellent! then, we'll discuss about nose2 :) (I need to backport your change to my trusty ppa first)
[13:40] <barry> didrocks: it might be a little while.  thursdays are meeting days ;)
[13:40] <jdstrand> zbenjamin: ok, can you add this before the last '}' in your profile: audit deny @{HOME}/.local/share/ r,
[13:40] <didrocks> barry: no worry, if you think you can't do it before EOW, just tell me, I'll do this then
[13:41] <jdstrand> zbenjamin: then do: sudo apparmor_parser -r /var/lib/apparmor/profiles/click_<your profile>
[13:41] <barry> didrocks: np.  definitely should get to at least look + new upstream today
[13:41] <didrocks> sweet!
[13:41] <jdstrand> zbenjamin: then try again? I think I like this check so I can adjust the debug policy group for it
[13:46] <zbenjamin> jdstrand: PermissionError: [Errno 13] Permission denied: '/home/phablet/.local/share'
[13:46] <zbenjamin> jdstrand: looking good
[13:47] <jdstrand> ok good. then I'll adjust the debug policy group
[13:47] <jdstrand> zbenjamin: I'm going to use 'audit deny' so we still have the denial logged, to give a cue on the check. I could drop 'audit'. do you have a preference as the main consumer of this policy group?
[13:47] <pitti> stgraber: do you have an opinion on bug 1361964?
[13:48] <zbenjamin> jdstrand: either way its fine for me
[13:48] <jdstrand> zbenjamin: ok, it will be in the next upload. likely later this week
[13:48] <zbenjamin> jdstrand: awesome thanks :)
[13:49] <zbenjamin> jdstrand: i'll ping you when i don't need access to /tmp anymore
[13:49] <lool> slangasek: multiarch question: install crossbuild-essential-armhf on my main system seems to want to remove multiarch-support; is that bad? this is because:  libgcc1:armhf : PreDepends: multiarch-support:armhf but it is not going to be installed
[13:50] <lool> slangasek: ah well, transitional package; I guess i need not worry
[13:52] <cjwatson> lool: sometimes happens if you have skew between arches, which shouldn't happen in the release pocket.  you don't have -proposed enabled by any chance?
[13:52] <stgraber> pitti: oh, sorry, yes, I said I'd review that one, doing so now
[13:52] <pitti> stgraber: yeah, pinged you as you said you wanted to; if you want to delegate to someone else (ScottK?) that's fine too of cousre
[13:53] <ScottK> pitti: Did upstream release the Qt5 version?
[13:54] <stgraber> pitti: edubuntu is the only flavour seeding it so I guess it sort of makes sense for me to review it, ScottK doesn't seem to be against it for utopic, just concerned about the backports and I believe you've addressed that (backport the last Qt4 version and then there won't be anything we can backport anyway)
[13:54] <pitti> ScottK: yes, 2.0.0 is that (http://calibre-ebook.com/whats-new)
[13:55] <pitti> stgraber, ScottK: If we want to go with the qt5 version, I'd like to get further 2.x reelases into utopic, as I expect a number of bug fixes for the new Qt5 UI
[13:55] <pitti> ah, 2.1 is out already, like clockwork
[13:55] <ScottK> Right, up to stgraber.  If it weren't seeded, I'd say go for it.
[13:56] <pitti> stgraber: would that introduce qt5 into edubuntu, or does edubuntu already have it and thus rather want to get off qt4?
[13:56] <pitti> to clarify, I won't be grumpy or anything if we postpone that to 15.04, just asking (as people generally prod me for packaging the latest and greatest)
[13:56] <lool> cjwatson: I do not
[13:56] <stgraber> pitti: there you go
[13:56] <lool> cjwatson: this is on utopic
[13:58] <lool> cjwatson: perhaps I'm doing it wrong too; basically it's an apt-get install crossbuild-essential-armhf on an utopic system with a moderate amount of tools installed; I've added "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ utopic main restricted universe" to sources.list and that's it
[14:03] <pitti> stgraber: ack, thanks; I'll keep up with 2.x versions, yes
[14:06] <lool> cjwatson, slangasek: Right, it was me missing add-architecture armhf; sorry for the trivia; works now, not removing multiarch-support
[14:11] <bdmurray> pitti: while all of that is true, we still get crash reports about click packages in the error tracker and at least having Package / ClickPackage information would help us better bucket these crashes.
[14:12] <pitti> bdmurray: hm, that's curious
[14:12] <pitti> bdmurray: oooh -- that's becuase we don't check any UnreportableReason for whoopsie
[14:12] <pitti> as the UI would reject those as they aren't from a package
[14:12] <pitti> now I at least understand why we are getting them in the first place
[14:24] <pitti> jodh, seb128, tedg: so it seems cjohnston has big trouble after a T->U dist-upgrade: almost none of his session upstart jobs run
[14:24] <pitti> cjohnston: mind pastbin'ing "initctl --list"?
[14:24] <pitti> any idea how to debug that?
[14:25] <pitti> so there's just a bare minimum desktop without much real meat
[14:25] <seb128> pitti, they are pending/waiting?
[14:25] <pitti> cjohnston: ^
[14:25] <pitti> (just the messenger, haven't seen much data myself)
[14:26] <cjohnston> http://paste.ubuntu.com/8233880/
[14:26] <cjohnston> seb128: ^
[14:26] <pitti> that's system upstart
[14:26] <pitti> "initctl --user list" then?
[14:26] <jodh> pitti: cjohnston: try changing STARTUP="upstart --user --debug 1>&2" in /etc/X11/Xsession.d/99upstart, attempt to login then (via a console) look at ~/.xsession-errors.
[14:26] <pitti> odd, for me it defaults to user when I run it as user
[14:27] <jodh> pitti, cjohnston: what does "almost none" mean - does the session actually start and run?
[14:27] <cjohnston> pitti: when adding --user I get: UPSTART_SESSION isn't set in the environment. Unable to locate upstart isntance
[14:27] <pitti> aah
[14:28] <pitti> "ps ux|grep upstart" -> I get upstart --user, and some upstart-*-bridge
[14:28] <cjohnston> jodh: when I login, I see unity, I see the top bar... the time/date, NM icon, sound icon, etc are missting... None of the icons in the unity bar work, can't open dash, ctrl+alt+t doesn't work
[14:28] <pitti> cjohnston: is upstart --user running for you? I. e. issue with passing the env, or starting upstart itself
[14:28] <jodh> cjohnston: try 'initctl list-sessions' to see if there is a session you can join (http://upstart.ubuntu.com/cookbook/#joining-a-session)
[14:29] <cjohnston> pitti: I do see upstart --user in the ps ux
[14:29] <jodh> cjohnston: please raise a bug via 'ubuntu-bug upstart' (even via the console) as that will suck up useful meta-data for the bug.
[14:34] <jamespage> doko, the start of that test failing seems to correspond to the switch to 5.20 of perl
[14:34] <cjohnston> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1365535
[14:40] <cjohnston> jodh: does that give you the info you need?
[14:40] <pitti> FWIW, I can't see this either -- is it super-private?
[14:41] <cjohnston> pitti: try again
[14:41] <pitti> ah, works now
[14:43] <jamespage> doko, yes - both in debian and ubuntu - at least that give me a clue
[14:47] <bulletxt|2> hi, is there someone here willing to put in ppa an update version of cifs-utils 6.0 for Ubuntu 12.04 ? I really need it........ thanks so much
[14:51] <cjohnston> jodh: someone else in #ubuntu+1 is reporting that with an intel gpu they don't have these issues
[14:53] <coreycb> mterry, hi, wanted to ping you on this bug as it's been idle for a bit https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4-apps/+bug/1349868
[14:56] <mterry> coreycb, ah yes so it has, sorry
[14:56] <mterry> coreycb, will try to look at today
[14:56] <coreycb> mterry, np thanks!
[14:57] <cjohnston> jodh: http://paste.ubuntu.com/8234110/
[14:59] <ahasenack> hi, I have this in debian/rules:     dh $@ --with python2 --no-guessing-deps
[14:59] <ahasenack> I want to pass --no-guessing-deps to dh_python2
[14:59] <ahasenack> but here is how it ends up being called:
[14:59] <ahasenack>  dh_python2 -O--no-guessing-deps
[14:59] <ahasenack> how do I make it right?
[15:12] <cjohnston> jodh: fwiw there is also https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1365039 and https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1365336
[15:35] <ahasenack> that -O is added by debhelper it seems, but incorrectly perhaps? The debhelper manpage talks about -O=option|bundle
[15:35] <ahasenack> here it's just breaking things
[15:35] <ahasenack> D: dh_python2:591: argv: ['/usr/share/python/dh_python2', '-O--no-guessing-deps']
[15:42] <cjohnston> jodh: not sure if it's helpful but I see: nouveau E[ PBUS] MMIO read of 0x00000000 FAULT AT 0x002140 [ !ENGINE ] quite a number of times... and also a systemd-login thing where it can't abandon a session scope
[15:44] <rbasak> infinity: so it looks like C/R didn't resolve the problem.
[15:45] <rbasak> Behaviour has changed a little, but apt still wants to remove mysql-server.
[15:45] <cjohnston> jodh: gQuigs has a similar issue, but for him he doesn't see the unity icons
[15:46] <infinity> rbasak: Kay.  Point me at a PPA, and I can have a look after some slightly more urgent firefighting.
[15:48] <cjwatson> ahasenack: I think that's a bug in dh_python2 for not handling that in a debhelper-standard way, though I haven't looked too closely
[15:48] <cjwatson> ahasenack: but you can easily work around it.  rather than passing that to the dh wrapper, you can instead use:
[15:48] <cjwatson> override_dh_python2:
[15:48] <ahasenack> cjwatson: right, I just did that
[15:49] <cjwatson> \tdh_python2 --no-guessing-deps
[15:49] <ahasenack> +1
[15:49] <cjwatson> (where \t is a literal tab of course)
[15:49] <ahasenack> sounded overkill, though
[15:49] <ahasenack> but it's the only thing that worked
[15:49] <cjwatson> it's fairly normal
[15:50] <cjwatson> ahasenack: this issue is raised in a comment on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638679
[15:51] <rbasak> infinity: thanks. Uploaded 5.6_5.6.19-1~exp1ubuntu1~dev4 to ppa:racb/experimental. That includes my C/R changes. Building will take a while, but hopefully will be done by the time you look.
[15:51] <ahasenack> it didn't error, it just ignored it
[15:51] <ahasenack> I think at some point they "fixed" it to not error on unknown options
[15:51] <ahasenack> but that is just masking the problem
[15:51] <cjwatson> ahasenack: you didn't read the whole bug
[15:51] <rbasak> infinity: to reproduce, I'm just doing 1) apt-get install mysql-server on Utopic, without the repo, and 2) Adding the repo, apt-get update and apt-get dist-upgrade to see what it wants to do.
[15:51] <ahasenack> no :)
[15:51] <infinity> rbasak: Righto.
[15:52] <ahasenack> "dh_python2 and dh_python3 also don't handle -O properly, which makes it
[15:52] <ahasenack> impossible to pass options to them from dh.
[15:52] <ahasenack> "
[15:52] <rbasak> infinity: though note that I used a local repo with just the debs from the mysql-5.6 build, not the PPA, since I'm building with nocheck to speed things up.
[15:52] <cjwatson> ahasenack: I'm specifically talking about the third paragraph in the second message.  it's not part of the "error out" bit, but it's caused by the same misdesign
[15:54] <infinity> rbasak: A local repo could also cause curious preference weight issues due to apt's strong dislike of unsigned repositories (unless you pass -o APT::Get::AllowUnauthenticated=true).
[15:54] <infinity> Unless that's ignored for file:// repos, I can never remember.
[15:55] <cjwatson> infinity,rbasak: deb [trusted=yes]
[15:55] <rbasak> Oh
[15:55] <rbasak> That might be a major issue for my testing actually.
[15:55] <rbasak> I will try hitting my PPA instead.
[15:55] <infinity> cjwatson: That's a thing?
[15:55] <infinity> cjwatson: I like this thing.
[15:55] <cjwatson> it sure is
[15:55] <infinity> cjwatson: How long has that been a thing?
[15:56] <cjwatson> couple of years I think
[15:56] <rbasak> When I use the local repo, I add a pin. I forgot about that.
[15:56] <rbasak> (since it's in a script)
[15:56] <cjwatson> also rather more recently mvo let you use rfc822-style sources.list
[15:56] <infinity> cjwatson: We should switch lp-buildd to using it, instead of the APT::Get::AllowUnauthenticated hammer, if all our build targets support it.
[15:56] <rbasak> Pin-Priority: 999
[15:56] <infinity> rbasak: Pinning doesn't change the internal "screw you, I hate unsigned packages" logic.
[15:56] <cjwatson> infinity: apt 0.8.16~exp3, 2011-07-15
[15:57] <rbasak> Oh, OK.
[15:57] <cjwatson> don't know if it was in Ubuntu earlier
[15:57] <infinity> cjwatson: Okay, so not supported in lucid, probably.  BUt could switch syntax when lucid dies.
[15:57] <infinity> cjwatson: Good to know.  I've always hated that we paper over that the way we do.
[15:57] <rbasak> No dice with [trusted=yes]
[15:57] <infinity> rbasak: Alright.  Will play later.
[15:59] <infinity> cjwatson: Hrm, also, this thing means that sbuild's ridiculously complex "let's generate a key to self-sign the local archive for the build-dep metapackage" thing is seriously overengineering and unnecessary.
[15:59] <cjwatson> yeah, fair point
[15:59] <infinity> cjwatson: Unless one is actually concerned about a third party without access to the sbuild user's private key somehow having access to poison the sbuild package cache.
[15:59] <cjwatson> though of course you can build for older series
[15:59] <rbasak> I hate that too. And anything else that blocks on /dev/random on a throwaway dev machine with low entropy. I'm looking at you too, adt-run.
[16:00] <cjwatson> but maybe we could detect apt versions
[16:00] <rbasak> I have a script to throw the same test key on my throwaway dev machines as a workaround. It's still annoying though.
[16:01] <infinity> cjwatson: Or just add a nice '/* FIXME: REMOVE ALL THIS CODE WHEN WE STOP CARING ABOUT SQUEEZE */'
[16:04] <ScottK> Didn't we do that already?
[16:05] <doko> pitti, ricotz: you sponsored/uploaded gtkhtml4, but it requires a transition, currently stuck in -proposed
[16:06] <infinity> ScottK: squeeze and lucid are both still supported, so some of us have to care. :P
[16:06] <ScottK> Lucid yes, but unless you're in the special squeeze-lts thing, not so much.
[16:07] <doko> LocutusOfBorg1, you uploaded insighttoolkit to -proposed, needs a transition
[16:08] <LocutusOfBorg1> yes doko I missed the point
[16:09] <LocutusOfBorg1> 4 packages needs to be rebuilt
[16:09] <doko> LocutusOfBorg1, please do
[16:10] <LocutusOfBorg1> I have no upload privileges
[16:10] <LocutusOfBorg1> :(
[16:11] <LocutusOfBorg1> I asked cjwatson a while ago about them
[16:11] <LocutusOfBorg1> (not about the upload privileges of course :p)
[16:13] <cjwatson> anyone with access can do no-change uploads; it's not a good idea to have me responsible for all of them
[16:17] <LocutusOfBorg1> I was meaning that I asked "here" about them
[16:18] <LocutusOfBorg1> wasn't a blame against you and your precious work ;)
[16:18] <LocutusOfBorg1> is it difficult to become an ubuntu developer?
[16:19] <LocutusOfBorg1> sometimes I would like to have sync privileges for packages I maintain in debian
[16:20] <ScottK> LocutusOfBorg1: Are you a DD?
[16:20] <LocutusOfBorg1> not yet
[16:20] <LocutusOfBorg1> DM
[16:20] <ScottK> That would make it easier, but it's still not hard.
[16:20] <LocutusOfBorg1> DM since one year, but my sponsor agreed that will advocate me soon
[16:21] <LocutusOfBorg1> (unfortunately he is really overbusy and I don't want to ask him again)
[16:21] <ScottK> LocutusOfBorg1: You probably want https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage and https://wiki.ubuntu.com/DeveloperMembershipBoard/#Application_process
[16:21] <LocutusOfBorg1> thanks a lot, I'll read them, I remember I read them a while ago, but I gave up :(
[16:22] <doko> LocutusOfBorg1, but this is not about syncing, but about keeping up until your upload is in the release pocket
[16:24] <LocutusOfBorg1> I understand, even this morning I looked at the proposed output, hoping that somebody had done the rebuild :(
[16:24] <LocutusOfBorg1> but unfortunately I need to ask, and people like cjwatson had already done too much for me :) (also daniel, who synced a package this morning)
[16:37] <LocutusOfBorg1> ScottK, so if I read correctly I need to put my name on the schedule, wait for the meeting and hope for the best? :)
[16:38] <doko> seb128, Sweetsha1k: any update on https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 ? pending for a month ...
[16:39] <seb128> doko, I don't know, that's one for Sweetsha1k
[16:39] <seb128> doko, in fact seems it's fixed, https://launchpad.net/ubuntu/+source/libixion/0.7.0-2ubuntu1
[16:39] <seb128> doko, should it be put back to New?
[16:40] <doko> seb128, why? where is the information for the MIR?
[16:47] <seb128> doko, ?
[16:47] <seb128> doko, why what?
[16:47] <seb128> doko, I was looking at https://launchpad.net/ubuntu/+source/libixion/0.7.0-2ubuntu1 , it seems it built on ppc64el in the current upload
[16:48] <seb128> doko, but I don't know more than this, maybe you are looking after another problem, I recommend you check with Sweetsha1k
[16:48] <doko> seb128, https://wiki.ubuntu.com/MainInclusionProcess
[16:48] <seb128> doko, I know what MIR are, thanks
[16:48] <seb128> doko, not sure why you ping me, it's not my MIR requests, it's Sweetsha1k's, I was just trying to help by pointing out that the ftbfs issue seems resolved
[16:49] <doko> seb128, you're the tech lead, afaik, that's why
[16:50] <seb128> doko, well, doesn't seems there is much tech to resolve there
[16:51] <seb128> Sweetsha1k just needs to write the content of the MIR
[16:51] <seb128> Sweetsha1k, ^ can you do that?
[17:12] <ScottK> LocutusOfBorg1: After writing an application and getting some endorsements.
[17:18] <doko> pitti, your no-change upload for pgrouting is wrong. needs sourceful changes
[17:29] <doko> slangasek, https://launchpad.net/ubuntu/+source/libphonenumber/6.0+r655-0ubuntu4 do you care about the ftbfs?
[17:29] <slangasek> doko: yes, it's on my list of lists
[18:10] <jtaylor> doko: if you have the time can you look at my numpy sru bug 1358870?
[18:12] <doko> jtaylor, commented. but I can't approve it
[18:13] <jtaylor> someone has to upload it first :)
[18:15] <doko> slangasek, libphonenumber fixed on ppc64el, arm64 still ftbfs
[18:15] <slangasek> doko: oh sure, you fixed the easy one ;)
[18:15] <doko> ahh, ok
[18:16] <doko> slangasek, so you don't get distracted ;-P
[18:16] <slangasek> heh
[18:53] <cjwatson> siretart: were any of your changes in https://launchpad.net/~motumedia/+archive/ubuntu/libav11/+packages more than straight rebuilds?
[19:48] <nadrimajstor> Hello everyone... Could someone point me to a proper guide on how to make a binary only (no upstream tar.gz) quilt 3.0 package?
[19:48] <cjwatson> that's not binary-only
[19:48] <cjwatson> I think you mean native?
[19:49] <cjwatson> if there's no upstream, then you cannot use 3.0 (quilt), as it doesn't make sense
[19:49]  * nadrimajstor having trouble wrapping his head around .install/include-binary and tools to manage
[19:49] <cjwatson> the point of the quiltiness is to manage differences from upstream
[19:50] <cjwatson> maybe step back and explain exactly what pieces you have
[19:50] <nadrimajstor> cjohnston: I just have a bunch of .PNGs that should be put in /boot/grub/themes
[19:51] <nadrimajstor> cjohnston: nothing else...
[19:51] <cjwatson> please note that I am cjwatson not cjohnston
[19:51]  * nadrimajstor oooops
[19:51] <cjwatson> ok, so I don't understand why you specifically want 3.0 (quilt), then
[19:52] <cjwatson> that sounds better handled as a native package
[19:53] <nadrimajstor> cjwatson: Reading the post on introduction of 3.0 packages and there was a mention of a quilt feature to have binary includes
[19:53] <cjwatson> you put "3.0 (native)" in debian/source/format and then do the rest of the packaging as normal, making sure not to have any patches (sounds like there's no danger of that here), and making sure that the version in debian/changelog does *not* contain the "-" character which ordinarily separates the upstream version from the revision of the packaging
[19:54] <cjwatson> that feature of 3.0 (quilt) isn't necessary here.  it's needed when you otherwise have an ordinary package from upstream and your packaging needs to contain a binary file like an icon or whatever
[19:54] <nadrimajstor> cjwatson: Being a total noob on deb packaging I wondered off to wrong direction...
[19:54] <cjwatson> but in this case a native package will do fine, and the whole thing will just be put together as a single tarball by debuild -S
[19:55] <cjwatson> that feature of 3.0 (quilt) is by comparison with the 1.0 format, which in the case where you had an upstream tarball would create a .diff.gz for the packaging; the diff could only represent text
[19:55] <cjwatson> but it's a red herring here
[19:56] <cjwatson> yeah, in cases where things have been put together incrementally over the years it can take a bit of catching up
[19:57] <nadrimajstor> cjwatson: I got it... Thank you.
[19:58] <cjwatson> np
[19:58]  * nadrimajstor thinks that deb package maintainers should get a medal... or a straightjacket... or both.... or a crate of whiskey at least. :D
[19:59]  * nadrimajstor is just lazy... ignore him.
[19:59] <cjwatson> well, my whiskey cupboard is quite full
[19:59] <cjwatson> but it's not really that hard when you're doing it regularly, like most things
[20:01] <cjwatson> it's just a system that does a lot of things and that people ask a lot of, so it has something of a learning curve
[20:01]  * nadrimajstor wondered of to make his grub theme package....
[20:04] <mterry> hallyn, hello!  Can I pick your brain on how to debug a cgroup issue I'm seeing?
[20:15] <hallyn> mterry: of course
[20:16] <mterry> hallyn, yay!
[20:16] <hallyn> :) what's up
[20:16] <mterry> hallyn, so on krillin devices with Ubuntu Touch, I'm seeing that apps don't have proper cgroups info in /proc/PID/cgroup, such that policykit requests are failing because it doesn't associate them with an active logind session
[20:17] <mterry> hallyn, I've got this far, but I'm not sure how to find out *why* there's no good info in the cgroup file
[20:17] <hallyn> mterry: i don't undestand.  what is in your /proc/pid/cgroup then
[20:18] <mterry> 4:name=systemd:/
[20:18] <mterry> 3:freezer:/
[20:18] <mterry> 2:cpuacct:/
[20:18] <mterry> 1:cpu:/
[20:18] <mterry> hallyn, ^
[20:19] <hallyn> so they're in the root cgroup.  these were started from a login session?
[20:19] <mterry> hallyn, I believe so yes
[20:20] <hallyn> what is /proc/pid/status and /proc/pid/cmdline?
[20:21] <mterry> hallyn, cmdline is system-settings
[20:21] <mterry> hallyn, status is http://paste.ubuntu.com/8253138/
[20:22] <hallyn> what is 1439, and what cgrou pis it in?
[20:22] <mterry> hallyn, 1439 is init --user
[20:23] <hallyn> hm.  on my laptop that is in proper cgroups (as is unity-settings)
[20:23] <mterry> hallyn, its cgroup file is similar
[20:23] <mterry> hallyn, right.  I have two devices next to me, mako and krillin.  Only happening on krillin
[20:23] <hallyn> is this with the newest upstart?
[20:23] <mterry> hallyn, this isn't a generic problem
[20:24] <mterry> hallyn, maybe upstart is related, but I haven't bisected the cause yet
[20:24] <hallyn> mterry: so as usual i guess i would set /etc/default/cgmanager to cgmanager_opts="--debug",
[20:25] <hallyn> reboot the device and look at /var/log/upstart/cgmanager.log
[20:25] <hallyn> look for entries for the user --session pid
[20:25] <mterry> k
[20:25] <hallyn> it didn't use to do this right?
[20:25] <mterry> hallyn, I don't recall no.  Some change happened
[20:25] <mterry> I just don't know which yet
[20:26] <hallyn> mterry: can you ssh into the device, cat /proc/self/cgroup there?
[20:26] <mterry> hallyn, why would ssh matter?
[20:27] <mterry> hallyn, I must not have followed the --debug instructions right, I don't have /var/log/upstart/cgmanager.log
[20:27] <mterry> hallyn, /etc/default/cgmanager didn't exist either...
[20:30] <hallyn> you have to create /etc/default/cgmanager
[20:30] <hallyn> but, ps -ef | grep cgmanager - is it there?
[20:32] <hallyn> zul: ok, so qa-regression-testing is failing for me everywhere, so i guess i'll ignore it for now.  Please take your 1.2.8 source, do "quilt pop", copy the add-cgmanager patch from 1.2.6 back in, uncomment that from series, quilt push, quilt ref, quilt push, test-build (should work, did for me) an dpush that.
[20:32] <hallyn> i'm gonna have to spend more time on qrt itself.  i think virtinst is the problem, but i'm not sure
[20:33] <hallyn> for instance:
[20:33] <hallyn> ERROR    internal error: process exited while connecting to monitor: qemu: could not load kernel '/home/serge/.cache/virt-manager/boot/virtinst-linux.is3pnZ': Permission denied
[20:33] <mterry> hallyn, yes: /sbin/cgmanager --sigstop --debug -m name=systemd
[20:34] <mterry> hallyn, I did create the /etc/default file
[20:34] <mterry> with contents: cgmanager_opts="--debug"
[20:34] <hallyn> then restarting cgmanager by all rights should create /var/log/upstart/cgmanager.log
[20:35]  * mterry reboots again
[20:37] <mterry> hallyn, there isn't...  :(
[20:37] <hallyn> is there /var/log/upstart/cgproxy.log?
[20:37] <mterry> yes
[20:37] <hallyn> that's a start...  pb it?
[20:38] <mterry> hallyn, http://paste.ubuntu.com/8253267/
[20:38] <hallyn> and now what pid is init --user?
[20:39] <mterry> hallyn, 1442
[20:48] <hallyn> can you show a full ps -ejH?
[20:50] <mterry> hallyn, http://paste.ubuntu.com/8253379/
[20:52] <zul> hallyn,: ack
[20:56] <hallyn> speaking of init --user, why do i have like 20 of these running:  lightdm  10268     1  0 Sep03 ?        00:00:00 init --user --startup-event indicator-services-start
[20:57] <mterry> hallyn, I dunno
[21:14] <Ampelbein> barry: Hi. A user in #-bugs asked about the SRU of bug 1290847 into trusty. Do you know the current status of this?
[21:15] <barry> Ampelbein: that was dstufft i gather :)
[21:16] <Ampelbein> Yeah. You two have a history? ;)
[21:16] <hallyn> mterry: oh, sorry.  so your init --user, does it hit systemd-logind?  That should be the one, i assume talking to cgmanager for you
[21:16] <mterry> hallyn, btw I tried adding --verbose too, but no luck for cgmanager output
[21:16] <hallyn> that's really weird
[21:17] <mterry> hallyn, what do you mean by hit?
[21:17] <barry> Ampelbein: oh yes :).  we know each other well from the python community.  we were talking earlier today about the sru for that bug.  i suggested he open an sru bug (rather than modifying the above, which he doesn't have perms for) and he said he'd see if someone on #-bugs could help. he's not an ubuntu dev, but he's friendly to the cause :)
[21:17] <mterry> systemd-logind is running...
[21:17] <hallyn> i mean does it get spawned by a task that goes through pam, thence through libpam-systemd
[21:17] <hallyn> what's its pid
[21:17] <mterry> hallyn, systemd-logind is 1040
[21:17] <hallyn> that's pretty late
[21:18] <Ampelbein> barry: I see. I'll see if he's at the keyboard currently and maybe can help him filing the SRU request. Thanks!
[21:18] <barry> Ampelbein: thanks!
[21:19] <hallyn> thogh older than lightdm i guess
[21:55] <Ampelbein> barry: bug 1365728 is the SRU request opened by dstufft.
[21:55] <barry> Ampelbein: thanks!
[22:16] <doko> mlankhorst, llvm 3.4 final is now in utopic
[22:41] <mbiebl> kees: hi, did you get the email regarding libseccomp
[22:42] <kees> mbiebl: hi! I did, though I'm still digging through a giant inbox after weeks of back-to-back conferences. :)
[22:43] <kees> mbiebl: ultimately, I have no problem with raising the priority, but I would note that libseccomp is not available on all archs.
[22:44] <mbiebl> kees: hm, thanks for the pointer
[22:44] <mbiebl> is libseccomp not functional on those particular architectures?
[22:44] <mbiebl> i.e. ! i386 amd64 armhf armel
[23:23] <mterry> robert_ancell, poke -- I think lightdm 1.11.8 is causing problems on krillin devices
[23:23] <robert_ancell> mterry, oh, rsalveti said it was working
[23:23] <rsalveti> which problems?
[23:24] <mterry> robert_ancell, rsalveti: I'm seeing that cgroups aren't being set for the user session correctly, so a lot of policykit requests are failing
[23:24] <robert_ancell> mterry, you have a lightdm.log?
[23:24] <mterry> robert_ancell, uh hold on just flashed
[23:24] <robert_ancell> 1.11.7 would have those problems
[23:25] <rsalveti> right, the issue I had got fixed with 1.11.8
[23:26] <robert_ancell> So, anyone want to send me a krillin? :)
[23:26] <mterry>  Interesting.  I'm not seeing the problem with 1.11.7
[23:27] <robert_ancell> mterry, it was a crash triggered by a race, so you might not have seen it
[23:28] <mterry> robert_ancell, well the failure is reliable with 1.11.8 (only on krillin)
[23:28] <robert_ancell> So I suppose your issue is different, though they both sounds related to logind
[23:37] <siretart> cjwatson: now, they were all straight rebuilds
[23:38] <siretart> cjwatson: btw, libav now migrated to debian/testing
[23:51] <robert_ancell> mterry, are you getting a log?
[23:51] <mterry> robert_ancell, yeah sorry had problems
[23:51] <robert_ancell> np
[23:51] <robert_ancell> just checking :)