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