[03:24] <slangasek> kees: woohoo
[05:57] <pitti> Good morning
[08:13] <dholbach> good morning
[09:04] <Laney> @pilot in
[09:04] <Laney> rawr
[09:04] <doko> shadeslayer_, no, unfortunately not
[09:06]  * dholbach hugs Laney
[09:11] <seb128> Laney, enjoy the piloting!
[09:11]  * Laney salutes
[09:12]  * xnox ponders what/where/how intel graphics are screwed up on my desktop.
[09:15] <seb128> how screwed?
[09:15] <mpt> Laney, coincidentally I have just learned what a Patch Pilot is, while wondering what to do with a patch in a bug report
[09:17] <mpt> Is there a simple how-to somewhere for turning a patch into a Bazaar branch proposed for merging? The closest I’ve found is <http://shallowsky.com/blog/linux/making-an-ubuntu-diff.html>, which is discouraging.
[09:17] <mpt> (And not entirely relevant to an upstream project.)
[09:20] <Laney> You can just subscribe ubuntu-sponsors if you like
[09:20] <Laney> It's not hard to do for someone who knows how
[09:20] <Laney> dholbach: how do I get to the packaging guide from http://developer.ubuntu.com/ ?
[09:21] <mpt> Laney, ok, I subscribed ubuntu-sopnsors to bug 965953. Thanks.
[09:21] <Laney> ta
[09:21] <dholbach> Laney, the page is currently broken and we're talking with IS to get it off of there and on to packaging.ubuntu.com so we also don't to keep the packaging guide css and the developer.u.c style in sync, etc
[09:22] <dholbach> Laney, I'll ping IS about it again
[09:22] <Laney> dholbach: oh ok
[09:23] <Laney> I googled for it and got the old wiki at number 1, then a pdf of the guide at number 2 (removing the filename from the url took me to a page about click packaging), then some other random stuff
[09:25] <dholbach> yeah, I know - something in the new wp deployment (and some links) broke
[09:26] <Laney> ah well
[09:26] <Laney> thanks for following up
[09:34] <xnox> seb128: i think it was a lockup "reboot" fixed it. but i do have a few crash files to upload.
[09:38] <cjwatson> stgraber: ltsp/ldm> not a problem, thanks
[10:06] <Laney> Mirv: want to take care of https://code.launchpad.net/~dandrader/ubuntu/trusty/qtdeclarative-opensource-src/backport_fix_qtbug_32004/+merge/195761 with your new powers ?
[10:07] <Laney> Wait, you don't have them yet
[10:08]  * Laney fixes that
[10:10] <Mirv> might do at some point, although as pointed out it's a bit slow process since I'd need to build it for armhf first and then run all AP:s
[10:12] <Mirv> it's in the 5.2 PPA builds now
[10:12] <Mirv> so if the patch needs modifications, it's good to know
[10:15] <Laney> Well, it's right near the top of the sponsorship queue now
[10:15] <Laney> So if it's good to get in then it'd be nice to help that, otherwise reject it
[10:15] <Laney> No good letting it sit there really
[10:16] <Mirv> right, makes sense. I'll raise it on my todo list.
[10:17] <Laney> ty
[10:18] <Laney> cjwatson: do you have launchpad.Edit? could you add ubuntu-qt5-dev to the qt5 packageset uploaders please?
[10:20] <cjwatson> Laney: launchpad.Edit on what object?
[10:21] <Laney> (<Archive at 0x16beb610>, 'newPackagesetUploader', 'launchpad.Edit')
[10:23] <cjwatson> Laney: nope, launchpad.Edit on the primary archive => techboard
[10:23] <cjwatson> Laney: you could ask a webop to do it though ...
[10:23] <Laney> ah, I thought ~launchpad gave you that
[10:23] <cjwatson> ~launchpad doesn't give me admin, no
[10:23] <Laney> ok
[10:23] <cjwatson> it gives some magic things but not that :)
[10:24] <cjwatson> launchpad.<PermissionName> is always contextual - depends on the object it's operating on
[10:24] <Laney> yeah, I just overestimated the power of that team
[10:30] <Laney> done
[10:30] <Laney> Mirv: you should be good to go
[10:30] <Laney> Riddell: ScottK: also kubuntu-dev can now upload qt5 stuff FYI
[10:41] <Riddell> thanks Laney
[10:43] <Mirv> thanks Laney
[10:59] <dholbach> Laney, http://packaging.ubuntu.com/ is up and running, mthaddon is putting up rewrite-rules and the landing page will be maintained in a branch (and made a bit prettier)
[11:18] <tedg> jodh, Could we have the upstart logs for stuff put a generic timestamp in for start and stop?
[11:18] <tedg> jodh, I could do it for my jobs in a pre-start type script, but it seems more generic.
[11:21] <jodh> tedg: https://bugs.launchpad.net/upstart/+bug/1154207. Not a priority for trusty, but patches welcome :)
[11:22] <jodh> tedg: oh wait, you're talking about upstarts output itself? if so, feel free to raise a bug as that's different :)
[11:23] <tedg> jodh, I was thinking a single timestamp "started at 23245345" type of thing, more than per message.
[11:23] <tedg> per message would mostly implicitly add that though.
[11:26] <xnox> tedg: what would be more interesting, is to record events in the job log which job is sensitive to "232122456 event: desktop-started SESSION_TYPE=Ubuntu" "Starting" ...... "Started"......"Stopping"....."Stopped"
[11:26] <xnox> (that way one sees lifecycle of a single job, and it's stages)
[11:29] <shadeslayer_> doko: drat :(
[11:34] <knocte> Cimi: ping
[12:39] <dobey> anyone know why the "show-hud" keybinding in dconf would keep getting reset, after i changed it?
[12:55] <Cimi> knocte, pong
[12:56] <Cimi> knocte, you ok in one hour?
[12:56] <Laney> doko: looks like pcre3 has done Bad Things
[12:56] <knocte> Cimi: in 1hr I don't think I'll be here; anyway I sent you a review-request for a merge, just try to ping me if you have any thing to discuss
[12:57] <doko> Laney, ?
[12:57] <Laney> doko: e.g. https://launchpadlibrarian.net/158171405/buildlog_ubuntu-trusty-i386.msva-perl_0.9.2-1ubuntu1_CHROOTWAIT.txt.gz
[12:57] <Laney> http://paste.ubuntu.com/6514370/
[12:58] <wgrant> Yeah
[12:58] <wgrant> Someone probably wants to delete that from -proposed :)
[12:59] <doko> wondering why ... https://launchpadlibrarian.net/158168960/buildlog_ubuntu-trusty-i386.pcre3_1%3A8.31-2ubuntu1_UPLOADING.txt.gz
[12:59] <doko> looks ok
[12:59] <Laney> blocked until someone can delete it
[12:59] <Laney> @pilot out
[12:59] <wgrant> doko: The file list at the end of that log looks pretty wrong
[13:00] <wgrant> -rw-r--r-- root/root    247196 2013-12-03 12:12 ./lib/i386-linux-gnu/libpcre.so.1.0.1
[13:00] <doko> ugh, soname change?
[13:01] <wgrant> doko: Heh
[13:01] <wgrant> doko: The soname is patched into configure by quilt
[13:01] <wgrant> So your dh-autoreconf will just clobber it
[13:01] <doko> wtf?
[13:01] <wgrant> Yep.
[13:02] <Laney> yeah ...
[13:02] <doko> ok removing the binaries
[13:02] <doko> and will add a symbols file to catch that
[13:03] <cjwatson> Yeah, this is why I said to check the patches :)
[13:03] <cjwatson> and why people patching only generated files should be Taught The Error Of Their Ways
[13:04] <wgrant> s/patching only generated files/including generated files in source tarballs/? :)
[13:04] <cjwatson> I'm fine with that personally
[13:04] <xnox> wgrant++
[13:04] <xnox> it's embedded copies of source, not preferred form of modification.
[13:05] <xnox> we force regenerate valac, strip out included java libraries, yet somehow configure/config.guess/config.sub are all fine =/
[13:05] <xnox> (i understand there is no licensing issues with configure/config.guess/config.sub but still)
[13:06] <cjwatson> I'm a big fan of regenerating them in the packaging, but it makes sense for upstream to include them IMO
[13:06] <xnox> quite.
[13:07] <xnox> i wish it would be RC bug if autoreconf -f -i fails for example. Because, in practice it means inability to modify sources in the preffered form.
[13:07] <doko> ok, binaries removed
[13:10] <pitti> doko: ^ that's for the broken pcre, right?
[13:10] <doko> pitti, yes
[13:10] <pitti> (causing nice havoc in jenkins)
[13:10] <pitti> doko: danke
[13:11] <doko> every day you find some worse packaging bits, it doesn't stop ...
[13:12] <mdeslaur> So, I've just rebooted saucy, and every time I start xchat from the message indicator, it comes up without global menus
[13:12] <mdeslaur> tedg: is there a race with upstart user sessions or something that could result in that? ^
[13:14] <tedg> mdeslaur, Not sure if saucy got the upstart restart patch for env vars?
[13:14] <xnox> mdeslaur: cat /proc/`pidof xchat`/environ | grep -a unity-gtk-module ?
[13:14] <xnox> mdeslaur: GTK_MODULES should have "overlay-scrollbar:unity-gtk-module"
[13:15]  * xnox is still confused why GTK_MODULES are *opt-in* instead of *opt-out*
[13:15] <mdeslaur> xnox: nope, not there
[13:15] <mdeslaur> GTK_MODULES=overlay-scrollbar
[13:15] <xnox> mdeslaur: then you will not have global menuabar.
[13:16] <mdeslaur> xnox: looks like the messaging indicator managed to start without it
[13:16] <xnox> mine starts with.
[13:16] <mdeslaur> xnox: mine starts with it 99% of the time
[13:16] <mdeslaur> xnox: once in a while, it doesn't
[13:17] <xnox> mdeslaur: I see that overlay-scrollbar is reliable added in /etc/X11/Xsession.d/.... let's check unity module
[13:17] <mdeslaur> xnox: could the indicator have started before /etc/X11/Xsession.d/81overlay-scrollbar got run?
[13:18] <xnox> no, but that script doesn't set unity-gtk-module.
[13:18] <mdeslaur> oh, duh -NEEDCOFFEE
[13:18] <xnox> so unity-gtk-module should be set in Xsession.d to be reliable and I don't see it set.
[13:19] <xnox> seb128: Laney: where is unity-gtk-module added to GTK_MODULES?
[13:21] <seb128> xnox, Xsession.d
[13:22] <seb128> hum, I though
[13:22] <xnox> $ grep unity-gtk-module -r /etc/X11/Xsession.d/ || echo fail
[13:22] <xnox> fail
[13:22] <xnox> =/
[13:22] <mdeslaur> heh
[13:22] <seb128> xnox, oh, upstart job
[13:22] <xnox> seb128: maybe there is some-wrapper or some-such side-effect.... if it's not set there, it's not guaranteed that all processes in the user session will inherit it.
[13:23] <xnox> right, i see.
[13:23] <seb128> I think ted suggested that (unsure though)
[13:24] <xnox> well it can't be because of touch right?
[13:25] <seb128> the upstart job should be reliable no?
[13:25] <seb128> what do you mean "because of touch"?
[13:25] <xnox> sure, for everything that is start on started dbus, but not before.
[13:25] <seb128> I guess people though using upstart job was a more modern way that using Xsession.d
[13:25] <mdeslaur> where are user session upstart jobs?
[13:26] <seb128> indicators shouldn't start before dbus is started...
[13:26] <xnox> mdeslaur: /usr/share/upstart/session; XDG_CONFIG_DIRS/upstart (array); XDG_CONFIG_HOME/upstart (single)
[13:26] <mdeslaur> xnox: ah! thanks
[13:26] <xnox> mdeslaur: i gave it in the order of last one wins, and overrides from the last one wins
[13:26] <xnox> mdeslaur: so you can e.g. drop an override into ~/.config/upstart/
[13:27] <mdeslaur> so...unity-gtk-module.conf may not get launched before the other jobs
[13:30] <xnox> so, it's doing "start on starting dbus" which we know is racy in saucy (fixed in trusty), as in dbus started event is emitted before dbus actually is available and therefore extra dbus gets autolaunched by indicators without enheriting the variable.
[13:31] <xnox> Laney: what's odd about the unity-gtk-module & overllay-scrollbars is that they are loaded unconditionally, regardless of the Desktop ENvironment.
[13:31] <mdeslaur> xnox: what ensures unity-gtk-module.conf gets loaded before, say, gnome-session.conf?
[13:31] <xnox> mdeslaur: when that happens, you should note that $ status dbus, doesn't match the dbus that is actually in use by the indicators.
[13:32] <brainwash> speaking of overlay scrollbars, can maybe anyone here explain why bug 1239014 happens? trace log included
[13:32] <xnox> mdeslaur: "started on dbus" in the gnome-session.conf. "started dbus" is not emitted until all tasks/jobs that are "start on starting dbus" are complete.
[13:32] <xnox> but the buggy dbus job (in saucy) means that "started dbus" is emitted before it has completed (too early).
[13:33] <xnox> mdeslaur: if you want to fix it for yourself, drop a file into XDG_CONFIG_DIRS after overlay-scrollbar, to add unity-gtk-module to the GTK_MODULES. that is guaranteed to be enherited by all processes in the user session.
[13:34] <xnox> (upstart and non-upstart managed and children of thereoff)
[13:34] <mdeslaur> xnox: ah! I see starting dbus vs started dbus
[13:34] <mdeslaur> xnox: I understand now, thanks
[13:34] <xnox> yeap =))))
[13:34] <mdeslaur> xnox: so this should be fixed in trusty?
[13:34] <xnox> yes, i believe it is.
[13:34] <mdeslaur> xnox: awesome, thanks
[13:35] <xnox> i don't find it important enough to fix in saucy =))))
[13:35] <seb128> mdeslaur, you are not running trusty?
[13:35] <mdeslaur> xnox: yeah, that's ok...I just wanted to make sure we were aware of this
[13:35] <mdeslaur> seb128: I have to wait until the desktop team stops breaking it first :)
[13:36] <mdeslaur> jk :)
[13:37] <seb128> mdeslaur, I'm going to show you what we can do :p
[13:37] <xnox> mdeslaur: well. I think it's a side-effect, of the same root cause which has been rectified.... =)
[14:03] <smoser> any one using trusty and finding 'apt-get dist-upgrade' to just be painfully slow ?
[14:04] <pitti> I find de.archive.u.c. to be painfully slow, but apt-get itself seems fine to me
[14:05] <smoser> well, this is the 'dist-upgrade' part itself which is painfully slow.
[14:05] <smoser> when it finishes, i'll pick the timestamps out of the log
[14:08] <seb128> tseliot, hey, why did you set the xrandr/optimus/g-s-d issue back to triaged on g-s-d? is g-s-d doing anything wrong? (it seems like an issue in the nvidia xrand handling)
[14:08] <tseliot> seb128: I was about to write the explanation. There's an error we should trap in libgnome-desktop
[14:08] <seb128> ok, good
[14:09] <tseliot> seb128: and I have a simple patch for that
[14:09] <tseliot> seb128: also worth SRUing
[14:09] <seb128> tseliot, sorry, just checked email after lunch and that one was in the batch ;-)
[14:09] <tseliot> :)
[14:09] <seb128> tseliot, great, it would be nice it you could upstream it as well (if it still applies to trunk)
[14:10] <tseliot> seb128: yes, things seem to have changed quite a bit but if they're still doing that, I will
[14:10] <seb128> tseliot, thanks
[14:10] <tseliot> seb128: yw
[14:11] <smoser> ugh.  there is a major lack of information here. i know that the dkms build was slow as I watched it, but for example /var/lib/dkms/virtualbox/kernel-3.12.0-5-generic-x86_64/log/make.log has only a start time
[14:11] <smoser> not a stop time.
[14:15] <Laney> xnox: I never set that stuff up
[14:15] <Laney> Xsession.d was working fine as far as I was concerned
[14:15] <xnox> ok.
[14:16] <Laney> you probably want to talk to ted
[14:28] <smoser> well, not very scientific numbers, but http://paste.ubuntu.com/6514743/
[14:29] <smoser> pitti ^. generally i do think that 'apt-get dist-upgrade' is much less performant than it was in say saucy. not sure what would have caused this, but 17 minutes for ~ 45 packages is pretty bad (even though one was kernel)
[14:32] <smoser> anyone else have non-scientific feelings that something in the path excercised by a genera 'apt-get dist-upgrade' is slower ?
[14:34] <mlankhorst> ok does anyone want to test mesa 10 before I upload it? it passed all tests I threw at it locally :P
[14:36] <xnox> smoser: is that amd64? or more specifically are there any foreign architectures defined?
[14:37] <xnox> (e.g. on amd64, by default i386 is enabled. and the only big features in trusty so far is to switch to using python:any dependency....)
[14:37] <smoser> xnox,
[14:37] <smoser> $ x=$(dpkg --print-foreign-architectures); echo "arches: $x"
[14:37] <smoser> arches:
[14:37] <xnox> horum.
[14:37] <smoser> it really feels like general IO to me.
[14:38] <xnox> very odd, indeed.
[14:38] <tseliot> seb128: so, shall I upload the quilt patch in gnome-desktop-3 in trusty and SRU the same package in precise? How do you suggest that I do it?
[14:38] <smoser> i admit to not having cutting edge hardware here.  T400 with spinning disk (2009 era thinkpad). but really...
[14:38] <seb128> tseliot, can you merge request it or put the diff up for review on the bug?
[14:40] <tseliot> seb128: a merge request using bazaar? (svn is listed in the control file)
[14:41] <seb128> tseliot, oh, we don't have a vcs ... I just want a diff/peer review
[14:41] <seb128> tseliot, can you put the debdiff on the bug?
[14:41] <tseliot> seb128: sure
[14:41] <seb128> thanks
[15:06] <spy6> cheers!
[15:07] <spy6> is there a way to request a merge for a package from debian?
[15:08] <spy6> #1244713 smells fishy and there arrived also a duplicate today
[15:09] <mlankhorst> spy6: requestsync ?
[15:09] <mlankhorst> although i guess that is a copy
[15:10] <cjwatson> xnox is touched-it-last for that package
[15:16] <spy6> mlankhorst: that is for pacakges without modifications ... nagios-plugins has ubuntu specific changes
[15:21] <tseliot> seb128: the debdiff for trusty is there now
[15:30] <seb128> tseliot, looks good to me ... could you upstream it and include the bug reference in the patch? then feel free to upload
[15:33] <tseliot> seb128: isn't this enough as a reference? http://paste.ubuntu.com/6515056/
[15:33] <tseliot> I'll try to upstream it too
[15:34] <seb128> tseliot, upstream bug reference is nice because it tells us it has been upstreamed
[15:34] <seb128> so we don't have to look for the info through logs and launchpad next time we merge
[15:34] <tseliot> seb128: oh, so you mean the upstream bug number. Ok, good
[15:35] <seb128> tseliot, right, sorry the upstreaming and bug references parts there were supposed to be one item ;-) thanks
[15:35] <tseliot> ok :)
[15:45] <mdeslaur> infinity: hrm, ruby-ffi needs some arm64 love
[15:46] <mdeslaur> infinity: I'm guessing lib/ffi/platform needs a new platform definition
[15:48] <tseliot> seb128: after a quick look I'm convinced that my patch is not upstreamable, as they moved all the RandR logic into Mutter: http://paste.ubuntu.com/6515114/
[15:49] <tseliot> seb128: and while I can try to contribute to mutter, it will be irrelevant to the bug report on launchpad
[15:49] <infinity> mdeslaur: Be my guest. :P
[15:50] <mdeslaur> infinity: ah geez, I asked nicely didn't I? :)
[15:50] <seb128> tseliot, it's still worth filling it in case they want to commit to 3.8, I think e.g the new RHEL might be based on GNOME 3.8
[15:50] <seb128> tseliot, just write that it applies for 3.8 and can be wontfixed if they don't want it there
[15:50] <tseliot> seb128: fair enough
[15:54] <mdeslaur> infinity: do I have access to a porting box somewhere?
[15:55] <infinity> mdeslaur: Sort of.
[15:56] <Laney> qemu seems to work
[16:00] <mdeslaur> infinity: oh, wait a sec...it compiled successfully before
[16:02] <mdeslaur> infinity: ignore me for now
[16:05] <mdeslaur> infinity: is DEB_HOST_ARCH still set to "arm64"?
[16:06] <mdeslaur> infinity: sorry, I mean dpkg-architecture
[16:09] <mdeslaur> infinity: ignore me again, I'm looking at the wrong issue
[16:12] <xnox> mdeslaur: $ mk-sbuild --arch arm64 trusty should actually work now. I fixed up last hurdles it was having.
[16:13] <mdeslaur> xnox: oh, cool, i'll give that try, thanks
[16:16] <xnox> rbasak: do you know if anyone can steal nagios-plugins merge away from me? i did it for a transition, but the 1.5.x is non-trivial.
[16:16] <xnox> alternatively i'll cherrypick fix for bug #1244713
[16:33] <bdmurray> seb128: a few weeks ago you'd asked about the discrepancy between bucket numbers on the landing page and on the problem page.  I have some information for you regarding that.
[16:34] <seb128> bdmurray, hey, I read your comment on "asana" (received those by email)
[16:34] <bdmurray> seb128: ah, okay then I won't repeat myself ;-)
[16:34] <seb128> bdmurray, thanks for investigating ;-)
[16:35] <bdmurray> seb128: no problem
[16:37] <tseliot> seb128: ok, the upstream report and reference are there, and I've also filed an SRU for Saucy and Precise
[16:40] <seb128> tseliot, thanks!
[16:40] <tseliot> seb128: you're welcome
[16:58] <doko> xnox, ping about demoting gccxml (split the boost python package)
[17:10] <plars> slangasek: hi, is there someone that can help us with https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1256695
[17:15] <cjwatson> plars: I was going to look at that
[17:16] <cjwatson> plars: (p.s. slangasek is on holiday)
[17:16] <plars> cjwatson: ack, thanks
[17:17] <cjwatson> plars: however, I have to fetch a current image first, so it probably won't be until tomorrow
[17:17] <jdstrand> @pilot in
[18:25] <bdmurray> seb128: you set bug 1024590 to In Progress for Saucy.  Do you plan on uploading an SRU for it?
[18:28] <seb128> bdmurray, I was discussing it with mvo this morning, he did merge it in http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/ubuntu-trusty/revision/308
[18:28] <seb128> bdmurray, not sure if he was going to upload or if he would welcome somebody else to deal with those bits though
[18:28] <seb128> mvo, ^^?
[18:28] <seb128> sorry for the double ^, that key stopped doing what it should somewhat for me
[18:29] <bdmurray> seb128: I saw the branch, thanks for chasing that
[18:29] <seb128> yw
[18:30] <bdmurray> mvo: I can do the SRU
[18:30] <seb128> I had enough to see that topping e.u.c, just tried to come with some sort of solution, mvo was nice enough to pick it up, improve a bit and get it commited ;-)
[18:30]  * seb128 hugs mvo
[18:31]  * ogra_ hugs mvo
[18:37]  * xnox hugs mvo 
[19:05] <infinity> mdeslaur: It compiled fine both times, didn't it?  It's the testsuite that fails.
[19:05] <mdeslaur> infinity: yeah, it's gem2deb that's broken, I uploaded a fix now
[19:08] <infinity> mdeslaur: Oh, shiny.
[19:09] <infinity> mdeslaur: Oh, "fixed".  I see.  Not quite as fixed as actually passing tests. :)
[19:09] <mdeslaur> infinity: oh, hehe, no :)
[19:09] <mdeslaur> infinity: it still needs love, but at least it won't be stuck in proposed :P
[19:42] <mdeslaur> infinity: oh, hehe, that last changelog was a bit misleading...I'm not the one who disabled the tests
[19:51] <vood> Hello, I have a question about myapps.developer.ubuntu.com, does somebody know, why application still apears in a Draft state even after ppa-info.txt upload ?
[19:52] <sarnold> vood: #ubuntu-app-dev might be a better place to ask
[19:52] <vood> thanks a lot!
[19:53] <mdeslaur> doko: mind if I merge ruby-mocha?
[20:16] <mdeslaur> doko: too late
[21:24] <jdstrand> @pilot out
[21:31] <chiluk> are there any pilots left?
[21:31] <chiluk> can I get some upload lovin for bug 560839 ... at this point I think it only pertinent that the fix be applied to trusty
[21:32] <chiluk> once it bakes there, I'll submit an sru for p,q,r,s
[21:34] <xnox> stgraber: in mountall, you added /sys/fs/cgroup with size=1024. Why 1024? it appears to be by default mounted with size=4k
[21:39] <infinity> chiluk: We don't need two copies of the same binary in the package, surely?
[21:39] <infinity>  	install -D -m644 memtest.bin debian/$(PACKAGE)/boot/$(PACKAGE).bin
[21:39] <infinity> +	install -D -m644 memtest debian/$(PACKAGE)/boot/$(PACKAGE).elf
[21:39] <infinity>  	install -D -m644 memtest debian/$(PACKAGE)/usr/lib/$(PACKAGE)/$(PACKAGE).elf
[21:40] <infinity> chiluk: If that second one is a well-known location we're afraid users might need a migration path for, install it as a symlink to the one you just put in /boot perhaps?
[21:41] <stgraber> xnox: well, maybe 4K is fine, I don't really care, I just wanted the smallest quota possible which will still let us create directories
[21:42] <xnox> i see.
[21:42] <xnox> ack.
[21:50] <chiluk> infinity, hmm good point.
[21:53] <chiluk> infinity ... Is there  a special way to "install a link" or would just calling ln from the rules file be sufficient.
[21:54] <xnox> chiluk: $ man dh_link ?
[21:54] <chiluk> thanks...
[21:55] <xnox> (just add "src dest" pairs in debian/$pkg.links)
[21:55] <xnox> chiluk: for added bonus it corrects the links to be policy compliant (relative/abolute as needed)
[21:56] <doko> xnox, ping about demoting gccxml (split the boost python package)
[21:58] <xnox> doko: you need it now?
[21:59] <xnox> i don't mind, it was demoted to Recommends in debian, but I guess we need it down to suggests.
[21:59] <doko> xnox, no, but please still this year
[21:59] <xnox> doko: ok.
[21:59] <doko> well, split it out, then you don't need to recommend it
[22:00] <xnox> doko: please elaborate, how are you suggesting to split it?
[22:00] <doko> xnox, move the pyste module into a separate package
[22:02] <xnox> ack.
[22:02] <xnox> doko: thanks, that will simplify a few things.
[22:10] <infinity> chiluk: As xnox says (or just do it in debian/rules with ln, given that there's variable exansion going on there)
[22:10] <infinity> chiluk: And make it an absolute link, since /boot and /usr can be different filesystems.
[22:14] <chiluk> infinity, trusty debdiff uploaded in bug..
[22:14] <chiluk> infinity how do you feel about specifying elf vs not specifying it in the menu-entry titles?
[22:15] <chiluk> I lean towards not doing so..
[22:15] <chiluk> but the original fix for this had elfs all over
[22:20] <infinity> chiluk: I don't see any reason for the GRUB entry to tell people things they don't need to know and won't understand.
[22:20] <chiluk> ok .. one sec.. I'll revert that bit as well.
[22:20] <infinity> chiluk: We don't tell people what sort of vmlinu{z,x,x.coff,etc} they're booting either.
[22:20] <chiluk> i tend to agree with you.
[22:24] <chiluk> infinity ... alright... it's all yours..
[22:29] <infinity> chiluk: Oh, if you're doing dh_link in debian/rules like that, you really should probably just use 'ln' directly, so you're not accidentally creating links in packages you didn't mean to (if it's a multi-binary package), etc.
[22:30] <infinity> chiluk: The correct way to use dh_link is with a debian/package.links file, but that would make the variable substitution bit hard, so I'd just use ln in rules with the install calls there.
[22:30] <chiluk> all I know is what I have there worked when I tested it...
[22:30] <infinity> chiluk: ie: "ln -s /boot/$(PACKAGE).elf debian/$(PACKAGE)/boot/$(PACKAGE).elf"
[22:31] <infinity> chiluk: Sure, but it could have surprising and unexpected results if there's a bit of a packagin reorg or someone adds another binary package to the source, etc.
[22:31] <chiluk> yeah that would work too
[22:31] <doko> pitti, jibel: please could you let tcl8.5 migrate? python-imaging is removed, and it's the only test failing
[22:31] <doko> infinity, or you: ^^^
[22:31] <chiluk> infinity,  so you want me to change it back to ln ?
[22:31] <infinity> chiluk: Yeah.
[22:32] <infinity> doko: You want release team for that, yeah, and I can do it.
[22:33] <infinity> doko: Done.
[22:33] <doko> thanks
[22:34] <infinity> doko: I'm confused by the python-imaging removal...
[22:34] <chiluk> alright last times a charm right?
[22:34] <infinity> doko: The comment you made was "NBS", but how can a source package be NBS? :P
[22:34] <doko> infinity, called pillow now
[22:35] <doko> hmm, maybe I should have written, removed from the archive ...
[22:35] <infinity> doko: Ahh, the binaries moved to another source, and the source had no binaries?
[22:35] <doko> yes
[22:35] <infinity> doko: Kay, cool.
[22:36] <infinity> pitti: Can you remove python-imaging tests from jenkins, or does that happen automatically (eventually) when sources are removed from the archive?
[22:42] <xnox> infinity: it has to be done manually, as typically packages drop tests by accident and that's considered a regression. Last time jibel removed it for me, I think.
[22:42] <chiluk> infinity new debdiff is attached... any more suggestions?
[22:44] <infinity> xnox: This isn't a package that dropped tests, it's a package that stopped existing.
[22:44] <infinity> xnox: But, indeed, the "dropped tests" case is what made me think maybe the "dropped package" case would be manual too.
[22:44] <xnox> infinity: i guess that's cruft, and britney will not request / consider that package anymore?
[22:45] <xnox> anyway, i don't actually know, so i should shut up.
[22:48] <infinity> chiluk: If I was nitpicking, I'd say that my "ln -s" paste probably should have been "ln -sf", so subsequent runs of the same target don't fail.  Of course, that might fail anyway if the directory wasn't yet created.  Let's see.
[22:49] <chiluk> I was going to suggest the f...
[22:49] <chiluk> apparently I have too much faith in you.
[22:49] <infinity> chiluk: I tend to talk more in pseudocode than actual copy-and-waste snippets.  I expect review and thought before application. :)
[22:49] <chiluk> hah...
[22:50] <chiluk> if you knew what i'm on you wouldn't expect much out of me at the moment... *(back surgery)
[22:50] <infinity> chiluk: Anyhow, let me apply this, look at it in context, fix if necessary, and upload.  More back and forth is probably a waste of time.
[22:50] <chiluk> agreed.
[22:50] <chiluk> the basic fix is there.
[22:51] <chiluk> but you have more experience with what I consider to be packaging issues..
[22:52] <chiluk> infinity do you want to upload for pqrs as well?
[22:52] <infinity> chiluk: Nope!
[22:52] <chiluk> just checking.
[22:52] <chiluk> I'll backport and create debdiffs
[22:52] <infinity> chiluk: But you should subscribe to bugs on the package and watch how the trusty upload fares for a month or so to see if this was a Bad Idea for any reason.
[22:52] <chiluk> and follow regular sru process
[22:52] <chiluk> will do.
[23:07] <doko> infinity, cjwatson: do you have an idea how dh-autoreconf should be called with cdbs?
[23:13] <infinity> doko: I thought cdbs had its own weird equivalent, but I'm fuzzy on that.
[23:13] <infinity> doko: seb128 or one of the GNOMEy people who use cdbs heavily might be best to ask.
[23:14] <infinity> doko: cdbs does have an autoreconf.mk, though, so I'm guessing that's the way to go.
[23:15] <tseliot> infinity: please approve bug #1255583 when you can, I'd like to upload a new nvidia-prime with the correct dependencies