[04:49] <pitti> Good morning
[04:49] <pitti> Noskcaj: python-dbusmock is fixed for upower now, FYI
[04:49] <pitti> Noskcaj: django-celery built, so apparently someone quietly retried it already
[08:37] <Noskcaj> pitti, good to know
[09:50] <popey> ☹ bug 1314796 has broken my utopic chroot
[10:07] <apachelogger> mvo_: have you moved apturl functionality into the software center already? I am currently preparing kubuntu ports to qt5 and probably will move the kde side of apturl into muon, so as far kubuntu is concerned apturl will probably become unused in 15.04
[10:13] <mvo_> apachelogger: yes, software-center can deal with the apturl stuff
[10:16] <apachelogger> mvo_: groovy, we can probably consider retiring apturl then
[10:16] <mvo_> +1 for that
[10:55] <pitti> jodh: thanks for your patch in bug 1342586, I'll apply to git!
[10:56] <pitti> jodh: what do you mean with "the packaging branch is out of date"?
[10:56] <jodh> pitti: the systemd bzr branch is out-of-date
[10:56] <pitti> oh, bzr
[10:58] <pitti> jodh: how urgent do you think is this?
[10:59] <jodh> pitti: the bugfix or the branch issue? :)
[10:59] <pitti> jodh: I don't care about the bzr branch, I have an ubuntu branch in the debian systemd packaging git :)
[10:59] <pitti> jodh: I mean the crash
[11:00]  * pitti tries booting with systemd on utopic du jour
[11:01] <jodh> pitti: well, it means you can't update very easily, so pretty important I'd say.
[11:03] <pitti> jodh: booting with systemd works fine here, but right, lightdm not crashing is a bummer; I'll upload
[11:21] <darkxst> hey pitti
[11:23] <darkxst> how is dependencies.txt generated? see bug 1342923, which lists libglib2.0-0 2.40.0-2, but the retrace has "/build/buildd/glib2.0-2.41.2~git20140710.60fe7b46" from a ricotz ppa (which the retracer can't know about since its not listed in dependencies.txt)
[11:50] <pitti> darkxst: it's asking apt on the reporting system about the versinos
[12:12] <darkxst> pitti, but is it getting the wrong version perhaps?
[12:14] <darkxst> we have five retraces (for the same crash) that show a symbol from ricotz glib snapshot, but the retracer does not know about that ppa, since its not listed as an [Origin: /] tag
[12:32]  * darkxst wonders, we have seen lots of failed retracers, with no real reason why, perhaps this is related, pitti?
[12:33] <pitti> darkxst: that bug does have packages from the PPA in dependencies; does the PPA actually have a newer glib version?
[12:40] <ricotz> pitti, hi, the reporters dependencies.txt refers to glib 2.40.0-2 which suggests only the gnome3-staging ppa is in use, but the trace mentions a snapshot version which happen to match the version i have/had in my ppa
[12:41] <ricotz> (the gnome3-staging ppa doesnt contain a newer package glib)
[13:13] <tseliot> pitti: hi, so, about this reverse dependency thing, bumblebee only "suggests" bumblebee-nvidia, which, in turn, depends on the nvidia drivers: https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002955.html
[13:14] <tseliot> pitti: a suggested dependency shouldn't really cause any troubles, should it?
[13:23] <pitti> tseliot: no, we don't install them by default or consider them in component-mismatches/britney
[13:24] <tseliot> pitti: so is that a false positive?
[13:24] <pitti> Recommends: nvidia-prime (>= 0.5) | bumblebee
[13:25] <pitti> tseliot: so supposedly a bug in component-mismatches then
[13:25] <tseliot> pitti: ok, thanks
[13:33] <xnox>  cjwatson: just noticed https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1274320 when working on mdadm update. Is there anything that can/should be done to resolve this?
[13:34] <xnox> e.g. I just did a stock raid1 mdadm install and ideally i wouldn't be seeing such messages on boot.
[13:36] <dannf> rbasak: sure, that'd be great (1324992 -> trusty)
[13:37] <rbasak> dannf: done already :)
[13:57] <cjwatson> xnox: I have a patch in my Debian inbox which I think will quieten that
[14:00] <xnox> cjwatson: \o/ cool.
[14:31] <Guest71295> hi, I am trying to port ubuntu to powerpc 32 bit little endian.  Am I in right place to ask question?
[14:33] <Guest71295> Does any one know what debian arch name for PowerPC 32 bit little endian?
[14:34] <cjwatson> I'm not sure one has been assigned, though my guess would be powerpcel.  It would be necessary to work with the Debian dpkg maintainers as pretty much the first step
[14:35] <Guest71295> thanks cjwatson!  That's what I thought and currently using it.  I sent email to Debian dpkg maintainer (3 of them) and I haven't gotten a message yet.
[14:35] <cjwatson> Yeah, nothing in dpkg.git
[14:35] <cjwatson> Right, but you'll have to wait for that first.  No point doing a bunch of work and then having to redo it all.
[14:37] <Guest71295> OK.  I will wait for the "confirm" message then.   I would be better to work on something else then. (such as porting xbuilder which seems ceased to support Trusty)
[14:40] <Guest71295> Anyway, I don't have a machine (power8 or so) yet, so I have finished test build powerpc64le multilib with Cross Linux From Scratch, and I am trying to finished
[14:41] <Guest71295> my work with my favorite linux distro, ubuntu.
[14:42] <Guest71295> well, anyway, thank you cjwatson. I will come back if there is any standout progress.^^
[15:17] <hallyn_> stgraber: cgmanager appears to be stuck in utopic-proposed.  but it passed jenkins.  how do i tell why it's hung up?
[15:18] <cjwatson> hallyn_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cgmanager
[15:18] <cjwatson> lxc autopkgtest regression
[15:18]  * hallyn_ notes that url
[15:19] <hallyn_> cjwatson: thanks
[15:20] <hallyn_> interesting.
[15:20] <hallyn_> stgraber: these look like what pitti was pinging you about the other night;  i somehwo thought you'd resolved them - https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-lxc/lastBuild/ARCH=amd64,label=adt/console
[15:29]  * doko shouldn't do a test build with nocheck and introduce a typo in the check code :-/
[15:41] <xnox> =))))))) happens.
[16:12] <hallyn_> cjwatson: d'oh, i bet the lxc failure was due to the same kernel cgroup kernel bug as the cgmanager test was
[17:42] <achiang> stgraber: i'm about to start investigating what it might take to create a deb that would automatically setup an LXC container + other bits. is there any prior art i could look at?
[17:43] <ogra_> achiang, like lxc-android-config ? :)
[17:43] <achiang> stgraber: my first thought is to stick a lot of manual setup stuff into the maintainer scripts
[17:43] <achiang> ogra_: good pointer, i'll take a look at that one
[17:43] <ogra_> (it does exactly that)
[17:44] <ogra_> we rely on unpacking the rootfs in initrd thuogh ... you would have to do that bit somewhere else for yours
[17:44] <ogra_> (the container rootfs that is)
[17:45] <achiang> ogra_: my use case is to create a metapackage that encapsulates a utopic lxc container and holds the ubuntu-sdk bits inside, for deployment on trusty
[17:45] <hallyn_> stgraber: yeah, lxc-test-unpriv fails with the utopic-release kernel (3.16), passes with 3.15, so i assume it's the cgroup-rmdir that's failing;  presumably the ubuntu upstream kernel will also allow it to pass (will test in a minute)
[17:46] <hallyn_> stgraber: anything we can do to let lxc promote anyway?  i suppose i need to find the kernel patch that caused this and try to get it cherrypicked? :(
[17:50] <hallyn_> hm, i'll see which rc fixes it at least
[18:05] <ricotz> doko, hi, seems like graphviz isnt initializing the plugins after upgrading, it refers to libgvc5-config-update rather then libgvc6-config-update in postinst and postrm
[18:41] <doko> ricotz, ok, looking
[19:30] <doko> ricotz, fixed in proposed
[21:00] <hallyn_> stgraber: d'oh.  found the cause of the lxc test failures in jenkins
[21:00] <hallyn_> sending a patch to m-l in a min
[21:03] <hallyn_> hm, this might be a contender for worst commit msg ever, but here goes
[21:04] <hallyn_> stgraber: please ack and push as quickly as possible, and we should get it into utopic-proposed asap to get jenkins to pass
[21:15] <ricotz> doko, thanks
[21:31] <achiang> stgraber: in your blog, why do we need to install things like ubuntu-artwork and dmz-cursor-theme? https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
[21:31] <hallyn_> bc #unicorns
[21:33] <achiang> hallyn_: was that addressed to me? or is that some weird irssi command? :)
[21:36] <hallyn_> achiang: to you :)
[21:37] <achiang> hallyn_: ha. ok, but... i don't get your joke. (it's a joke, right?)
[21:37] <hallyn_> unicorns, pretty artwork...  sorry.  i'll leave now
[21:38] <hallyn_> ok i'm going to push those two patches to git and to utopic
[21:40] <hallyn_> cjwatson: xnox: what is "utopic-release"?  is that for things which are held back by jenkins failures?  or a synonym for -updates?  or what?
[21:46] <hallyn_> (new lxc pushed, hopefully that will unblock cgmanager 0.27)
[21:46] <stgraber> achiang: mostly so things don't look bad :)
[21:46] <Chipaca> is there a way to specify, in a control file, that a package depends on the same version of another package that is built from the same source?
[21:47] <stgraber> achiang: I believe that was mainly visible with steam
[21:47] <stgraber> achiang: and possibly also relevant to skype if you want it to look like a gtk app
[21:47] <achiang> stgraber: ah, ok. i mean i was wondering... if you're using chrome in a container, why do you need a wallpaper?
[21:47] <achiang> stgraber: but anyway, makes sense, thanks
[21:50] <Noskcaj> Host can i make infernal not attempt to build on i386?
[21:50] <Noskcaj> *how
[21:51] <Noskcaj> Since not all i386 machines have SSE2, the debian maintainer has set binaries to only build on amd64, but us building arch: all on i386 means it attempts to build there
[22:01] <xnox> hallyn_: "utopic" is ambigious. on archive.ubuntu.com/ubuntu/dists/ we have 4 suites - "utopic", "utopic-updates", "update-proposed", "utopic-security". However on launchpad those map to utopic series with - "releae", "updates", "proposed", "security" /pockets/
[22:01] <xnox> hallyn_: britney / proposed migration is as follows - all uploads are redirected into "utopic-proposed" from where they migrate to "utopic" (aka utopic-release) if are installable and adt tests pass.
[22:02] <xnox> hallyn_: updates and security pockets are only opened after series becomes stable, at that time "release" pocket is frozen ("utopic" suite on the archive.ubuntu.com).
[22:02] <xnox> hallyn_: more about proposed migration is on https://wiki.ubuntu.com/ProposedMigration
[22:04] <xnox> hallyn_: on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cgmanager you will be able to track if new lxc unblocks things.
[22:04] <xnox> hallyn_: the new lxc is still building and hasn't been tested yet =)
[22:10] <hallyn_> xnox: d'oh, i see.  so -release is a synonym for just 'utopic' bc it's devel release.  sorry, i was being a moron
[22:10] <stgraber> achiang: note that it's "ubuntu-artwork" not "ubuntu-wallpapers" (though I suspect it pulls that latter in). So that's the combination of icon themes, gtk themes, ... that make Ubuntu looks like Ubuntu
[22:10] <hallyn_> thanks
[22:10] <achiang> stgraber: ack
[22:11] <achiang> i was sloppy in my comment
[22:11] <xnox> hallyn_: yeah, terminology is fuzzy =)
[22:12] <hallyn_> all right while i wait for that i can finally look at the StopSession for systemd-shim
[22:13] <achiang> stgraber: if i am in an lxc environment, is there some issue with loading libraries outside of standard LD_LIBRARY_PATH? i have put the ubuntu-sdk in a container and am trying to build my app, which builds a shared lib in a local dir. upon trying to test, i get an error about not being able to load it
[22:16] <stgraber> achiang: I can't really think of anything special there. LXC doesn't do any fancy ld configuration or anything.
[22:16] <achiang> stgraber: hm, must be something else then.
[22:16] <achiang> stgraber: i'll keep digging, thanks
[22:22] <achiang> stgraber: ABI mismatch of sorts. i had built the lib outside the lxc on trusty host, then attempted to run a QML app inside the utopic lxc
[22:22] <achiang> stgraber: rebuilding inside utopic lxc fixed everything :)
[22:29] <stgraber> achiang: good to hear lxc wasn't to blame :)
[22:30] <achiang> stgraber: i'm sure that 90% of the time when i touch something and it breaks, for me specifically it can be root caused to pebkac ;)
[22:30] <stgraber> :)
[22:30] <achiang> stgraber: anyway, my little adventure with lxc is proving fruitful. lxc-izing the ubuntu-sdk helps minimize the dev pain if a user wants to stay on utopic
[22:30] <achiang> sorry
[22:30] <achiang> if a user wants to stay on trusty
[22:31] <achiang> but target utopic
[22:32] <achiang> stgraber: i haven't got there yet, but there will be bits that will require unity8 hosting inside lxc on trusty... i understand you're working on something like that. so when you're off holidays, maybe i can ping you
[22:44] <stgraber> achiang: right, christownsend and I have been working on running a whole unity8 session inside LXC on trusty. I've heard some progress have actually been made on that today though I'm still waiting for the details.
[23:16] <lifeless> has anyone else see reschedules not happenign
[23:17] <lifeless> like, when it should happen it goes nowhere
[23:17] <lifeless> state BUILD task -
[23:19] <mwhudson> lifeless: mischan?
[23:19] <mwhudson> if not i have no idea what you mean :)
[23:22] <Noskcaj-school> Can someone please retry the kanla build in utopic? It should work now.
[23:23] <lifeless> mwhudson: yup
[23:23] <lifeless> mwhudson: openstack foo
[23:23] <lifeless> sorry
[23:28] <cjwatson> Noskcaj-school: retried
[23:29] <mwhudson> lifeless: heh nw
[23:33] <UserError> What is with the signon-ui/signond dependencies?
[23:33] <UserError> I mean really.