=== sarnold_ is now known as sarnold
[01:54] <LinuxPC> Does anyone know of an app to use to connect my LG cell phone to my HP Laptop, so that I can transfer files between the 2 devices?
[01:55] <LinuxPC> I am using Ubuntu 12.04 on my laptop
[02:02] <sarnold> LinuxPC: if you have bluetooth in both you can probably use a bluez-provided obex transfer mechanism
[02:03] <sarnold> LinuxPC: there are a variety of webserver kinds of applications available for many cell phone operating systems, if you can configure one of those you may be able to then use wget --mirror or similar on your laptop..
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
[02:22] <LinuxPC> i will give that a try
[02:22] <LinuxPC> thanks
[02:30] <YokoZar> pitti: Err I hadn't looked into it further, I suppose that means I'm supposed to nudge you
=== mwhudson is now known as zz_mwhudson
=== doko_ is now known as doko
[07:10] <Noskcaj> what happened to qa.ubuntuwire.com ?
[07:24] <geser> Noskcaj: what's wrong with it? It's available for me
[07:43] <pitti> Good morning
[07:45] <pitti> cjwatson: vala mocks> I'm afraid I don't have a recommendation; I haven't used mocks in Vala myself yet, but you might be able to use cmocka?
[07:46] <pitti> slangasek: I figure containers can't do modprobe
[07:46] <pitti> slangasek: so that's a test which we need to mark as "does not work in containers" then
[07:46] <Noskcaj> geser, all the parts pointed to qa.ubuntuwire.org no longer work. e.g. reverse-depends
[07:46] <Noskcaj> and my bookmark of the ftbfs list
[07:46] <pitti> infinity: right, ppc64 is using clone, no overlays; arm is using overlayfs still
[07:49] <pitti> infinity: yes, the arm/ppc64 jobs live in their own sections instead of being part of the matrix job, mostly because we don't gate on them yet
[07:50] <infinity> pitti: Right, okay, then the armhf/eglibc failure is an overlayfs grump (and why I use aufs instead of overlayfs for my sbuild schroots).
[07:50] <infinity> pitti: I'll have to look at that bizarre ppc64el failure sometime though.
[07:50] <pitti> infinity: aufs completely broke all ppc builds on Monday, so I reverted it
[07:51] <infinity> pitti: Oh, super fun.  Can't win, I guess.
[07:51] <infinity> (I use it on all arches here, but that's all arches except ppc64el, maybe there's a bug there that needs sorting)
[07:51] <pitti> infinity: wiht that, upgrading python3.3 in the chroot failed with a dpkg "cannot rename file" error
[07:51] <infinity> I guess I should test it in a ppc64el VM and whine at Andy.
[07:52] <pitti> infinity: then I gave up and just use cloning; much slower, but avoids that kind of fun
[07:52] <infinity> pitti: What was the backing store for your aufs?  ext4 on ext4?  tmpfs on ext4?  Any LVM in play?
[07:52] <pitti> infinity: I had expected tmpfs on ext4
[07:52] <pitti> no LVM
[07:53] <infinity> LVM snapshots are, really, the least dangerous way to do what you're trying to do here, to be fair, it's just far more of a pain to set up.
[07:53] <infinity> (Pot calling the kettle black, cause I should be using LVM for my sbuild/schroot setup too, and don't)
[07:54] <pitti> infinity: well, everything which actually hits the disk is already slow
[07:54] <pitti> infinity: on my laptop I build everything on tmpfs overlays (containers, schroots, etc.); way to go
[07:54] <infinity> pitti: Yeah, I use tmpfs-aufs-on-ext4 on my laptop.
=== jackson is now known as Guest46812
=== Guest46812 is now known as Noskcaj
[08:19] <dholbach> good morning
[08:19] <Noskcaj> evening dholbach
[08:20] <dholbach> hi Noskcaj
[08:21] <Noskcaj> Could you please send another call for sponsors email sometime soon?
[08:23] <dholbach> Noskcaj, you could send one as well? :)
[08:24] <Noskcaj> i wasn't sure i was allowed to, plus you saying it will probably be heard by more
[08:24] <dholbach> of course you are
[08:25] <dholbach> I'm going to run around like a headless chicken for the rest of the day, because I have quite a lot of work ahead of me
[08:25] <dholbach> so feel free to send the mail
[08:25] <dholbach> and I'll follow up to it
[08:25] <Noskcaj> ok, which list(s)?
[08:26] <dholbach> ubuntu-devel@ should be good
[08:27] <Noskcaj> ok
[08:31] <geser> Noskcaj: I just checked again and for me both qa.ubuntuwire.com and .org work
[08:31] <Noskcaj> strange
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[09:10] <seb128> infinity, thanks for fixing firefox/ppc!
[09:11] <infinity> seb128: NP.  Tomorrow sometime (I hope), there should be a ppc porter back online too (that's where I did all my iterative test builds to burn it in)
=== shookees is now known as Guest3383
[09:13] <seb128> infinity, nice
[09:20] <cjwatson> pitti: Mm, yeah, cmocka is the closest I've seen.  I suspect that I might actually end up borrowing ideas from it rather than using it directly
[09:22] <cjwatson> pitti: Since I'm translating selected code from Python to Vala (this is in click), I was actually thinking of writing a crazy Python decorator which generates LD_PRELOADable libraries on the fly and re-execs single tests with them :-)
[09:22] <cjwatson> pitti: But still need to experiment ...
[09:23] <pitti> cjwatson: I'm not aware of anything resembling python-mock for Vala (would probably be rather difficult to do as C doesn't have the dynamism of py)
[09:24] <pitti> cjwatson: what do you want to mock in particular?
[09:25] <cjwatson> pitti: The equivalent of things in Python like (a) faking up os.stat/os.chown so that I can run ensure-file-ownership tests without root (b) installing a mock subprocess.call so that I can test which subprocesses a method would run
[09:25] <cjwatson> http://paste.ubuntu.com/6998847/
[09:26] <pitti> cjwatson: ah, that indeed sounds like LD_PRELOAD
[09:26] <cjwatson> Yeah.  I was toying with translating the relevant bits of the test suite to Vala too, but I'm not sure that actually helps a whole lot, and I'd be more comfortable leaving the test suite in more or less its original state
[09:27] <cjwatson> Dynamically generated LD_PRELOAD isn't going to be as convenient as mock.patch, but I *might* be able to get it to the point where it isn't a horrible wart
[09:28] <cjwatson> Maybe
[09:28] <pitti> cjwatson: crap's uid_wrapper (http://cwrap.org/#learnmore) provides something like this, but not for chown; but we don't have a package for cwrap anyway
[09:28] <pitti> cjwatson: I guess you'd just need some extension of fakeroot which logs the calls and simply ignores them?
[09:29] <cjwatson> Background: I'm translating bits of click from Python to Vala (could also be C but Vala worked out much easier) so that I can export a libclick to other bits of the phone middleware stack so that they don't have to use the slow exec("/usr/bin/click") path for certain queries - this is expected to save anything up to a second from app startup time
[09:29] <pitti> cjwatson: actually, if you test this in-process instead of a separate process, you might just be able to define chown() etc. in your test, instead of going through the LD_LIBRARY dance?
[09:30] <cjwatson> I have indeed also thought about the approach of making all the relevant calls go through some kind of function pointer scheme that I can substitute in the tests
[09:30] <cjwatson> That's a bit more invasive though
[09:30] <pitti> ah, like introducing a FileOp class with wrappers, which the test can subclass; but that would still only work in-process
[09:31] <cjwatson> Yeah, and also it seems distinctly non-trivial to do in Vala
[09:31] <cjwatson> It doesn't really want to assign to non-delegate functions
[09:31] <pitti> cjwatson: so your tests are in-process?
[09:32] <cjwatson> Yes
[09:32] <pitti> cjwatson: if so, perhaps a cheap trick would be to link it to a test_posix.vapi which re-routes Posix.chown() and friends to your test wrapper?
[09:33] <cjwatson> So, I only want to do this for certain tests, and I'd like to avoid having to relink libclick.so all the time
[09:33] <pitti> (I haven't tried that myself, you might get some "already defined" error)
[09:33] <cjwatson> i.e. I'd like to be able to run the tests against the genuine as-will-be-shipped libclick.so
[09:34] <pitti> cjwatson: hmm; I think in the end a standalone LD_PRELOAD lib which logs the calls instead of executing them might be best
[09:34] <pitti> it's not hard to do, and it will work for any programming language you might port click to in the future
[09:34] <pitti> and it's very flexible as you can load it or not in different scenarios
[09:34] <cjwatson> Yeah, provided relevant function names are reasonably stable anyway
[09:35] <pitti> cjwatson: it's mostly chown, execve(), stat, and getpwnam()?
[09:35] <cjwatson> I actually really like Vala, mostly, and I can sort of imagine how one might do a better mocking framework in it, but I think it needs extensions to the core language
[09:35] <pitti> *nod*
[09:36] <pitti> cjwatson: I like the language and design of Vala too; it just feels like its development got stuck halfway in, one hits rough corners quite often
[09:36] <pitti> too bad
[09:37] <pitti> it's quite understaffed as not that many projects are using it; chicken-egg
[09:37] <cjwatson> Well, I sent a couple of trivial patches for it anyway :)
[09:38] <xnox> since it's C# inspired, using similar syntax to established mock libs, e.g. https://github.com/Moq/moq4
[09:39] <pitti> well, C# uses bytecode and a runtime interpreter/compiler, so there's more places to stuff in mocks
[09:40] <pitti> vala is by and large just a transpiler to C, so there's no extra runtime layer to do modifications
[09:40] <tvoss> cjwatson, is there a specific reason you have chosen Vala for libclick?
[09:40] <pitti> but you can certainly do that in pricinple at compile time, by allowing vapis to get swapped out or partially overridden
[09:41] <cjwatson> tvoss: Yes, I wanted gobject-introspection so that I had trivial bindings in Python because I'm only rewriting part of click, not all of it; I tried both C and Vala and the latter came out much more readable and compact
[09:42] <cjwatson> I wanted to put just about zero effort into bindings
[09:43] <cjwatson> pitti: Well, you could also switch around symbols at run-time in the kind of way cmocka does; doing that at the Vala layer would be helpful because it could make it type-safe
[09:43] <cjwatson> And automatically clean up, etc.
[09:45] <tvoss> cjwatson, well, we were rewriting the scopes engine to get rid of Vala. As pitti pointed out, it's kind of half finished
[09:46] <cjwatson> tvoss: Different contexts, I think
[09:46] <pitti> I use vala in umockdev for pretty much the same reasons: It's much more compact, utterly fast (essentially C speed), and I get automatic bindings
[09:46] <pitti> and it effortlessly mixes C anc Vala code, so I can write the tricky bits (the preload library) in C
[09:47] <cjwatson> tvoss: While I do need to solve the test-suite issues, this is mostly a matter of Vala failing to help me out rather than a matter of Vala getting in my way - I'd have the same basic set of things to solve in C
[09:47] <cjwatson> tvoss: And I'm not prepared to use C++ for anything ever, sorry :-)
[09:48] <pitti> yeah, C++ is an utter pain for libraries (aside from being comparatively hard to grasp)
[09:48] <cjwatson> I'm also simply not skilled in it
[09:48] <cjwatson> And I know better than to think I can teach myself it properly in a short time
[09:48] <tvoss> pitti, I'm not sure that I agree that C++ is a pain for libraries
[09:49] <cjwatson> As I say, I'm very happy with how the core libclick code looks in Vala
[09:49] <tvoss> cjwatson, ack
[09:49] <pitti> tvoss: well, it combines "brittle ABI" with "zero bindings for other languages"
[09:49] <cjwatson> Also, I need to interface with code currently written in C/GObject; one of those projects is the most important client for this
[09:49] <tvoss> pitti, define brittle ABI please, I think that's one of the most common misconceptions about C++
[09:49] <pitti> I also find it comparatively hard to grasp, but I'm well aware that this may just be a personal grudge, and it's certainly not an objective argument
[09:50] <tvoss> cjohnston, which one is that?
[09:50] <cjwatson> tvoss: upstart-app-launch
[09:50] <tvoss> cjwatson, ack
[09:50] <cjwatson> tvoss: So you won't ever be asking us about symbol management issues again, then? :-)
[09:50] <pitti> tvoss: it's way too easy to break the ABI inadvertently, unless you are really careful
[09:50] <tvoss> pitti, zero bindings is not true, specifically generating python bindings for C++ and Javascript is super easy
[09:50] <tvoss> cjwatson, I think the symbol mgmt. issue arises from our tools not being fit for the job
[09:51] <cjwatson> I think that's simplistic
[09:51] <tvoss> cjwatson, that's not a question or language property
[09:51] <tvoss> cjwatson, I have to argue against that. I spent a fair amount of time on the symbols topic and dpkg-gensymbols is tailored towards a C world
[09:51]  * pitti pulls himself out of the "my language is better" discussion before getting too deep in it; we all have our preferences ;)
[09:51] <tvoss> cjwatson, which is perfectly fine, not argueing about that
[09:52] <cjwatson> I think it would be more accurate to say that dpkg-gensymbols is tailored towards the ELF representation of the binary
[09:52] <infinity> pitti: That python-cffi upload of yours, jtaylor thinks it's a toolchain bug.
[09:53] <pitti> infinity: this one drives me crazy; I sbuilt it in trusty-i386, and I can't reproduce it
[09:53] <infinity> https://sourceware.org/bugzilla/show_bug.cgi?id=16625
[09:53] <ubottu> sourceware.org bug 16625 in libc "sin gives wrong result with 2.19 on i386" [Normal,New]
[09:53] <infinity> pitti: Really?
[09:53] <pitti> infinity: even without the most recent patch (which sounded related, but apparently wasn't)
[09:53] <pitti> infinity: ooh, 2.19; I didn't build it in trusty-proposed
[09:53] <pitti> infinity: so I guess that's what the difference was
[09:54] <tvoss> cjwatson, well, it certainly does not take into account that all the stl symbols are weak, which leads to the massive blow-up in symbol file size
[09:54] <pitti> infinity: ah, so -O0 helps, too?
[09:54] <pitti> infinity: thanks for pointing out
[09:55] <cjwatson> tvoss: Yeah, that's apparently subtle, did we point you at https://lists.debian.org/debian-devel/2012/01/msg00759.html ?
[09:55] <infinity> pitti: Rebuilding glibc with -Og made the bug go away.  Not sure how much we can divine from that (and I haven't tried myself).
[09:55] <pitti> infinity: well, it's not like I urgently need that cffi upload in release, I just need it in -proposed to stop DoSing the armhf/ppc64el test boxes; so it can just wait until that eglibc/gcc bug gets fixed
[09:55] <cjwatson> And the followup  https://lists.debian.org/debian-devel/2012/01/msg00760.html
[09:56] <tvoss> cjwatson, nope, no one pointed me there
[09:56] <cjwatson> tvoss: (anyway, I actually think that's a relatively shallow issue, I only haven't dug into it myself because as I said my C++ experience is fairly weak, or more accurately I have a chunk of C++ experience but it predates the STL so isn't very useful in a modern world)
[10:27] <Riddell> am I right in thinking you can't become and ubuntu-dev in whatever flaour without first being an ubuntu-member in whatever flavour?
[10:28] <seb128> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb12
[10:28] <pitti> seb12, haha
[10:28] <cjwatson> Riddell: when I was last involved with this, being a developer was considered to grant membership, rather than membership being a prerequisite
[10:29] <Laney> Indeed, it's not a prerequisite
[10:29] <ogra> yeah
[10:29] <seb128> pitti, shrug :p
[10:29] <cjwatson> Riddell: i.e. you must meet the criteria for membership to be in ubuntu-dev (or similar), but that doesn't mean you have to separately acquire membership first
=== cjwatson changed the topic of #ubuntu-devel to: Trusty Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
[10:29] <ogra> it comes alongside though
[10:29] <seb128> cjwatson, thanks ;-)
[10:29] <Riddell> cjwatson: hmm, so if membership needs to wait 6 months minimum does that mean 6 months before you can become a developer?
[10:29] <cjwatson> Riddell: now you're outside the set of things I remember from when I was on the DMB :)
[10:29] <pitti> ah, I had a trimmed /topic halfway typed in, but cjwatson beat me to it
[10:30] <cjwatson> the criteria for membership was traditionally "sustained and significant contribution", and six months was maybe a guideline for sustained I suppose
[10:30] <xnox> Riddell: to become a developer, one needs to show a sustained contribution for more than one cycle, so yeah 6+ months is requirement for developers.
[10:30] <cjwatson> criteria *were, sigh
[10:30] <Laney> We recently changed the requirements so that you don't have to get membership to become a developer
[10:30] <cjwatson> or *criterion was :)
[10:30] <Laney> In some circumstances etc
[10:31] <xnox> Riddell: i've seen that e.g. contributions to Debian could count as sustained contribution to ubuntu.
[10:33] <seb128> is syncing on new packages to universe subject to feature freeze?
[10:34]  * seb128 unsure
[10:34] <Laney> One of the exclusions which might apply to Riddell is that flavour packagesets still require membership
[10:34] <Laney> yes it is
[10:35] <seb128> Laney, thanks
[10:35] <Laney> np
[10:40]  * dholbach hugs seb128
[10:40]  * seb128 hugs dholbach back
[10:41] <infinity> seb128: Subject to, but likely to get quick verbal exceptions for things that don't look super scary.
[10:43] <seb128> infinity, noted, it turned out that this package was already in and the sponsoring request buggy, but good to know for the next time ;-)
[12:06] <shadeslayer> jibel: any news on those lxc issues?
=== brainwash_ is now known as brainwash
=== _salem is now known as salem_
[12:47] <jibel> shadeslayer, I didn't fix your code because it is based on an old version of the upgrader that has largely evolved
[12:47] <jibel> shadeslayer, instead I deployed 3 profiles https://jenkins.qa.ubuntu.com/search/?q=upgrade-kubuntu
[12:48] <jibel> shadeslayer, there S->T, P->T and P+backports ->T
[12:48] <pitti> nice, and they all succeed!
=== salem_ is now known as _salem
[13:23] <Saviq> pitti, you said ppa-sourced -dbgsym packages should be in their respective PPAs, is that something that should work already, or just a thing that "should be like that"?
[13:35] <infinity> Saviq: Depends on how the PPA is set up but, yes, they can be set up to publish ddebs to the PPA.
[13:35] <infinity> Saviq: That's mutually exclusive with the PPA being used as a copy source to the primary archive, though.
=== psivaa is now known as psivaa-lunch
[14:21] <Saviq> infinity, that'd be fine - so we need to ask for it per-PPA to be enabled?
[14:22] <Saviq> Mirv, think we want that enabled for qt5-beta2 ↑?
[14:22] <shadeslayer> jibel: <3
[14:28] <Mirv> Saviq: 1. there are already manually build -dbg in the PPA, 2. in the past it was found out neither those or .ddebs were enough in case qt not built with debug options, 3. I'm offering the qt5-proper PPA with debug options enabled (non-tested) now that I enabled full release mode for qt5-beta2
[14:28] <Mirv> Saviq: so, I'm not really sure if it would get anything extra to enable ddebs there
[14:29] <Mirv> Saviq: or the 2. is what you know about more and because of which at some point I switched to building everything in debug mode earlier
[14:29] <Saviq> Mirv, hmm ok
[14:29]  * Saviq just assumed I needed -dbgsym, but if everything's there in -dbg, then we're good
=== psivaa-lunch is now known as psivaa
[14:54] <jibel> shadeslayer, and now available on https://jenkins.qa.ubuntu.com/view/Upgrade/
[14:54] <shadeslayer> :D
=== _salem is now known as salem_
=== blaroche_ is now known as blaroche
=== freeflying is now known as freeflying_away
[15:38] <doko> jtaylor, qhull and octave did migrate
[15:44] <slangasek> pitti: bluez doesn't do a modprobe, it only relies on udev loading the module
[15:53] <pitti> slangasek: ok, same thing in a container, I guess
[15:55] <slangasek> pitti: hmm, would it be?  I would expect the request to be handled by the host udev
[15:59] <pitti> slangasek: the host doesn't have bluetooth hardware I expect (it's just a ppc64el vm), and isn't running bluez; woudl such a request somehow be propagated to the host's udev? that sounds odd
[16:00] <slangasek> pitti: bluez tries to start and asks for an AF_BLUETOOTH socket; the kernel doesn't have this address family and goes looking for it; the host udev sees the request and loads bluetooth.ko
[16:00] <slangasek> pitti: this isn't hardware support, but address family support
[16:00] <slangasek> bluez will run with or without bluetooth hardware present
[16:03] <pitti> slangasek: it still seems odd to me that we'd allow a container to cause modprobes in the hosts? but maybe that's supposed to work, I don't know really
[16:05] <stgraber> pitti: containers can't load modules, we block that through appear and capability drop
[16:05] <stgraber> pitti: /me reads the rest of backscroll
[16:06] <stgraber> pitti: hmm, right, that auto-loading bits for network families may still work though. So yeah, ignore me, whatever slangasek said ;)
[16:16] <pitti> stgraber, slangasek: FWIW, it also fails locally on amd64:
[16:16] <pitti> apt0t-bluez_response FAIL status: 0, stderr: Can't open HCI socket.: Address family not supported by protocol
[16:16] <pitti> (in LXC)
[16:17] <pitti> exactly the same as on ppc64el, so I'll keep it in the "does not work in container" category
[16:17]  * pitti waves good night
[16:17] <stgraber> pitti: interesting, so one thing you could do is load whatever modules it needs from the host
[16:17] <stgraber> pitti: similar to what you have to do when you want iptables to work in a container
[16:18] <pitti> barry: please don't review https://code.launchpad.net/~xnox/ubuntu/trusty/ofono/python3/+merge/208117, it's superseded by https://github.com/rilmodem/ofono/pull/56
[16:18] <stgraber> pitti: I guess the "bluetooth" module ought to load everything that's needed for the test.
[16:19] <barry> pitti: i'll forward my comments there (it's much easier for me to review branches in my inbox ;)
[16:20] <xnox> barry: well, i think pitti didn't do my mistakes there with wrapping everything in list()
[16:20] <xnox> barry: why does 2to3 is list() overzealous? just to be on the save side?
[16:21] <barry> xnox: exactly
[16:21] <barry> which is another reason i don't much like 2to3 ;)
[16:22] <cyphermox> stgraber: if you want to do anything useful with bluez though, you'll need a hardware driver too
[16:22] <cyphermox> stgraber: I don't remember seeing a mock bluetooth device driver
[16:23] <stgraber> cyphermox: does kvm provide a fake bluetooth device then? (we're talking about adt here, I'm guessing those actually pass in kvm)
[16:23] <cyphermox> figured it was adt.
[16:23] <cyphermox> I don't know
[16:23] <cyphermox> I could search a bit, I did find a fake-rfkill driver after all :)
[16:25] <cyphermox> stgraber: ignore me, I guess pitti found and uses that already: http://www.spinics.net/lists/linux-bluetooth/msg03127.html
[16:29] <Saviq> Mirv, just remembered... -dbgsym in qt5-beta2 could be useful for other packages :)
[16:35] <tseliot> slangasek: can you approve bug #1282796 , please?
[16:35] <ubottu> bug 1282796 in nvidia-prime (Ubuntu Precise) "prime-xconfig can write an invalid BusID string" [High,In progress] https://launchpad.net/bugs/1282796
[16:35] <barry> pitti: commented
=== robru-is-dying is now known as robru
[17:11] <hallyn> hm, apt-get install software-properties-common in trusty contaienr gives me http://paste.ubuntu.com/7000799/
[17:11] <hallyn> actually that's python3-dbus
[17:12]  * hallyn tries installing apport
[17:15] <stgraber> hallyn: that's a python3.4 bug
[17:16] <hallyn> stgraber: ok thx
[17:16] <hallyn> (i thought it had stopped the pkg install but i see now it didn't)
[17:17] <xnox> barry: can you help with http://paste.ubuntu.com/7000830/ ?
[17:17] <xnox> barry: python3.4 specific failure.
[17:18] <xnox> doko: is this known http://paste.ubuntu.com/7000830/ ?
[17:20] <Saviq> xnox, hey, cross-build issue of qmenumodel: http://paste.ubuntu.com/7000839/ - not sure what should be done about this...
[17:20] <Saviq> (or can, for that matter)
[17:21] <xnox> Saviq: something somewhere build-depends on "python3" instead of "python3:any"
[17:21] <xnox> Saviq: let me check it out.
[17:21] <Saviq> xnox, thanks
[17:22] <Saviq> xnox, looks like it's qmenumodel itself
[17:22] <Saviq> xnox, yeah http://bazaar.launchpad.net/~indicator-applet-developers/qmenumodel/trunk/view/head:/debian/control
[17:23] <xnox> Saviq: i believe all three should be moved to Build-Depends-Indep to be honest.
[17:24] <Saviq> xnox, mhm
[17:25] <xnox> Saviq: also it will probably fail due to dependency on qt5-qmake anyway.
[17:25] <Saviq> xnox, ugh, it probably uses it to determine the qml install dir :/
[17:26] <Saviq> yeah
[17:26] <xnox> Saviq: there are stock install locations for those...
[17:26] <Saviq> xnox, https://bugreports.qt-project.org/browse/QTBUG-29987
[17:27]  * Saviq wonders where others are taking it from these days
[17:29] <xnox> Saviq: i bet they just stick it into "CMAKE_LIBDIR/qt5/qml/"
[17:29] <Saviq> xnox, looks like it, yeah
[17:32] <Saviq> xnox, actually most query qmake still...
[17:32] <xnox> Saviq: i know a lot of _our_ code does, what about non-ubuntu code?
[17:33] <Saviq> xnox, they don't cross-build ;)
[17:33] <Saviq> xnox, so what do they care
=== superm1_ is now known as superm1
[18:35] <barry> xnox: did you figure it out?
[18:38] <seb128> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Trusty Alpha 2 released! | Archive: feature freeze (+ beta1 migration block) | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== psivaa is now known as psivaa-afk
=== bfiller is now known as bfiller_afk
[19:32] <stokachu> anyone come across "postrm-does-not-call-updaterc.d-for-init.d" even though we only have <package>.upstart in our dist
[19:33] <stokachu> i looked through dh_installinit and it seems to handle all the magic automatically, at one point you could force --upstart-only but that was deprecated
[19:33] <stokachu> ive tried adding <package>.postrm with the updaterc.d to attempt to silence that error but no go
[19:35] <directhex> so what's the quickest way to get mono ppc64el removed from the archive? it's a blocker for -proposed transition, and i *really* want that unblocked for FFe reasons
[19:35] <directhex> i recognise that critical test suite failures should cause package build aborts. i'm discussing the best way to do that with upstream
=== henrix_ is now known as henrix
[19:53] <Noskcaj> seb128, I thought Bug 1282937 doesn't need an FFe since all non-bugfix changes we already have as patches
[19:53] <ubottu> bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937
[19:54] <seb128> Noskcaj, 480k of diff isn't something I'm wanting to wave through as "bug fix only", but maybe some other sponsors want to do that...
[19:54] <Noskcaj> ok, i'll file an FFe now
[19:54] <seb128> thanks
[19:56] <Noskcaj> Also, the libxfce4ui merge needs the tarball from http://archive.xfce.org/src/xfce/libxfce4ui/4.11/libxfce4ui-4.11.1.tar.bz2
[19:56] <seb128> Noskcaj, is Debian using the same tarballs?
[19:56] <Noskcaj> yep
[19:56] <seb128> the libxfceui one wasn't happy with the upstream tarball
[19:56] <seb128> or I did something wrong
[19:56] <Noskcaj> strange
[19:57] <seb128> well, I got the tarball from Debian and it was fine, but maybe I got something wrong on the first try
=== cmagina_ is now known as cmagina
=== robru is now known as robru-sick
=== freeflying_away is now known as freeflying
=== lionel_ is now known as lionel
=== hggdh_ is now known as hggdh
=== zz_mwhudson is now known as mwhudson
=== doko_ is now known as doko
=== DrKranz is now known as DktrKranz
=== ChrisTownsend1 is now known as ChrisTownsend
=== LBo is now known as Guest67033
=== doko_ is now known as doko
=== doko is now known as stub
=== stub is now known as doko
=== smoser` is now known as smoser
=== LeonBo is now known as LBo
[22:10] <Noskcaj_school> seb128: The clutter new release builds fine, i said might need exta symbols since i wasn't sure of other arches
[22:15] <Noskcaj_school> seb128_: Did you see my message?
[22:16] <seb128_> Noskcaj_school, which one? having flacky internet there, I don't think so
=== seb128_ is now known as seb128
[22:19] <Noskcaj_school> seb128: The clutter new release builds fine, i said might need exta symbols since i wasn't sure of other arches
[22:19] <seb128> Noskcaj_school, oh, ok, maybe you can try in a ppa to see if that's the case?
[22:20] <Noskcaj_school> I did, build's just finished, ppa is fine.
[22:20] <seb128> good
[22:20] <stgraber> doko, infinity: does that mean something to either of you? http://paste.ubuntu.com/7002151/
[22:21] <doko> is systemd happening that fast?
[22:22] <stgraber> I'm working on patching our logind to work with cgmanager
[22:22] <doko> anyway, afk now
[22:22] <stgraber> I started getting this today, first thought it was my patch, then noticed that a no change rebuild of systemd reproduces it too
=== salem_ is now known as _salem
=== bfiller is now known as bfiller_afk