[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.


[10:11] <smb> infinity, Holy grep it's crap! I mean the other way round (my build failures of Xen seem to be caused by grep in the sbuild environment deciding in the middle of a file to switch from text to binary mode)
[10:51] <apw> smb, in the middle of a file ?
[10:52] <smb> apw, yep
[10:52] <smb> well not middle but after around 43 lines
[10:57] <apw> smb, could you just switch to grep --text, or something
[10:57] <smb> apw, as a work around, yes
[10:57] <apw> oh its "text" is it, like utf8 or something, sigh
[13:18] <jdstrand> rtg: hey, curious, looking at the 4.4.0-7.22 changelog, I see 'rebase to v4.4.2' and 'Miscellaneous upstream changes'. does the latter include all of the changes that went into 4.4.2 over 4.4.1?
[13:19] <jdstrand> rtg: talking about the upstream changes
[13:19] <jdstrand> I've got an external displayport issue that I've been meaning to report that downgrading to 4.3 fixes
[13:20] <jdstrand> so I keep looking at 4.4 kernel changes. I don'
[13:20] <jdstrand> t see anything related to this, so curious if the list of upstream changes is complete
[13:20] <jdstrand> (it is something I've always wondered about)
[13:21] <rtg> jdstrand, The patches included in v4.4.2 are not listed in the changelog. That seems like an oversight.
[13:21] <rtg> is that what you are asking ?
[13:22] <jdstrand> I was asking about all the upstream changes whenever you rebase, in this base, 4.4.1 to 4.4.2, but more just generally
[13:22] <jdstrand> s/this base/this case/
[13:23] <rtg> jdstrand, during the dev cycle the changes introduced by a rebase are not listed, though they are easy ebough to find (if you know what you're doing)
[13:23] <jdstrand> or more simply, can I rely on Ubuntu's changelog to list all changes from one release to the next, upstream and Ubuntu, or just the Ubuntu changes
[13:23] <jdstrand> ok, that's fine
[13:23] <jdstrand> I imagine the changelog would be rather long
[13:24] <rtg> jdstrand, post dev, all commits are applied on top (modulo CVE rebases)
[13:24] <rtg> so they'll all get listed in the changelog
[13:24] <jdstrand> cool, thanks
[13:25] <jdstrand> all that is going through my mind is "So your saying there's hope" :)
[13:26] <rtg> jdstrand, for a display issue ? don't get too wound up :)
[13:26] <rtg> jdstrand, if you have a bisectable range, then you could work with jsalisbury
[13:27]  * jdstrand nods
[13:27] <jdstrand> I wanted to try the next one from you guys before reporting
[13:27] <jdstrand> I can say for sure that wily's kernel doesn't have this bug
[13:28] <rtg> jdstrand, that bodes well for bisectability
[13:28] <jdstrand> I was then going to (re)try the earliest 4.4 kernel in the archive, then report
[13:28] <rtg> jsalisbury is a wizard
[13:28] <jdstrand> yeah
[13:29] <rtg> jdstrand, plus, I'm about to be on vacation :)
[13:29] <jdstrand> this bug is rather annoying-- the screen just goes blank for 1 second or 2, then comes back, at totally random times, but only on the external monitor
[13:29] <jdstrand> never seen anything quite like it
[13:29] <jdstrand> rtg: nice! enjoy :)
[13:29] <rtg> jdstrand, Intel I assume ?
[13:30] <jdstrand> yes
[13:31] <jdstrand> it seems like the it goes blank at all the wrong times too. almost like its sentient
[13:31] <rtg> jdstrand, I've got Intel on my laptop connected to HDMI 4K monitor. its got some quirks but overall seems to work OK
[13:31] <jdstrand> I may have not gotten inough sleep last night :P
[13:31] <jdstrand> rtg: yeah, this is displayport (mini) 4K
[13:31] <rtg> has it started to talk to you ? maybe you _shoud_ sleep.
[13:32] <rtg> should*
[13:32] <jdstrand> rtg: like you said, some quirks, mostly ok. The biggest quirk is hotplugging the monitor
[13:32] <jdstrand> (other than this bug)
[13:33] <rtg> jdstrand, I have to turn mine completely off once in awhile after resume from suspend. that is about the worst of the quirks
[13:33] <jdstrand> but a dialog comes up that says it couldn't xrandr or something (and the display is all stretched out), but if I tap 'Enter' to dismiss the dialog, it rights itself
[13:33] <jdstrand> rtg: yes, I used to see that more, but see it less often now
[13:34] <jdstrand> it does this whole dance when hotplugging-- the laptop and the display flash, the monitor goes blank, it comes back, it might do it again, etc
[13:34]  * jdstrand shrugs
[13:34] <jdstrand> I'll file a bug for that another day
[13:35] <rtg> jdstrand, slacker. I'm sure jsalisbury would love to have you test about a dozen kernels :)
[13:35] <jdstrand> hey, well, that never worked right so...
[13:36] <jdstrand> actually, the not being able to randr might've worked on wily...
[13:36] <jdstrand> anyhoo, another day. I want to get this odd blanking bug reported
[16:22] <lamont> jsalisbury: good kernel!  next rock?  (bug updated)
[16:31] <jsalisbury> lamont, I'll build it now
[16:36] <lamont> ta
[18:19] <jdstrand> jsalisbury (fyi, rtg and ogasawara_): the external monitor screen blinking bug is bug #1547619
[18:20] <jsalisbury> jdstrand, ok, thanks.  we'll probably have to bisect it.  Are you able to test some kernels?
[18:22] <jdstrand> jsalisbury: yes. will they be Ubuntu kernels? (ie, with apparmor compat, etc)
[18:23] <jsalisbury> jdstrand, sure I can build Ubuntu kernels instead of upstream ones.  I'll post an update to the bug.
[18:23] <jdstrand> jsalisbury: thanks! :)
[18:28] <jsalisbury> jdstrand, Can you first test 4.4.0-1.15 to see if we can narrow the bisect window.  I post a link to it in the bug.
[18:35] <jdstrand> jsalisbury: sure
[18:35] <jsalisbury> jdstrand, thanks.  Then I'll start the bisect and post a test kernel.
[18:37] <jdstrand> hmm, I do have secure boot enabled... I guess I'll need to fiddle with my configuration
[18:37] <jdstrand> oh now, it'll fallback
[18:49] <jdstrand> jsalisbury: fyi, I'm in 4.4.0-1.15-generic. it hasn't happened yet, but that doesn't mean anything. I'll report back in the bug
[19:01] <jsalisbury> jdstrand, thanks
[19:12] <jdstrand> jsalisbury: hah
[19:12] <jdstrand> jsalisbury: the *moment* I started to do real work in a terminal, it happened
[19:13] <jdstrand> I swear this thing is here to annoy the *&%^ out of me
[19:13] <jsalisbury> jdstrand, thanks for testing.  I'll start the bisect with that being the first bad kernel
[19:14] <jdstrand> jsalisbury: thank you for helping resolve this. I can't tell you how annoying this bug is
[19:15] <jsalisbury> jdstrand, np.
[19:15] <jdstrand> I mean it isn't data loss or anything, but it really takes you out of the moment
[19:15] <jsalisbury> jdstrand, I'm sure it does


