[05:11] <playdough> How do I get dpkg to not delay ldconfig on a package?  I think it has something to do with triggers, but I'm not sure how to generate my package.
[05:11] <playdough> I put LDCONFIG_NOTRIGGER into a custom postinst, but the standard debhelper doesn't do this.
[05:11] <playdough> All I have is a .install and let debhelper do the rest.  But when I install the package the ld.so.cache doesn't contain my library.
[05:33] <RAOF> playdough: Why are you putting LDCONFIG_NOTRIGGER in?
[05:34] <playdough> In order to force ldconfig to run.  Without it, ldconfig defers but never runs.
[05:34] <playdough> Do I need an 'activate ldconfig' in a trigger file in my package?
[05:34] <playdough> Wait.
[05:34] <playdough> I think I may have tracked it down.
[05:35] <playdough> Seems that our components group removed the ldconfig trigger from our internal libc package.
[05:36] <playdough> I presume that when a package calls ldconfig it automatically activates the ldconfig trigger, no?
[05:37] <pitti> Good morning
[05:37] <pitti> Unit193: ah, thanks for finding out! mind filing a bug against initramfs-tools then?
[05:38] <RAOF> playdough: I think that's right, yes.
[05:39] <playdough> Ok.  That makes sense.  Removing the 'interest ldconfig' from libc-bin is causing all packages that invoke ldconfig to be ignored.
[09:33] <Mirv> xnox: (qt without x) no, I don't have a straight answer to how to do that. it would probably need a lot of experimentating with qtbase-opensource-src's debian/rules, to switch from -xcb & -qpa xcb to something else (for arm) and trying builds without X deps
[12:38] <zbenjamin> ted: did there anything change in application launching? Its not possible anymore to start applications from QtC.
[12:52] <shadeslayer> bdmurray: ping, re https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc in kde-workspace, upstream thinks its https://bugs.kde.org/show_bug.cgi?id=334152 , but has no fix since they can't reproduce the issue
[13:07] <ted> stgraber, Hmm, is there an sqlite file in ~/.cache/url-dispatcher/ ?
[13:08] <ted> stgraber, Hmm, I bet it's because there's no click packages.
[13:10] <stgraber> ted: yeah, there's a sqlite db in there
[13:10] <ted> stgraber, It's probably just getting built after 60 sec when we do the refresh.
[13:10] <stgraber> ted: though both tables are empty
[13:11] <ted> stgraber, That could be if nothing using custom URLs is installed.
[13:11] <stgraber> ted: any way I can force that refresh somehow? as I have no way to get out of that unity8 session, I've put it on a 20s timeout then it VT switches back to my X session :)
[13:11] <stgraber> ted: could be though I have the ubuntu-system-settings app in the dash and that one won't start...
[13:12] <ted> stgraber, It's a couple Upstart jobs. There's url-dispatcher-refresh that signals url-dispatcher-update
[13:12] <ted> stgraber, You can force a url-dispatcher-update
[13:13] <ted> stgraber, Is it a new session each time? I'm curious if URL dispatcher is breaking itself, but my only theory there would be if the sqlite file didn't exist.
[13:13] <ted> stgraber, On a second login, that should be fixed.
[13:14] <stgraber> ted: yeah, it's a new session every time (I wipe .cache .local and .config)
[13:14] <stgraber> ted: I'll add a manual url-dispatcher-update run to my script
[13:18] <ted> stgraber, Hmm, I don't see anything obviously wrong :-/
[13:21] <stgraber> ted: so my guess is that there's simply nothing doing an initial url-dispatcher-update run on first start, so you need to wait 60s before it works. As my session never lasts 60s, then it always fails for me.
[13:21] <ted> stgraber, Yeah, that was my theory. But it looks like the service calls the create code correctly, so it should be fine.
[13:22] <ted> stgraber, It wouldn't do custom URLs, but the application launching is hard coded.
[13:23] <ted> stgraber, I think that error is loading the system settings custom URLs, which would effect the indicators.
[13:23] <ted> stgraber, But it doesn't make sense for the white screen apps.
[14:23]  * ogra_ sees utopic-changes and waits for doko to upload "burn" next 
[14:24] <doko> that's called gcc
[14:24] <ogra_> haha
[14:44] <pitti> xnox: o, I just noticed your autopilot-gtk upload; I'm working on that too ATM, it needs some more adjustmends
[14:47] <xnox> pitti: yeah,
[14:47] <pitti> xnox: I'm also attempting to move it to py3, but I keep running into errors like http://paste.ubuntu.com/7488613/ ; no idea about that yet (nor has thomi)
[14:47] <xnox> pitti: i was too hasty with it.
[14:47] <xnox> pitti: we don't need autopilot-gtk in python3.
[14:47] <pitti> so perhaps I'll propose my py2 fix first, and stash the py3 change, similar to bug 1320211
[14:48] <pitti> xnox: well, not "need", but we want to get rid of -legacy ASAP, I figure?
[14:48] <xnox> pitti: we will never get rid of legacy.
[14:48] <xnox> pitti: unity7 will be stuck using it, until we migrate away from unity7.
[14:48] <xnox> (due to python2 tests of unity7 using crazy pyrex python2 modules to interface with compiz or some such)
[14:49] <xnox> (4 deprecated technologies in one sentence =) )
[14:50] <pitti> xnox: ok, I have the package build and autopkgtest work with -legacy now
[14:50] <xnox> \o/
[14:50] <pitti> (https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/)
[14:50] <xnox> upload =)
[14:50] <pitti> xnox: well, MP :)
[14:51] <pitti> giving the py3 port ten more minutes before I get frustrated too much :)
[14:51] <xnox> pitti: i figured the r73, failed at figuring out r74 =) looks cool.
[14:52] <pitti> xnox: yeah, sorry for the double work on r73; I didn't expect you (or someone else) to jump at this
[14:53] <xnox> pitti: it's only blocking like gcc-4.9 from migrating =)
[14:53] <doko> gcc-4.9 is blocked by the ppc64el ftbfs
[14:53] <pitti> yeah, and blocking my sandbox-run fix, that's how I noticed
[14:57] <pitti> xnox: https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/+merge/220075 FYI
[14:58] <pitti> xnox: oh, I just noticed your https://code.launchpad.net/~xnox/autopilot-gtk/fix-ftbfs/+merge/220045 -- yay collisions :/
[15:00] <xnox> pitti: well, mine one can be rejected, but you do want to cherrypick the upload commit, maybe. just a tag.
[15:01]  * xnox should really stop uploading crap that will just be stuck in proposed anyway.
[15:01] <pitti> xnox: hm, that would look a bit weird in that MP (we don't usually add tags and debian changelogs to MPs)
[15:02] <xnox> it does work.
[15:03] <pitti> or we could just remove the -proposed upload
[15:07] <xnox> pitti: true, won't be able to reuse the version number though.
[15:35] <seb128> bdmurray, ev: something weird is happening on e.u.c daily's view again it seems
[15:36] <seb128> the top entry has 48 reports
[15:37] <seb128> that seems too low to be realistic
[15:42] <bdmurray> seb128: some javascript was updated recently so maybe try a full refresh?
[15:49] <seb128> bdmurray, what do you mean "full refresh"? that's happening in a new browser instance and consistently since this morning
[15:49] <seb128> bdmurray, e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day
[15:49] <bdmurray> seb128: okay, I'm looking into it
[15:49] <seb128> bdmurray, thanks
[15:52] <bdmurray> seb128: its an issue with writing crash reports to the database
[16:08] <bladernr_> Hey, who is responsible for spinning the netboot images? (Specifically the ones that appear at ports.ubuntu.com)??
[16:10] <cjwatson> bladernr_: They happen as part of debian-installer package uploads.
[16:10] <bladernr_> ahhh, is there any way to build on on our own?
[16:11] <cjwatson> You can build debian-installer yourself.
[16:11] <cjwatson> Just feed it to sbuild or whatever, or run "make -C build rebuild_netboot"
[16:31] <mapreri> pitti: hi! I subscribe you to the bug #1319433, it's a really minor issue I introduced setting a wrong Replaces: field :)
[17:35] <killer> Hey , I m tryinng to package an app in debian format , but I m getting an error on running "fakeroot dpkgpackage -F" .Here is the rules file http://pastebin.com/20996iy8 .
[21:38] <geser> wgrant: Hi, could you sponsor bug #1321014 when you have a spare minute? Thanks.
[21:52] <suudy> I'm trying to get plymouth working on our custom embedded system (i915 based) and am having trouble getting any output.
[21:53] <suudy> plymouthd is running (plymouth --ping says it is alive), but the screen is blank.  The debug log doesn't show any errors.