[00:01] <mdeslaur> infinity: could you pocket-copy xen from raring-security to saucy, pleeze?
[00:02] <infinity> mdeslaur: Maaaaaybe.
[00:02] <mdeslaur> infinity: sure you will, cause you're nice and all :P
[00:02] <infinity> mdeslaur: Done.
[00:02] <mdeslaur> infinity: cool, thanks :P
[00:03] <infinity> mdeslaur: To be fair, you could have done it too.
[00:03] <mdeslaur> infinity: oh?
[00:03] <infinity> mdeslaur: copy-package -s raring-security --to-suite=saucy-proposed -b xen
[00:04] <infinity> mdeslaur: You should be able to copy to any pocket you'd be able to upload to.
[00:04] <mdeslaur> infinity: oh, I didn't know that...thanks, I'll try it next time
[00:05] <infinity> (At least, I believe that's the case...)
[00:06] <ogra_> RAOF, huh ? i thought it uses libinput
[00:07] <RAOF> Reading from evdev
[00:07] <ogra_> we dont even remotely have support for evdev on the touch images
[00:07] <cjwatson> infinity: Indeed.
[00:08] <ogra_> RAOF, that will cause massive issues with the kernels
[00:09] <ogra_> we would have to patch them to actually provide evdev devices instead of talking to libinput
[00:09] <slangasek> this seems like an architecture question for Phonedations to solve
[00:09] <slangasek> ;)
[00:10] <ogra_> well, lwould have been nice to know :)
[00:10] <ogra_> we will definitely have issues with that ...
[00:10] <RAOF> ogra_: So what's the actual problem?
[00:10] <ogra_> RAOF, did you guys actually test mir on touch images (vs on the nexus7 desktop one for example)
[00:10] <RAOF> Because I'm pretty sure that we're getting input events on Mir on the phone.
[00:11] <ogra_> RAOF, that the assumption is that we will go on using the android HAL layer for all devioce interaction (including input)
[00:11]  * ogra_ needs to relocate ... lets discuss that later (and probably in person)
[00:11] <slangasek> ogra_: implying that we would be using android hal even for Mir on desktop images?
[00:12] <RAOF> ogra_: So, as far as I can tell, Mir uses libinput, which reads evdev from /dev/input/*.
[00:12] <slangasek> ah
[10:06] <zyga> diwic: out of curiosity, the kernel associated with bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1169984 is not fixing the problem on my hardware
[10:06] <diwic> zyga, okay; what problem are you having with that kernel?
[10:07] <zyga> diwic: I'm updating the bug report
[10:07] <diwic> zyga, please don't
[10:07] <diwic> zyga, you're probably having a different bug then
[10:07] <diwic> zyga, the last thing we need is all different problems in the world in the same bug
[10:08] <zyga> ah
[10:08] <zyga> true
[10:08] <diwic> zyga, or maybe you have both 1169984 and another bug
[10:09] <zyga> diwic: I'll check if actual audio got fixed
[10:10] <zyga> diwic: audio works but is distorted
[10:10] <zyga> diwic: but it's better than vanilla 13.04 kernel
[10:10] <diwic> zyga, ok, so that's a different bug then
[10:11] <diwic> zyga, still a regression though, if the audio was non-distorted on 12.10 ?
[10:11] <zyga> let me just triple check on 12.04 to ensure that audio was not distorted there
[10:11] <zyga> diwic: I don't have 12.10 here
[10:11] <diwic> ok
[10:11] <zyga> diwic: just 12.04 and 13.04
[10:12] <zyga> diwic: yes, perfectly clear audio
[10:12] <diwic> ok
[10:13] <diwic> zyga, please run "ubuntu-bug audio", note if both test tone sets are distorted or just the second one, and point me to the resulting bug.
[10:15] <zyga> diwic: on 13.04, right?
[10:15] <diwic> zyga, yes.
[10:15] <zyga> rebooting
[10:20] <zyga> diwic: should I expect some test playback during `ubuntu-bug audio`
[10:20] <diwic> zyga, yes
[10:20] <zyga> diwic: presented with the question "in what way the sound quality is bad" I'm uncertain
[10:20] <diwic> zyga, just pick one
[10:21] <zyga> I did't hear any sound
[10:21] <diwic> zyga, ok
[10:21] <zyga> diwic: the initial dialog lists several devices
[10:21] <zyga> diwic: many have the same name
[10:21] <diwic> zyga, what same name, "HDMI" ?
[10:21] <zyga> diwic: I selected the second of the group, hoping it would be my 'hdmi 2'
[10:21] <diwic> ok
[10:21] <zyga> diwic: "Digital Out, HDMI"
[10:22] <zyga> diwic: I just tried another, still no sound
[10:22] <diwic> zyga, sounds like my apport symptom could be improved...
[10:22] <zyga> diwic: hmm I suspect ubuntu-bug is broken there
[10:23] <zyga> diwic: the next dialog is shown instantly
[10:23] <zyga> diwic: maybe missing dependency? can I somehow see what is going on there
[10:23] <zyga> diwic: I suspect it never actually tried to play anything, having crashed in the attempt
[10:23] <diwic> zyga, don't bother troubleshooting the troubleshooter at this point
[10:23] <zyga> ok
[10:23] <zyga> :D
[10:24] <diwic> zyga, maybe just file a bug with "ubuntu-bug pulseaudio" instead
[10:24] <zyga> ok
[10:32] <zyga> diwic: bug 1174696
[10:34] <diwic> zyga, hmm, crackling and metallic feeling sounds like https://wiki.ubuntu.com/Audio/PositionReporting - could you try the stuff there and see if it makes a difference?
[10:34] <zyga> diwic: looking
[10:35] <zyga> brb
[10:50] <zyga> uh
[10:50]  * zyga is sick
[10:57] <zyga> diwic: testing position fix=1
[11:02] <zyga> diwic: using =1 makes it worse, sound cuts off after a second and does not go back
[11:02] <zyga> diwic: trying =2
[11:04] <zyga> diwic: =2 is the same as without adding that option
[11:04] <zyga> diwic: tryig the scheduling trick
[11:06] <zyga> diwic: module-udev-dectect has use_ucm=0 in my default.pa, is that oka?
[11:07] <diwic> zyga, ucm is unrelated
[11:07] <diwic> zyga, ucm is for embedded devices
[11:07] <zyga> diwic: tsched did not affect this
[11:08] <zyga> diwic: if you want I can record the playback
[11:08] <diwic> zyga, ok, not sure what's wrong with it then
[11:28] <zyga> diwic: despite using LANG=C pactl list uses some localized strings, do you know where they might come from?
[11:28] <diwic> zyga, try LC_ALL=C or LC_MESSAGES=C
[11:30] <zyga> diwic: nope
[11:30] <zyga> diwic: so stuff that pactl prints itself is in english
[11:30] <zyga> diwic: but Description fields are localized
[11:30] <zyga>         Description: Wbudowany dźwięk Analogowe stereo
[11:30] <diwic> zyga, right, that's not much to do about in pactl
[11:31] <zyga> diwic: so where does that come frome?
[11:31] <diwic> zyga, that's translated in PulseAudio, you would have to run the entire pulseaudio with LC_ALL=C to get rid of that
[11:31] <zyga> ohhh
[11:31] <zyga> ok
[11:31] <zyga> thanks for the tip
[11:31] <zyga> that means we may not be able to use Description in any heuristic
[11:31] <diwic> zyga, but then sound settings will no longer be localized for you either
[11:32] <diwic> zyga, well, there are "names" to every description you should use instead for heuristics
[11:34] <zyga> diwic: right
[11:44] <zyga> hmm
[11:45] <zyga> diwic: is the hot-plug issue affecting both hdmi and dp?
[11:50] <diwic> zyga, what hot-plug issue?
[11:50] <diwic> zyga, no dynamic re-probing on hotplug? Yes, that affects both.
[11:52] <zyga> diwic: ok
[11:52] <zyga> diwic: thanks
[11:52] <zyga> diwic: I found that I don't see hdmi, after I plug it, it is there, then if I un-plug it, it seems to stay there
[11:53] <diwic> zyga, there was a bug that ELD info is still valid after hotplug, that I fixed recently - it probably has not reached 3.2 kernel yet, if it ever will.
[11:53] <zyga> diwic: this is on raring actually
[11:53] <zyga> diwic: I have a draft plan for the test \]program
[11:54] <zyga> diwic: https://gist.github.com/zyga/5488243
[11:55] <diwic> zyga, ok, I'd typically go for just choosing the "stereo" option, i e remove all that do not start with "hdmi-stereo"
[11:56] <diwic> zyga, or do you typically want to test 5.1 surround too?
[11:56] <zyga> diwic: good question
[11:57] <zyga> diwic: no, let's keep 5.1 out of it
[11:59] <diwic> zyga, btw, you only have to select the profile on the card; you don't need to set the default sink, instead specify what sink you want playback on when you play the sample sound
[12:07] <zyga> diwic: ah, that's good
[12:07] <zyga> diwic: thanks
[12:07] <zyga> diwic: I'd like to use dbus api so that I don't have to parse all of that
[12:08] <zyga> diwic: what is the best place to learn about this?
[12:10] <diwic> zyga, about the dbus API? It's not even enabled in 12.04.
[12:10] <zyga> oh
[12:10] <zyga> so what other choices do I have?
[12:10] <zyga> I'm good with C
[12:11] <diwic> zyga, for a tool such as yours pactl + paplay seems the simplest option IMO
[12:12] <diwic> zyga, otherwise, the native API http://freedesktop.org/software/pulseaudio/doxygen/
[12:12] <zyga> diwic: for the simple approach, I'd have to parse the output of pactl list cards; right?
[12:13] <diwic> zyga, right.
[12:13] <zyga> diwic: is it any formal thing? yaml?
[12:13] <diwic> zyga, there might be some python code in my apport symptom.
[12:13]  * zyga mutters something about inveinting output formats
[12:13] <zyga> inventing
[12:14] <diwic> zyga, can't be worse than inventing libraries, can it ;-)
[12:15] <diwic> zyga, I don't think it's formalised.
[12:16] <zyga> diwic: haha, good point
[12:16] <diwic> zyga, use the C API if you want something more guaranteed to be stable
[12:16] <zyga> diwic: ok
[12:16] <zyga> diwic: actually
[12:16] <zyga> diwic: a feature to output json would be a nice patch on top of pactl list
[12:16] <diwic> zyga, patches welcome
[12:16] <zyga> diwic: that would be a good compromise on using the c api
[12:16] <zyga> diwic: and I would rather have that with some simple python side
[12:16] <zyga> diwic: rather than doing a custom program just for that
[12:16] <zyga> diwic: thanks
[12:16] <diwic> zyga, I believe json output from pactl would be encouraged by upstream
[12:17] <zyga> diwic: yeah
[12:17] <zyga> diwic: I think that would be good
[12:17] <zyga> diwic: although with dbus api that might be seen as a useless addition
[12:17] <zyga> diwic: anyway
[12:17] <zyga> diwic: let's assume that's my plan
[12:18] <diwic> zyga, well, question is if you actually submit json patches to upstream, how do you get it into 12.04...?
[12:19] <zyga> diwic: that's a valid question but I suspect I know somoene that knows the answer
[12:19] <zyga> diwic: ara is gone now
[12:19] <zyga> diwic: I'll know in an hour or so
[12:20] <zyga> diwic: I suspect that we could backport pactl into our testing ppa, it depends on exactly what needs to be certified
[12:20] <diwic> zyga, I have upload rights for PulseAudio in Ubuntu and commit rights to PulseAudio upstream.
[12:20] <zyga> diwic: ok
[12:21] <diwic> zyga, and honestly, from an SRU point of view, it seems easier just for you to parse pactl as it is
[12:22] <diwic> zyga, I've not done that many SRUs for pulseaudio but still I think I might want more motivation than "slightly more convenient interface for an internal testing tool" to give to the SRU approvers
[12:22] <zyga> diwic: hmm, perhaps
[12:22] <zyga> diwic: is there any way to access the dbus api on 12.04 or is that just gone?
[12:23] <diwic> zyga, yes, "load-module module-dbus-protocol"
[12:23] <diwic> zyga, it's disabled because there are race conditions on card unplug that can make PA crash.
[12:23] <zyga> diwic: ah
[12:24] <zyga> diwic: ok
[12:25] <zyga> diwic: I guess a parser is in order then
[12:25] <zyga> diwic: thanks for your help
[12:25] <zyga> diwic: I'll let you know which approach we'll take
[12:26] <diwic> zyga, ok, good luck :-)
[12:45] <hallyn> SpamapS: could you push the libvirt raring-proposed?
[14:06] <zyga> diwic: quick question, how crazy would it be to load the pa dbus module just for testing?
[14:06] <zyga> diwic: and unload it later
[14:06] <zyga> diwic: doable?
[14:18] <diwic> zyga, I guess
[14:19] <diwic> zyga, I don't know enough about the dbus module to know if it fits the purpose
[14:21] <zyga> diwic: ok
[14:21] <zyga> diwic: I guess parsing is really the only option then :)
[14:21] <zyga> diwic: I'll make a library for that
[14:58] <rbasak>   /win 19
[15:36] <zyga> diwic: we've decided to create a custom parser
[15:36] <zyga> diwic: and work upstream to file bugs
[15:37] <zyga> diwic: about pactl list being json parsable
[15:37] <zyga> diwic: about the discrepancy between x and pulse
[15:37] <zyga> diwic: and anything else we may encounter
[15:37] <zyga> diwic: we'd like to get a better upstream relationships
[15:56] <jibel> xnox, https://code.launchpad.net/~jibel/ubuntu/saucy/python-apt/AddSaucy_lp1174562/+merge/161631
[15:58] <stgraber> xnox: 15:56 < jibel> xnox, https://code.launchpad.net/~jibel/ubuntu/saucy/python-apt/AddSaucy_lp1174562/+merge/161631
[15:58] <jibel> xnox, https://code.launchpad.net/~jibel/ubuntu/saucy/python-apt/AddSaucy_lp1174562/+merge/161631
[16:31] <hallyn> infinity: could you push https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text=libvirt (raring sru for libvirt)?
[16:31] <hallyn> (if i understand right that you're part of sru team)
[16:39] <infinity> hallyn: I might be.
[16:40] <infinity> hallyn: There are precise and quantal tasks for this too, what's up with that?
[16:47] <cousteau> Changelog for aptitude:   * Apply upstream multiarch-conflicts.patch to handle conflicts on multi-arch systems.
[16:48] <cousteau> ok, it only took 2 years to solve...
[16:48] <cousteau> anyway, does this mean aptitude is safe now?
[16:53] <hallyn> infinity: yeah those will be needed too
[16:54] <infinity> hallyn: Hrm.  I like that there are 3 of the in the quantal queue...
[16:54] <hallyn> infinity: yup
[16:55] <infinity> hallyn: The precise one is missing a bug ref in the changelog.
[16:55] <infinity> hallyn: Pls to be fixing.
[16:55] <hallyn> k  (the quantal one is too i think)
[16:55] <infinity> hallyn: The Q one has the bug ref a few lines up.
[16:56] <hallyn> ah yes i see
[16:56] <hallyn> re-pushing precise
[16:57] <hallyn> (pushed)
[17:42] <xnox> stgraber: what does "lxc-start: invalid sequence number 1. expected 2" means?
[17:58] <cjwatson> pitti: Are you already working on the systemd/powerpc build failure?
[17:59] <cjwatson> The udev/systemd cluster tickles some kind of excitingly pathological path in proposed-migration so I'd like to get it sorted out fairly sharpish :)
[18:22] <pitti> cjwatson: was in a meeting, but I'll sort it out now
[18:30] <cjwatson> pitti: If it helps, the full test output is http://paste.ubuntu.com/5619996/
[18:31] <pitti> cjwatson: yeah, a lot of the tests don't work in our buildd environment unfortunately; I'll just disable that one for now; we don't use the journal anyway
[18:32] <cjwatson> OK, cool, thanks
[18:32] <pitti> (uploaded)
[19:06] <robert_ancell> pitti, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/3151169/+listing-archive-extra
[19:06] <pitti> robert_ancell: \o/
[19:07] <Laney> ph33r
[19:08]  * pitti reboots
[19:13] <pitti> robert_ancell, Laney: works fine here, and now properly kills the screensaver on user switching
[19:13] <Laney> phew
[19:13] <pitti> indicator-session still doesn't show the users, though; but that's marked as pending merge?
[19:13] <robert_ancell> pitti, nice
[19:14] <Laney> right, try that from trunk
[19:14] <pitti> or is that just for suspend/shutdown?
[19:14] <Laney> cyphermox: ^ do you know when dailies for indicators are starting up?
[19:14] <cyphermox> the plan is actually possibly to not start them until after things can be merged for desktop/touch
[19:15] <Laney> huh
[19:15] <cyphermox> to give time to do the merges, fix things, make sure it all works everywhere to some limited degree of working
[19:15] <Laney> so can we get indicator-session (and datetime) in for logind somehow? :-)
[19:15] <cyphermox> yes, we should
[19:16] <cyphermox> I think we'll do one such run, and then disable it
[19:16] <pitti> OOI, can we just do a manual upload of PS packages, or would that confuse the autolanding machinery?
[19:16] <Laney> yes to both ;-)
[19:16] <cyphermox> Laney: I'll come see you, we need to discuss more stuff related to logind -- I've heard many stories about suspend and such not working, but it's fine here. I just want to make sure I'm set up properly
[19:17] <cyphermox> pitti: you can do a manual upload of PS packages, yes
[19:17] <cyphermox> it doesn't really confuse things, but it gets detected and means we need to merge the changes in afterwards
[19:17] <Laney> cyphermox: there was a big bug with suspend that pitti fixed yesterday
[19:17] <cyphermox> but as above ^ I guess we'll run the indicators at least once, and then disable them
[19:18] <cyphermox> I'm supposed to enable all the daily stuff today
[19:18] <pitti> the only broken thing known to me right now is that closing the lid doesn't lock the screen (but does suspend fine)
[19:18] <cyphermox> or you know, at least for a few of the packages
[19:18] <cyphermox> pitti: interesting. it's been working for me forever, didn't ever run into such a bug
[19:18] <cyphermox> I upgraded to saucy on thursday or something
[19:18] <cyphermox> updated yesterday morning
[19:19] <pitti> cyphermox: well, "forever" means "for the last two days?" :-)
[19:19] <cyphermox> yes ;)
[19:19] <Laney> the suspend bug was up until you restarted your session after dist-upgrading to saucy
[19:19] <cyphermox> forever given the current lifetime of saucy ;)
[19:19] <cyphermox> ah
[19:19] <cyphermox> then I would have never seen it, yes
[19:19] <Laney> almost melted my bag at lunch yesterday :P
[19:19] <cyphermox> haha ;)
[19:20] <cyphermox> glad to know it's just that I restarted my session at the right time
[19:20] <cyphermox> pitti: we'd be running into a similar issue with the NM session tracking changes, too
[19:21] <pitti> cyphermox: but we don't restart NM on upgrades, do we?
[19:22] <Laney> NM is fine here and I still haven't restarted since dist-upgrading
[19:24] <pitti> Laney: want to see how far you can get with the in-memory processes without rebooting? :-)
[19:24] <pitti> lunch o'clock
[19:25]  * Laney is hardcore
[19:29] <jbicha_> robert_ancell: why does Ubuntu have liblightdm-qt-2-dev but Debian has liblightdm-qt-dev? there's only 2 rdepends but it doesn't seem worth keeping a diff with Debian for that
[20:45] <cyphermox> pitti: indeed we don't restart NM; we just use the reboot notifier.
[21:14] <Laney> pitti: have you looked at porting apport?
[21:14] <pitti> Laney: not yet, but on my list
[21:15] <pitti> Laney: in fact, I'm currently working on apport anyway for slangasek's upstart logs, so I can do that right now
[21:15] <Laney> ah, OK, was going to look but go ahead
[21:16] <pitti> in_session_of_problem() ... skipped 'no ConsoleKit session'
[21:16] <pitti> hah, tests even pick that up :)
[21:32] <Laney> bah, reimplementing GetCurrentSession everywhere sucks
[21:33] <pitti> Laney: this does nicely for me: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2630
[21:33] <pitti> I'll do an upstream apport release now and upload
[21:35] <Laney> ah, very clever
[21:35] <pitti> no d-bus any more
[21:35] <pitti> and dropping the requirement of GI for apport
[21:35] <pitti> err, no, ignore that (the UI uses it, of course)
[21:36] <Laney> ah, gnome-user-share is done upstream, yay
[21:37] <pitti> Laney: it's also worth checking for patches on https://git.fedorahosted.org/cgit/
[21:37] <pitti> for projects which aren't maintained upstream any more
[21:39]  * Laney nods
[22:34] <pitti> cjwatson: mind if I steal the packagekit merge from you? I need a newer version for proper logind support
[22:55] <pitti> cjwatson: ah well, I just upload it, and receive the blame later; it's a trivial merge anyway
[23:02] <cjwatson> sure, that's fine
[23:04] <pitti> Laney: seems we are about halfway through :)
[23:20] <pitti> RAOF: FYI, colord FTBFS with "debian/rules build", I'll commit a fix to collab-main
[23:20] <pitti> t
[23:20] <RAOF> pitti: Oh, where?
[23:20] <pitti> RAOF: oh, it is already fixed there
[23:20] <pitti> setting DEB_HOST_ARCH_OS
[23:20] <RAOF> Right.
[23:20] <pitti> RAOF: can we sync, or does this need a merge?
[23:21] <RAOF> Is libsystemd-login-dev in main? If so: sync.
[23:21] <pitti> yes
[23:21] <pitti> RAOF: syncing, thx
[23:22] <RAOF> Ok.
[23:22]  * RAOF forgot --force on his syncpackage, so you can take it :)
[23:23] <pitti> autopkgtest FTW :)
[23:23] <RAOF> I'll get you to upload 0.1.33 to experimental sometime this week too, if you're game.
[23:23] <pitti> sure; my sbuilders are yearning for something to do :)
[23:23] <pitti> RAOF: or wait until Monday and upload it to unstable :)
[23:24] <RAOF> Also win :)
[23:24] <pitti> (unless you need exp glib or so)
[23:24] <RAOF> Don't think so.
[23:24] <pitti> assuming that Debian releases on the weekend