[00:12] <infinity> YokoZar: That's rather unfortunate. :/
[00:13] <YokoZar> infinity: I find it unfortunate we've both missed the opportunity to make an epoch fail pun.
[02:58] <hyperair> w 1
[02:58] <hyperair> whoops
[05:25] <pitti> Good morning
[07:36] <pitti> 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] <pitti> stgraber: per-user containers sounds cool, is the isolation robust/strong enough by now to allow that?
[07:38] <dholbach> good morning
[08:43] <darkxst> Laney, can you add me to desktop-extras while you work on the ubuntu GNOME packageset?
[09:02] <Sweetshark> wgrant infinity cjwatson: any hints of what went wrong here: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2/+build/5530899 ?
[09:03] <Sweetshark> "failed to build", no log, happened multiple times to me in recent days.
[09:04] <wgrant> Sweetshark: Let me see
[09:04] <wgrant> 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] <seb128> wgrant, that's libreoffice you are talking about, what could go wrong ;-)
[09:05] <wgrant> Yeah, that was an upgrade issue. Retry should work.
[09:05] <wgrant> seb128: I wasn't going to say that, but yes :)
[09:05] <Sweetshark> wgrant: of course my builds are evil enough to kill builders. but usually they are in a good mood and spare them.
[09:06] <wgrant> Sometimes!
[09:07] <seb128> 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] <Sweetshark> 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] <seb128> wgrant, should I just close the launchpad bug I had open?
[09:08] <wgrant> seb128: Unless you see it again, yeah
[09:08] <seb128> wgrant, ok, doing that then
[09:09] <wgrant> Thanks
[09:12] <Laney> darkxst: righto
[09:21] <stgraber> pitti: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
[09:22] <pitti> stgraber: bonjour -- oh, you are in London, I presume?
[09:22] <stgraber> 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] <stgraber> pitti: I am indeed, core sprint
[09:26] <pitti> stgraber: ver nice!
[09:33] <shadeslayer> dpm: any news on the intltool MR?
[09:36] <seb128> shrug, doko
[09:37] <seb128> that "build poppler with -O0 is wrong"
[09:37] <seb128> that "build poppler with -O0" is wrong
[09:37] <dpm> shadeslayer, not really, no. I'd suggest pinging danilo and dobey
[09:37] <shadeslayer> dobey: ping pign
[09:37] <shadeslayer> *ping
[09:38] <seb128> stgraber, can you get doko on IRC? ;-)
[09:41] <stgraber> seb128: there you go ^
[09:41] <seb128> stgraber, thanks
[09:42] <seb128> 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] <seb128> ?
[09:42] <seb128> doko, I started looking at the issue yesterday, why can't it wait a day for us to fix it?
[09:43] <doko> seb128, yes, it is blocking sensible results from the test rebuild
[09:43] <pitti> could we perhaps put the -O0 poppler into the test rebuild PPA only?
[09:44] <seb128> right, I was going to say
[09:44] <doko> pitti, why?
[09:44] <doko> to hide the issue?
[09:44] <seb128> doko, because that's a workaround
[09:44] <seb128> you are hidding the issue by using -O0
[09:44] <seb128> making our pdf rendering slower on the way
[09:44] <pitti> doko: well, -O0 is obviously not a solution, that hides the issue as well
[09:44] <doko> now at least the rebuild did uncover a missing -fPIC
[09:44] <pitti> it was just an idea
[09:45] <seb128> doko, how did the rebuild uncover things when poppler isn't built/published yet?
[09:45] <Laney> build failure
[09:45] <seb128> https://launchpad.net/ubuntu/+source/poppler/0.24.5-0ubuntu2
[09:45] <seb128> it ftfbs
[09:45] <seb128> well done doko
[09:45] <doko> seb128, you didn't listen. it happens with both versions
[09:46] <seb128> what changed?
[09:46] <seb128> poppler built some days ago
[09:46] <doko> 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] <seb128> 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] <seb128> doko, you said the issue was new to the new poppler
[09:47] <seb128> so I'm not sure I understand your description of the issue anymore
[09:48] <seb128> doko, please revert the -O0 hack in the archive, we need to fix that bug properly
[09:49] <darkxst> Laney, thanks
[09:49] <Laney> yw
[09:49] <doko> seb128, no. the bug affects everything which is newly uploaded
[09:50] <seb128> doko, what bug are we talking about? the poppler/tex one? or the fPIC thing?
[09:50] <seb128> sorry I'm slightly confused
[09:50] <doko> seb128, better spend some time why the Poppler-0.18.o is built without either -fPIC nor -fPIE
[09:51] <seb128> 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] <seb128> doko, that package used to build and it fails now in trusty with the exact same version
[09:52] <seb128> same binaries, there was no rebuild in between
[09:52] <seb128> libpoppler43 i386 0.24.3-0ubuntu12
[09:52] <doko> your analysis is flawed. take a step back and calm down please
[09:52] <seb128> how is it flawed?
[09:53] <seb128> poppler 0.24.3-0ubuntu12 on jan 08, gdb-doc built fine
[09:54] <seb128> poppler 0.24.3-0ubuntu12 on jan 28, gdb-doc fails to build
[09:54] <seb128> (tested in a fresh pbuilder yesterday as said)
[09:54] <seb128> how can it be poppler creating tex issues if poppler didn't change?
[09:56] <seb128> doko, ?
[09:57] <slangasek> seb128: is this not related to the poppler in trusty-proposed?
[09:57] <seb128> slangasek, no, as said to doko twice, I get the same issue rebuilding gdb-doc using a trusty fresh pbuilder without proposed
[09:57] <whandi> hey
[09:57] <slangasek> seb128: ah
[09:58] <seb128> slangasek, using 0.24.3-0ubuntu12 which was used in the success rebuilds from jan 08
[09:58]  * slangasek nods
[09:58] <seb128> 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] <seb128> not a poppler bug imho, I fail to see how the -O0 hack would have lead to that
[09:59] <seb128> shrug
[10:00] <seb128> 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] <seb128> that's just hiding issue and leaving us with performance regressions and hacks to clean up later
[10:00] <slangasek> right, I think that's clear
[10:01] <seb128> thanks
[10:04] <pitti> 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] <Fudge> 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] <pitti> seb128: (I mean the failed umockdev autopkgtest on amd64)
[10:05] <seb128> pitti, well, I'm just random guessing there
[10:05] <seb128> 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] <pitti> seb128: ok; let's leave it in -proposed for now, it's not urgent
[10:06] <seb128> pitti, I doubt -O2 -> -O0 is creating that issue
[10:06] <seb128> pitti, danke
[10:06] <pitti> right, but I thought there were two different ones
[10:06] <seb128> "different ones"?
[10:07] <seb128> we have tex issues, that doko is blaming poppler for, he uploaded a poppler rebuild using -O0 to workaround those
[10:07] <pitti> I mean the missing -fPIC is unrelated to the -O0 bug (whatever that is, I didn't look into logs)
[10:07] <seb128> that rebuild is failing now though because of the g-i fPIC thing on arm*
[10:07] <seb128> right
[10:33] <ypwong> zyga, hi, is there any plan to update command-not-found? I'd like to see bug 1029204 fixed in trusty
[10:33] <seb128> doko, slangasek: Unpacking texlive-latex-recommended (2013.20131219-1) over (2013.20140123-1) ...
[10:33] <seb128> doko, that downgrade fixes the gdb-doc build in a trusty pbuilder for me
[10:46] <zyga> ypwong: hey
[10:46] <zyga> ypwong: hmm, that's a *very* good question
[10:46] <zyga> ypwong: I'm okay with fixing trunk, I have no upload rights
[10:47] <zyga> ypwong: and the project doesn't have releases upstream that get packaged, it was all handled by mvo before he left
[10:47] <zyga> ypwong: I'd like to work together to fix issues somehow, just not sure how
[10:48] <ypwong> zyga, ah ok, I think we could use some help from ubuntu developers here?
[10:48] <zyga> ypwong: indeed, I'm just unsure how
[10:48] <zyga> ypwong: one thing that could be done is a entirely new upstream release
[10:49] <zyga> ypwong: before it was all somehow fluid, without real releases
[10:49] <pitti> this is a native package, there's not really another upstream
[10:50] <zyga> pitti: but I have no rights to upload it
[10:50] <zyga> pitti: what would be your recommendation?
[10:50] <pitti> Vcs-Bzr: doesn't exist any more either, so I suppose that tag should be dropped
[10:50] <zyga> pitti: I was thinking about making it non-native
[10:50] <pitti> zyga: err, why?
[10:50] <seb128> 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] <zyga> pitti: just because I know that workflow better, I might propose it to debian
[10:51] <zyga> pitti: and really handle the software, not the distribution part
[10:51] <pitti> zyga: c-n-f is also in Debian
[10:51] <pitti> but it's still a native package
[10:51] <zyga> pitti: the same one or different?
[10:51] <pitti> (but Debian's is much older)
[10:51] <pitti>  command-not-found | 0.3ubuntu8    | trusty         | source, all
[10:51] <zyga> pitti: I see
[10:51] <pitti>  command-not-found | 0.2.38-1 | sid     | source, all
[10:51] <zyga> (well suse has c-n-f but entirely different (just named the same)
[10:51] <zyga> 0
[10:51] <zyga> )
[10:52] <ypwong> debian one has not been updated since 2009..
[10:54] <zyga> 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] <pitti> zyga: so I recommend branching off UDD, updating it, and proposing a merge, so that it'll go via the sponsoring queue
[10:54] <pitti> yeah, and it should be updated for trusty, too; I suppose that there's some command in it to do it
[10:55] <zyga> 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
[10:58] <slangasek> 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] <seb128> slangasek, right, -O0 working says compiler bug to me
[11:00] <slangasek> seb128: indeterminate; it could be either a compiler bug or a poppler bug
[11:01] <seb128> slangasek, right, in any case it's not a bug in the new poppler
[11:01] <slangasek> correct
[11:01] <seb128> it's already there in the 0.24.3 binaries
[12:35] <ogra_> is anyone else getting a "Connection Refused" error from upload.ubuntu.com when dputting ?
[12:38] <Laney> it's being upgraded, see #ubuntu-release
[12:40] <ogra_> Laney, yup, #is told me
[12:42] <zyga> hmm, I'm trying to link to a copyright file on packages.ubuntu.com
[12:42] <zyga> specifically to http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.3/python3.3_3.3.1-1ubuntu5.2/python3.3.copyright
[12:42] <zyga> but it seems that all copyright files are 404
[12:42] <zyga> is this expected?
[12:43] <zyga> similar link works fine on packages.debian.org
[12:43] <zyga> http://metadata.ftp-master.debian.org/changelogs//main/p/python3.3/python3.3_3.3.3-5_copyright
[13:12] <sil2100> 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] <sil2100> doko: it builds fine on all other architectures
[13:21] <xnox> barry: http://bazaar.launchpad.net/~xnox/autopilot/1.4+slow+rexec/view/head:/debian/rules#L36
[13:21] <xnox> barry: see changes to override_dh_install, line 39 onwards
[13:37] <xnox> barry: http://paste.ubuntu.com/6837865/
[13:55] <doko> sil2100, https://bugs.launchpad.net/bugs/1266492
[13:55] <sil2100> doko: thanks!
[13:55] <doko> I didn't look yet into his arguments about glibc
[13:57] <dobey> dpm, shadeslayer: you need to ping danilo to re-review
[14:03] <doko> sil2100, replied to the issue. I think sbeattie's proposed fixes are the right thing to do
[14:13] <mitya57> mlankhorst: re bug 1205643: why me? (apart from that I wanted to ask you about the status, but didn't)
[14:17] <mlankhorst> mitya57: oh woops :P since you targeted it for saucy
[14:18] <mlankhorst> but I'll set it to the person arguing for it
[14:18] <mitya57> Ah, I of course did.
[14:18] <mlankhorst> there ya go
[14:19] <mitya57> I can help with paperwork, but I don't get it so can't test it and don't know impact
[14:20] <mlankhorst> naw don't worry
[14:20] <mlankhorst> it's a test, alternative was closing it WONTFIX ;)
[14:44] <ogra_> can someone bump teh build score of lxc-android-config ... seems to sit since ages in "needs build"
[14:45] <cjwatson> ogra_: done
[14:45] <ogra_> thanks :)
[15:07] <sil2100> RAOF, mlankhorst: hi guys, I need someone that's a xorg-server maintainer
[15:08] <dobey> how does one register URL handlers now?
[15:08] <mlankhorst> sil2100: ¿
[15:09] <dobey> nevermind
[15:09] <sil2100> mlankhorst: so, there is this: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492
[15:09] <sil2100> 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] <sil2100> 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] <sil2100> 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] <dobey> pitti: any idea why the retracer would mark my bug as a dup of another one, when the "StacktraceTop" is different?
[15:26] <smagoun> Hi, do we have automated tests for the precise+LTS HWE stack-to-trusty upgrade?
[15:26] <mlankhorst> naw
[15:27] <seb128> dobey, how different is the stacktrace? the signature is only on a few functions
[15:27] <seb128> dobey, is the top of the bt identical?
[15:28] <pitti> dobey: hm, does the bug has a DuplicateSignature: field, or an identical StacktraceAddressSignature:
[15:28] <pitti> ?
[15:28] <dobey> seb128: no, the first two functions in the trace are from a different library
[15:28] <mlankhorst> smagoun: what do you want to test? :P
[15:28] <pitti> dobey: or, easier question, what's the dup and master bug?
[15:28] <seb128> dobey, is that an abort() bug?
[15:29] <dobey> seb128: i don't know if my bug was in an abort()
[15:29] <seb128> dobey, what pitti said I guess, bug number would be useful
[15:29] <dobey> pitti: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1273920 and https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1153365
[15:29] <smagoun> 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] <pitti> dobey: need to run out for a bit, but I'll have a look later
[15:29] <seb128> dobey, it is, the title states sigabrt
[15:29] <dobey> oh yeah, it is an abrt
[15:30] <mlankhorst> smagoun: do you have 32-bits libs by any chance?
[15:30] <smagoun> mlankhorst: I might, let me check
[15:30] <dobey> 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] <mlankhorst> smagoun: hm can't upgrade to 14.04 for now, all the lts-packages need to  be uninstalled manually
[15:31] <dobey> or even on 13.10
[15:31] <smagoun> mlankhorst: yep, lots of 32-bit libs
[15:31] <dobey> only very recently on trusty
[15:31] <seb128> dobey, I think it's matching abort messages, which is wrong in that case
[15:32] <smagoun> 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] <mlankhorst> I need to add a whole bunch of transitional packages to 'xorg' for that to work. :P
[15:32] <smagoun> mlankhorst: what sort of bribe do you require for that? beer? testing? something else? :)
[15:33] <seb128> 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] <Laney> They don't necessarily have to be in that package
[15:33] <mlankhorst> smagoun: hm some ass kicking probably
[15:33] <diwic> mlankhorst, fyi, 14.04 already have -lts-quantal|raring|saucy packages for kernel
[15:33] <Laney> if you want to keep xorg clean-ish, introduce -lts-whatever packages that are transitional
[15:33] <mlankhorst> Laney: yeah that's the plan
[15:33] <smagoun> mlankhorst: ok, I will ask jasoncwarner to kick your ass for you :P
[15:33] <doko> mlankhorst, can't you just add the proper solution suggested by sbeattie and sil2100 ?
[15:34] <dobey> seb128: request? or needs?
[15:34] <mlankhorst> 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] <seb128> dobey, "requests"
[15:34] <dobey> ok
[15:34] <seb128> dobey, it means "next time a duplicate is retraced, attach the result there rather than cleaning it"
[15:34] <doko> mlankhorst, you are plain wrong.
[15:35] <seb128> dobey, the needs is "needs to be retraced" (e.g didn't get picked yet)
[15:35] <dobey> huh
[15:35] <doko> debian's binutils does behave the same way once glibc 2.18 is installed
[15:35] <mlankhorst> odd
[15:35] <doko> mlankhorst, so please don't paper over the issue, and fix it properly
[15:35] <mlankhorst> but I don't want to debug binutils
[15:36] <doko> now you even have the recipy posted in the bug report
[15:38] <mlankhorst> 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] <doko> mlankhorst, sure, I do understand, but the way how they introudce pie support is wrong
[15:43] <doko> and it will break there too once glibc from experimental is uploaded to unstable
[15:44] <seb128> doko, "please don't paper over the issue, and fix it properly" ... can you apply that to poppler as well? ;-)
[15:44] <doko> (and I didn't look if the current i386 in ftbfs is caused by your workaraound)
[15:46] <Laney> 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] <jibel> Laney, looking
[15:47] <doko> 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] <seb128> doko, I'm not sure downgrading performance of our default pdf renderer to fix a few build issues is "correct"
[15:48] <seb128> 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] <mlankhorst> doko: oh yeah, grabbing binutils from debian and stuffing it in trusty crashes too
[15:51] <doko> mlankhorst, see https://sourceware.org/ml/binutils/2014-01/msg00080.html and the upstream report for some background
[15:52] <jibel> 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] <Laney> jibel: aha
[15:52] <Laney> I didn't check the timestamp
[15:52] <seb128> how often are those running?
[15:52] <Laney> thanks
[15:53] <Laney> it's probably because of the precise upgrade
[15:53] <ogra_> yeah, seems everything is a bit slow today
[15:54] <doko> mlankhorst, so if debian just wants to use pie, it should maybe introduced in the upstream build infrastructure explicitly.
[15:54] <mlankhorst> it's some autotools silliness anyway
[15:55] <jibel> cjwatson, do you know why britney didn't run since 11:30 today?
[15:55] <jibel> that's the timestamp of the most recent log file
[15:56] <doko> mlankhorst, you could build with --disable-static maybe
[15:56] <mlankhorst> we already do, that's why it's autotools silliness
[15:56] <doko> ahh
[15:58] <Laney> jibel: The archive master is being dist-upgraded to precise today
[15:58] <Laney> cf. #ubuntu-release backlog
[15:59] <jibel> Laney, ack, thanks
[15:59] <mlankhorst> 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] <Laney> I forgot to check britney's timestamp
[16:00] <doko> mlankhorst, well, that's one opinion, ld.gold behaves differently
[16:30] <cjwatson> 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] <cjwatson> it'll get there ... eventually
[16:32] <cjwatson> my guess would be an ETA of about 40-50 mins until this publisher run finishes
[16:35] <mitya57> Mirv: will you be able to upload my pyqt5 patch to your ppa today (to see how it goes)?
[16:36] <mitya57> 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] <mitya57> Mirv: also, adding 1: epoch in recipe build is going to break upgrades for people using your PPA :)
[16:41] <tarpman> 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] <pitti> 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] <pitti> dobey: so apparently they were identical; is there evidence that it's a different bug?
[16:57] <pitti> stgraber: lxc-create -t download → this is golden! many thanks for that
[17:08] <cjwatson> ... publisher will take longer, we forgot about source
[17:08] <cjwatson> +40mins maybe?
[17:18] <alkisg> Hi, is vesafb.ko missing in Trusty? Should udev-fallback-graphics get updated to `modprobe uvesa`?
[17:18] <alkisg> $ grep vesa /etc/init/udev-fallback-graphics.conf
[17:18] <alkisg>         modprobe -q -b vesafb
[17:18] <alkisg> $ ls /lib/modules/*/kernel/drivers/video/*vesa*
[17:18] <alkisg> /lib/modules/3.13.0-5-generic/kernel/drivers/video/uvesafb.ko
[17:19] <sil2100> pitti: hello!
[17:19] <pitti> hey sil2100
[17:19] <sil2100> pitti: so, it seems we're having armhf problems with your platform-api unit tests
[17:19] <pitti> oh? last time I tried them they still ran fine
[17:20] <sil2100> pitti: didrocks, tvoss and lool tried to figure out what in the environment is causing the issue, but with no luck
[17:20] <pitti> sil2100: I can try them on the current image, do they fail now?
[17:20] <sil2100> pitti: the problem is...
[17:20] <sil2100> pitti: they fail only on CI and the hardware builders
[17:20] <didrocks> pitti: they didn't fail for tvoss on the current phone
[17:20] <sil2100> pitti: see here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5534151
[17:20] <didrocks> they do in launchpad non virtualized builders
[17:21] <didrocks> and in CI
[17:22] <sil2100> 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] <sil2100> pitti: it's blocking a lot of things right now ;)
[17:22] <pitti> err, sure that these are *non*virtualized builders?
[17:22] <didrocks> (even without code change)
[17:22] <didrocks> pitti: yeah, it's the distro builders
[17:22] <pitti> that looks like qemu emulated builders
[17:22] <didrocks> that are used in those ppa
[17:22] <didrocks> hum
[17:22] <didrocks> if so, we really have an issue
[17:22] <pitti> ah, actually not
[17:22] <Laney> kishi are distro builders
[17:22] <didrocks> ah, phew :)
[17:22] <pitti> the qemu failure was different
[17:24] <pitti> so, if tvoss already tried on the current phone, let me try on the porter box
[17:24] <didrocks> yeah, that would worth it
[17:25] <pitti> trying on my nexus 4 anyway
[17:26] <pitti> meh, shedir's porter schroot is awfully big
[17:27] <Laney> not sure those things ever get cleaned up
[17:29] <pitti> temporary overlays would be much better
[17:29] <Laney> Debian's new scheme is nice
[17:30] <pitti> yeah, indeed
[17:30] <pitti> I really like how Debian's current porter boxes work, no clutter + self-service
[17:31] <Laney> yep, only trouble is that I often forget to clean up after myself
[17:31] <Laney> this conversation reminded me to end a webkit session ...
[17:33] <pitti> didrocks, sil2100: err, where did dbus-cpp-dev go? platform-api depends on it, but it's not in trusty any more
[17:33] <dobey> 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] <didrocks> pitti: IIRC, it's libdbus-cpp-dev
[17:34] <sil2100> pitti: hah, it got changed into libdbus-cpp-dev
[17:34] <pitti> hm, that needs to be fixed in platform-api then
[17:34] <sil2100> pitti: we have merges for that, thomas prepared them and we want to release that
[17:34] <sil2100> pitti: yes, let me show it to you - but we can't release it becasue the unittests are failing
[17:35] <pitti> ah :)
[17:35] <sil2100> 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] <pitti> anyway, building now in porter, my phone is still installing build deps
[17:36] <sil2100> pitti: I buy you a beer if you fix the platform-api test failures on those branches
[17:36] <sil2100> 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] <pitti> oh, it fails on amd64, too?
[17:37] <pitti> /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] <sil2100> pitti: no, just armhf - on our PPA it was failing because of location-service (nevermind that!)
[17:37] <pitti>  #include <org/freedesktop/dbus/codec.h>
[17:38] <pitti> it doesn't even build in current trusty :(
[17:38] <sil2100> pitti: do you have the location-service I pointed out?
[17:38] <sil2100> (from the merge ;) )
[17:38] <pitti> sil2100: no, I'm not testing any branch, I"m currently testing the trusty package
[17:38] <pitti> that certainly built at some point?
[17:38] <sil2100> 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] <sil2100> pitti: but we can't as the armhf unittests fail
[17:39] <pitti> ah, so we landed dbus-cpp too early, or something like that?
[17:39] <pitti> 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] <pitti> (armhf debs from the location-service MP)
[17:40] <sil2100> pitti: yes, the 'rule' was that tvoss provides the fixes ASAP afterwards, but it took longer
[17:41] <sil2100> pitti: yes, this one and code from tvoss's branch
[17:41] <pitti> wow, that's a lot of variables to keep track of :)
[17:42] <pitti> 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] <pitti> (just to double-sure I understand everything)
[17:43] <sil2100> pitti: yes :) This is the branch that is fixed for dbus-cpp
[17:43] <sil2100> (the new one)
[17:43] <sil2100> pitti: sorry for the confusion, this was supposed to be landed already and in the archive ;)
[17:47] <pitti> argh
[17:47] <pitti> I can't install .debs in a porter chroot
[17:47] <pitti> only apt-get install
[17:48] <sil2100> hmm, ok, give me a moment
[17:48] <pitti> sil2100: so, I'll try on my phone, and I can also try on my shiny new toy on the calxeda node
[17:48] <pitti> there I have lxc and full root
[17:48] <sil2100> pitti: ppa:ci-train-ppa-service/landing-005 use this PPA and fetch location-service from there
[17:48] <sil2100> pitti: you can use it on your porter I guess? ;)
[17:48] <pitti> sil2100: I can't add PPAs either; that's a plain trusty schroot
[17:48] <sil2100> pitti: uuuuu
[17:49] <sil2100> ok
[17:49]  * pitti gives up on shedir and moves to the calxeda box
[17:49] <sil2100> 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] <pitti> sil2100: builders are also calxeda nodes, so chances are high
[17:51] <Mez> 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] <pitti> "don't use saucy" (I'm 90% serious about that)
[17:53] <pitti> use precise, or use trusty
[18:04] <Mez> pitti: has trusty switched to Mir ?
[18:04] <pitti> not on the desktop (won't happen for trusty)
[18:04] <Mez> 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] <Mez> 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] <lool> sil2100: so my current suspicion is with locales
[18:05] <lool> sil2100: but we need a way to reproduce this error somehow
[18:06] <lool> sil2100: I dont understand where this weird float values would come from otherwise
[18:06] <lool> (cosmic rays perhaps)
[18:06] <pitti> lool: you mean platform-api?
[18:06] <pitti> well, they are by and large zero
[18:07] <lool> pitti: what is zero?
[18:07] <lool> pitti: numbers for the precision and min max are not zero
[18:07] <lool> it's like 0.5 expected and 0.1 found
[18:07] <pitti> oh, right, I misread it as e-31
[18:07] <pitti> it's e31
[18:07] <lool> there's an e31 right
[18:07] <pitti> lool: I'm currently trying to reproduce https://launchpadlibrarian.net/164031765/buildlog_ubuntu-trusty-armhf.platform-api_0.20%2B14.04.20140129.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:07] <pitti> lool: I guess that's the same error
[18:07] <lool> yes
[18:07] <pitti> that you are talking about?
[18:08] <stgraber> pitti: glad you like it :)
[18:08] <pitti> it's takes a while to install all those changed debs and branches, but building now
[18:08] <lool> cool
[18:10] <pitti> lool, sil2100, didrocks: reproduces perfectly here
[18:11] <sil2100> pitti:
[18:11] <sil2100> \o/
[18:12] <sil2100> pitti: by reproduces you mean, it fails?
[18:12] <pitti> yes, with pretty much exactly the same numbers AFAICS
[18:12] <pitti> 1: Value of: ua_sensors_accelerometer_get_min_value(s)
[18:12] <pitti> 1:   Actual: 1.9283833e+31
[18:12] <pitti> 1: Expected: 0.5
[18:12] <pitti> now hte build on my phone finished as well
[18:13] <pitti> same failure
[18:13] <sil2100> So it seems tvoss had a golden phone
[18:14] <sil2100> pitti: if you would manage to fix it, as I said - could you send me an e-mail with the merge request? I'll add it to the landing and release it ASAP ;)
[18:14] <sil2100> pitti: thanks in advance!
[18:14] <pitti> sil2100: yes, but probably not today any more, it's late
[18:15] <sil2100> pitti: let's connect tomorrow then
[18:15] <pitti> but for comparison I'll re-try the current trusty version and fish out the old dbus-cpp debs
[18:26] <pitti> sil2100, lool, didrocks: fun that the really complicated tests (the events, which use the timers and so on) still succeed..
[18:26] <pitti> sil2100, didrocks, lool: I have a hunch
[18:26] <pitti> this smells like something recently changed the float API?
[18:26] <pitti> that would explain the weird numbers
[18:27] <didrocks> pitti: yeah, -1.xxxxx
[18:28] <pitti> ricmm mentioned something like changing the platform-api to move from returning floats to something else
[18:29] <pitti> didrocks: how do you mean -1.xxx?
[18:29] <ricmm> I havent changed it yet
[18:29] <pitti> but it's definitively the functions that return floats that now act up
[18:29] <ogra_> probably your thinking about it broke it already
[18:29] <ricmm> but you arent going over hybris, so why would it break?
[18:30] <pitti> well, AFAICS tvoss' branch still uses aapcs for both
[18:30] <pitti> so that should be fine
[18:30] <ricmm> everything is still aapcs
[18:30] <pitti> ok, my build of current trusty platform-api just finished, same result
[18:31] <pitti> so it's not due to new libdbus-cpp or https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105
[18:32] <didrocks> pitti: sorry, people try to ddos me with pings IRL and IRC it seems, can't find the link :)
[18:32] <didrocks> (with the weird float results)
[18:33] <pitti> is there a bug for this, BTW? (just in case I want to drop some notes)
[18:41] <pitti> see you tomorrow, need to call it a day now
[20:22] <didrocks> pitti: not that I know of
[20:54] <smoser> anyone know how i can easily get -Zgzip passed throug to dpkg-deb when invoked as 'debuild' ?
[20:55] <smoser> (no, it wasn't a trick question).
[20:55] <smoser> the answer is debuild -Zgzip.
[20:55] <smoser> duh
[20:59] <smoser> hm.. maybe not. seems like it didn't actually change anything
[21:03] <infinity> smoser: By altering debian/rules.
[21:03] <smoser> more hint ?
[21:03] <infinity> Depends on the rules. :P
[21:04] <infinity> But dh_builddeb -- -Zgzip or similar seems likely.
[21:04] <infinity> Is there a reason you don't love xz?
[21:05]  * Logan_ subtly pokes infinity again about netcdf
[21:05] <infinity> Logan_: Sorry, we're firefighting today.  Try again later? ;)
[21:05] <Logan_> also xz is wonderful
[21:05] <Logan_> damn it :P
[21:06] <Logan_> what happened?
[21:06] <tarpman> smoser: debuild -Zgzip probably did something, but to dpkg-source rather than dpkg-deb
[21:06] <infinity> Logan_: We broke the archive a little bit, that's all.
[21:06] <Logan_> casual
[21:06] <smoser> tarpman, yeah, you're right.
[21:06] <smoser> http://paste.ubuntu.com/6840144/ is why i don't like xz
[21:07] <smoser> my debian/rules == /usr/share/doc/debhelper/examples/rules.tiny
[21:10] <tarpman> smoser: http://paste.ubuntu.com/6840152/ implements what infinity suggested above; works for me in lucid schroot
[21:11] <smoser> yeah. thanks tarpman. i had just come to that.
[21:26] <GunnarHj> slangasek: ping?
[21:28] <Logan_> infinity: were all i386 builds turned back over to the buildds or something?
[22:15] <slangasek> GunnarHj: hi
[22:16] <GunnarHj> Hi Steve!
[22:16] <GunnarHj> Just wondering if you have noticed Skype 4.2.0.13.
[22:19] <GunnarHj> slangasek: It's the latest Linux version on the Skype site.
[22:20] <slangasek> GunnarHj: the skype package is in partner; updates to it are made at the request of the partner in question
[22:21] <GunnarHj> slangasek: So you wouldn't just take the latest without Skype asking for it?
[22:21] <slangasek> GunnarHj: not generally
[22:22] <GunnarHj> slangasek: I see. This is the changelog: https://community.skype.com/t5/Linux/Skype-Linux-changelog/m-p/2878795/highlight/true#M8660
[22:44] <Logan_> does anyone know how to force system libtool on a package that uses libtool.m4?
[23:31] <cjwatson> Logan_: we retried everything that had gone into chrootwait.  but if you're asking about the huge i386 build queue, that's a test rebuild in a copy archive