[01:05] <Noskcaj> Is anyone able to sponsor a few things for xubuntu?
[01:07] <Noskcaj> bug 1282734 and bug 1282937
[01:17] <LinuxPC> xnox????
[01:19] <infinity> LinuxPC: It's 1:20am Monday morning for xnox, there's a fair chance he's not around.
[01:21] <LinuxPC> oh, ok, I didn't know what time it is where he is.
[01:21] <infinity> LinuxPC: London.
[01:21] <jtaylor> infinity: can you build glibc without optimizations?
[01:21] <jtaylor> I tried just replacing O2 with O0 and it complained cannot build without optimizations
[01:22] <infinity> jtaylor: Dunno, never tried.  It could be a mismatch of -O and -DFORTIFY that's tripping you up.
[01:23] <jtaylor> it was an actual error message telling me I need to optimize
[01:23] <jtaylor> but I wonder how do you debug it properly then
[01:24] <infinity> jtaylor: Right, but what was the error message?  -DFORTIFY_SOURCE will yell at you at -O0, I believe.
[01:24] <jtaylor> hm ok, I'll try without fortify thx
[01:25] <infinity> Most people, I believe, debug it by getting good at reading optimized gdb backtraces, since an -O0 build would be sufficiently different from -O2 to not always be helpful.
[01:26] <jtaylor> I'm reasonably familiar with it too by now but for some code its just much faster to ahve O0 code
[01:26]  * infinity nods.
[01:26] <jtaylor> if its not serial code usually you get the same results
[01:26] <jtaylor> s/not//
[01:27] <jtaylor> though I should give the new Og flag a try once
[01:28] <LinuxPC> infinity: Thanks for the info, I'll check back at a better time. What I wanted to tell him, is, I really appreciated his help. I was getting errors trying to install Ubuntu onto a new drive and then loading dual-boot so that I could still have access to my windows drive. He was an awesome help to me and I wanted him to know it.
[01:54] <infinity> doko_: Should gcc-4.8 depend on libgcc-4.8-dev?
[01:55] <infinity> doko_: Without it, <stddef.h> doesn't exist, and pretty much nothing useful can be compiled.
[01:55] <infinity> doko_: (g++ pulls it in transitively through g++ -> libstdc++-dev -> libgcc-dev, hence why build-essential and the buildds are fine and don't show the problem)
[01:58] <infinity> doko_: And, indeed, saucy's gcc-4.8 has the dependency, so I assume maybe it got lost during the libgcc 4.8/4.9 shuffle?
[02:01] <slangasek> infinity: no idea what's going on with libnih, but pitti mentioned libnih autopkgtest timing out on ppc64el too, so maybe that's related and it's an across-the-board regression
[02:01] <infinity> doko_: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1283850
[02:01] <infinity> slangasek: The libnih thing is another incarnation of https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1266492
[02:01] <infinity> slangasek: Seems like a bit of a random fluke on default build flags or something that it triggers in a sid userspace and not a trusty one.
[02:01] <slangasek> infinity: and adsb seems to think it's a toolchain bug - right
[02:01] <RAOF> In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc
[02:01] <slangasek> (toolchain/libc)
[02:02] <RAOF> In related gcc news, why do we now have a gcc-4.9-base package that does nothing but provide a gcc-4.9 binary that says “you don't have gcc-4.9 installed”?
[02:02] <slangasek> RAOF: because any compiler we build comes with a corresponding -base, but gcc-4.9 is only supported for go, not for C
[02:02] <infinity> RAOF: RAOF Erm, gcc-*-base don't provide any binaries...
[02:03] <slangasek> right, there is no gcc-4.9 binary in that package
[02:03] <slangasek> how did you come to find this out, exactly? :)
[02:03] <infinity> RAOF: gcc-*-base is a tiny (very tiny) package that just provides common docs for all packages built from that GCC source.
[02:03] <RAOF> slangasek: Ah, that makes sense. It's just a bit surprising that we've got /usr/bin/gcc-4.9 that, if you call it, says “you don't have gcc-4.9 installed”
[02:03] <RAOF> Looks like it's hardening-wrapper providing a diversion.
[02:03] <infinity> RAOF: So, it exists to provide the changelog and copyright for libgcc1_4.9, basically.
[02:04] <infinity> RAOF: Yeah, hardening-wrapper always did that to you. :P
[02:04] <RAOF> slangasek: I found out because I noticed an upgrade install gcc-4.9-$SOMETHING and thought “ooh, I like trying newer compilers to see if they bring up any new and interesting warnings”
[02:09] <infinity> slangasek: So, the bug with the configure test is a binutils bug.  But the part where it subsequently hangs is a glibc bug.  I'm uploading a workaround to just skip past the whole mess right now, since the glibc bug is Really Hard to fix, and the binutils bug seems to have seen no traction.
[02:10] <infinity> slangasek: http://deb.li/3DdiR (thanks to sbeattie)
[02:14] <mwhudson> er\
[02:14] <mwhudson> anyone willing to admit to knowing anything about setcontext?
[02:17]  * mwhudson now knows why his go process is crashing but isn't really sure about who is to blame
[02:17] <mwhudson> (on arm64)
[02:19] <infinity> mwhudson: Marcus Shawcroft would be your best bet.
[02:19] <mwhudson> yeah i think so too probably
[02:19] <infinity> mwhudson: Have you tested with the glibc 2.19 in -proposed?
[02:20] <mwhudson> no, but i looked at pretty recent glibc sources
[02:20] <infinity> mwhudson: Err, assuming this uses glibc at all.  If you're talking directly to the kernel, then... Not sure who to talk to.
[02:20] <mwhudson> yeah, this is gccgo so glibc is involved
[02:21] <mwhudson> basically: setcontext copies the uc_stack of the context to the task's sigaltstack settings
[02:22] <mwhudson> which seems a bit strange
[02:22] <mwhudson> and certainly not what the gccgo runtime is expecting...
[02:22] <infinity> Guessing this isn't how it works on armv7?
[02:22] <mwhudson> had started to look at that but no idea at this stage
[02:24] <infinity> mwhudson: 402a76b62dded0ee93cfec0471aaeccb989196d2 is the ARM setcontext implementation, modulo later cleanups and bugfixes.
[02:24] <mwhudson> yeah i think that probably doesn't have the odd behaviour that's causing problems
[02:25] <mwhudson> unexpected croissant break, brb
[02:25] <infinity> Unexpected?  Did you just get thwacked in the head by a wild croissant?
[02:26] <mwhudson> someone walked in with a tray of them
[02:33] <mwhudson> so yes, i'm feeling like this is a glibc bug
[02:33] <mwhudson> cool! i haven't found one of them recently
[02:35] <infinity> mwhudson: There are no glibc bugs, only features that you're using incorrectly.
[02:35] <mwhudson> infinity: i thought mr drepper was doing other things now
[02:35] <infinity> mwhudson: (On a more serious note, the aarch64 port is still pretty immature, and really only has the one guy working on it, so please do file bugs and annoy Marcus if you sort out solid testcases and the like)
[02:35] <mwhudson> it could also be a kernel bug, it depends how you squint
[02:36] <mwhudson> infinity: oh, i am definitely going to annoy people
[02:36] <infinity> mwhudson: Marcus comes back from VAC in ~6h, and will no doubt be flooded by people annoying him (including me)... Get in line. :)
[02:36] <mwhudson> haha
[02:37] <mwhudson> infinity: i presume there is a glibc bugzilla somewhere?
[02:37]  * infinity looks forward to arm64 kit being more widely available and the general hacker community banging on it and finding all the problems with the port.
[02:37] <infinity> mwhudson: https://sourceware.org/bugzilla/
[02:38] <mwhudson> would be nice if that happened before T...
[02:38] <mwhudson> looking unlikely i guess now
[02:38] <infinity> Yeah, even if people start getting their hands on AMD dev boards, it's a bit too late for that to influence trusty in any meaningful way.
[02:38] <infinity> But some bugfixes will likely be backportable.
[02:39] <infinity> mwhudson: Want to CC me (adconrad@0c3.net) on your bug report, so I can keep tabs on what's going on?
[02:39] <mwhudson> infinity: sure
[02:41] <infinity> mwhudson: Do be sure to test with my 2.19 packages before you report bugs, though.
[02:42] <infinity> We're so dangerously close to mainline right now that you can almost pretend that's testing against mainline. :P
[02:42] <infinity> Almost.
[02:42] <mwhudson> oh heh look at that
[02:42] <mwhudson> i am already :)
[02:42] <mwhudson> (t-mwhudson)mwhudson@am1:~/gccgo-4.9-4.9-20140222$ dpkg-query -W libc6
[02:42] <mwhudson> libc6:arm64     2.19-0ubuntu1
[02:42] <infinity> Shiny.
[02:43] <infinity> I need to find the round tuits to set up a PPA for actual mainline builds.
[02:43] <infinity> So I can be warned in advanace of new testsuite failures, etc.
[02:43] <infinity> Instead of the post-release "hey, all this stuff is broken and I need to fix it" panic. :/
[02:44] <infinity> Probably also much easier to rebase patches one day at a time instead of 6 months at a time.
[02:53] <mwhudson> er
[02:53] <mwhudson> paste.ubuntu.com is down?
[02:54] <mwhudson> infinity: test case: http://hastebin.com/qunasobobo.c
[02:54] <mwhudson> infinity: output http://hastebin.com/kacilipepi.sm
[02:55] <Takyoji> paste.ubuntu.com appears to be up
[02:56] <mwhudson> Takyoji: not accepting new pastes though
[02:56] <Takyoji> ahh, understood
[02:56] <mwhudson> anyway, have got a sysadmins attention now
[03:01] <hyperair> what's the common practice for handling changelog entries for debian revisions in x.y.z+reallyA.B.C releases?
[03:03] <hyperair> do i just put the intermediate A.B.D-1 changelog entry in between the x.y.z+reallyA.B.C-0ubuntu1 and x.y.z+reallyA.B.D-1ubuntu1 entries?
[03:03] <hyperair> or do i just leave it out?
[03:03] <infinity> hyperair: Up to you.  But if it implies bug closures and such, it might be less confusing to leave it out.
[03:04] <hyperair> hmm, why would it be less confusing in that case?
[03:04] <infinity> Because people parsing a changelog for the bug might think it's closed.
[03:04] <infinity> *shrug*
[03:04] <hyperair> but it is closed, is it not?
[03:04] <infinity> I mean if the interim new upstream release closed bugs.
[03:04] <hyperair> i mean the bugs closed in the A.B.D-1 changelog entry
[03:05] <infinity> If that closed bugs, you should reopen them.
[03:05] <hyperair> why?
[03:05] <infinity> ...
[03:05] <infinity> Because they're no longer fixed by code you're not shipping?
[03:05] <hyperair> why wouldn't they?
[03:05] <hyperair> the bugfixes are from A.B.C..A.B.D
[03:06] <hyperair> i'm merging these changes into x.y.z+reallyA.B.C so that it's x.y.z+reallyA.B.D.
[03:06] <infinity> Oh, I may not be seeing your usecase here.  I'm thinking that you're reverting from x.y.z to A.B.D, not just upgrading from A.B.C to A.B.D
[03:06] <hyperair> i've already reverted from x.y.z to A.B.C
[03:07] <hyperair> now i'd like to upgrade from A.B.C to A.B.D
[03:07] <infinity> So, if this is about us having messed up and reverted in the past and now merging with Debian's A.B.C->A.B.D, then yeah, I'd keep the Debian changelog entries in between.
[03:07] <hyperair> rigth, and should i renumber the entries?
[03:07] <hyperair> so that debian's A.B.C-1 entry is now x.y.z+reallyA.B.C?
[03:07] <infinity> Nah.
[03:07] <hyperair> okay
[03:07] <infinity> What's the actual package in question here?
[03:08] <infinity> Is x.y.z close enough to A.B.D that the mistake will sort itself soon?
[03:08] <infinity> Or are we talking an order of magnitude where it might be worth begging the Debian maintainer to add an epoch to get you out of your mess? :P
[03:09] <hyperair> banshee
[03:09] <hyperair> i'm the debian maintainer
[03:09] <hyperair> no epoch necessary
[03:09] <infinity> Ahh, yeah, that'll sort itself soon enough.
[03:09] <hyperair> yeah
[03:09] <infinity> So, yeah, I'd just stuff the interim versions in there unchanged in your merge.
[03:10] <hyperair> okay cool
[03:10] <mwhudson> infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16629
[03:10] <infinity> "Merge changes from 2.6.1-5"
[03:11] <infinity> hyperair: For sanity's sake, I probably would have called that 2.9.0+really2.6.1-5ubuntu1 instead of 2.9.0+really2.6.1-0ubuntu1, as a better indication of the relationship with the Debian packaging.
[03:11] <hyperair> infinity: yeah i realized that a little too late, and didn't think it warranted another upload
[03:11]  * infinity nods.
[05:46] <Noskcaj> How can i check locally if a package supports building on ppc64el?
[05:47] <sarnold> check build logs on launchpad?
[05:47] <Noskcaj> For a merge i'm doing
[05:47] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/garcon/merge/+merge/207861
[05:47] <Noskcaj> and two more in progress
[05:54] <RAOF> Noskcaj: I believe the current status is ‘upload it and see’; it doesn't seem that qemu has grown support yet.
[05:54] <Noskcaj> ok
[05:54] <Noskcaj> And chance you could do some sponsoring then?
[05:54] <RAOF> That said, we're in feature freeze now; does it have an exception?
[05:54] <Noskcaj> bugfix releases
[05:54] <RAOF> (Or is purely bugfix?)
[05:55] <Unit193> Trusty has a git snapshot, it's now actually released with a bugfix or two.  (Garcon)
[05:55] <Noskcaj> one is bugfix + translation, the other we have a git snapshot of so it's just re-enabling docs and more translations
[05:56] <infinity> Noskcaj: If it has a configure script, you can make an educated guess on support.
[05:57] <Noskcaj> how?
[05:58] <infinity> Noskcaj: Also, it might not matter unless it builds a library...
[05:58] <infinity> Ahh, it does.
[05:58] <Noskcaj> libxfce4ui does, i'm not sure about garcon
[05:58] <infinity> Noskcaj: So, search for "powerpc64" in libtool.m4 and configure, and other places that have that construct.  Compare the /usr/share/aclocal/libtool.m4 ... Note that your is wrong.
[05:59] <Noskcaj> "your is" ?
[05:59] <infinity> Noskcaj: If you run dh-autoreconf, it might just solve itself, assuming autoreconf on that package relibtoolizes.
[05:59] <infinity> Noskcaj: The merge you linked to has old libtool macros.
[05:59] <Noskcaj> garcon is also a library
[05:59] <infinity> s/your/yours/
[06:00] <Noskcaj> ok
[06:00] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxfce4ui/4.11.1 is the other merge
[06:00] <infinity> In other news, why do people still do Debian merges as MPs?  It's completely unreadable and unparseable.
[06:01] <Noskcaj> infinity, How should i be doing it?
[06:01] <Noskcaj> (debian merges)
[06:01] <infinity> Noskcaj: Well, that merge explicitly claims it's using dh-autoreconf for ppc64el, so I assume that works. :P
[06:01] <infinity> Noskcaj: I dunno.  I prefer the sort of patches that MoM spits out.  Delta against Debian is much more helpful (usually tiny) than delta against previous Ubuntu (can be several megs of unauditable goop).
[06:02] <infinity> Plus, you can interdiff deltas between Debian nicely.
[06:02] <infinity> Old delta was foo, new delta was bar, quick interdiff shows the 5 lines you had to change to make the merge work.
[06:03] <Noskcaj> makes sense, issue being MoM makes a lot of files and clutter, which get's confusing to new people trying to merge
[06:03] <infinity> Surely nowhere near as confusing as a massive MP no one's going to read before committing. :P
[06:03] <Noskcaj> although i should be on the reviewing end soon-ish
[06:03] <infinity> (And if no one's going to review it, you'd just subverted the whole point of getting a sponsor to upload)
[06:03] <infinity> s/you'd/you've/
[06:06] <Noskcaj> yep
[06:07] <Noskcaj> my current issue being, i have both sorts of merge up, and no sponsoring anywhere
[06:07] <Noskcaj> e.g. bug 1282937
[06:08] <Noskcaj> (bugfix only, all major changes are already in ubuntu as patches)
[06:21] <infinity> Noskcaj: Well, now that feature freeze has come and gone, you might be able to find sponsors who aren't crazy busy. :)
[06:22]  * Noskcaj looks at sponsoring queue, 51 packages.
[07:01] <pitti> Good morning
[07:01] <dholbach> good morning
[07:05] <pitti> hey dholbach, wie gehts?
[07:06] <dholbach> pitti, sehr gut - und dir? :)
[07:06] <pitti> dholbach: still feeling a bit zombie-like with the jetlag, but ok; at least no ubuflu :)
[07:09] <pitti> infinity, slangasek: yes, libnih keeps getting eternally stuck on ppc64 and armhf; it even seems to reset autopkgtest's timeout timer, so not even that kicks in
[07:09] <pitti> infinity, slangasek: so I had to kill all of them at some point
[07:15] <Noskcaj> Could someone please sponsor https://code.launchpad.net/~noskcaj/ubuntu/trusty/clutter-1.0/1.16.4/+merge/207778 ?
[07:16] <Noskcaj> It's bugfixes, so it shouldn't need an FFe
[07:17] <pitti> infinity: ah, gunnarhj reminded me that we should refresh the -base langpacks, as we just got a new ubuntu-docs; I'm doing that now, does that still work out for beta-1?
[07:17] <pitti> (will also make the images smaller)
[07:44] <infinity> pitti: Yeahp, should be fine, b1 freeze is later todayish.
[07:45] <infinity> Noskcaj: Can you find out where clutter upstream got their libtool from?
[07:45] <infinity> Noskcaj: It's buggy. :/
[07:45] <infinity> Noskcaj: If Fedora's shipping that, they need to stop.
[07:46] <Noskcaj> looking now
[07:46] <infinity> Noskcaj: See this bit from your diff: http://paste.ubuntu.com/6985749/
[07:46] <infinity> Noskcaj: That top set should say powerpc64le and powerpc64 (as the libtool.m4 on your Ubuntu system does).
[07:47] <Noskcaj> ok
[07:47] <infinity> Noskcaj: So, they obviously relibtoolized with a broken libtool, we should hunt down where that's coming from before it infects more upstream projects.
[07:48] <Noskcaj> the git log doesn't seem to have a libtool change since 2011, but i've seen that issue before in something
[07:48] <pitti> doko_: I've seen 'Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0x7fc66afe24e0>>
[07:48] <infinity> pitti: Everyone's seen it.  Happens on every python postinst. :P
[07:48] <pitti> doko_: from /usr/lib/python3.4/subprocess.py in a lot of places; postinst scripts, tests, etc.; do you know where that's coming from? that's something since the py3.4 default
[07:49] <infinity> Noskcaj: libtool and configure bits might not be in git at all, autogen might be part of the tarball release process.
[07:49] <Noskcaj> looks like your right, i can't see libtool in the source
[07:50] <infinity> Noskcaj: Right, hence hunting down the guy who did the release tarball to find out what distro he made it on to see if their libtool can be fixed would be awesome.
[07:50] <infinity> (My guess is Fedora, since it's a fairly GNOMEish thing, but who knows)
[07:50] <Noskcaj> just let my computer unfreeze from my current compiling and i'll look
[07:53] <tseliot> pitti: apparently the kernel API broke again and fglrx doesn't build any more in Trusty. I wasn't notified. Is there a way to get the system to send me an email about it?
[07:59] <pitti> tseliot: we don't currenlty have anything which triggers the ubuntu-drivers-common autopkgtest on kernel uploads
[07:59] <pitti> tseliot: jibel is doing separate DKMS tests, they might be able to give you an email notification
[08:00] <pitti> tseliot: http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/ ran on Saturday and succeeded
[08:00] <tseliot> pitti: err... I think it would be useful to do that when the kernel is uploaded, so that if the API breaks we know about it
[08:00] <pitti> http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx_updates/ ran on Sat as well and failed
[08:03] <pitti> yes, it would; we could perhaps add a linux-libc-dev build dependency to u-d-common, so that the reverse dependency check mechanism kicks in?
[08:04] <pitti> tseliot: https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/58/ ran yesterday, did we get a new kernel since yesterday?
[08:04] <pitti> (and succeeded)
[08:04] <Noskcaj> infinity, The developer's name is Emmanuele Bassi, i have to go and have dinner, than i'll email him
[08:05] <infinity> pitti: How would ubuntu-drivers-common help identify if fglrx or nvidia have stopped building?
[08:05] <tseliot> pitti: I updated my system on Saturday and the build failed. I'm not sure if they fixed it over the weekend.
[08:05] <tseliot> apw: ^^
[08:05] <infinity> pitti: Or is its autopkgtest an attempt to build everything it knows about?
[08:05] <pitti> infinity: its autopkgtests check our most popular dkms packages (nvidia, fglrx, bcmwl)
[08:05] <infinity> tseliot: There have been no new kernels over the weekend, though there is one in proposed since Friday.
[08:06] <pitti> infinity: https://jenkins.qa.ubuntu.com/view/DKMS/? is a more comprehensive approach to testing DKMS packages, but it doesn't hold back new kernels on failures
[08:06] <tseliot> let me check what kernel version caused the problem
[08:06] <tseliot> 3.13.0-11-generic
[08:07] <infinity> pitti: I don't know if it should hold back new kernels necessarily, but it certainly needs a notification system that isn't "refresh the page once in a while".
[08:08] <pitti> infinity: I'm not sure whether it has notifications; jibel and the kernel team discussed how notifications should look like back then, but I forgot what the result was
[08:08] <pitti> adding email notifications to jenkins is trivial, but I don't know any more whether the kernel team actually wanted them
[08:08] <tseliot> the failure: http://paste.ubuntu.com/6985814/
[08:08] <zyga> good morning
[08:12] <tseliot> pitti: is this a good log? http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/Trusty%20Release%20-generic/job/dkms-trusty-release-generic-fglrx/24/ARCH=amd64,label=wazn-adt/artifact/results/fglrx/13.350/3.13.0-12-generic/x86_64/log/make.log
[08:12] <tseliot> pitti: "build succeeded with return value 0 duplication skipped - generator was not called from regular lib tree done."
[08:17] <tseliot> pitti: the log from "successful" builds looks exactly like the one from the failed build (19 February)
[08:23] <pitti> at least it seems the compilation worked?
[08:27] <tseliot> pitti: it still doesn't here
[08:27] <tseliot> let's try the kernel in -proposed
[08:34] <Wnt> I'm having problems installing Skype on my 64 bit Trusty machine. Is this the right place to as for help? Output of "apt-get install skype" and "apt-get install skype-bin" and some other commands at: http://upload.egarden.fi/apt-get_install_skype_failed.txt
[08:38] <infinity> Wnt: You want #ubnutu, this isn't a support channel.
[08:39] <tseliot> yes, #ubuntu
[08:39] <phanimahesh> Hello guys! I need help with a FTBFS issue on trusty.
[08:39] <phanimahesh> anyone has a few minutes to spare?
[08:40] <infinity> phanimahesh: Depends on the issue and the minutes.  Just ask.
[08:40] <phanimahesh> unity-tweak-tool is a package in the repos, and I am a member of its dev team.
[08:40] <Noskcaj> python3.4 transition issues
[08:40] <phanimahesh> And due to a python transition issue, tha package fails to build on trusty.
[08:41] <phanimahesh> and i'm not able to figure out how to fix it.
[08:41] <infinity> Wasn't that fixed in the archive 4 days ago?
[08:41] <phanimahesh> + python3.3 setup.py build --executable=/usr/bin/python3
[08:41] <phanimahesh> /bin/sh: 2: python3.3: not found
[08:42] <phanimahesh> that is the relevant error message in the failed build log
[08:42] <infinity> phanimahesh: That should just be python3, not python3.3
[08:42] <phanimahesh> https://github.com/freyja-dev/unity-tweak-tool/blob/master/debian/rules
[08:42] <phanimahesh> That is our debian/rules
[08:42] <infinity> http://launchpadlibrarian.net/167142991/unity-tweak-tool_0.0.6_0.0.6ubuntu1.diff.gz
[08:43] <infinity> phanimahesh: Like I said, this was already fixed in the archive, afaict.
[08:43] <infinity> Andrew should probably have forwarded you the patches, but there you go.  The last build in trusty was against python3.4 as default, and worked fine.
[08:43] <phanimahesh> Oh.
[08:43] <phanimahesh> Thanks. :)
[08:43] <phanimahesh> I did see that he backported a crash fix,
[08:44] <phanimahesh> but did not notice the change to debian/rules.
[08:44] <infinity> And debian/control.
[08:44] <phanimahesh> I'll pull in the changes.
[08:44] <phanimahesh> Thanks.
[08:44] <infinity> Equally important.
[08:44] <phanimahesh> yup. just looked at the changelog.
[08:44] <phanimahesh> thanks!
[08:58] <imapados> Hey guys! I have to geplace gksudo by pkexec. But how can i display a special message to the user like gksudo --message "Hey you"?
[08:58] <imapados> replace
[09:00] <pitti> imapados: it uses the polkit .policy's message, see e. g. /usr/share/polkit-1/actions/com.ubuntu.update-notifier.policy
[09:00] <imapados> thx, pitti!
[09:00] <pitti> imapados: the pkexec caller can't set an arbitrary message
[09:00] <pitti> that's quite by design
[09:01] <imapados> Hmmppff..
[09:01] <phanimahesh> Noskcaj: infinity: thanks for your help.
[09:01] <Noskcaj> no problem
[09:01] <imapados> But you won't use gksudo in future?
[09:01] <phanimahesh> I should have noticed it earlier, though.
[09:01] <pitti> imapados: we have dropped gksudo for almost everything many cycles ago already, so yes
[09:02] <imapados> so, i will follow you! ;)
[09:09] <pitti> infinity: ok, built and tested; upload ahoi
[09:10] <infinity> pitti: Should all build before stgraber wakes up, so yay. :)
[09:10] <infinity> Especially with that massive army of x86 builders you now have...
[09:15] <pitti> infinity: indeed; I wonder whether they can keep up with debuild/dputting them :)
[09:16] <pitti> hm, probably should have updated the chroots before, but *shrug* too late
[09:16] <infinity> You mean the LP buildd chroot?
[09:16] <pitti> yes
[09:17] <infinity> pitti: The largest portion of that upgrade (libc6 and gcc) is in -proposed, which isn't in the chroots, so wouldn't win you much.
[09:17] <pitti> ah, ok
[09:17] <pitti> 54 upgraded packages
[09:18] <infinity> Not like 2m builds are a big deal. :P
[09:23] <pitti> langpack pwned! https://launchpad.net/builders
[09:24] <zyga> doko_: hey, I'd like to understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703 better
[09:24] <zyga> doko_: that effectively breaks virtualenv on python3.4
[09:24] <zyga> doko_: is that the status quo for the next 5 years or is this still something we can fix for trusty?
[09:31] <doko> zyga, mind adding something constructive to the bug report?
[09:33] <zyga> doko: I try to understand what's the current status first, is ensurepip deliberaltely disabled?
[09:35] <zyga> I just found that it is, what is the reason for that?
[09:37] <doko> zyga, see debian-devel about shipping pip. debian wants to use the pip shipped by debian. and I don't want to have the ensurepip interfer with the system python
[09:38] <zyga> doko: I see, that makes sense, so pyvenv-3.4 should link to the local copy of pip, right?
[09:38] <zyga> doko: (currently you just get a relatively useless virtualenv as you know, with just bare python)
[09:39] <doko> zyga, yes, but it is currently my highest priority
[09:40] <zyga> doko: so you are working on this?
[09:40] <doko> no
[09:40] <zyga> doko: can I help you somehow?
[09:40] <zyga> doko: it is your highest priority or isnt?
[09:41] <doko> ahh, typo. no, not my highes prio
[09:41] <zyga> ah
[09:42] <zyga> doko: do you have a preferred solution to this problem? is it just as simpe as symlinking pip pip-3 pip-3.4 in the right place?
[09:42] <zyga> *simple
[09:43] <doko> zyga, if you have patch, please send it
[09:43] <zyga> doko: I'm willing to work on it if I know that's the right solution you will accept
[09:44] <doko> you'll need to find this solution. I just outlined the requirements
[09:44] <zyga> doko: ok, thankyou
[09:57] <zyga> doko: can you tell me if the older version of python3-pip is a part of the story? upstream released 1.5.4, debian (and trusty) is at 1.4.1
[09:58] <zyga> doko: is that deliberate due to wheels or is that just lack of manpower?
[09:58] <Laney> infinity: cjwatson: Can I have a slither of moderation in the direction of u-d-a please?
[09:58] <pitti> can do, too
[09:58] <Laney> oh really?
[09:58] <pitti> done
[09:58] <Laney> you should be on here then https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
[09:58] <Laney> thanks!
[09:59] <pitti> Laney: well, I don't admin the ML, I just have a moderation pw
[09:59] <Laney> mmm, "run by"
[09:59] <infinity> It's a hard (hah!) password to forget.
[09:59] <Laney> anyway, happy voting
[09:59] <pitti> *shrug* ~/.listadmin.ini FTW :)
[10:00] <infinity> Laney: Is it bad if I put everyone below None of the Above?
[10:00] <pitti> *chuckle*
[10:00] <infinity> Or, I guess, none of the below...
[10:00] <Laney> it's NOTB
[10:00] <xnox> infinity: haha =)
[10:00] <Laney> if that expresses your thoughts :-)
[10:01] <infinity> Nah.  Not this time around. :)
[10:02] <pitti> Snow-Man: hey
[10:02] <pitti> Snow-Man: you asked me about http://www.postgresql.org/message-id/52D6D914.8090207%40agliodbs.com the other day
[10:03] <pitti> Snow-Man: FWIW, I think that features like conf.d are rather useless if you can disable them
[10:03] <pitti> Snow-Man: especially if you can do so at runtime
[10:04] <pitti> Snow-Man: for Debian I'd enable it in the packages, and we can then change p-common to use those instead of always modifying the default one in-place
[10:07] <seb128> ev, bdmurray_: the e.u.c trusty retracing have quite some issues, is there anything we can do help figuring out what is wrong? like the ranking shows we have new compiz/unity segfaults but the reports are of no use since retracing doesn't work
[10:07] <pitti> Snow-Man: while configurability doesn't hurt distros so much, it entirely breaks configuration tools/GUIs that are supposed to work everywhere
[10:07] <darkxst> doko, I suppose you have already seen this, but Bug 1283850 is blocking all things beta1-ish like QA for ubuntu GNOME, would be great if you can take a look today ;)
[10:07] <pitti> Snow-Man: so if you want to make it configurable, you can just as well drop the feature entirely; halves the testing space and avoids trouble
[10:07] <seb128> ev, bdmurray_: e.g https://errors.ubuntu.com/problem/44226fe8b2fa8e16ed82ac4469f9b26e726420a0
[10:08] <doko> darkxst, please ask ScottK, I didn't update spamassassin
[10:14] <xnox> doko: well commentry on the bug report, suggests gcc missing a build-dep on libgcc-x.y-dev.
[10:14] <xnox> doko: unless that was intentional...
[10:15] <doko> hmm, no
[10:18] <doko> hmm, more gccgo fallout
[10:21] <seb128> pitti, we don't have detailed logs of retracings anymore?
[10:22] <pitti> seb128: on the porter box? nothing changed wrt. logging for a long time
[10:22] <seb128> I didn't look at those for ages
[10:24] <pitti> seb128: I still saw proper logs a few days ago; which logs do you mean?
[10:24] <seb128> pitti, I'm trying a retracing by hand, trying to figure out why https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1283885 is missing unity symbols
[10:25] <seb128> "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing
[10:25] <seb128> "
[10:25] <seb128> that part looks ok
[10:25] <seb128> pitti, I only see "retracing <...>" in the log, not the logs of the actual retrace (that would hint on why symbols are missing)
[10:27] <seb128> shrug
[10:27] <seb128> #4  0x00007f5b7c526b3a in ?? () from /tmp/s/usr/lib/compiz/libunityshell.so
[10:27] <seb128> No symbol table info available.
[10:27] <seb128> but no indication why that's missing
[10:27] <pitti> the package looks current at least
[10:27] <darkxst> doko, it was the gcc update that killed it, read the bug ;)
[10:28] <seb128> pitti, is there any way to tell apport-retrace to display infos about the ddebs it fetches?
[10:28] <seb128> the log has
[10:28] <seb128> "dynamically loaded /usr/lib/compiz/libunityshell.so needs package unity, queueing"
[10:28] <seb128> then the gdb bt
[10:28] <seb128> no debug in between
[10:29] <pitti> WARNING: /home/townsend/.compiz-1/plugins/libunityshell.so is needed, but cannot be mapped to a package
[10:29] <pitti> seb128: ^
[10:29] <pitti> seb128: ah sorry, different bug
[10:30] <pitti> seb128: that's your local log? because I don't see that on the porter bos
[10:30] <seb128> pitti, on osageorange
[10:30] <seb128> $ ls cache-amd64/Ubuntu\ 14.04/apt/var/cache/apt/archives/*unity_*ddeb*
[10:30] <pitti> box
[10:30] <seb128> pitti, I ran the command manually on porter to have the log
[10:30] <seb128> $ apport/bin/apport-retrace -sv --auth launchpad-credentials -S config --sandbox-dir=/tmp/s  1283885
[10:31] <tseliot> doko: that broke fglrx too here (trusty amd64). The module won't build although the relevant headers are included: http://paste.ubuntu.com/6985814/
[10:31] <seb128> bah
[10:32] <seb128> pitti, ddebs are missing from http://ddebs.ubuntu.com/pool/main/u/unity/
[10:32] <pitti> go ddeb-retriever!
[10:32] <seb128> pitti, that version is 4 days old, can we rescue them?
[10:32] <pitti> seb128: yes, hang on
[10:32] <seb128> thanks
[10:33] <pitti> err, buildds don't have ddebs any more from Feb 20?
[10:33] <seb128> pitti, https://launchpadlibrarian.net/166943400/buildlog_ubuntu-trusty-i386.unity_7.1.2%2B14.04.20140220-0ubuntu1_UPLOADING.txt.gz
[10:34] <seb128> "unity has no unstripped objects, ignoring
[10:34] <seb128> find: `/build/buildd/unity-7.1.2+14.04.20140220/debian/unity-dbgsym': No such file or directory
[10:34] <seb128> /usr/bin/pkg_create_dbgsym: nothing in /build/buildd/unity-7.1.2+14.04.20140220/debian/unity-dbgsym and no dbgdepends, ignoring"
[10:34] <seb128>  
[10:34] <seb128> I guess upstream bug/lack of -ggdb
[10:34] <pitti> http://klock.buildd/~buildd/ddebs/20140220/
[10:34] <pitti> empty
[10:35] <pitti> it seems that we don't have ddebs up to 2040220/ on the buildds any more
[10:35] <seb128> pitti, yeah, seems like the upstream build generates stripped binaries
[10:35] <pitti> 20140221 and on still have ddebs
[10:35] <pitti> seb128: so, two bugs here
[10:35] <pitti> although I guess infinity's ppc64 rebuild and temporarily changing the apaches has got something to do with the missing ddebs
[10:36] <pitti> so, missing -g for unity and the manual cleanup
[10:40] <seb128> pitti, thanks for helping debugging that
[10:40] <seb128> pitti, I've opened https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047 about the unity issue
[10:40] <pitti> seb128: wasn't that helpful after all :/, but yw
[10:40] <pitti> thanks
[10:45] <seb128> hum
[10:45] <seb128> seems like they have none of the standard build flags
[10:46] <pitti> infinity: so we'll do the locales change in 14.10?
[10:47] <seb128> e.g no -fstack-protector
[10:47] <seb128> debdiff between saucy and trusty has
[10:47] <seb128> -CFLAGS=$(shell echo $$CFLAGS | sed -e 's/\-Wall//')
[10:47] <seb128> +export CFLAGS=$(shell echo $$CFLAGS | sed -e 's/\-Wall//') -Wno-error=deprecated-declarations
[10:47] <infinity> pitti: Nope, I'll do it soon in trusty and get an FFe for it.  Just wanted 2.19 in first.
[10:47] <pitti> infinity: ah, godo
[10:47] <pitti> good, too
[10:47] <seb128> is that buggy?
[10:48] <infinity> pitti: As for ddebs, I didn't touch anything on !ppc64el buildds...
[10:48] <pitti> infinity: hm, so do the ddebs not keep the last 7 days of ddebs any more, but perhaps only 3?
[10:49] <infinity> pitti: It's been 3 for... Ever.
[10:50] <pitti> infinity: oh, was it? I had the impression it was 7
[10:50] <pitti> so, nevermind
[10:50] <seb128> it was 7 iirc
[10:50] <infinity> You can remember all you want, but it's not correctly. :P
[10:50] <infinity> It's been 3 for years.
[10:50] <seb128> lol
[10:51] <seb128> that's not ever :p
[10:51] <infinity> Well, it's been 3 ever since the project was split from LP in 2011.  And was 3 before that too, just too lazy to go find the old tree and see how far back.
[10:52] <seb128> shrug, I wonder why unity doesn't get the standard build flags :/
[10:52] <seb128> cmake issue?
[10:52] <doko> jtaylor, what is the status of the qhull transition? looks like a lot of octave updates are needed too. maybe merge octave from unstable first?
[10:56] <xnox> seb128: debhelper changed to BuildType=None, that might affect cmake based projects...
[10:56] <xnox> seb128: i was personally against that change...
[10:56] <seb128> xnox, what is BuildType? can I change that just to see if that restore the flags?
[10:57] <xnox> seb128: dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release
[10:58] <xnox> seb128: but... previously it was not defined at all. which is different from defining it to any value... your mileage may vary...
[11:00] <seb128> xnox, no luck, anyway I'm going to let that to the unity team/cmake people to debug
[11:01] <seb128> xnox, "-g -O2 -fstack-protector" are missing, do you know where they are supposed to come from
[11:02] <seb128> commented on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047 anyway
[11:02] <xnox> seb128: let me poke that a bit.
[11:02] <seb128> xnox, thanks
[11:12] <xnox> seb128: i have a fix. do you want it as a branch to lp:unity? or direct upload...
[11:13] <xnox> seb128: http://paste.ubuntu.com/6986427/
[11:14] <xnox> seb128: or the two export lines should be gone, and unity fixed to build with -Wall and -Werror=deprecated-declarations ;-)
[11:14] <xnox> (but still keep DPKG_EXPORT_BUILDFLAGS & include line)
[11:17] <infinity> xnox: Isn't it a bit redundant to include the flags and then use dpkg-buildflags?
[11:18] <xnox> infinity: i know.... but i'm hoping the two overrides will be dropped. And first include gets me cppflags & ldflags, which i'm not overriding.
[11:20] <infinity> xnox: My point is that you already have the environment, why are you running dpkg-buildflags at all?
[11:20] <infinity> xnox: http://paste.ubuntu.com/6986456/
[11:21] <infinity> xnox: In fact, you also don't need to export twice either.  This is all sorts of sloppy. :P
[11:21] <seb128> xnox, sorry, got a timeout, please merge request, that can be batched with other fixes that need to be uploaded today
[11:21] <infinity> xnox: http://paste.ubuntu.com/6986466/ <-- See?
[11:22] <xnox> infinity: ah, ok. I was getting make variable references itself =/ yours looks better indeed.
[11:22] <infinity> xnox: You got the self reference if you used = instead of := at some point.
[11:23] <xnox> infinity: ack. wanna merge propose your fix to lp:unity ? =)
[11:23] <infinity> xnox: Nope.  I'm going to bed.  It's all yours.
[11:23] <xnox> infinity: ok, good night.
[11:23] <seb128> infinity, night
[11:24] <infinity> xnox: Out of curiosity, what sort of irresponsible project are we running that removes -Wall? :/
[11:25] <infinity> Shouldn't they, I dunno, fix the warnings?
[11:25] <xnox> infinity: unity7
[11:25] <xnox> infinity: ditto deprecated-warnings.
[11:25] <xnox> infinity: actually, i'll just give them the dpkg-buildflags, and they should fix the other two.
[11:25] <pitti> removing -Wall sounds weird, though; is that meant to remove -Werror perhaps?
[11:26] <xnox> infinity: pitti: and given that i now fetch flags from dpkg-buildflags, in fact, neither Wall nor Werror will be present by default....
[11:26] <infinity> Actually, wait.  Why is this madness being done this way at all? :P
[11:26] <pitti> ah, so this is moot then
[11:26] <xnox> thus the whole "fix" reduces to removing custom processing of CFLAGS/CXXFLAGS....
[11:26] <seb128> the "don't use Wall" seems to be from didrocks in 2010
[11:27] <seb128> that could probably be revisited
[11:27] <didrocks> well, it's from time of unity7 in vala
[11:27] <didrocks> so unity1 :)
[11:27] <didrocks> can probably be revisted for sure
[11:27] <seb128> yeah, could/should probably be revisited ;-)
[11:28] <infinity> xnox: Here.  Use dpkg-buildflags how it's meant to be used: http://paste.ubuntu.com/6986490/
[11:29] <xnox> infinity: i didn't know it can do _STRIP
[11:30] <infinity> xnox: Yeahp.  Though, as you point out, -Wall isn't in the default flags anyway, so those two lines are unnecessary, and you could just use the APPEND.
[11:32] <xnox> didrocks: we had unity in vala! =) lolz.
[11:32] <xnox> i didn't know that.
[11:32] <didrocks> xnox: yeah, we even shipped it! :)
[12:09] <seb128> hum
[12:09] <seb128> (ignore that)
[12:10] <seb128> what's the best way to see what keeps something in main?
[12:11] <pitti> it used to be http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty
[12:11] <pitti> but that now redirects to http://people.canonical.com/germinate-output/ubuntu.trusty/ and is 404
[12:12] <pitti> cjwatson: ^ is that supposed to exist still?
[12:12] <Laney> put a / on the end
[12:12] <Laney> ...
[12:12] <pitti> aah :)
[12:13] <pitti> seb128: e. g. http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/udisks2/
[12:13] <pitti> seb128: you get a file for each binary of that source, and an rdepends tree
[12:14]  * apw is seening a few python blammos during apt-get dist-upgrades ... are these known
[12:15] <apw> Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0x7f7809bfb2b0>>
[12:15] <apw> that sort of thing
[12:15] <Laney> yep
[12:15] <apw> ok cool
[12:15] <seb128> pitti, the 404 is the "hum" I just had before :p
[12:16] <seb128> pitti, I was looking at that, but it's not really "digest"
[12:16] <seb128> e.f http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/gnome-control-center/gnome-control-center
[12:16] <seb128> e.g
[12:16] <seb128> lot of those are "depends: u-c-c | g-c-c"
[12:16] <pitti> grep for "seed"?
[12:16] <pitti> oh, ok
[12:17] <seb128> g-c-c dropped from the daily iso
[12:17] <Laney> I like this table better, although it only lists one thing at a time
[12:17] <seb128> so I guess that's something out of the iso that keeps it in main
[12:17] <Laney> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/all
[12:17] <seb128> gnome-media (Recommends)
[12:17] <seb128> hum
[12:18] <pitti> but gnome-media is in universe
[12:18] <Laney> hmm, indeed
[12:19] <seb128> compiz (Build-Depend)    as well
[12:19] <seb128> oh, and some apps like deja-dup build-depends on libgnome-control-center-dev
[12:19] <seb128> ok, I guess we are not being able to demote it then
[12:20] <Laney> yeah those would do it
[12:22] <xnox> seb128: Laney: i think the point was that "gnome-settings-daemon" / "gnome-control-center" binaries could be demoted to universe, whilst the source/dev/lib packages will stay in main.
[12:23] <xnox> and security would like "gnome-settings-daemon" / "gnome-control-center" bin packages to be demoted.
[12:24] <seb128> xnox, yeah, that should work
[12:25] <xnox> seb128: gnome-control-center-unity: gnome-control-center-unity seems to want to go into universe, i guess it's safe to remove from the archive now?
[12:26] <seb128> xnox, yeah, let me do that
[12:26] <xnox> Laney: seb128: and all the gnome-media / gnome-panel is probably coming from ppc64el/arm64 pulling in a desktop into main... since unity is not built?!
[12:26] <seb128> still not?
[12:26] <xnox> well, let's check.
[12:26] <seb128> https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20140220-0ubuntu1 has all archs
[12:28] <xnox> seb128: looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg something is odd in the indicator-datetime chain.
[12:29] <seb128> Recommends: indicator-applet | indicator-renderer
[12:29] <seb128> should the default be changed?
[12:29] <seb128> though other indicators do the same thing
[12:29] <xnox> seb128: who provides indicator-renderer?!
[12:29] <seb128> unity
[12:30] <seb128> and indicator-applet
[12:30] <mitya57> I believe some Xfce applet provides it as well.
[12:30] <seb128> $ apt-cache showpkg indicator-renderer
[12:30] <seb128> http://paste.ubuntu.com/6986720/
[12:31] <xnox> seb128: in that case i'm failing to understand why gnome-panel is still pulled in by components missmatches.
[12:32] <xnox> well indicator-applet to be precise.
[12:32] <seb128> could it be that unity is not installable on some arch?
[12:32] <seb128> built != installable
[12:32] <xnox> seb128: but it migrated to release pocket.... britney would tell us that.
[12:32] <xnox> let's check that output.
[12:33] <seb128> britney prevents regressions no?
[12:33] <xnox> seb128: http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty_uninst_full.txt
[12:33] <seb128> e.g if unity had never been installable on e.g ppc64el, would it prevent it to migrate?
[12:33] <xnox> seb128: unity appears to be installable.
[12:34] <seb128> I don't know then
[12:34] <xnox> seb128: actually....
[12:34] <seb128>   unity (7.1.2+14.04.20131106.1-0ubuntu4): libunity-core-6.0-8
[12:34] <seb128> in the ppc64el section
[12:34] <xnox> yeap. greping for "unity (7" helped.
[12:37] <seb128> xnox, btw, let me know when your unity cflags fix is up for review, I can ack it
[12:38] <xnox> seb128: oh, i get a hallarious internal compiler error =)
[12:38] <Laney> it should be -6.0-9 no?
[12:39] <xnox> seb128: but not when building twice =)
[12:40] <Laney> ah not ubuntu4, that's an old version
[12:40] <seb128> Laney, yeah, I'm not sure why that version is listed
[12:40] <seb128> I wonder if that's a side effect of the ppc64el new boostrap/rebuild
[12:40] <seb128> infinity hinted that component mismatch might be buggy for some days due to that
[12:40] <doko> seb128, defaults to O3 now
[12:41] <doko> please get the preprocessed source if possible
[12:41] <xnox> seb128: in a ppc64el chroot, unity7 is installable.
[12:42] <xnox> (well it's downloading packages at the moment...)
[12:42] <Laney> the report refers to an old version
[12:42] <xnox> Laney: well, it's been generated twenty minutes ago... looks like britney is full of lies then.
[12:43] <xnox> doko: is 03 default on i386/amd64 as well?!
[12:43] <Laney> weird isn't it
[12:44] <doko> xnox, no
[12:51] <Laney> xnox: I see some hack for ppc64el in britney
[12:52] <Laney> https://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/221
[12:52] <Laney> it's probably the full of lies that we should ignore
[12:53] <xnox> cjwatson: infinity: ppc64el rebuild is complete, can we drop the snapshot archive from britney? it's now actively generating lies for us =)
[12:54] <xnox> ditto elsewhere, e.g. components-mismatches if that was tricked into snpashot archive as well.
[12:54] <Laney> I don't see where it was done for c-m though
[12:57]  * xnox loves launchpad without CSS loading
[14:39] <smoser> asac, sure. i think tomcat test failure might be bug 1269073
[14:49] <zyga> doko: sorry to bother you with that again, I had some unrelated fire-fighting to do, back to virtualenv problem. Do you think it is the same code that disables 'ensurepip' which makes `virtualenv -p python3 --system-site-packages` *not* install pip as it did before?
[14:50] <doko> zyga, I don't know. maybe barry could have a look? he uses venv much more than me
[14:51] <zyga> doko: it seems that python2.7 is affected too
[14:51] <barry> zyga: what's going on?
[14:51] <zyga> doko: i think this is a very serious issue now
[14:51] <zyga> barry: hey
[14:52] <zyga> barry: please run `virtualenv -p python2.7 --system-site-packages /tmp/py27-sys` and confirm that you *don* have pip inside your new venv
[14:52] <zyga> barry: also affects 3.3 and 3.4
[14:53] <zyga> barry: I'm trying to understand what caused that, initially I assumed that is --without-pip which disables 'ensurepip' on 3.4 but I don't understand how that affects 2.7
[14:53] <zyga> *dont*
[14:53] <barry> zyga: looks like that's the case.  pip still comes from /usr/bin/pip
[14:53] <barry> and there's no pip in the venv
[14:53] <zyga> barry: this is a change of beahavior, is that expected?
[14:54] <barry> zyga: that's *despite* the fact that the log message says it's installing it :/
[14:54] <zyga> barry: in particular, the outer pip cannot install anything into my venv now
[14:54] <zyga> barry: yes
[14:54] <barry> zyga: i think that's a bug, yes
[14:54] <zyga> barry: ok, I'd love to file and follow it till it gets fixed (I can help) because it blocks all of my work
[14:55] <zyga> barry: on python-defaults or what? I still don't understand how it might have happened
[14:55] <barry> zyga: if you de-install system pip, does it work?
[14:56] <barry> zyga: i would file it on python-virtualenv.  we can always reassign it later
[14:57] <zyga> barry: yes
[14:57] <zyga> barry: ok, on it
[14:57] <barry> tumbleweed: ^^  you did the last few updates on python-virtualenv in debian (which ubuntu syncs unchanged).  i wonder if something broke in upstream's 1.11?
[14:58] <smoser> is this expected ?
[14:58] <smoser> $ du -hs ~/.cache/upstart
[14:58] <smoser> 454M    /home/smoser/.cache/upstart
[14:58] <smoser> $ ls -altrh ~/.cache/upstart/dbus.log
[14:58] <smoser> -rw-r----- 1 smoser smoser 410M Feb 24 09:58 /home/smoser/.cache/upstart/dbus.log
[14:59] <barry> zyga, tumbleweed, doko: nope, it's an upstream bug:
[14:59] <barry> 1.11.1 (2014-01-20)
[14:59] <barry>  
[14:59] <barry> Fixed an issue where pip and setuptools were not getting installed when using the --system-site-packages flag.
[14:59] <barry> i will upload a new version to debian and sync it over
[14:59] <zyga> barry: thanks for the quick reaction :)
[14:59] <zyga> barry: will we also get latest pip through that?
[14:59] <smoser> jodh, ^
[15:00] <barry> zyga: yes, inside the venv i think, but outside it, that's a separate package
[15:00] <barry> of course, i never use outside-the-venv pip anyway (that's crazy talk)
[15:01] <smoser> now that i look at the contents, its not upstarts fault i'd guess, but bamfdaemon seems to like to log glib-critical messages a bunch.
[15:01] <zyga> barry: I'm sadly forced to work with things that require system-wide packages installed so that's not an option
[15:01] <smoser> (bamfdaemon:3853): GLib-CRITICAL **: Source ID 163665 was not found when attempting to remove it
[15:01] <barry> zyga: no, what i mean is that /usr/bin/pip is a separate thing, which i don't think sane people on a distro like debuntu should be using if they can help it ;)
[15:02] <tumbleweed> it'd be very nice to not bundle pip in virtualenv
[15:02] <tumbleweed> but I can't figure that one out
[15:02] <zyga> barry: ah, sure
[15:03] <zyga> barry: we use it to get some level of consistency between 12.04 and 14.04 where we are willing to use things not available on 12.04
[15:03] <jodh> smoser: I don't see that locally. What does tailing the log show? Reminds me, we could do with https://code.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate being reviewed some time ;)
[15:03] <zyga> (but only inside that virtualenv)
[15:03] <barry> zyga: right.  it should work inside venv with --system-site-packages
[15:04] <zyga> barry: so is there a bug still needed or is the sync the only thing that is required? can I help somehow?
[15:06] <barry> zyga: no, you don't need to file a bug.  i could build a test .deb if you want
[15:06] <zyga> barry: absolutely, is it just a rebuild of python-virtualenv from debian?
[15:07] <smoser> jodh, theres a bunch of bamfdaemon warnings in it at the end, but that accounts for only a tiny piece.
[15:07] <smoser> its quite possible this is just grown forever an dnever been truncated
[15:07] <smoser> i surely have never manually cleaned it and hope that isnt expected :)
[15:07] <barry> zyga: well, first i have to update the version in debian ;)  i could put up some .debs for you to install and test before it clears debian and gets sync'd into ubuntu
[15:08] <barry> zyga: i *am* going to test the new debian version first
[15:08] <zyga> barry: fix it in debian svn
[15:08] <zyga> barry: and I'll build and test that
[15:09] <xnox> barry: ! =) hello.
[15:09] <jodh> smoser: if you haven't restarted your session that could be true - the current session logrotate job only rotates once, soon after login (hence my [o/s] MP to run periodically)
[15:09] <barry> zyga: watch #debian-python :)
[15:09] <barry> xnox: hello!
[15:09] <xnox> barry: so unity8, ubuntu-ui-toolkit, and a few core-apps clicks fully pass under python3.
[15:09] <xnox> barry: i'm running through the rest of clicks.
[15:09] <barry> xnox: i've seen your blueprint updates, thanks!
[15:09] <zyga> barry: ok
[15:10] <xnox> barry: the bits which will hold up python2 on the phone are: gdebi-core, ofono-scripts.
[15:10] <barry> xnox: what's the status if your phablet-tools branch?
[15:10] <xnox> barry: i'm in the mean time going through other clicks.
[15:10] <xnox> barry: my phablet-tools branch is wonderful =) and fully works as needed.
[15:10] <barry> xnox: how do we land it? :)
[15:10] <xnox> barry: as in, it does proper python2/python3 setups and can execute either tests.
[15:11] <xnox> sergiusens: can we land phablet-tools branch? it's now been fully tested with both deb and click based tests both under python2 and python3 and it's wonderful.
[15:12] <smoser> jodh, you have a suggestion on how to determine when i logged in ?
[15:13] <barry> xnox: so, gdebi-core and ofono-scripts.  what's up with them?
[15:14] <xnox> barry: gdebi-core is pulled in by packagekit-backend-aptcc, which cjwatson expressed desire to keep (as it's useful to query system installed package info)
[15:14] <xnox> barry: and that's not used on the desktop, cause we seed python3 "fake-packagekit api" instead.
[15:15] <xnox> barry: and gdebi-core appears to be python2 only at the moment. We could drop the dep from packagekit-backend-aptcc, but i'd rather not.
[15:15] <sergiusens> xnox, sure, let me give it a silo
[15:15] <xnox> barry: ofono-scripts, are used for testing/manually driving the GSM/SIM stack, and they are python2 only upstream at the moment.
[15:15] <xnox> barry: porting them to python3 only or bilingual would be nice, and pushing that upstream / do a distro-patch.
[15:15] <sergiusens> xnox, you can probably remove them from the default build
[15:16] <sergiusens> if in a hurry
[15:16] <xnox> sergiusens: correct, at the moment we are attempting to keep them.
[15:16] <sergiusens> it's not an exposed interface
[15:16] <xnox> sergiusens: we have a few other things to release, before ofono-scripts becomes dead-last one.
[15:16] <xnox> sergiusens: barry: so yeah, with both gdebi-core and ofono-scripts => we could just drop them from the seed, but it would be nice to port them anyway.
[15:17] <barry> xnox: i see LP: #1283571 attached to the blueprint.  is there a bug or task for gdebi-core?
[15:18] <xnox> barry: yes, one sec.
[15:18] <xnox> bug #1283574
[15:18] <xnox> now linked on the blueprint.
[15:19] <barry> xnox: excellent, thanks
[15:21] <barry> Laney, sergiusens: so landing-010.  can you test those packages according to the si test plan?  if i can get a second +1, then i think we'll be safe to land it
[15:21] <bdmurray_> seb128: thanks for looking into the retracer issue, it'll be the same problem with errors
[15:21] <Laney> barry: I added another UI fix to u-s-s & seb128 is going to test it
[15:22] <barry> Laney: ack
[15:22] <Laney> I tested it myself earlier without that UI fix and it mostly worked
[15:22] <Laney> just showed a buggy state while the update was downloading
[15:22] <barry> mostly? ;)
[15:22] <seb128> bdmurray_, how come e.u.c gives no bt at all where launchpad retracing had some useful functions (even if some symbols are missing)
[15:22] <Laney> hopefully this additional thing fixes that
[15:23] <barry> Laney: and that's with the previous behavior re-enabled right? (i.e. starts update when s-s panel is open, tries to start again when Updates is clicked)
[15:23] <Laney> ya
[15:23] <Laney> basically it said "Checking for updates" with a spinner instead of something more useful
[15:23] <Laney> as it actually was downloading the update
[15:23] <Laney> then the popover came up correctly and I could install it
[15:23] <barry> cool
[15:23] <doko> pitti, are autopkg tests really running? don't see much progress ...
[15:24] <bdmurray> seb128: probably because it is marked as failing, but I'll double check.
[15:25] <pitti> doko: they are, but there's a rather huge backlog, mostly due to eglibc triggering the world twice
[15:25] <jodh> smoser: try "ps -ostart,comm,pid -p$(initctl list-sessions|awk '{print $1}')". You can run the logrotate session job any time fwiw ("start logrotate").
[15:27] <smoser> jodh, i just opened bug 1284164 and am currently uploading 'dbus.log.bz2'.
[15:27] <seb128> bdmurray, thanks
[15:37] <jodh> smoser: thanks - bug updated.
[15:38] <smoser> jodh, note, that while bamf is the *last* annoyance listed
[15:38] <smoser> it is i think ~ 1%
[15:50] <Laney> barry: did you kill --testing?
[15:51] <barry> Laney: no, but you do need system-image-dev installed
[15:52] <Laney> hmm
[15:53] <barry> i'm pretty sure that *has* to work, otherwise the test suite would fail ;)
[15:53] <Laney> like this: sudo system-image-dbus --testing=update-manual-success right?
[15:54] <barry> should be, yes
[15:56] <Laney> system-image-dbus: error: unrecognized arguments: --testing=update-manual-success
[15:57] <barry> Laney: system-image-dbus --help ?
[15:59] <jodh> smoser: bug updated again
[15:59] <seb128> Laney, do you have system-image-dev installed?
[16:00] <barry> Laney: well, that's interesting. i get the same bug
[16:00] <Laney> ruh roh
[16:00] <barry> i'm also seeing the weird NoneType error on package install that doko observed last week
[16:03] <barry> Laney: looks like we have a missing dep
[16:04] <barry> Laney: the workaround is to apt-get install python3-psutil.   i'll update the packaging branch and mp.  we'll need another silo build
[16:04] <Laney> ack
[16:06] <Laney> barry: is there a testing mode which simulates a long-running download?
[16:06] <Laney> so I can reproduce this other bug
[16:06]  * barry looks
[16:07] <Laney> I think under testing the first CheckForUpdate finishes before you get to click on the entry
[16:10] <barry> Laney: there isn't.  i do two things: a non --testing update against the real server is slow enough (given a sufficiently old flash revision) to take a long time to download.  in my test suite, i create a bunch of 100MB data files, and use the --testing=live with a client.ini that points to my test suite's http/https server.  that test takes long enough to trigger the issue (before the patch).  you could use the same technique.  it's a
[16:10] <barry> bit tricky to set up all the keyrings and signed files, but systemimage.testing.helpers has lots of methods to do just that
[16:10] <barry> Laney: tl;dr: doable, but takes a little work ;)
[16:12]  * Laney whispers "sleep()"
[16:13]  * barry mutters feature request bug
[16:14] <dobey> barry: hey. do you have any idea how much work it would be to get a python3 version of launchpadlib? or is lazr.restfulclient a huge problem?
[16:14] <Laney> oh look, a small bug appears
[16:15] <barry> dobey: "a lot" :(
[16:15] <dobey> :(
[16:15] <barry> dobey: last time i looked at it (admittedly a cycle or so ago) i thought it would be less work to ditch the whole stack and write it again from scratch without all those dependencies
[16:17] <barry> dobey: but we may just be talking about different degrees of infinity here
[16:18] <dobey> well, wadllib appears to be ported, and seems like a necessity here. i think lazr.restfulclient is the big remaining roadblock
[16:18] <barry> dobey: yes
[16:19] <barry> dobey: unfortunately, i don't think it's a trivial port
[16:19] <dobey> yeah, probably not
[16:19] <dobey> :-/
[16:20] <dobey> ah well
[16:22] <Snow-Man> pitti: Really surprised to hear that as I feel that it makes management much easier if conf.d-style directories exist and are enabled by default.
[16:22] <dobey> wow. indicator-datetime keeps crashing constantly for me now :(
[16:22] <barry> i may tackle it again... someday.  but as i said, i'm really tempted to just rewrite it.  then again, i'll be tempted to fix its api too, so that's probably not a recipe for success ;)
[16:23] <Snow-Man> pitti: Being enabled by default should allow most users to use it and configured things through the conf.d dir instead of having to hack up the .conf files directly.
[16:23] <Snow-Man> pitti: I don't see any situation where we would force the user to have a conf.d directory- is there anything which does that?
[16:23] <seb128> dobey, bt?
[16:24] <dobey> seb128: https://bugs.launchpad.net/bugs/1284172
[16:25] <seb128> charles, tedg: ^ saw that one?
[16:26] <dobey> barry: yeah. it might be easier to write a new lib on top of wadllib that doesn't use lazr stuff
[16:26] <charles> seb128, got it
[16:26] <dobey> anyway, time to get some lunch
[16:26] <seb128> charles, thanks
[16:26] <seb128> dobey, seems charles is on it ;-)
[16:26] <dobey> thanks
[16:27] <zyga-afk> re
[16:27] <charles> seb128: I see the bug, datetime isn't testing the ecalcomponent's summary for NULL before stuffing it into a std::string
[16:28] <charles> strange to have a NULL summary, but still, not bounds-checking isn't cool
[16:29] <seb128> is the e-d-s api supposed to return NULL? in that an error case?
[16:29] <xnox> is there a cli for packagekit? i need to trigger distro-upgrade
[16:31] <charles> dobey, is 1284172 repeatable for you s.t. you can test a patch?
[16:32] <charles> seb128: there are two places where we're using strings in that function -- one is to get the color hint from an ECalClient, and one where we get the summary
[16:32] <charles> so one of those is returning NULL and we're putting it into a std::string
[16:33] <charles> It probably is possible to have a component without a summary. I'm not sure how you'd do it via, say, the Evolution gui
[16:33] <charles> but these components can be created anywhere
[16:38] <seb128> charles, k
[16:39] <seb128> charles, in any case seems like it's worth putting the fix up for review, dobey can test from the ppa later on when somebody does a landing request
[16:40] <charles> seb128, dobey: https://code.launchpad.net/~charlesk/indicator-datetime/lp-1280341/+merge/207970
[16:45] <rsalveti> awe: pitti: ogra: is there a way for phonesim to not export the data call capability in touch?
[16:45] <rsalveti> NM takes a while to settle down because it tries to connect a few times
[16:45] <rsalveti> http://paste.ubuntu.com/6987869/
[16:45] <rsalveti> and that happens for every reboot in our CI environment
[16:47] <ogra> do we use it for anything ?
[16:47]  * ogra guesses thats a cyphermox question ... he will know how to suppress it in NM
[16:48] <cyphermox> not without code.
[16:48] <cyphermox> phonesim is meant to export these things, so that it can simulate them
[16:49] <ogra> well, we want to get rid of all the preinstalled testing stuff on the images anyway
[16:49] <ogra> could we probably have a switch in phonesim to turn it off except when we are actually testing ?
[16:49] <ogra> pitti, ^^^
[16:49] <xnox> ogra: oh, oh, remove ofono-scripts first!
[16:49] <ogra> (like an /etc/default/phonesim
[16:49] <xnox> ogra: it's testing stuff.... =)
[16:49] <ogra> )
[16:50] <ogra> xnox, no it is debugging stuff :P
[16:50] <xnox> ogra: LOL!
[16:50] <ogra> xnox, and thats awe's decision, not mine :)
[16:50] <ogra> i know that they are needed for people that want to use features we havent got a UI for though
[16:50] <xnox> ogra: i'd love to see the line between debugging and testing =) it's even more blurry than sysadmin and devops.
[16:51] <xnox> or ci and qa.
[16:51] <ogra> haha, yeah
[16:51] <ogra> well, but i think the point is, get the designers to design us teeh UIs and we can quickly drop it
[16:52] <ogra> (if you accidentially lock your SIM by typing your PIN false several times, i think the only way to enter the PUK is these scripts)
[16:52] <ogra> (not sure though)
[17:15] <seb128_> doko, https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1273779 ... does it mean we can dropped the workaround? (not sure you saw my question before, there was an irc split)
[17:22] <seb128> doko, just saw you did it, thanks
[17:35] <pitti> rsalveti, ogra: I suppose you could call it with a different XML with the data/call capabilities ripped out, but I haven't tried that
[17:35] <pitti> ogra: ofono-phonesim should not be installed by default; tests should pull ofono-phonesim-autostart as a test dependency only
[17:39] <ogra> pitti, right, we found the problem lies elsewhere
[17:39] <ogra> pitti, the test ppulls it in, but never uninstalls it
[17:39] <ogra> which then makes it hog some CPU in later tests
[17:43] <rsalveti> ogra: pitti: problem is that it's installed when setting up the test build
[17:44] <rsalveti> then at every reboot we get that issue
[17:44] <ogra> rsalveti, right, we need to uninstall it
[17:49] <dobey> charles: evolution-calendar-factory (i think) was eating up ~35% cpu when the crash occurred. the crash isn't happening again for me when i open the indicator rihgt now, but i'm also not getting any events shown in it; even though i have multiple calendars with daily events
[18:00] <jtaylor> doko: why did you sync octave?
[18:00] <jtaylor> its a relatively large unfinished transition
[18:01] <jtaylor> I'm really unhappy about it but its weird after ff
[18:02] <jtaylor> but I'm not happy that it now seems to collides with my qhull transition which I hoped have to finish yesterday :(
[18:05] <doko> jtaylor, was looking at support for ppc64 and arm64. currently syncing and uploading
[18:06] <jtaylor> is octave really important for that?
[18:09] <Laney> I don't know of any blanked FFe for that kind of thing
[18:35] <mapreri> Hi! I'm about merging varnish, and I'm wondering if I can/should apply this: https://bugs.launchpad.net/ubuntu/+source/varnish/+bug/1284095
[18:42] <jtaylor> mapreri: it would be better to bring it up in debian first
[18:43] <jtaylor> if its good for ubuntu its most likely good there too and we don't need to maintain another diff
[18:43] <mapreri> jtaylor: bringing change to debian is always better, but often debian maintainer are not responsive on bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661602
[18:44] <mapreri> I don't think this worths a NMU...
[18:45] <jtaylor> maybe just ping the bug again, its possibly just been overlooked
[18:48] <mapreri> jtaylor: so, I'm emailing the bug, let's see what happen
[19:06] <infinity> jtaylor: Hrm, did you see Andrea's followup to your sin() bug?  Might need to dig deeper. :/
[19:06] <infinity> jtaylor: Can you reduce a smaller testcase that doesn't involve python/ffi?
[19:07] <jtaylor> I wanted to check it again soon
[19:07] <jtaylor> can you reproduce it?
[19:08] <jtaylor> the testcase is quite easy to run in an trusty chroot
[19:08] <infinity> jtaylor: Haven't tried, but I assume I can reproduce it on Ubuntu, where you did.
[19:08]  * infinity does so now.
[19:08] <jtaylor> I can try changing compiler
[19:40] <infinity> jtaylor: Your debugging instructions leave something to be desired.  If you're sure it's sin() acting up, you'd think a 2-line testcase in C would be less hassle than indirection through python?
[19:40] <jtaylor> you'd think
[19:41] <jtaylor> I failed to create a C testcase
[19:41] <jtaylor> I'm guessing something run during cffi tests changes the rounding mode and screws things up
[19:41] <jtaylor> I didn't find what
[19:42] <jtaylor> regardless of rounding mode change the result should not be that wrong
[19:43] <jtaylor> I guess I could try and hunt down all libc calls done by cffi
[19:44] <jtaylor> but the time might be better spent by someone knowing this code just running cffi maybe he/she sees the issue a lot faster
[20:17] <directhex> how often does update_output update?
[20:19] <infinity> directhex: Same frequency as update_excuses.
[20:22] <directhex> ...
[20:23] <infinity> directhex: Whenever the publisher runs and the archive changes is the correct answer.
[20:23] <infinity> directhex: Which is anywhere from once every 5 minutes to once every half hour, to once every many hours on lazy weekends.
[20:26] <Laney> directhex: Look at excuses first, anyways
[20:28] <Laney> (which will be confused until mono gets out of NEW on i386)
[20:28] <Laney> (also blocked by the freeze)
[20:31] <Noskcaj> Do we want to sync http://packages.qa.debian.org/r/ruby-tilt.html ?
[20:31] <Noskcaj> Apparently the 2.0 release broke a lot of things
[20:35] <Noskcaj> slangasek, the glm ftbfs is fixed in the new upstream bugfix release. It requires manual refreshing of a patch, so i can't package it.
[20:35] <Noskcaj> (i pinged you since you were the last ubuntu uploader of it)
[20:52] <slangasek> Noskcaj: I may have uploaded the package in the past, but it's in sync now, so there's no reason to look at me in particular :)
[20:56] <Noskcaj> just wondering if you new the package very well.
[20:56] <Noskcaj> Can someone please update glm? should fix the ftbfs
[20:57] <slangasek> what testing have you done of the new version of the package?  Have you checked whether a FFe is needed for the new upstream version?
[20:57] <Noskcaj> Just test building both versions in a PPA. And it's a very minor release change, i'll find the changelog now
[20:58] <slangasek> have you checked whether the problem is reproducible on Debian unstable?
[20:59] <Noskcaj> debian built fine two weeks ago, so i doubt it
[20:59] <doko> kenvandine, the bug submitter for bug #1269978 did ping me. could you have a look?
[21:00] <kenvandine> doko, sure
[21:01] <Noskcaj> My only point is the current release failed to build in my PPA, the new release built, and http://paste.ubuntu.com/6991073/ is the changelog
[21:03] <slangasek> Noskcaj: well, #5 is already listed as having been cherry-picked into the current package, and I don't see how any of the other changes listed there would have fixed this build failure... and the current version of the package doesn't fail to build for me locally either
[21:03] <Noskcaj> strange
[21:04] <Noskcaj> How much memory did the build use for you? The ftbfs log seems to be that the build froze for some reason
[21:04] <Noskcaj> as was my failure, and building it locally made my pc crash
[21:05] <slangasek> the memory usage isn't problematic; 1.2G or so
[21:05] <slangasek> well, and growing
[21:05] <slangasek> but that's for the 'matrix' test, which isn't where it broke in the build test
[21:10] <slangasek> Noskcaj: so at this point I would conclude that the build failure is intermittent, and unless someone can reproduce it locally I don't think we should conclude that a new upstream version is a proper fix
[21:10] <Noskcaj> makes sense
[21:20] <directhex> can someone please purge the ppc64el binary packages from src:mono? it isn't usable, and should never have been considered ready for an LTS
[21:23] <jtaylor> infinity: fwiw I just build package libc with -Og and the issue is gone :(
[21:26] <infinity> directhex: Perhaps if the packaging didn't ignore its testsuite...?
[21:27] <infinity> directhex: That would seem much saner than arch-restricting it, then people could SEE the problems and put in the porting effort.
[21:28] <directhex> infinity, i could make some specific test failures critical
[21:29] <infinity> directhex: pinvoke*?
[21:30] <infinity> Anyhow, "just removing mono" isn't as simple as that.
[21:30] <directhex> infinity, pinvoke.exe is the main one, the others are edge casey
[21:30] <infinity> It has a ton of rdeps.
[21:30] <directhex> &*^&(%^%
[21:35] <infinity> directhex: So, we can clean this up.  I'm just multitasking a bit too hard right now.
[21:36] <infinity> directhex: But, while you could yell at doko for enabling it in the packaging, I think it's pretty sane to suggest that your package shouldn't ship kown-broken binaries.
[21:36] <infinity> Running a testsuite and then ignoring it is a bit pointless. :/
[21:38] <jtaylor> can one emulate ppc64el somehow now?
[21:38] <jtaylor> still would like to know whats going on with numpy on tat platform
[21:38] <jtaylor> (it ignores its testsuite result ...)
[21:39] <mwhudson> how is the platform with mis-aligned accesses?
[21:39] <infinity> qemu-system-ppc64 doesn't seem to quite do the trick on x86, last I tried.
[21:39] <mwhudson> i think numpy luurves mis-aligned access
[21:39] <jtaylor> mwhudson: yes but it works on platforms which bus error on missaligned
[21:40] <mwhudson> ok
[21:40] <jtaylor> considerable effort is spent on keeping it working
[21:40] <jtaylor> (too much in my opinion but ...)
[21:43] <jtaylor> I guess its actually the long double patch ubuntu carries
[21:43] <jtaylor> but thats just guessing
[21:44] <jtaylor> if someone can give me a backtrace I can have a look
[21:47] <jtaylor> hm latest log doesn'T show a crash anymore :O
[21:48] <jtaylor> nice probably was an issue somewhere else then
[22:07] <Unit193> https://launchpadlibrarian.net/166777028/dropbear_2013.60-1ubuntu1_2013.60-1ubuntu2.diff.gz That presumes the only reason to put dropbear in the initramfs is if you have something in crypttab, not taking into account if DROPBEAR is set to y or n.
[22:11] <Unit193> http://paste.openstack.org/show/x2OknRbbgwzf0Fyov8u8/ perhaps something like that would be better?