[00:12] YokoZar: That's rather unfortunate. :/ [00:13] infinity: I find it unfortunate we've both missed the opportunity to make an epoch fail pun. [02:58] w 1 [02:58] whoops === mwhudson is now known as zz_mwhudson === Logan_ is now known as OldLogan === Logan_ is now known as Guest44808 === Guest44808 is now known as Logan_ [05:25] Good morning [07:36] stgraber: is lxc-* eventually supposed to work as user? ATM it only creates some files in ~/.local/share/lxc/ and then fails to chown them [07:37] stgraber: per-user containers sounds cool, is the isolation robust/strong enough by now to allow that? [07:38] good morning [08:43] Laney, can you add me to desktop-extras while you work on the ubuntu GNOME packageset? [09:02] wgrant infinity cjwatson: any hints of what went wrong here: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2/+build/5530899 ? [09:03] "failed to build", no log, happened multiple times to me in recent days. [09:04] Sweetshark: Let me see [09:04] That usually means that your build is evil enough to kill the builder, but there were some issues witha buildd upgrade yesterday that might be relevant. [09:05] wgrant, that's libreoffice you are talking about, what could go wrong ;-) [09:05] Yeah, that was an upgrade issue. Retry should work. [09:05] seb128: I wasn't going to say that, but yes :) [09:05] wgrant: of course my builds are evil enough to kill builders. but usually they are in a good mood and spare them. [09:06] Sometimes! [09:07] wgrant, oh, btw, I uploaded a new gtk yesterday, translations got imported this time, https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports [09:07] wgrant: well a builder that shows up with to little discspace had it coming for him. That builder has nobody to blame but himself. [09:07] wgrant, should I just close the launchpad bug I had open? [09:08] seb128: Unless you see it again, yeah [09:08] wgrant, ok, doing that then [09:09] Thanks [09:12] darkxst: righto [09:21] pitti: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ [09:22] stgraber: bonjour -- oh, you are in London, I presume? [09:22] pitti: and to answer your question, yes, it's safe because no code is actually running as root at all, well, except for a minimal setuid binary to setup the network device on the host (as the user isn't allowed to add a new device to the host) [09:22] pitti: I am indeed, core sprint [09:26] stgraber: ver nice! === barry__ is now known as barry [09:33] dpm: any news on the intltool MR? [09:36] shrug, doko [09:37] that "build poppler with -O0 is wrong" [09:37] that "build poppler with -O0" is wrong [09:37] shadeslayer, not really, no. I'd suggest pinging danilo and dobey [09:37] dobey: ping pign [09:37] *ping [09:38] stgraber, can you get doko on IRC? ;-) [09:41] seb128: there you go ^ [09:41] stgraber, thanks [09:42] doko, hey, is poppler blocking anything? why do we need to jump on a workaround, making our pdf rendering slower, rather than fixing the issue, [09:42] ? [09:42] doko, I started looking at the issue yesterday, why can't it wait a day for us to fix it? [09:43] seb128, yes, it is blocking sensible results from the test rebuild [09:43] could we perhaps put the -O0 poppler into the test rebuild PPA only? [09:44] right, I was going to say [09:44] pitti, why? [09:44] to hide the issue? [09:44] doko, because that's a workaround [09:44] you are hidding the issue by using -O0 [09:44] making our pdf rendering slower on the way [09:44] doko: well, -O0 is obviously not a solution, that hides the issue as well [09:44] now at least the rebuild did uncover a missing -fPIC [09:44] it was just an idea [09:45] doko, how did the rebuild uncover things when poppler isn't built/published yet? [09:45] build failure [09:45] https://launchpad.net/ubuntu/+source/poppler/0.24.5-0ubuntu2 [09:45] it ftfbs [09:45] well done doko [09:45] seb128, you didn't listen. it happens with both versions [09:46] what changed? [09:46] poppler built some days ago [09:46] pitti: yesterday I spent a day trying to make some progress with this issue. just to have to hear that "Not sure that's a poppler issue" without any futher evidence [09:47] doko, I tried to build gdb-doc in a trusty fresh pbuilder without proposed yesterday evening and I hit the same build issue [09:47] doko, you said the issue was new to the new poppler [09:47] so I'm not sure I understand your description of the issue anymore [09:48] doko, please revert the -O0 hack in the archive, we need to fix that bug properly [09:49] Laney, thanks [09:49] yw [09:49] seb128, no. the bug affects everything which is newly uploaded [09:50] doko, what bug are we talking about? the poppler/tex one? or the fPIC thing? [09:50] sorry I'm slightly confused [09:50] seb128, better spend some time why the Poppler-0.18.o is built without either -fPIC nor -fPIE [09:51] doko, what makes me say it's not poppler is that https://launchpadlibrarian.net/162010028/buildlog_ubuntu-trusty-i386.gdb-doc_7.6.1-1_UPLOADING.txt.gz [09:52] doko, that package used to build and it fails now in trusty with the exact same version [09:52] same binaries, there was no rebuild in between [09:52] libpoppler43 i386 0.24.3-0ubuntu12 [09:52] your analysis is flawed. take a step back and calm down please [09:52] how is it flawed? [09:53] poppler 0.24.3-0ubuntu12 on jan 08, gdb-doc built fine [09:54] poppler 0.24.3-0ubuntu12 on jan 28, gdb-doc fails to build [09:54] (tested in a fresh pbuilder yesterday as said) [09:54] how can it be poppler creating tex issues if poppler didn't change? [09:56] doko, ? [09:57] seb128: is this not related to the poppler in trusty-proposed? [09:57] slangasek, no, as said to doko twice, I get the same issue rebuilding gdb-doc using a trusty fresh pbuilder without proposed [09:57] hey [09:57] seb128: ah [09:58] slangasek, using 0.24.3-0ubuntu12 which was used in the success rebuilds from jan 08 [09:58] * slangasek nods [09:58] slangasek, doko: that fPIC issue with today rebuild looks like it's probably a new issue due to gobject-instrospection (that got updated yesterday in trusty) [09:59] not a poppler bug imho, I fail to see how the -O0 hack would have lead to that [09:59] shrug [10:00] slangasek, please talk to doko, jumping on such hacks isn't helping us, we should fix the real issue with tex and not try to workaround build doing poppler -O0 rebuild hacks [10:00] that's just hiding issue and leaving us with performance regressions and hacks to clean up later [10:00] right, I think that's clear [10:01] thanks [10:04] seb128: g-i is stuck in -proposed due to a transient amd64 VM failure; I take it I should NOT retry this for now, to keep it in -proposed until this is examined? [10:04] hey guys, when I accidently hit enter on a tv show I am watching in Nautilus, it spawns a second movie player. Is that behaviour intentional?\ [10:05] seb128: (I mean the failed umockdev autopkgtest on amd64) [10:05] pitti, well, I'm just random guessing there [10:05] pitti, but that seems a likely candidate, since the fPIC issue happens in g-i commands and the same poppler built less a week ago [10:06] seb128: ok; let's leave it in -proposed for now, it's not urgent [10:06] pitti, I doubt -O2 -> -O0 is creating that issue [10:06] pitti, danke [10:06] right, but I thought there were two different ones [10:06] "different ones"? [10:07] we have tex issues, that doko is blaming poppler for, he uploaded a poppler rebuild using -O0 to workaround those [10:07] I mean the missing -fPIC is unrelated to the -O0 bug (whatever that is, I didn't look into logs) [10:07] that rebuild is failing now though because of the g-i fPIC thing on arm* [10:07] right [10:33] zyga, hi, is there any plan to update command-not-found? I'd like to see bug 1029204 fixed in trusty [10:33] bug 1029204 in command-not-found (Ubuntu) "locale.Error: unsupported locale setting" [High,Fix committed] https://launchpad.net/bugs/1029204 [10:33] doko, slangasek: Unpacking texlive-latex-recommended (2013.20131219-1) over (2013.20140123-1) ... [10:33] doko, that downgrade fixes the gdb-doc build in a trusty pbuilder for me [10:46] ypwong: hey [10:46] ypwong: hmm, that's a *very* good question [10:46] ypwong: I'm okay with fixing trunk, I have no upload rights [10:47] ypwong: and the project doesn't have releases upstream that get packaged, it was all handled by mvo before he left [10:47] ypwong: I'd like to work together to fix issues somehow, just not sure how [10:48] zyga, ah ok, I think we could use some help from ubuntu developers here? [10:48] ypwong: indeed, I'm just unsure how [10:48] ypwong: one thing that could be done is a entirely new upstream release [10:49] ypwong: before it was all somehow fluid, without real releases [10:49] this is a native package, there's not really another upstream [10:50] pitti: but I have no rights to upload it [10:50] pitti: what would be your recommendation? [10:50] Vcs-Bzr: doesn't exist any more either, so I suppose that tag should be dropped [10:50] pitti: I was thinking about making it non-native [10:50] zyga: err, why? [10:50] pitti, you can unblock the g-i update, turned out that the poppler ftbfs was because the -O0 hack from doko was buggy and nuked the hardening flags from the build [10:50] pitti: just because I know that workflow better, I might propose it to debian [10:51] pitti: and really handle the software, not the distribution part [10:51] zyga: c-n-f is also in Debian [10:51] but it's still a native package [10:51] pitti: the same one or different? [10:51] (but Debian's is much older) [10:51] command-not-found | 0.3ubuntu8 | trusty | source, all [10:51] pitti: I see [10:51] command-not-found | 0.2.38-1 | sid | source, all [10:51] (well suse has c-n-f but entirely different (just named the same) [10:51] 0 [10:51] ) [10:52] debian one has not been updated since 2009.. [10:54] one problem is that it's really tied to the archive so whoever really maintains it needs to have a loop that rebuilds the hint database basically, every week, and uploads on any change [10:54] zyga: so I recommend branching off UDD, updating it, and proposing a merge, so that it'll go via the sponsoring queue [10:54] yeah, and it should be updated for trusty, too; I suppose that there's some command in it to do it [10:55] pitti: it's non-trivial, I had several failed attempts to rewrite it entirely to make it easier to maintain but I never had enough time === _salem is now known as salem_ [10:58] seb128: right - though even though it was the tex upgrade that triggered the regression... how could rebuilding poppler with -O0 work around a tex bug? The root bug must be in poppler or the compiler anyway, because a -O0 rebuild doesn't change any of the library interfaces [11:00] slangasek, right, -O0 working says compiler bug to me [11:00] seb128: indeterminate; it could be either a compiler bug or a poppler bug [11:01] slangasek, right, in any case it's not a bug in the new poppler [11:01] correct [11:01] it's already there in the 0.24.3 binaries === JanC is now known as Guest97920 === MacSlow is now known as MacSlow|lunch [12:35] is anyone else getting a "Connection Refused" error from upload.ubuntu.com when dputting ? [12:38] it's being upgraded, see #ubuntu-release [12:40] Laney, yup, #is told me [12:42] hmm, I'm trying to link to a copyright file on packages.ubuntu.com [12:42] specifically to http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.3/python3.3_3.3.1-1ubuntu5.2/python3.3.copyright [12:42] but it seems that all copyright files are 404 [12:42] is this expected? [12:43] similar link works fine on packages.debian.org [12:43] http://metadata.ftp-master.debian.org/changelogs//main/p/python3.3/python3.3_3.3.3-5_copyright === Sweetsha1k is now known as Sweetshark [13:12] doko: hello! Could you help me how to interpret this failure here? https://launchpadlibrarian.net/164023960/buildlog_ubuntu-trusty-i386.xorg-server_2%3A1.14.5-1ubuntu3_FAILEDTOBUILD.txt.gz [13:12] doko: it builds fine on all other architectures === j_f-f_ is now known as j_f-f [13:21] barry: http://bazaar.launchpad.net/~xnox/autopilot/1.4+slow+rexec/view/head:/debian/rules#L36 [13:21] barry: see changes to override_dh_install, line 39 onwards [13:37] barry: http://paste.ubuntu.com/6837865/ [13:55] sil2100, https://bugs.launchpad.net/bugs/1266492 [13:55] Ubuntu bug 1266492 in xorg-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Triaged] [13:55] doko: thanks! [13:55] I didn't look yet into his arguments about glibc [13:57] dpm, shadeslayer: you need to ping danilo to re-review [14:03] sil2100, replied to the issue. I think sbeattie's proposed fixes are the right thing to do [14:13] mlankhorst: re bug 1205643: why me? (apart from that I wanted to ask you about the status, but didn't) [14:13] bug 1205643 in xserver-xorg-video-openchrome (Ubuntu Saucy) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy & 12.04.4 candidate" [Low,In progress] https://launchpad.net/bugs/1205643 [14:17] mitya57: oh woops :P since you targeted it for saucy [14:18] but I'll set it to the person arguing for it [14:18] Ah, I of course did. [14:18] there ya go [14:19] I can help with paperwork, but I don't get it so can't test it and don't know impact [14:20] naw don't worry [14:20] it's a test, alternative was closing it WONTFIX ;) [14:44] can someone bump teh build score of lxc-android-config ... seems to sit since ages in "needs build" [14:45] ogra_: done [14:45] thanks :) === freeflying is now known as freeflying_away [15:07] RAOF, mlankhorst: hi guys, I need someone that's a xorg-server maintainer [15:08] how does one register URL handlers now? [15:08] sil2100: ¿ [15:09] nevermind [15:09] mlankhorst: so, there is this: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 [15:09] Ubuntu bug 1266492 in xorg-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Triaged] [15:09] mlankhorst: we needed to rebuild xorg-server for the Mir release, but it fails to build from source for i386 because of this problem [15:10] mlankhorst: you can see the failure here: https://launchpadlibrarian.net/164023960/buildlog_ubuntu-trusty-i386.xorg-server_2%3A1.14.5-1ubuntu3_FAILEDTOBUILD.txt.gz [15:12] mlankhorst: doko recommended to use the fix from the bug report mentioned, but I think it first needs to be discussed with you guys [15:26] pitti: any idea why the retracer would mark my bug as a dup of another one, when the "StacktraceTop" is different? [15:26] Hi, do we have automated tests for the precise+LTS HWE stack-to-trusty upgrade? [15:26] naw [15:27] dobey, how different is the stacktrace? the signature is only on a few functions [15:27] dobey, is the top of the bt identical? [15:28] dobey: hm, does the bug has a DuplicateSignature: field, or an identical StacktraceAddressSignature: [15:28] ? [15:28] seb128: no, the first two functions in the trace are from a different library [15:28] smagoun: what do you want to test? :P [15:28] dobey: or, easier question, what's the dup and master bug? [15:28] dobey, is that an abort() bug? [15:29] seb128: i don't know if my bug was in an abort() [15:29] dobey, what pitti said I guess, bug number would be useful [15:29] pitti: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1273920 and https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1153365 [15:29] Ubuntu bug 1153365 in evolution (Ubuntu) "duplicate for #1273920 evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed] [15:29] mlankhorst: I have a system with 12.04 + the -lts-quantal stack, and I want to upgrade to 14.04. Update Manager says that it can't do that due to dependency problems. I was going to look at the test results (if they exist) to see if that's a known issue [15:29] Ubuntu bug 1153365 in evolution (Ubuntu) "evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed] [15:29] dobey: need to run out for a bit, but I'll have a look later [15:29] dobey, it is, the title states sigabrt [15:29] oh yeah, it is an abrt [15:30] smagoun: do you have 32-bits libs by any chance? [15:30] mlankhorst: I might, let me check [15:30] seb128: but the bug it was marked a dup of is against evo 3.6 on 13.04 (which is now EOL, so that bug will probably just be closed anyway), and i never had this problem when i was on 13.04 :( [15:30] smagoun: hm can't upgrade to 14.04 for now, all the lts-packages need to be uninstalled manually [15:31] or even on 13.10 [15:31] mlankhorst: yep, lots of 32-bit libs [15:31] only very recently on trusty [15:31] dobey, I think it's matching abort messages, which is wrong in that case [15:32] mlankhorst: uninstalled manually? that sounds painful. Do you know if there is a plan to create an upgrade path that does not require uninstalling? [15:32] I need to add a whole bunch of transitional packages to 'xorg' for that to work. :P [15:32] mlankhorst: what sort of bribe do you require for that? beer? testing? something else? :) [15:33] dobey, one way to "workaround" it is to tag the old bug "apport-request-retrace" to get a new retrace, submit again, then undup and point to the new retrace output [15:33] They don't necessarily have to be in that package [15:33] smagoun: hm some ass kicking probably [15:33] mlankhorst, fyi, 14.04 already have -lts-quantal|raring|saucy packages for kernel [15:33] if you want to keep xorg clean-ish, introduce -lts-whatever packages that are transitional [15:33] Laney: yeah that's the plan [15:33] mlankhorst: ok, I will ask jasoncwarner to kick your ass for you :P [15:33] mlankhorst, can't you just add the proper solution suggested by sbeattie and sil2100 ? [15:34] seb128: request? or needs? === Guest12754 is now known as wedgwood [15:34] doko: the 'proper solution' is fixing ld not to crash, debian's binutils don't, I didn't chase it down but it seems to be one of the ubuntu patches [15:34] dobey, "requests" [15:34] ok [15:34] dobey, it means "next time a duplicate is retraced, attach the result there rather than cleaning it" [15:34] mlankhorst, you are plain wrong. [15:35] dobey, the needs is "needs to be retraced" (e.g didn't get picked yet) [15:35] huh [15:35] debian's binutils does behave the same way once glibc 2.18 is installed [15:35] odd [15:35] mlankhorst, so please don't paper over the issue, and fix it properly [15:35] but I don't want to debug binutils [15:36] now you even have the recipy posted in the bug report === oSoMoN_ is now known as oSoMoN [15:38] doko: I want to share the solution with debian's xorg-server and keep the delta small, they made it clear they don't want hardening-wrapper as build-dep [15:43] mlankhorst, sure, I do understand, but the way how they introudce pie support is wrong [15:43] and it will break there too once glibc from experimental is uploaded to unstable [15:44] doko, "please don't paper over the issue, and fix it properly" ... can you apply that to poppler as well? ;-) [15:44] (and I didn't look if the current i386 in ftbfs is caused by your workaraound) [15:46] jibel: could you please look into why these are fake-RUNNING http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#poppler ? [15:46] Laney, looking [15:47] seb128, feel free to fix it properly, *iff* you know how to fix it properly. until then a quick-fix which is correct but maybe slow sounds like the reight short-term solution [15:48] doko, I'm not sure downgrading performance of our default pdf renderer to fix a few build issues is "correct" [15:48] doko, I would say that those ftbfs don't create any issue atm, we don't need to rebuild today any of the packages that are failing to build in the archive rebuild [15:49] doko: oh yeah, grabbing binutils from debian and stuffing it in trusty crashes too [15:51] mlankhorst, see https://sourceware.org/ml/binutils/2014-01/msg00080.html and the upstream report for some background [15:51] sourceware.org bug 2014 in translator "cannot use backslash for escape sequences" [Normal,Resolved: fixed] === mhall119_ is now known as mhall119 [15:52] Laney, last run of britney was at 11:28:17 and results for poppler have been published at 11:43:58 so they've not been collected yet. [15:52] jibel: aha [15:52] I didn't check the timestamp [15:52] how often are those running? [15:52] thanks [15:53] it's probably because of the precise upgrade [15:53] yeah, seems everything is a bit slow today [15:54] mlankhorst, so if debian just wants to use pie, it should maybe introduced in the upstream build infrastructure explicitly. [15:54] it's some autotools silliness anyway [15:55] cjwatson, do you know why britney didn't run since 11:30 today? [15:55] that's the timestamp of the most recent log file [15:56] mlankhorst, you could build with --disable-static maybe [15:56] we already do, that's why it's autotools silliness [15:56] ahh [15:58] jibel: The archive master is being dist-upgraded to precise today [15:58] cf. #ubuntu-release backlog [15:59] Laney, ack, thanks [15:59] doko: and from that bug report, ld -static -pie is perfectly fine. glibc might not handle it correctly but -static (to ld) merely causes it to look for libfoo.a instead of libfoo.so [15:59] I forgot to check britney's timestamp [16:00] mlankhorst, well, that's one opinion, ld.gold behaves differently === mterry_ is now known as mterry [16:30] jibel: right, it's been upgraded, but the apt-ftparchive db format has changed so it's very slowly rebuilding all its caches [16:31] it'll get there ... eventually [16:32] my guess would be an ETA of about 40-50 mins until this publisher run finishes === Guest97920 is now known as JanC [16:35] Mirv: will you be able to upload my pyqt5 patch to your ppa today (to see how it goes)? [16:36] I will be offline for a couple of days starting tomorrow evening, to I would like to get the fix uploaded to archive tomorrow morning. [16:37] * mitya57 has fired up his qemu armhf pbuilder to test with 5.0, but that's going to take the whole night to build [16:38] Mirv: also, adding 1: epoch in recipe build is going to break upgrades for people using your PPA :) [16:41] charles: hi, yesterday you rejected my MP to indicator-datetime; wondering whether you spotted my reply and branch update after that (https://code.launchpad.net/~rtandy/indicator-datetime/lp976100/+merge/200209) and whether a resubmit would be appropriate [16:44] dobey: ah, apport doesn't use the original (poor) stack trace for duplication; it retraces it and then compares to the retraced one, i. e. https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1153365/comments/2 [16:44] Ubuntu bug 1153365 in evolution (Ubuntu) "evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed] [16:44] dobey: so apparently they were identical; is there evidence that it's a different bug? [16:57] stgraber: lxc-create -t download → this is golden! many thanks for that [17:08] ... publisher will take longer, we forgot about source [17:08] +40mins maybe? [17:18] Hi, is vesafb.ko missing in Trusty? Should udev-fallback-graphics get updated to `modprobe uvesa`? [17:18] $ grep vesa /etc/init/udev-fallback-graphics.conf [17:18] modprobe -q -b vesafb [17:18] $ ls /lib/modules/*/kernel/drivers/video/*vesa* [17:18] /lib/modules/3.13.0-5-generic/kernel/drivers/video/uvesafb.ko [17:19] pitti: hello! [17:19] hey sil2100 [17:19] pitti: so, it seems we're having armhf problems with your platform-api unit tests [17:19] oh? last time I tried them they still ran fine [17:20] pitti: didrocks, tvoss and lool tried to figure out what in the environment is causing the issue, but with no luck [17:20] sil2100: I can try them on the current image, do they fail now? [17:20] pitti: the problem is... [17:20] pitti: they fail only on CI and the hardware builders [17:20] pitti: they didn't fail for tvoss on the current phone [17:20] pitti: see here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5534151 [17:20] they do in launchpad non virtualized builders [17:21] and in CI [17:22] pitti: so, we actually thought that something else, some dependency changed and suddenly made it fail for armhf, but after investigation made by didrocks and other guys, it seems it's just broken somehow [17:22] pitti: it's blocking a lot of things right now ;) [17:22] err, sure that these are *non*virtualized builders? [17:22] (even without code change) [17:22] pitti: yeah, it's the distro builders [17:22] that looks like qemu emulated builders [17:22] that are used in those ppa [17:22] hum [17:22] if so, we really have an issue [17:22] ah, actually not [17:22] kishi are distro builders [17:22] ah, phew :) [17:22] the qemu failure was different [17:24] so, if tvoss already tried on the current phone, let me try on the porter box [17:24] yeah, that would worth it [17:25] trying on my nexus 4 anyway [17:26] meh, shedir's porter schroot is awfully big [17:27] not sure those things ever get cleaned up [17:29] temporary overlays would be much better [17:29] Debian's new scheme is nice [17:30] yeah, indeed [17:30] I really like how Debian's current porter boxes work, no clutter + self-service [17:31] yep, only trouble is that I often forget to clean up after myself [17:31] this conversation reminded me to end a webkit session ... [17:33] didrocks, sil2100: err, where did dbus-cpp-dev go? platform-api depends on it, but it's not in trusty any more [17:33] pitti: since the retracer isn't attaching the retraced data to my bug, i don't see a way to actually verify whether they are the same or not [17:34] pitti: IIRC, it's libdbus-cpp-dev [17:34] pitti: hah, it got changed into libdbus-cpp-dev [17:34] hm, that needs to be fixed in platform-api then [17:34] pitti: we have merges for that, thomas prepared them and we want to release that [17:34] pitti: yes, let me show it to you - but we can't release it becasue the unittests are failing [17:35] ah :) [17:35] pitti: you need this https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 and location-service from here: https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105 [17:35] anyway, building now in porter, my phone is still installing build deps [17:36] pitti: I buy you a beer if you fix the platform-api test failures on those branches === bfiller is now known as bfiller_afk [17:36] pitti: if you manage to fix it, please send me an e-mail with the merge requests - we'll add those to the landing and get everything super fixed [17:37] oh, it fails on amd64, too? [17:37] /usr/include/ubuntu-location-service-0/com/ubuntu/location/service/session/interface.h:28:40: fatal error: org/freedesktop/dbus/codec.h: No such file or directory [17:37] pitti: no, just armhf - on our PPA it was failing because of location-service (nevermind that!) [17:37] #include [17:38] it doesn't even build in current trusty :( [17:38] pitti: do you have the location-service I pointed out? [17:38] (from the merge ;) ) [17:38] sil2100: no, I'm not testing any branch, I"m currently testing the trusty package [17:38] that certainly built at some point? [17:38] pitti: yes, but dbus-cpp update broke it, and as I say - we want to fix it by releasing platform-api and location-service [17:39] pitti: but we can't as the armhf unittests fail [17:39] ah, so we landed dbus-cpp too early, or something like that? [17:39] sil2100: i. e. I should install the debs from http://jenkins.qa.ubuntu.com/job/location-service-trusty-armhf-ci/27/artifact/work/output/*zip*/output.zip ? [17:39] (armhf debs from the location-service MP) [17:40] pitti: yes, the 'rule' was that tvoss provides the fixes ASAP afterwards, but it took longer [17:41] pitti: yes, this one and code from tvoss's branch [17:41] wow, that's a lot of variables to keep track of :) [17:42] sil2100: i. e. I shouldn't build trusty's platform-api, but lp:~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform ? [17:42] (just to double-sure I understand everything) [17:43] pitti: yes :) This is the branch that is fixed for dbus-cpp [17:43] (the new one) [17:43] pitti: sorry for the confusion, this was supposed to be landed already and in the archive ;) [17:47] argh [17:47] I can't install .debs in a porter chroot [17:47] only apt-get install [17:48] hmm, ok, give me a moment [17:48] sil2100: so, I'll try on my phone, and I can also try on my shiny new toy on the calxeda node [17:48] there I have lxc and full root [17:48] pitti: ppa:ci-train-ppa-service/landing-005 use this PPA and fetch location-service from there [17:48] pitti: you can use it on your porter I guess? ;) [17:48] sil2100: I can't add PPAs either; that's a plain trusty schroot [17:48] pitti: uuuuu [17:49] ok [17:49] * pitti gives up on shedir and moves to the calxeda box [17:49] pitti: just so you know - it fails all the time on the builders and our CI, but tvoss couldn't reproduce it on his phone, so strangeness [17:50] * Mez rants and raves around the room [17:50] sil2100: builders are also calxeda nodes, so chances are high [17:51] I don't like the 9 month till EOL, btw. Not when there's a showstopper for Saucy, and someone deletes the software from a PPA I was using. Meaning I now have to host my own Apt repository somewhere. [17:52] "don't use saucy" (I'm 90% serious about that) [17:53] use precise, or use trusty [18:04] pitti: has trusty switched to Mir ? [18:04] not on the desktop (won't happen for trusty) [18:04] pitti: I might try it then - but I have a feeling the same regression is going to be there (for non-3d machines() [18:05] and precise - well - wouldn't work for us - we need more up-to date than precise (and I don't want to have to backport everything again) [18:05] sil2100: so my current suspicion is with locales [18:05] sil2100: but we need a way to reproduce this error somehow [18:06] sil2100: I dont understand where this weird float values would come from otherwise [18:06] (cosmic rays perhaps) [18:06] lool: you mean platform-api? [18:06] well, they are by and large zero [18:07] pitti: what is zero? [18:07] pitti: numbers for the precision and min max are not zero [18:07] it's like 0.5 expected and 0.1 found [18:07] oh, right, I misread it as e-31 [18:07] it's e31 [18:07] there's an e31 right [18:07]