[04:51] <pitti> Good morning
[07:52] <dholbach> good morning
[08:16] <mlankhorst> morning
[08:51] <Tribaal> hi all. Quick question -sorry if it's the wrong place to ask, but how can I add my "pin" to the ubuntu memebers map shown on https://wiki.ubuntu.com/Membership (I'm a recent Ubuntu member)
[08:51] <ogra_> urgh, what added all the GL deps to the touch image ??
[08:52] <darkxst> Tribaal, many ubuntu members seem to live in the ocean according to that map!
[08:53] <Tribaal> darkxst: yes, yes, privacy, I know. But I'd like to add mine nonetheless :)
[08:53] <Tribaal> darkxst: I'm one of the very few Ubuntu members living in Africa - I might as well send the message that we're around :)
[08:55] <darkxst> Tribaal, there may be better ways to do that than a broken map ;)
[08:56] <TJ-> Is there a way to force apt to ignore Conflicts|Replaces in order to keep 2 packages installed simultaneously?
[08:58] <darkxst> TJ Conflicts are not arbitrary, they are there for a reason
[09:00] <TJ-> darkxst: I know; and in my case the reason is in the way of work. Currently I use a script to manually fix-up the package lists and dpkg status, but I'd rather do it through an apt configuration option
[09:01] <darkxst> TJ-, if you want help breaking your system, there are probably better channels than this!
[09:02] <darkxst> TJ-, this channel is really for ubuntu development
[09:02] <ogra_> Laney, can we drop the x86 build deps on armhf for https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.4.0-1ubuntu1 ? ... it results in http://people.canonical.com/~ogra/touch-image-stats/208.changes
[09:03] <ogra_> Laney, referring to "- Build-depend on libgl1-mesa-dev and libglu1-mesa-dev."
[09:03] <TJ-> darkxst: Which is what I am doing
[09:04] <ogra_> seb128, is Laney at debconf this week ?
[09:04] <seb128> ogra_, yes
[09:04] <darkxst> TJ-, ignoring conflicts is a bad idea!
[09:04] <ogra_> damned
[09:04] <ogra_> k, thanks
[09:04] <seb128> yw!
[09:05] <TJ-> darkxst: Having the option to do so is a good idea. I hoped there'd be  a pre-existing configuration item that is hidden away, but if not, I'll patch apt to have one
[09:06] <darkxst> TJ-, sure go ahead, but you are playing with fire!
[09:10] <TJ-> darkxst: Fire is fine, I know what I'm doing, I just want to avoid having to run a hook-script. My case is developing GRUB, and needing grub-pc and grub-efi installed alongside each other
[10:51] <Mirv> if a core-dev _or_ MOTU (in this case) would be available for reviewing/acking packaging changes for a CI Train upload, please see https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/14/
[10:52] <Mirv> ok sil2100 is back so he'll check that out
[10:54]  * sil2100 is in meeting spree
[10:54] <sil2100> But yeah, I have a moment now :)
[13:35] <sergiusens> pitti: any idea how to solve this? http://paste.ubuntu.com/8149970/
[13:35] <sergiusens> it's a chroot
[13:36] <ogra_> do we now always need policy-rc.d mangling ?
[13:40] <jamin> has anyone successfully used the text based oem-config in 14.04?
[13:41] <ogra_> probably someone in #ubuntu-server
[13:41] <ogra_> (sounds more like the place where you would use it)
[13:42] <jamin> https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1361595
[13:42] <jamin> I don't think it's possible
[13:44] <pitti> sergiusens: yes, it's bug 1320534
[13:44] <pitti> sergiusens: I did the merge with Debian a month or so ago, but it's blocked on reviewing
[13:45] <pitti> sergiusens: I guess I could try and upload that in isolation though
[13:45] <pitti> I already cherry-picked some other bug fixes this morning
[13:47] <pitti> sergiusens: the update-rc.d warning should be fixed with this morning's sysvinit, I suppose you didn't get that yet?
[13:47] <ogra_> we didnt have an image build yet
[13:47] <ogra_> (so he wont)
[13:48] <pitti> oh, I thought that was from some local/recent deboostrap run
[13:48] <pitti> err, apt-get install, I mean
[13:48] <pitti> (see first line)
[13:48] <pitti> probably missing a dist-upgrade in his schroot
[13:48] <ogra_> ah, right
[13:49] <ogra_> (sorry, didnt mean to rip that out of context)
[13:50] <sergiusens> pitti: yeah
[13:50] <sergiusens> pitti: wrt ogra_'s comment, it's related to not being able to dpkg -i from a chroot in our recovery image
[14:25] <Riddell> seb128: do we have the Adwaita gtk theme in utopic?
[14:27] <seb128> Riddell, it's default since GNOME3, so we have it since precise or something
[14:28] <seb128> not sure to understand the question
[14:28] <Riddell> seb128: hmm I'm still seeing the ugly default theme for evince and the gtk-selector in kde doesn't list adwaita
[14:30] <seb128> Riddell, do you have gnome-themes-standard installed?
[14:31]  * Riddell installs
[14:33] <Riddell> seb128: ah yes that does it, thanks
[14:33] <seb128> Riddell, yw
[14:44] <pitti> sergiusens: I couldn't reproduce it with my schroots, but xnox got it somehow; where did you see that exactly?
[14:44] <pitti> sergiusens: reproduction steps would be appreciated in that bug, so I could verify the fix
[14:46] <sergiusens> pitti: ah, it's a complicated chroot created with crouton for the chromebook
[14:46] <sergiusens> it's my armhf builder
[14:47] <pitti> sergiusens: if you have an easy way to check, could you upgrade to the binaries in http://people.canonical.com/~pitti/tmp/sysvinit-merge/ ?
[14:47] <pitti> sergiusens: it has amd64 and armhf
[14:47] <sergiusens> pitti: yeah, I can check
[14:53] <sergiusens> pitti: it gets a bit further, no it doesn't start with invoke.rc.d: initscript ssh, action "start" failed
[14:54] <sergiusens> pitti: ah, it's the same error
[14:56] <sergiusens> pitti: this is crouton btw https://github.com/dnschneid/crouton
[14:56] <pitti> sergiusens: ah, no idea about /var/run/utmp; that might just not work in a chroot; the bug above is about a missing /run/shm/
[14:56] <sergiusens> pitti: yeah, I manually created the dir and the complaints ended for utmp
[14:57] <pitti> -rw-rw-r-- 1 root utmp 0 May  7  2013 /run/utmp
[14:57] <pitti> sergiusens: I have that in my sid chroot
[14:57] <pitti> sergiusens: and /var/run is a symlink to /run
[14:57] <pitti> same in utopic
[14:59] <pitti> sergiusens: so mabe your case isn't about /run/shm/ at all then, and xnox' situation was different
[14:59] <sergiusens> so it's not that bug :-)
[15:00] <pitti> sergiusens: for building a chroot you probably want a policy-rc.d?
[15:00] <sergiusens> pitti: I don't know how that chroot is built; I just use it; but if you say so, I'll look into it
[15:01] <pitti> sergiusens: which of the two is missing OOI, /var/run symlink, or /run/utmp ?
[15:03] <sergiusens> pitti: /var/run is not a symlink here
[15:03] <sergiusens> that may be it
[15:03] <sergiusens> nah, ls'ed wrong; it's a link to /run
[15:04] <sergiusens> pitti: /run/utmp is missing though
[15:04] <pitti> sergiusens: not sure what creates that; perhaps debootstrap itself
[15:04] <pitti> ah no, apparenlty base-files:
[15:05] <pitti> base-files.postinst:  if [ ! -f /var/run/utmp ]; then
[15:05] <pitti> base-files.postinst:    echo -n>/var/run/utmp
[15:05] <pitti> so perhaps that didn't get configured properly in your schroot?
[15:05]  * pitti -> bbiab
[15:46] <caribou> Is it acceptable to have two names listed in the Maintainer field of a package ?
[15:46] <pitti> caribou: yes, with comma separation as usual
[15:46] <pitti> caribou: ah sorry, no
[15:47] <pitti> caribou: that'd be Uploaders:
[15:47] <pitti> caribou: not that it matters at all in Ubuntu; ubuntu specific packages should usually be owned by Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[15:50] <caribou> pitti: thanks, that's for a Debian package
[15:50] <pitti> caribou: so put the primary dev or a team (pkg-*@alioth ML or so) into Maintainer:, and the others into Uploaders:
[15:51] <caribou> pitti: good idea, thanks for the quick answer
[16:07] <tedg> stgraber, talking to hallyn he thought that you had the race nailed down.
[16:11] <stgraber> tedg: oh right, sorry, blurry memory and all. So I think we figured that the race was lightdm spawning the user session before cgmanager was actually started.
[16:12] <stgraber> tedg: in a perfect world we'd be able to get systemd-shim to depend on cgmanager but since that one is dbus activated, that's not quite possible
[16:12] <stgraber> tedg: so an ugly way to avoid the race would be to override the dbus start condition to be whatever start condition it currently has + cgmanager-ready
[16:14] <tedg> stgraber, Does it make sense to start lightdm before cgmanager in general? Or it just works because we're not using cgroups in any system jobs?
[16:14] <pitti> stgraber, hallyn: could we alternatively make cgmanager dbus activatable?
[16:14] <hallyn> tedg: the problem is that not everyone running lightdm will have cgmanager installed
[16:14] <stgraber> pitti: no we can't
[16:14] <stgraber> pitti: cgmanager doesn't listen on the system bus
[16:15] <pitti> ah right, ignore me :)
[16:15] <tedg> hallyn, cgmanager could be start on starting dbus ?
[16:15] <hallyn> dbus isn't always installed
[16:15] <tedg> "That's crazy!" says the client guy
[16:16] <stgraber> tedg: jodh suggested that but that's plain wrong since cgmanager doesn't need the dbus daemon :)
[16:16] <hallyn> cgmanager does start as early as possible 9afaik)
[16:17] <tedg> stgraber, Well, it doesn't need it, but it should start before it.
[16:17] <stgraber> tedg: sure, but there's no way to describe "if service X is around, then wait for it" in upstart jobs :)
[16:17] <hallyn> i suppose we could have a essentials upstart job that emits "cgmanager-not-needed", which gets overridden by cgmangaer
[16:18] <stgraber> otherwise the right thing to do would be to have dbus.conf wait until cgmanager is ready if cgmanager is installed
[16:18] <stgraber> hallyn: that seems rather ugly :)
[16:18] <hallyn> i thought it elegant :)
[16:19] <stgraber> if we want a blocking behavior (and we said that maybe we don't want that to avoid hanging the whole system when something goes wrong), systemd-shim ought to be the one blocking requests until the cgmanager socket is available
[16:19] <tedg> I guess I'm kinda surprised that cgmanager startup is the problem. *a lot* has to start before we run applications, do we know why cgmanager is taking so long?
[16:21] <hallyn> tedg: oh, it's bc yo uneed the cgproxy i think
[16:21] <hallyn> if yo uhad a newer kernel yo uwouldn't have this issue
[16:21] <hallyn> so you run cgproxy, start cgmanager, then run a new cgproxy that talks dbus to cgmanager. then you're finally ready
[16:22] <tedg> Can we make the session upstart startup block on cgmanager being ready?
[16:23] <tedg> I think we get an event for that no?
[16:23] <stgraber> no
[16:23] <stgraber> you need to block before you switch to the phablet user
[16:23] <stgraber> cgmanager needs to be started before logind sets up your user session
[16:23] <tedg> Oh
[16:26] <tedg> How about having systemd-login dbus activate a shell script that blocks until cgmanager is ready?
[16:27] <stgraber> if we are going in that direction, I'd rather we just make systemd-shim itself wait for cgmanager, no point in using a wrapper when we can have the real thing do it properly
[16:28] <stgraber> the obvious problem with that and the reason why it wasn't done that way to begin with is that if cgmanager fails to start, then you won't be able to login
[16:30] <hallyn> well it could have a sane timeout, 10s
[16:30] <hallyn> and a config file to override
[16:31] <popey> Why is mencoder not in utopic? http://packages.ubuntu.com/search?keywords=mencoder
[16:32] <ogra_> popey, probably fallout of the libav transition
[16:32] <popey> oh ugh
[16:33] <ogra_> (just guessing)
[16:33] <tedg> stgraber, So that works for me, is that something you're going to work on a patch for?
[16:34] <LocutusOfBorg1> sil2100, please remove lucene++ from mentors
[16:34] <LocutusOfBorg1> :)
[16:34] <LocutusOfBorg1> it has been uploaded
[16:34] <stgraber> tedg: I haven't done any work on systemd-shim, so that's more a pitti or hallyn question
[16:35] <hallyn> really a q for desrt|pdx - if he's ok with it
[16:35] <pitti> tedg, hallyn, stgraber: what's so wrong about having lightdm start ".. and started cgmanager"?
[16:35] <pitti> under upstart we always need it now anyway, and under systemd the upstart job won't be used
[16:36] <hallyn> on the phablet, probably nothing
[16:43] <tedg> hallyn, Are you suggesting an override on the phablet then?
[16:43] <hallyn> tedg: i was, but maybe pitt's right and we can just do it everywhere
[16:44] <tedg> We'd then need to add a dependency in the binary package, no?
[16:44] <ogra_> tedg, how much boot time will that cost us ?
[16:45] <tedg> ogra_, Not sure, perhaps hallyn knows. It should be the same amount of tasks, just change ordering slightly.
[16:45] <tedg> Depends if it creates a bubble in the boot chart.
[16:45] <ogra_> it does today
[16:45] <tedg> What does? CGManager?
[16:46] <ogra_> (well, i didnt do charts for a while, but cgmanager definitely has its own PID and shows up)
[16:46] <ogra_> everything with a PID has a bootchart entry
[16:46] <tedg> Sure, I'm more saying if it blocks things so that CPU/IO isn't used. Overall we should use the same amount of CPU/IO, just ordering could change.
[16:46] <ogra_> ok
[16:47] <pitti> ogra_, tedg: well, considering that lightdm starting before cgmanager is currently broken, and it just happens to work most of the time, it hardly is a boot time problem at all?
[16:47] <tedg> Honestly, from the UTAH testing it gets the right order 95% of the time anyway :-)
[16:48] <ogra_> tedg, the utah bootchart testing is totally wrong and broken
[16:48] <ogra_> better use phablet-bootchart locally
[16:48] <ogra_> (they test on a device that has a ton of test stuff installed before creating the chart)
[16:48] <tedg> ogra_, I mean the autopilot testing, where we start to see failures when turning on cgroups.
[16:48] <ogra_> ah
[16:49] <ogra_> pitti, how does that breakage manifest ?
[16:49] <tedg> ogra_, Intermittent failures of application startup. They can't create the Upstart jobs for the apps.
[16:49] <ogra_> lightdm depends on the container being started
[16:49] <ogra_> and the container depends on cgmanager being started
[16:49] <sil2100> LocutusOfBorg1: \o/ Thanks!
[16:49] <pitti> I don't know, I haven't seen it myself; I was just catching on to the discussion here that lightdm needs cgmanager so that it can create cgroups for the user sessions (and its own session)
[16:50] <ogra_> right, but so does lxc
[16:50] <sil2100> LocutusOfBorg1: I'm somehow sooo busy recently that I need to find a free time jiffy to do that
[16:50] <ogra_> and lxc comes far before lightdm in the boot process
[16:51] <tedg> Hmm, that's interesting. Wonder how cgmanager isn't started.
[16:51] <ogra_> does cgmanager have semi-ready states it announces via upstart or some such ?
[16:51] <tedg> Perhaps then it's the cgproxy stuff that's confusing Upstart?
[16:52] <ogra_> hmm, could be
[16:52] <hallyn> yes both will send the cgmanage-rready event
[16:52] <tedg> hallyn, But it seems that cgproxy sends it in pre-start instead of post-start?
[16:52] <tedg> Oh, wait, both.
[16:53] <hallyn> yeah, the cgproxy one isn't right
[16:53] <hallyn> i forget, who wrote that bit?
[16:53] <ogra_> so you would actually have to wait for cgproxy, not cgmanager
[16:53] <tedg> Heh, it seems like you should tell Upstart that you exist before everything is signaled ready.
[16:54] <tedg> ogra_, Seems we should be waiting on cgmanager-ready
[16:54] <ogra_> well, which is essentially the same, but yeah :)
[16:54] <hallyn> ogra_: right, cgmanager upstart job shoul dkeep state to know that it started cgproxy and then not send the ready signal
[16:54] <hallyn> i think jodh wrote those bits, hm
[16:55] <tedg> ogra_, the lxc-android-config job is waiting on that event.
[16:55] <ogra_> phablet@ubuntu-phablet:~$ grep cgmanager /etc/init/lxc-android-config.conf
[16:55] <ogra_> start on cgmanager-ready
[16:55] <ogra_> phablet@ubuntu-phablet:~$ grep android /etc/init/lightdm.override
[16:55] <ogra_>            and android)
[16:55] <ogra_> phablet@ubuntu-phablet:~$
[16:56] <ogra_> tedg, right and lightdm is waiting for the android event thats fired after the container is 100% up
[16:56] <hallyn> so who knows where an upstart job could keep that state?  use /var/run?
[16:56] <hallyn> hm, so you're saying this race isn't really possible bc the container wouldn't start?
[16:56] <ogra_> tedg, so you should actually already have a big delay between your session and cgmanager
[16:56] <ogra_> right
[16:57] <tedg> Hmm, stgraber how were you guys seeing the race?
[16:57] <ogra_> container wiats for cgmanager-ready and then emits android once the container is ready
[16:57] <ogra_> and lightdm starts on android
[16:58] <stgraber> tedg: I never saw the race, we did the debugging solely based on feedback from jodh
[16:59] <hallyn> it's still possible,
[17:01] <tedg> stgraber, Do you know what behavior he was looking for to conclude that?
[17:02] <stgraber> tedg: he made cgmanager start on dbus and that solved it for him which suggested some race between something dbus related and cgmanager, with the obvious candidate being shim+logind
[17:05] <tedg> So could logind be started before cgmanager-ready by something else?
[17:06] <tedg> Would it handle cgmanager starting after it already started?
[17:08] <ogra_> Laney, poke
[17:10] <pitti> stgraber, tedg: oh, indeed -- appending "or starting dbus" sounds like a nice (and mostly correct) way for cgmanager.conf's start condition, and doesn't introduce new dependencies
[17:11] <Laney> hi ogra, will look later on
[17:11] <pitti> and will sort itself before dbus
[17:11]  * ogra_ hugs Laney 
[17:11] <tedg> pitti, Apparent hallyn was saying that there are systems with cgmanager but not dbus.
[17:11] <ogra_> Laney, thanks, just wanted to make sure the ping didnt get lost :)
[17:11] <pitti> tedg: that's totally fine -- it's an "or" condition
[17:11] <Laney> nope
[17:11] <pitti> tedg: that more or less just says "if dbus is there, start it after cgmanager"
[17:12] <hallyn> right now cgmanager starts on mounted /sys/fs/cgroup or virtual-filesystems
[17:12] <hallyn> that really should beat dbus
[17:13] <hallyn> unless mounted /sys/fs/cgroup never happens bc it's mounted in initramfs?
[17:13] <hallyn> so yeah that sounds fine
[17:13] <pitti> start on local-filesystems
[17:13] <ogra_> <ou would notice that on the phone ...
[17:13] <pitti> that's dbus, so also very early on
[17:13] <ogra_> the container fully depends on cgmanager-ready
[17:13] <pitti> local-filessystems is almost always satisfied right after initramfs, if you don't have any extra /usr or similar mounts
[17:13] <ogra_> without container, no graphics ...
[17:14] <ogra_> (or lightdm ... or session)
[17:16] <tedg> K, so hallyn is that a patch you can make/upload?
[17:17] <hallyn> tedg: stgraber: pitti:  http://paste.ubuntu.com/8151670/ ook ok?
[17:18] <hallyn> oh is there a bug# for this?
[17:19] <hallyn> i'll use 1357252
[17:19] <pitti> hallyn: LGTM (but please give it a boot test; I'm not exactly an upstart expert)
[17:19] <tedg> hallyn, +1, yeah bug 1357252
[17:20] <pitti> right, I think that's the one jodh pointed me to
[17:21] <hallyn> (building )
[17:21] <pitti> hallyn: applied that here, rebooting
[17:22] <hallyn> shared-mime-info triggers be slow
[17:22] <cjwatson> TJ-: There's no good reason to install grub-pc and grub-efi alongside each other (speaking as a GRUB developer).  The *-bin packages exist so that you can coinstall them and use grub-mkimage etc.  The only purpose of the -bin-less names is to own the system's boot process, and only one package should do that.
[17:23] <pitti> hallyn: seems happy enough here (amd64 utopic desktop du jour)
[17:23] <TJ-> cjwatson: So I can remove the non-bin packages without any undo regressions?
[17:24] <cjwatson> TJ-: I expect you'll want to keep the one you're actually using to boot
[17:24] <cjwatson> TJ-: But assuming you mean "undue", then yes.  I only have one of those installed.
[17:24] <TJ-> cjwatson: Using both, that's why I've been using a script to alter the package lists
[17:24] <cjwatson> But I have both grub-efi-amd64-bin and grub-pc-bin.
[17:25] <cjwatson> How can you possibly be using both to boot?
[17:25] <cjwatson> I mean, routinely.
[17:25] <hallyn> pitti: same here, so pushing
[17:25] <TJ-> cjwatson: Portable disk; able to boot on either type of firmware
[17:25] <hallyn> (will have to push to upstream and debian later)
[17:25] <pitti> hallyn: thanks
[17:25] <cjwatson> TJ-: You can always arrange to manually run grub-install with whatever special options you need after upgrades.
[17:25] <tedg> Thanks hallyn!
[17:25] <cjwatson> TJ-: That will be MUCH easier than messing about with editing package lists.
[17:26] <hallyn> np, let's hope this actually sorts out the evice
[17:26] <cjwatson> TJ-: And that's basically all that the surplus non-bin package will be doing for you.
[17:26] <hallyn> device
[17:26] <TJ-> cjwatson: Yeah, I was looking at an additional script in /etc/kernel/postinst.d/
[17:27] <TJ-> cjwatson: Although I've had an enjoyable day learning the internals of apt :)
[17:27] <flexiondotorg> cjwatson, You might remember that I am working on Ubuntu MATE.
[17:28] <flexiondotorg> cjwatson, How do I coerce Ubiquity to use Marco as the window manager and the themes I've created for Ubuntu MATE?
[17:29] <flexiondotorg> cjwatson, Thanks to you and xnox I submitted merge proposals for adding Marco support to Ubiquity.
[17:29] <flexiondotorg> cjwatson, Which have been accepted and merged for some time now.
[17:30] <flexiondotorg> cjwatson, I have settings packages that make the appropriate gschema overrides.
[17:32] <cjwatson> flexiondotorg: I expect that just needs work in ubiquity-dm.  No idea otherwise.
[17:32] <cjwatson> flexiondotorg: Maybe also in the upstart job file.
[17:34] <flexiondotorg> cjwatson, I added support to ubiquity-dm. Also merged.
[17:35] <flexiondotorg> cjwatson, Upstart job?
[17:35] <cjwatson> flexiondotorg: debian/*.upstart, wherever it is.  (I'm at a conference right now.)
[17:35] <flexiondotorg> cjwatson, Thanks. That is enough of a pointer.
[17:35] <cjwatson> Probably debian/ubiquity.ubiquity.upstart.
[17:36] <cjwatson> But that only really specifies the DM.
[17:36] <cjwatson> So shouldn't matter here.
[17:37] <cjwatson> flexiondotorg: What's actually going wrong?
[17:37] <flexiondotorg> cjwatson, If I select "Try Ubuntu", nothing. Everything is fine.
[17:38] <flexiondotorg> cjwatson, If I select "Install Ubuntu", then the default them in Ambiance not the themes I've configured using gschema overrides.
[17:38] <flexiondotorg> cjwatson, Also the live sessions always drags in Metacity which should be required since Marco is now a suitable depend.
[17:38] <cjwatson> flexiondotorg: I guess that means your overrides are wrong somehow, but I'm afraid I really don't know much about that.
[17:39] <flexiondotorg> cjwatson, No. The overrides are correct. Sorry to be blunt. I've override mate and gnome.
[17:39] <cjwatson> flexiondotorg: Do you mean that the live *image* has metacity when it shouldn't?
[17:39] <flexiondotorg> cjwatson, Yes.
[17:39] <cjwatson> flexiondotorg: The overrides are your responsibility to debug, I'm afraid.  I'm sorry I can't help.
[17:39] <cjwatson> flexiondotorg: For the presence of metacity, you probably just need to seed marco.
[17:40] <flexiondotorg> cjwatson, Also be aware Ubuntu is not being built on Canonical infrastructure right now.
[17:40] <flexiondotorg> s/Ubuntu/Ubuntu MATE/
[17:40] <cjwatson> flexiondotorg: I'm well aware, since if it were then I would have set it up.
[17:41] <flexiondotorg> cjwatson, Come the day I can help setup Ubuntu MATE if you'd like via merge porposals.
[17:41] <flexiondotorg> cjwatson, I am seeding Marco.
[17:41] <cjwatson> flexiondotorg: Where is your image build log?
[17:41] <cjwatson> You're obviously not doing so in the right place :)
[17:42] <flexiondotorg> cjwatson, I fully prepared to accept I've messed it up somewhere 😃
[17:42] <flexiondotorg> cjwatson, I can make my build logs available a bit later.
[17:43]  * cjwatson finds the MATE seeds and does a test germinate run
[17:43] <flexiondotorg> cjwatson, I am seed 'marco' in the live seed.
[17:43] <flexiondotorg> cjwatson, Which then creates a duplicate in the 'desktop' seed.
[17:44] <cjwatson> You don't need it in the live seed, and in any case marco isn't in http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.utopic/view/head:/live
[17:45] <flexiondotorg> cjwatson, So should I leave 'marco' in the 'live' seed and 'desktop' see?
[17:45] <cjwatson> It's not in the live seed, as far as I can see.
[17:45] <cjwatson> Unless your seeds are somewhere other than where I'm looking.
[17:46] <flexiondotorg> cjwatson, You are looking in the right place. marco was in the live and desktop seeds. But I got duplicate warnings so I removed from the desktop seed.
[17:46] <flexiondotorg> cjwatson, Should I leave marco in both the live and desktop seed?
[17:46] <cjwatson> But it is not in the live seed there right now.
[17:46] <cjwatson> It is in the desktop seed, which is where it belongs.
[17:47] <cjwatson> A test germinate run against your seeds doesn't pull in metacity.
[17:48] <flexiondotorg> cjwatson, Hence my confusion as to why metacity is in the resulting image and also the default.
[17:48] <cjwatson> So image builds at least with our code wouldn't pull in metacity, as far as I can see.  I don't know what your code is doing.
[17:48] <flexiondotorg> cjwatson, OK that sounds encouraging.
[17:48] <cjwatson> Perhaps you're using a different build process ...
[17:49] <flexiondotorg> cjwatson, Another issue I can possible chalk up to "if was built officially".
[17:49] <cjwatson> Is your build code pushed somewhere I can see?
[17:49] <flexiondotorg> cjwatson, Thanks for you help again. Most appreciated.
[17:49] <flexiondotorg> cjwatson, Yes. I'll just pushed to current version...
[17:51] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-iso
[17:55] <cjwatson> flexiondotorg: You need to drop "LIVE_TASK='ubuntu-live'" from your modified livecd-rootfs in the ubuntu-mate section.  That'll be causing it to pull in the ubuntu-live task, which won't be appropriate for you.
[17:56] <cjwatson> You're already installing the ubuntu-mate-live metapackage, so the ubuntu-live task is at best redundant and at worst will cause problems like this.
[17:59] <flexiondotorg> cjwatson, Many thanks. I'll make that change.
[18:33] <tvoss> mvo, around?
[18:33] <mvo> tvoss: yes, at a conference so a bit busy, but available
[18:47] <pitti> stgraber, infinity: I'm uploading calibre 2.0.0 to sid which ports from qt4 to qt5; would you consider that a feature (the UI is actually the same), i. e. needs an FFE?
[18:48]  * pitti just purged qt4 from his system, yay
[19:01] <stgraber> pitti: that's a borderline one, I guess just apply for an FFe, I'll confirm it's only depended upon by Edubuntu and then grant you the FFe
[19:05] <jtaylor> when is trusty unapproved being processed next?
[19:05] <jtaylor> been 3 weeks now already
[19:10] <mlankhorst> when you bug sru admins ;-)
[19:12] <arges> jtaylor: which particular package are you interested in?
[19:12] <jtaylor> tango
[19:14] <arges> jtaylor: can you fill in the rest of the SRU template on the bug (regression potential, impact)
[19:15] <arges> jtaylor: also it may be easier to identify where the patches come from if you use the DEP-3 tag 'Origin'
[19:19] <jtaylor> I'd have got to ask the debian maintainer about that, he told me when I sponsored but thats long out of my logs ._.
[19:20] <arges> jtaylor: well its probably ok since the other patchsets seem to be in the same style.
[19:20] <arges> jtaylor: just let me know when you filled out the rest of teh SRU template on that bug
[19:26] <kyleN> just did dist-upgrade on utopic and got this:
[19:26] <kyleN> dpkg: error processing archive /var/cache/apt/archives/unity-schemas_7.3.1+14.10.20140811-0ubuntu1_all.deb (--unpack):
[19:26] <kyleN>  trying to overwrite '/usr/share/glib-2.0/schemas/org.compiz.unityshell.gschema.xml', which is also in package libunity-core-6.0-9 7.3.0+14.10.20140711-0ubuntu1
[19:26] <kyleN> workaround?
[19:34] <seb128> kyleN, try to apt-get -f install it should work
[19:34] <jtaylor> arges: done
[19:34] <kyleN> seb128, didn't
[19:36] <seb128> kyleN, weird, can you paste the log from a -f install?
[19:36] <kyleN> sure, hang on
[19:36] <arges> jtaylor: thanks! Ok accepted.
[19:37] <kyleN> seb128, http://paste.ubuntu.com/8152652/
[19:39] <seb128> kyleN, try to sudo apt-get install libunity-core-6.0-9
[19:40] <kyleN> seb128, http://paste.ubuntu.com/8152688/
[19:41] <seb128> kyleN, try to sudo apt-get install libunity-core-6.0-9 unity-schemas
[19:41] <kyleN> seb128, http://paste.ubuntu.com/8152695/
[19:42] <seb128> kyleN, apt-cache policy unity-services
[19:42] <seb128> kyleN, or try to add unity-services to the install list
[19:43] <kyleN> seb128, your first suggestion: http://paste.ubuntu.com/8152701/
[19:43] <kyleN> seb128, your second: http://paste.ubuntu.com/8152704/
[19:43] <seb128> shrug
[19:44] <seb128> kyleN, add libunity-protocol-private0 qtdeclarative5-ubuntu-content1 to the list?
[19:44] <kyleN> seb128, alas: http://paste.ubuntu.com/8152712/
[19:45] <seb128> kyleN, keep adding the packages in front of the line and see if you manage to unblock it
[19:45] <seb128> like libunity9 ibunity-dev unity
[19:45] <seb128> you might get new ones, try iterating
[19:46] <seb128> did/do you have ppas or weird versions installed?
[19:48] <kyleN> I seb128 not utopic ppas installed
[19:48] <seb128> :-/
[19:49] <seb128> kyleN, adding extra source doesn't help resolving it?
[19:49] <seb128> source->binaries
[19:49] <seb128> to the install line
[19:49] <kyleN> seb128, example command pls?
[19:50] <seb128> kyleN, well, the install you had, addlibunity9 ibunity-dev unity
[19:50] <seb128> ups
[19:50] <seb128> libunity9 libunity-dev unity
[19:50] <seb128> it might give you extra errors with new package name
[19:50] <seb128> keep adding those to the install and try again
[19:50] <seb128> until it gives you one that might work
[19:51] <kyleN> ok. I'll work on this. thanks for the tips
[19:51] <seb128> yw
[19:51] <seb128> well, let me know how it goes
[19:51] <seb128> try just adding those and pastebin again
[19:51] <seb128> it's weird that it requires so much forcing though
[19:52] <seb128> you might try aptitude otherwise, its resolver works better sometimes...
[20:09] <kyleN> sebs, aptitude to the rescue :)
[20:10] <kyleN> $ sudo apt-get install -f
[20:10] <kyleN> Reading package lists... Done
[20:10] <kyleN> Building dependency tree
[20:10] <kyleN> Reading state information... Done
[20:10] <kyleN> The following packages were automatically installed and are no longer required:
[20:10] <kyleN>   linux-headers-3.15.0-6 linux-headers-3.15.0-6-generic linux-headers-3.16.0-4 linux-headers-3.16.0-4-generic linux-image-3.15.0-6-generic
[20:10] <kyleN>   linux-image-3.16.0-4-generic linux-image-extra-3.15.0-6-generic linux-image-extra-3.16.0-4-generic
[20:10] <kyleN> Use 'apt-get autoremove' to remove them.
[20:10] <kyleN> 0 upgraded, 0 newly installed, 0 to remove and 675 not upgraded.
[20:10] <kyleN> seb128, ^
[20:12] <seb128> kyleN, what did aptitude do exactly?
[20:14] <kyleN> seb128, nver used aptitude before :( . It reported a lot of packages and I used the 'g' option to handle them. they were removed and reinstalled (not sure if they all were reinstalled)
[20:15] <kyleN> I have the list of pkgs if that interested you (a copy of part of stdout during the operation)
[20:18] <kyleN> seb128, here are the removals through aptitude: http://paste.ubuntu.com/8152916/
[20:18] <jtaylor> arges: thanks
[20:20] <kyleN> seb128, I still have the complete stdout of aptitude here: http://paste.ubuntu.com/8152929/