[02:11] argh [02:11] is indicator-application meant to be started via dbus or upstart? [02:12] i see an upstart job and no dbus job, but if you start indicator-application after it's crashed out via upstart, it refuses to stay alive [02:12] it just says (process:1679): libindicator-WARNING **: No watchers, service timing out. [02:12] and then it dies and gets restarted [02:12] pfft [02:16] hyperair: Maybe restart unity-panel-service? [02:17] (shot in the dark, based on event deps) [02:17] infinity: this is exactly what caused the problem in the first place [02:17] Oh. :) [02:17] you restart unity-panel-service, and indicator-application goes down and refuses to come back up [02:18] * hyperair is affected by a compiz bug where it hangs when you change your screen configuration [02:18] plug in external monitor -> hang [02:18] unplug external monitor -> hang [02:18] * hyperair has a hotkey defined in compiz that allows me to kill compiz, so it's not like compiz itself is hung, just the displaying portion of it [02:19] but it doesn't work if unity's running the lock screen [02:19] oh wait a second... [02:19] IT FINALLY STARTED [02:19] YAY === FJKong_afk is now known as FJKong [06:02] Good morning [06:51] pitti: Good morning! [06:52] hey RAOF, how are you? [06:52] Surprisingly well, given Zoe's sleeping patterns of late :/ [06:53] RAOF: heh, you are learning to sleep really fast? [06:54] :) [06:54] So, I've got two fun things for you! Firstly, I don't know why http://paste.ubuntu.com/7144964/ hangs in the read() of errfd. [06:55] Secondly, if you comment out that read (and the associated check), you find that umockdev's evemu playback doesn't round-trip. === masACC is now known as maswan [07:00] RAOF: the delays in the events are almost zero; could it be that the startup of evemu-record takes longer than 0.07 seconds, so it doesn't see any event any more? [07:00] RAOF: can you try replacing teh "0." with "1.", does it work then? [07:00] pitti: I don't think so, because the first event matches up. I'll give that a whirl, though. [07:00] RAOF: instead of starting to replay events immediately it probably should wait some time before it starts the playback [07:01] RAOF: ah, nevermind, that was bogus [07:01] RAOF: playback starts when the client program open()s the device [07:01] RAOF: -EMONDAYMORNING [07:01] :) [07:01] RAOF: do you actually expect any stderr output? [07:01] No. [07:02] RAOF: I mean, SIGINT doesn't actually terminate the program, does it? that's like Ctrl+Z, or is that still Monday morning? [07:02] Has anyone ever looked at how insane the new deps for bamfdaemon and libunity-webapps0 are? [07:02] ah it is, that's SIGSTOP [07:03] SIGINT is ctrl-C; it generally does terminate the program. [07:03] (It terminates evemu-record) [07:03] Pulling in hundreds of megs of packages for no reason on non-Qt platforms sounds like a wonderful idea. [07:04] RAOF: do you have the output of evemu-record (i. e. "sout") when disabling the stderr read()? [07:04] RAOF: i. e. in what way it doesn't match up? (other than slightly different timestamps) [07:05] pitti: I'll grab it again from gdb, but when I inspected it it terminated early. [07:05] RAOF: but that's a nice test, thanks for that [07:07] pitti: Output is: http://paste.ubuntu.com/7145011/ [07:07] lool, gstreamer ping [07:08] pitti: ie: we get the first 3 packets fine, and then stop for some reason. [07:09] RAOF: ok; I have no off-hand idea about that, that needs some in-depth debugging [07:11] UserError: Which Qt libs would those be? [07:12] All of them (Only half kidding) [07:12] do the chain of deps [07:12] http://packages.ubuntu.com/en/trusty/bamfdaemon [07:12] libunity should be a recommends to begin with, or hell even a suggests [07:13] but the service on libunity-webapps0 should be a recommends [07:15] having a library != wanting a service [07:16] UserError: unity-webapps-service links with libunity, you can't just magically make a linked library not necessary by changing the packaging. [07:17] UserError: And I'm still not seeing the Qt-related complaint... [07:17] pitti: (a) Do you want this formalised somewhere (github issue, merge request?) and (b) are you in the mood for debugging it? :) [07:18] infinity because you failed to follow the dep chain [07:18] all the way down [07:18] infinity: would you have a minute to accept the postgresql-8.4 lucid/precise SRUs for bug 1294006, or tell me that I can/should self-review them? (bdmurray already accepted the corresponding -9.1 uploads) [07:18] bug 1294006 in postgresql-8.4 (Ubuntu Precise) "New upstream microreleases 9.3.4, 9.1.13, 8.4.21" [Undecided,In progress] https://launchpad.net/bugs/1294006 [07:18] i followed every fork in the road until i saw the insanity [07:19] RAOF: (a) can't hurt, git pull request sounds nice, then I have the new test ready for examination; (b) later today, yes; not right away I'm afraid [07:19] UserError: That's nice. How about a hint, then. [07:19] bamfdaemon -> libunity-webapps0 -> unity-webapps-service -> webapp-container = [07:19] libqt5core5a , libqt5gui5 , libqt5network5 , libqt5qml5 , libqt5quick5 , libqt5widgets5 , unity-webapps-qml. [07:19] pitti: If they match the ones bdmurray did, just self-accept. [07:19] and because ubuntu and debian now pull in recommends by default, just imagine [07:19] pitti: Ok. I'll do (a) and then EOD; (b) is therefore not important :) [07:20] andddddd the library does indeed work without the service [07:20] UserError: So, perhaps you could have started with "does webapp-container really need to be installed" instead of where you did? :P [07:20] 0 for 2 [07:22] just like bamfdaemon works without the webapp stuff they added in some 13.xx version [07:22] Are you people still depends-ing xprint6 too? [07:22] Though, it only seems to be installed by default on ubuntu-desktop anyway. [07:23] Right however sane package structure is the norm for a distribution with official and community spins [07:23] Fine. File a bug. [07:23] It looks like it probably came in like that on some ubuntu-touch stuff because I recall it from around that time period [07:24] Yeah, it would have come from touch/unity8 integration. Qt is sort of here to stay for Ubuntu. [07:25] So by default, 14.04 is using three frameworks? [07:25] unity* [07:27] pitti: Enjoy your shiny new pull request! [07:28] * RAOF EOD [07:31] RAOF: thanks, good night! [07:39] good morning [07:40] infinity: ack, done (postgresql SRU) === zequence_ is now known as zequence [08:07] Does anyone want to update clutter-gst-2.0 to 2.0.10? It fixes a memory leak and adds a few new interfaces [08:11] Noskcaj, we are past feature freeze, and that doesn't look like a bug fix only reales [08:11] darkxst, My thoughts too. I'll see how hard it would be to cherry pick the memory leak fix [08:15] that said, it might be ok [08:20] pitti: Oh, Merry Christmas, BTW. You have an autopkgtest flood. === soren_ is now known as soren [08:51] doko: pong [08:52] lool, solved, problem introduced by siretart [08:56] dholbach, Is there anything i should be doing to try and improve my chance of getting MOTU tomorrow morning? [08:56] Or at least xubuntu packageset, since all my uploads there have been high quality [08:58] Noskcaj, you could ask your sponsors to see if they update their testimonials? [08:58] Noskcaj, I could have a look at updating mine if you give me the link to your application again [09:00] infinity: eglibc o'clock? :-) [09:00] pitti, is the autopkgtest for mysql-5.6 5.6.16-1~exp1: RUNNING? blocks ncurses [09:00] crazy the number of uploads we get on freeze days :p [09:01] pitti: python-flake8 autopkgtest always fails [09:01] doko: yep, that's a new test which is broken [09:02] doko: mysql-5.6 is actually running, yes; but for quite a while already [09:02] doko: eek, started two days ago; I suppose something in the test hangs and also kills the timeout timer, I kill it [09:04] zul, python-taskflow autopkg test fails [09:04] dholbach, https://wiki.ubuntu.com/Noskcaj#MOTU [09:05] Although you testimonial is pretty good, maybe mention that there's around 100 sponsorings from you [09:06] I've batch pinged a fair few other sponsors, no one replied, except logan, who said he wasn't ready to leave a testimonial [09:07] Noskcaj, one note from me is that you should be more selective in your updates after ff, you tend to merge on Debian when there are not so many useful changes that we need/the changes don't bring any real value (that adds reviews etc load which is not spent on bugfixes) [09:08] seb128, That's actually something that's been making me think recently, just what level of fixes are worth uploads for [09:08] Noskcaj, cherrypy3 autopkg test is failing [09:08] * Noskcaj looks [09:09] I'm going to guess it's not from my change though [09:10] um. link to tests plz [09:12] Noskcaj, you should know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ... [09:13] doko, I've seen it before, just didn't know the location [09:16] Sweetshark: ping, when/why/how did the libreoffice package start recommending default-jre? [09:18] Noskcaj: what was the intention of the "make basic autopkgtest" in python-flake8? [09:18] Noskcaj: it just calls "flake8" without any arguments, but it should ceratinly be called on some python tree? [09:19] Sounds like something i shouldn't have done, but i'm not allowed to be on the computer at the moment [09:20] same applies to the cheerypy3 test failure [09:20] Noskcaj: I'll create some test files and run flake8 on that, and send it to Debian [09:20] ty [09:30] apachelogger: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=06cc27ab781946cf92bc45dbf48fdd2ff8a46b0f;hp=ba56ec3d266f5f232304b13a80bb19b86e02c172 [09:30] Sweetshark: is that absolutely necessary to be recommends? it made kubuntu amd64 go oversized quite a bit [09:32] doko: are you planning on fixing plainbox for 3.4? [09:33] doko: python-flake8 autopkgtest fix uploaded, and bug/patch sent to debian [09:33] Laney, ugh, wasn't aware that it is broken ... [09:33] I don't know if the code is, but X-Python3-Version << 3.4 [09:33] zyga: ^? [09:34] Laney: we're uploading 0.5 without that today [09:34] Laney: which is okay on 3.4 [09:34] Laney, doko: so please hold on and approve the sync request from debian instead [09:34] zyga, debian only has beta2 [09:35] zyga, do you want to have a look at the bzr test failures? [09:35] doko: yes, we've fixed the final i18n bug on Sunday [09:35] doko: gladly but I need to upload 0.5 first, give me one hour please === slacker_1l is now known as slacker_nl [09:42] zul: python-taskflow autopkgtest failure shows the missing new dependency on -kazoo; I filed bug 1296607 [09:42] bug 1296607 in python-taskflow (Ubuntu) "MIR: python-kazoo; new taskflow version needs python-kazoo from universe" [Undecided,New] https://launchpad.net/bugs/1296607 [09:44] Laney, https://bugs.launchpad.net/ubuntu/+bug/1282837 is this approved by you? [09:44] Launchpad bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed] [09:46] doko: yes, but why has it lingered for a month? [09:46] ask ubuntu-archive? [09:47] doesn't seem to be in their queue [09:48] also you ∈ ubuntu-archive :P [09:48] no, just for test rebuilds and mir [09:48] hmm [09:49] we really need to revisit all these teams, and who is working when on things ... [09:50] maybe I should have subscribed the sponsors [09:50] how did you come across it? [09:55] xnox, it looks like your autopilot change causes some havoc ... [09:56] xnox, if you look at the .crash files on all these failed tests on http://ci.ubuntu.com/smokeng/trusty/touch/mako/255:20140323:20140304/7336/ [09:56] the error is always: apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'" [10:11] stokachu: ^^ who are you expecting to land bug 1282837? [10:11] bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed] https://launchpad.net/bugs/1282837 [10:17] any archive admins around? [10:18] ubuntustudio-live needs approval, getting close to release time and it would be nice to have it on our ISO ASAP :) [10:19] zequence: it is already in [10:19] laney@iota> rmadison -S trusty ubuntustudio-live ~ ubuntustudio-live | 1 | trusty/universe | source, all [10:19] Laney: Ah, great. Missed it. Thanks! === oSoMoN_ is now known as oSoMoN === Sweetsha1k is now known as Sweetshark [11:42] pitti: i saw thanks [12:10] do we have any bootchart specialists ? i'm wondering why --crop-after is racy for me ... i sometimes get http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png ... which is properly cropped after unity8 ... but http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png then again doesnt crop at all [12:19] Hey all, we are seeing trusty installs failing due to python 3.4 change. [12:19] I'm about to report a bug, but wanted to know if this was a known issue already. === MacSlow is now known as MacSlow|lunch [12:22] doko, ^ [12:23] marga, hey, I noticed the daily iso failed on some python error as well, so I guess it's somewhat known [12:23] Yes, pkern had already pinged doko privately. In any case, I'll just file the bug :) [12:23] seb128, known but not reported? === FJKong is now known as FJKong_afk [12:25] marga, there is at least one reported against plainbox it seems [12:26] Yeah, I'm looking at https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1289334, but it's older [12:26] Launchpad bug 1289334 in plainbox (Ubuntu) "package python3-plainbox 0.4-4 failed to install/upgrade: ErrorMessage: le sous-processus script post-installation installé a retourné une erreur de sortie d'état 3" [High,Confirmed] [12:26] This one: https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1296588 [12:26] Launchpad bug 1296588 in plainbox (Ubuntu) "Precise -> Trusty upgrade fails: plainbox fails to configure with E: py3compile:243: Requested versions are not installed" [Critical,Triaged] [12:27] marga, could you file a bug and we'll duplicate if it is already known. [12:27] jibel, it's this second one. [12:28] marga, okay. zyga will upload plainbox .5 to fix this. [12:28] Ok, good [12:29] hmm [12:30] I'm seeing strange failures on precise that weren't there before [12:30] zyga, please can we fox this now? [12:30] doko: trying to [12:30] doko: but this prevents us landing stuff to trunk [12:30] sphinx fails to build correct documentation with nothing but 'error: None' and return code1 [12:30] nothing in sphinx changelog seems to explain why [12:31] zyga: do you have a candidate package? [12:32] doko: in debian svn, the only thing I need is the documentation update and the final tarball that cannot generate because of that sphinx failure [12:33] ohhh, I think i found it [12:33] zyga, I don't care, I would rather upload an interim package to fix the installation failure first [12:33] any news for usb-creator? [12:34] doko: sync 0.5b2 from unstable [12:34] doko: I fixed the issue [12:35] doko: give me 3 minutes and everything will be ready [12:40] xnox: ping [12:43] doko: plainbox-0.5 upstream released, debian packaging updated, request for sync sent, looking at the ubuntu package now === _salem is now known as salem_ [12:52] doko: so how should we release plainbox-0.5 into ubuntu now? can you somehow sponsor it to debian? or would you rather sync 0.5b2 which is in unstable already? [12:52] zyga, already synced [12:52] doko: thanks [12:52] doko: will you fix 0.5 once it lands, it fixes i18n bugs that we'd like to see in 14.04 [12:52] zyga, sure I can do that, just put a signed dsc somewhere [12:53] doko: I never uploaded plainbox to debian myself, I always requested sponsorship, not sure what I need to do to give you the final .dsc [12:54] zyga, who did in the past? [12:54] doko: p1otr (Piotr Ożarowski) [12:54] doko: I sent him RFS a few minutes ago [13:06] infinity: thanks for sorting out the coreutils build failure, I'd been stuck on that === MacSlow|lunch is now known as MacSlow === cmagina-away is now known as cmagina === cmagina is now known as cmagina-away === cmagina-away is now known as cmagina === and`_ is now known as and` [13:35] pitti: I'm trying to work out how to trigger a bug report for a certain condition from the kernel. One possible trigger would be the appearance of a certain file in /var/log - does apport support anything like that? [13:45] rbasak: smoser was handling it i thought [13:46] stokachu, rbasak: cloud-installer (- to 0.1+bzr111-0ubuntu1) [13:46] Maintainer: Ubuntu Developers [13:46] Section: universe/admin [13:46] 0 days old [13:46] cloud-install-landscape/amd64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-multi/amd64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-single/amd64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-landscape/arm64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-multi/arm64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-single/arm64 unsatisfiable Depends: cloud-installer [13:46] cloud-install-landscape/ppc64el unsatisfiable Depends: cloud-installer [13:47] cloud-install-multi/ppc64el unsatisfiable Depends: cloud-installer [13:47] cloud-install-single/ppc64el unsatisfiable Depends: cloud-installer [13:47] Not considered [13:47] doko: nice [13:51] stokachu, well, only nice if you fix it ;p [13:51] doko: yea i think its b/c of the architecture set in it === caribou_ is now known as caribou [14:04] sforshee: we'd need to wire that through an upstart job [14:04] sforshee: that's fairly similar to what we are already doing with pretty much all other crashes [14:05] sforshee: e. g. /usr/share/upstart/sessions/update-notifier-crash.conf [14:06] sforshee: we also used to have (not sure if it still works) integration with kerneloops which calls /usr/share/apport/kernel_crashdump on an oops [14:08] pitti: I'm looking at kerneloops too but the spewage in dmesg would need to be changed to be more consistent [14:08] pitti: but the upstart job might work, I'll play with that. Thanks. [14:09] sforshee: another option might be to send an uevent, if you can do that in that situation [14:09] pitti: there is a uevent, another option I'm considering :-) [14:09] sforshee: wiring through an udev rules avoids assuming a particular init system, if you want to use this for other distros (e. g. upstreaming to linux), and in ubuntu's future [14:10] pitti: do you know of an example of doing it that way from a udev rule? [14:11] sforshee: in the past we used to have that for missing firmware [14:11] sforshee: e. g. the hplip bits listened for that, and we also plumbed it into jockey [14:11] sforshee: but no existing example for something crash-y [14:12] pitti: okay, thanks. I'll look into doing it that way too. === greyback is now known as greyback|lunch [14:20] seb128, not sure if I read the excuses list correctly, but python3-defaults not moving out of -proposed is because of dh-python tests failing somehow? seb128, looks like dh-python failed somehow? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dh-python/ARCH=amd64,label=adt/ - not sure if I read the excuses list properly [14:20] oops [14:21] dholbach, correct, apparently I'm still missing some tests. but maybe barry can help ;p [14:22] doko, great - I was just looking at why this was one failing https://launchpadlibrarian.net/170552764/buildlog_ubuntu-trusty-i386.click-reviewers-tools_0.6-0~181~ubuntu14.04.1_FAILEDTOBUILD.txt.gz - but I guess the two are related :) [14:24] dholbach, it did succeed here: https://launchpad.net/ubuntu/+source/click-reviewers-tools/0.5build1 [14:24] doko: hi [14:24] doko, dholbach: the ppa doesn't use trust-proposed so it still tries to build for the old python version [14:24] ahh, ok [14:24] ah, that makes sense then [14:24] thanks guys :) [14:24] which ppa? [14:25] doko, https://launchpad.net/~ubuntu-sdk-team/+archive/staging [14:25] it probably makes sense for a ppa you recommend to users [14:25] you don't want the to get proposed updates with it [14:25] sure [14:27] hi, how do you generate a new random-seed file? [14:30] glambert: it's done at every shutdown by /etc/init.d/urandom [14:31] sudo dd if=/dev/urandom of=/var/lib/urandom/random-seed bs="$(( ($(cat /proc/sys/kernel/random/poolsize) + 7) / 8 ))" count=1 [14:31] should do it manually [14:32] I don't see why you would need to do it manually though, given that it's only read on startup [14:32] And all that's done at startup is to shove it back into /dev/urandom [14:32] cjwatson, I'm writing a version of the virt-sysprep tool from libguestfs that I'm tweaking to suit my needs but also trying to port all of the tools they have [14:33] generating a new random-seed file is one of the things on there [14:33] Ah, makes sense [14:33] but given that I'm going to be running my version on the guest rather than on the host [14:33] if it's all done at startup I don't suppose I need to do anything [14:33] I think you need to run it on the host - until you've seeded the RNG you don't have meaningful entropy in the guest, surely [14:34] Well, it's done at startup/shutdown, but you might well end up with a weak RNG in the guest if you don't do anything [14:34] It's good practice to give it some entropy from an environment that actually has some [14:35] cjwatson, I can't run it on the host, the virtual machines are running in network storage and the virt-sysprep tool can't connect to them [14:35] hence the reason for going it alone so to speak [14:35] You might consider installing something like haveged in the guest to assist [14:35] (Though IANA cryptographer) === pete-woods is now known as pete-woods-lunch === roaksoax_ is now known as roaksoax [14:54] seb128: seems that protocol handling is semi working now [14:54] for firefox [14:54] seb128: however firefox is still not reading /etc/firefox/pref/apturl.js [14:54] symlinking it to /usr/lib/firefox/browser/defaults/preferences/apturl.js makes stuff work [14:54] shadeslayer, it's not supposed to [14:55] but as noted before, that's wrong :P [14:55] yeah [14:55] chrisccoulson said that firefox needs to be fixed [14:56] chrisccoulson: ^^ when you fix apturl , please poke me too, I'd like to register some extra protocols for KDE like magnet link handling and such [14:58] shadeslayer, I don't think apturl needs fixing, it's firefox which does, nothing prevents you do add handlers to KDE meanwhile [14:58] seb128: sure, but how do I do that? [14:58] I mean, I can do them via browser/defaults/preferences [14:59] application/x-scheme-handler, like every other handler ;) [14:59] you don't add them in firefox [14:59] okay, ktorrent for eg doe register magnet links in application/x-scheme-handler [14:59] shadeslayer, you add e.g "x-scheme-handler/apt" to the MimeType of the .desktop [14:59] but firefox doesn't open it [15:00] right, firefox needs to be fixed [15:00] the url handler code is buggy [15:00] that's what chrisccoulson said at least [15:00] it used to work, and then regressed over a year ago [15:00] it's only the last few weeks that people have been mentioning it ;) === greyback|lunch is now known as greyback [15:11] cjwatson: just sent an e-mail to u-d-a if you have a sec to approve [15:13] stgraber: done [15:14] thanks [15:17] hallyn: congratulations to your shiny new core-dev badge! [15:18] pitti, i know you are familiar how bootchart works, do you know whats the condition for the --crop-after arg ? i suddenly got a bootchart like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-255.png (properly cropped) while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-25&.png [15:18] err [15:19] while they usually look like http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-256.png [15:22] ogra_: it's a list of process names at whose appearance (any, not all) the boot is considered "done" [15:22] pitti, right, i added unity8 to that [15:22] ogra_: e. g. the cron job does --crop-after=compiz,metacity,mutter,kwin,xfwm4,unity8 [15:22] and all CPU usage after that is attributed to user action [15:22] (and i'm actually creating the png locally with pybootchartgui with that arg) [15:23] ogra_: but I'm actually not entirely sure how that works entirely, as normally cropping should happen once the CPU goes idle [15:23] right [15:23] thats what the documentation says [15:23] oh right, the documentation even says that [15:23] that process runs AND CPU is idle [15:23] and there is no CPU use ... [15:23] as it can be idle in between (like, waiting for a driver to load or so) [15:24] ogra_: so I do see unity8 on the second chart; was that done with the same parameters? [15:25] pitti, yes, its a script i run locally on a N4 with broken screen (great use for the broken phones) [15:25] all bootcharts in that dir are created by the same script [15:25] heh [15:26] http://paste.ubuntu.com/7146809/ [15:26] thats the script === pete-woods-lunch is now known as pete-woods [15:38] hallyn, OOOH !congrats ! [15:38] hallyn: congrats! === cmagina is now known as cmagina-away === cmagina-away is now known as cmagina [15:58] doko: dh-python autopkgtest still fails - maybe try http://paste.ubuntu.com/7146925/ ? [15:59] doko: t204 looks a bit dodgy too [16:00] thanks :) [16:01] cjwatson, hmm, but it's strange that it did succeed earlier this release cycle ... [16:02] cjwatson, doko yeah, they do. i need to finish up something in progress, and get lunch, but i can start to look afterward [16:03] thanks, afk now for some hours [16:05] doko: well there was a non-trivial merge in there IIRC === rcj` is now known as rcj [16:17] barry: ok, soon would be good since it's making click tests fail [16:17] cjwatson: ack [16:38] awe_: cyphermox: do you know if NM is going to ofono or [16:38] is MM still the focus for dan? [16:39] asac, not sure... [16:39] doko: dh-python autopkgtest fixed, FTR [16:39] awe_: got pinged by debian about updating MM package to 1.0+ [16:39] I know he was interested in our ofono support, but not sure if he has plans to merge any of it soon? [16:39] so wondered if we rather want to drop it and go ofono.. but seems not [16:40] ok so surely not yet superseded upstream. thats enough info [16:40] no, it's MM [16:40] yea, that might be too premature [16:40] cyphermox: would the 1.0 package we have in trusty be good for debian? [16:40] asac: it's already in experimental [16:40] also there's always going to a be a set of modems that MM will support better than ofono [16:40] cyphermox: i know. but people want it in sid i guess [16:40] and we'll upload 1.2 to experimental or unstable soon too [16:40] yes [16:40] what is holding that back? [16:40] ah good [16:40] ETA? [16:40] as I recall it was breaking parts of KDE [16:40] maybe this week? [16:40] depends how much time I can spend on that [16:40] cyphermox: you work with mbiebl on this in debian? [16:41] yeah [16:41] kk [16:41] will forwar that info to richi then [16:41] I already told him [16:42] kk === cmagina is now known as cmagina-away === cmagina-away is now known as cmagina === maclin__ is now known as maclin [17:19] QUESTION (cross-post): Can't boot on freshly installed 12.04.4 64bit. Got multiple CPU soft lockup messages. Could someone point me how to boot in verbose/debug mode to figure out what's going on? === bfiller is now known as bfiller_afk === Fudus2 is now known as Fudus [17:46] cjwatson, doko dh-python 1.20140128-1ubuntu8 passed dep8 and is being propomted [17:46] yay, thanks [17:46] cjwatson: i can't take any credit. looks like pitti fixed the 2.6 bits [17:46] transfer as appropriate :) [17:47] :) [17:47] :) [17:47] that should also make python-defaults go in finally [17:47] barry: It fails in Debian CI too, so please fix there as well. [17:47] ScottK: ah [17:48] barry: well, it rather just disables three explicit "2.6" checks; I'm not entirely sure how that's supposed to work in dh-python (e. g. if you have an explicit python2.6 shebang, but 2.6 isn't supported) [17:48] but as ScottK says, it's failing in Debian as well, so I hope Piotr will fix it properly [17:55] mwhudson: I assume you're keeping an eye on https://sourceware.org/bugzilla/show_bug.cgi?id=16629 for me so I don't have to, and you'll let me know when Will has a patch that actually works for you? :P [17:55] sourceware.org bug 16629 in libc "[aarch64] setcontext clobbers alternate signal stack" [Normal,New] [18:11] doko: did you notice the arm64 build failure in your gluegen2 sync? [18:58] glambert: cjwatson: is someone in need of an RNG seed at first boot? :-) [18:58] there's an app for that :-) [18:59] somehow I get the impression apport is buggy as hell: it overwrites existing reports in /var/crash if the same binary crahes again [19:00] that way I cannot keep record of crashes happened on my system ... [19:04] pitti: any idea? [19:09] cjwatson, yes, known. regression when we switch from zero to hotspot. will need to fix this next week with an openjdk-7 update [19:17] cjwatson, can you give me a hint why python3-stdlib-extensions won't migrate? [19:19] how does the naming scheme of apport work? what means 1000.crash? [19:20] kdeuser56, thats the UID [19:21] ogra: always the same here ... [19:21] always the same user then [19:21] ogra_: okay ... but what happens if the same program crashes again? [19:21] ogra_: I suppose the file gets overwritten? [19:22] might be, ask the author :) [19:22] i would guess they are though [19:23] ogra_: it is certainly like that... now I am asking myself whether apport is that sophisticated that it automatically tries to detect if a backtrace is similar and if not ... write a new file ... [19:23] ogra_: but I can't imagine that ... [19:23] ogra_: there would be a very simple solution to that: simply add a time stamp in the filename ... [19:24] apport surely knows if a backtrace is identical ... well, at least the launchpad side of it does (so i guess the local one does too) [19:25] ogra_: do you have any idea how I could simulate crashes? [19:26] easiest is to kill a python app that creates a traceback i think [19:26] (also wont make the backtras so big) [19:26] *backtrace [19:26] ogra_: will the trace always be identical if I kill the same application? [19:27] if you kill it at the same point [19:27] ogra_: do you know some example python app from the repos that is not that big? [19:28] not of the top of my head ... juust take something installed [19:29] i think apport auto-increments [19:30] or maybe not [19:31]