[01:00] <Lns> sbalneav: Language is overrated... ;)
[03:46] <sbalneav> Evening all
[03:46] <stgraber> hey sbalneav
[03:49] <Ahmuck_> hi stgraber
[15:51] <stgraber> highvoltage: ping
[20:34] <erieslabhu> I have fallen and I can't get up :(
[20:34] <erieslabhu> I have my network interfaces config file jacked
[20:35] <erieslabhu> can anyone offer me some assistance?
[20:35] <erieslabhu> I added a second LAN port so that Edubuntu could be used as a LTSP server, started to configure the file and now I have nothing at all.
[20:36] <erieslabhu> no network card anywhere. When i try sudo /etc/init.d/networking restart, I get Ignoring unknown interface eth0=eth0.
[20:37] <erieslabhu> ok going to ltsp channel
[20:39] <alkisg> erieslabhu: so you need a new interfaces file?


[08:50] <DanChapman> good morning
[08:50] <SaberX01> very early good morning 2:00am here :-)
[08:52] <DanChapman> SaberX01, Wow thats early! :-) I couldn't manage being up at that time
[08:55] <SaberX01> Holidays, .. this time of day si the only time it's quiet around here :-)
[15:28] <elfy> PaulW2U: when you do testcases - it's better for you not to worry about numbering them - we do that when we add them to the tracker system - that's where the numbers actually originatr
[15:29] <elfy> there is already a 1628 ;)
[15:30] <elfy> mmm - not in the branch though ...
[15:33] <elfy> there is now
[15:34] <elfy> PaulW2U: anyway - installing kubuntu to a vm - will deal with those testcases you've got mp for over the next day or so
[16:00] <PaulW2U> elfy: yeah, sorry about that. I missed that until I read the instructions a second time. it was my first attempt though :)
[16:01] <elfy> yep - you should have been about for my first attempt(s) poor old balloons and DanChapman :)
[16:01] <DanChapman> :-)
[16:01] <elfy> of course I blamed bzr for it all
[16:03] <PaulW2U> to a non-programmer it is a little confusing. more kde testcases to come once I know the three that I've done are ok
[16:03] <elfy> PaulW2U: I TOTALLY know where you coming from :)
[16:03] <phillw> I will probably get told off again, but there is a non-pae version of lubuntu 13.10 http://phillw.net/isos/non-pae/
[16:04] <elfy> just ask balloons or DanChapman about talking about autopilot to me ...
[16:05]  * DanChapman has always been impressed with elfy's attempts to 'try' and understand :-)
[16:05] <elfy> PaulW2U: only thing I would be thinking about now - while you can build these testcases and someone will merge them into the tracker - it'll be up to kubuntu qa to sort out the package tracker - at present there's not anywhere for the kubuntu ones to live
[16:06]  * elfy is always impressed at DanChapman's attempts to explain it :)
[16:06] <PaulW2U> elfy: oh, i see. am I wasting my time or do I need to contact someone?
[16:07] <elfy> well I don't know - I've not any idea what the kubuntu plans are - even if they want to do it - I'd ask before doing more
[16:08] <PaulW2U> ok, i just saw all the kde todo's and thought it would be a good place to start
[16:08] <elfy> yea
[16:10] <elfy> PaulW2U: chilcuil did a whole load of bugs and tagged them - I'd find out if kubuntu are going to do anything with them - and if not maybe mark the bugs as invalid or something
[16:11] <elfy> I'll hold off on merging them as well until you let me know there's a need for them - does that sound sensible?
[16:11] <PaulW2U> looking at packages.qa.ubuntu.com now - i see what you mean, no kubuntu, thanks for the heads up
[16:11] <PaulW2U> elfy: yes, thanks
[16:11] <elfy> that's ok - I thought I'd mention it :)
[20:13] <sergio-br2> hi, anyone?
[20:15] <Noskcaj> sergio-br2, always someone
[20:15] <sergio-br2> Noskcaj, how are you
[20:15] <Noskcaj> Pretty good. you?
[20:15] <sergio-br2> fine!
[20:16] <sergio-br2> i have some hardwares issues in trusty, and there is no testcase in laptop.qa
[20:17] <Noskcaj> You don't need a testcase to report a bug
[20:17] <sergio-br2> hum, yeah
[20:18] <sergio-br2> so... there is no need of testcases in laptop.qa?
[20:29] <Noskcaj> I think that got partly removed. And either way, file a bug first
[20:30] <sergio-br2> one problem is this: Bug #1263351
[20:32] <Noskcaj> Maybe try and get it fixed upstream?
[20:32] <sergio-br2> i think it is problem with the kernel, because there is a firmware problem. But i don't know how to assign it to upstream
[20:34] <TheLordOfTime> what do you mean "assign" it to upstream.
[20:35] <sergio-br2> hum, "subscribe" or link it with upstream, i don't know the correct word for it
[20:39] <TheLordOfTime> sergio-br2: okay, because "assign" means assigning someone to the bug, which isn't what you want to do, if you file an upstream bug and Ubuntu knows about the upstream tracker, it can link the two, if not, just post a link to the upstream bug as a comment, referencing that you've filed it upstream
[20:40] <TheLordOfTime> i think there's special kernel triage guidelines though, lemme double check that
[20:40] <TheLordOfTime> (this is why I don't touch kernel bugs)
[20:41] <TheLordOfTime> i was right, the kernel team has special triage procedures https://wiki.ubuntu.com/Kernel/BugTriage
[20:41] <TheLordOfTime> ultimately though if it's not working with a proprietary driver, then the proprietary driver providers are probably the ones fixing it
[20:42] <TheLordOfTime> (not to intrude on your thunder, Noskcaj, just my observations is all)
[20:42] <sergio-br2> hey, thanks
[20:43] <Noskcaj> TheLordOfTime, no problem. I'd looked away after saying "file a bug"
[20:43] <TheLordOfTime> Noskcaj: hehe
[20:44] <TheLordOfTime> i'm assuming since you've filed against linux, sergio-br2, that its a kernel / firmware / driver issue, so that's about all I can do to help ya, I make it a mission to avoid touching any bugs that have special triage guidelines :P
[20:45] <TheLordOfTime> ('tis why i work primarily in the server packages with my triage, they don't have super special guidelines in most cases)