[00:26] <maxb> Would anyone happen to know why mdadm installs udev rules which create /dev/md/* symlinks ?
[00:26] <maxb> Why the extra names, instead of just using /dev/md* ?
[02:08] <nobuto> SpamapS, pitti: Hi. "pkgsel" package for Lucid-SRU(Bug #797985) is still in unapproved queue. Could you take a look to push lucid-proposed? Thanks in advance.
[08:18] <elmo> Daviey: your cloud thing is losing it's mind again and spamming us with failure mails
[08:52] <pitti> nobuto: we'll get to it; I'll probably ask our latest SRU team member RAOF to review it :)
[11:06] <sveinse> I have a package which has only static files which shall be installed, and I've put the list of the files into debian/install. However, I need to pass --sourcedir to dh_install. How do I do that when I'm using the default %:   dh $@   rules?
[11:07] <RAOF> sveinse: You can write an override_dh_install: target that will be called instead of dh_install.  That target would call dh_install --sourcedir=whatever.
[11:08] <sveinse> Are there any variables available for the root of the sources?
[11:09] <RAOF> The root of the sources?  debian/rules is guaranteed (by dh_test) to be called from the root of the sources (or at least the directory containing debian/), so CURDIR will be what you want.
[11:10] <sveinse> Excellent. Thanks
[11:23] <RAOF> pitti: What is the SRU policy WRT translations?  The package for Bug #797985 appears to contain a full export of launchpad translations, so has a bunch of translation changes unrelated to the specific bug, but we probably want them all.
[11:50] <cjwatson> RAOF: I can cut it down if you like, but there didn't seem a strong reason to do so
[11:52] <RAOF> cjwatson: I agree.  As the newest SRU team member I'm just checking that everyone *else* agrees, too :)
[11:56] <zyga> https://launchpad.net/~linaro-validation/+archive/ppa
[12:42] <sveinse> Is it possible to rename the installed file when using the listing in debian/install?
[12:45] <cjwatson> sveinse: no, sorry, that's a documented limitation (in dh_install(1))
[12:46] <cjwatson> sveinse: if you need that, create the containing directory in debian/dirs, and then have an override_dh_install rule that does 'install -m0755 source-file-name debian/packagename/usr/bin/target-file-name' or whatever
[12:46] <sveinse> yes, thanks
[12:48] <sveinse> Is it considered bad to do 'install -D ...'? (instead of using debian/dirs I mean)
[12:51] <sveinse> cjwatson: ^
[12:52] <cjwatson> sveinse: doesn't matter much
[12:59] <DktrKranz> mvo: hi! vte 2.90 is in unstable now, I think next gdebi upload could be targeted unstable as well.
[13:03] <mvo> DktrKranz: awsome news!
[14:20] <pitti> cjwatson, kees: just sent a tb@ mail about moving the meeting today
[14:24] <mdeslaur> pitti: are you available?
[14:24] <pitti> mdeslaur: yes, I am; I can come over to the security room
[14:24] <pitti> ok?
[14:24] <mdeslaur> pitti: sure, cool
[14:24] <pitti> your chairs are a lot better than our's :)
[14:25] <mdeslaur> pitti: yes, they are :P
[14:25] <kees> pitti: some of our chairs were stolen though
[14:25] <mdeslaur> kees: Dude! Don't tell him, he won't come
[14:34] <sveinse> What are the options in the section line in debian/control ?  I thought I could put universe here, but lintian refuses to accept it
[14:34] <Laney> ha at the security team being a victim of chair theft :-)
[14:42] <TheMuso> sveinse: The universe keyword is added by the archive software, and does not get put into actual package control files.
[14:48] <geser> Laney: bad security I'd say :)
[14:48]  * Laney expects a USN post haste
[14:51]  * micahg sends USN-CHAI-R
[14:53] <sveinse> TheMuso, what can be put into the section keyword?
[14:54] <brendand> anyone know which package contains GtkFileChooserDialog in Oneiric?
[14:59] <geser> sveinse: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[15:00] <sveinse> ok, so the debian sections also applies for ubuntu. Thanks
[15:00] <evfool> brendand: that'd be probably the gtk package
[15:01] <evfool> brendand: https://launchpad.net/gtk
[15:02] <brendand> evfool - not possible to assign a bug to it though. i think that's a project page anyway, not necessarily a package
[15:03] <brendand> i guess it may be https://launchpad.net/ubuntu/+source/gtk+3.0 ?
[15:04] <evfool> brendand:yep, that's it
[15:20] <kees> Laney: you mentioned it were interested in the TB meeting? we're moving it 2 hours earlier, fyi
[15:21] <Laney> kees: righto. I'm just interested in hearing the outcome to my mail really :-)
[15:21] <Laney> thanks for letting me know
[15:21] <kees> okay :)
[15:36] <pitti> james_w: do you know whether status.u.c. publishes the db files anywhere? I need the current one for debugging
[15:36] <pitti> james_w: I can't access viburnum.canonical.com
[15:37] <james_w> pitti, I didn't change that code, so it does
[15:37] <pitti> http://status.ubuntu.com/ubuntu-oneiric/oneiric.db doesn't exist
[15:37] <james_w> http://status.ubuntu.com/ubuntu-oneiric/ubuntu-oneiric.db
[15:37] <pitti> oh, ubuntu-oneiric.db
[15:37] <pitti> *headdesk*, sorry
[15:37] <pitti> thanks!
[15:37] <james_w> np
[15:38] <pitti> james_w: we retargeted a whole bunch of oneiric specs to p, and the tables updated properly, but not the charts
[15:38] <james_w> hmm
[15:38] <pitti> james_w: I suppose the charts still count the dropped WIs somehow
[15:38] <james_w> not sure what would cause that
[15:39] <james_w> pitti, you did it by changing the series on the blueprints?
[15:39] <pitti> yes
[15:39] <pitti> but I suppose that didn't clean the specs from the db
[15:39] <james_w> hmm
[15:40] <pitti> I'm still not quite sure what happened
[15:40] <pitti> just that we dropped some 50 WIs, and there's no visible dent at all on http://status.ubuntu.com/ubuntu-oneiric/canonical-desktop-team.html
[15:43] <pitti> hm, on second look I actually can't find any inconsistency in the numbers
[15:45] <pitti> I'll just do an experiment
[15:47] <pitti> james_w: do you know when the WI tracker cron fires?
[15:48] <james_w> pitti, *:33
[15:48] <pitti> james_w: thanks
[15:51] <pitti> tseliot: if [ "$1" = install -o "$1" = upgrade ] && [ -z "$2" ]
[15:55] <mdeslaur> mvo: any availability to talk about the stuff we didn't get around to talking about?
[16:11] <slangasek> cnd: can x11proto-input 2.0.2-2 be merged?
[16:12] <mneptok> @conference/canonical  <--- All-Hands? a sprint?
[16:12] <udevbot_> Error: "conference/canonical" is not a valid command.
[16:12] <mneptok> udevbot_: sit down you pile of persnickety Python.
[16:12] <udevbot_> Error: "sit" is not a valid command.
[16:13] <cjwatson> mneptok: platform rally
[16:14] <cjwatson> (nee sprint)
[16:14] <StevenK> Don't forget LP
[16:14] <mvo> mdeslaur: I will come over at 17:00 or tomorow morning, is that ok?
[16:14] <cjwatson> oh yes
[16:14] <mdeslaur> mvo: sounds good, thanks
[16:15] <mneptok> that's some coincidence. i just bought "Platform Rally" for the PS3.
[16:15] <StevenK> Indeed, we're doing a bunch of good work. Unless you're infinity.
[16:15] <StevenK> That came out wrong. :-(
[16:15] <mneptok> StevenK: welcome to my world.
[16:16] <StevenK> mneptok: You should see a doctor for that.
[16:16] <mneptok> StevenK: i tried. the doctor said solving that issue is like putting a Band-Aid on an amputee. :/
[16:20] <cnd> slangasek, I'm not sure what you're asking?
[16:21] <cnd> I'm sure it could be merged, it looks like a bug fix according to the version numbers
[16:21] <cnd> there could be conflicts, but I'd be surprised if there were
[16:26] <slangasek> cnd: I'm asking if it's safe to merge the new upstream version; you're listed on https://merges.ubuntu.com/main.html as the last person to touch it, I haven't looked at the delta at all and don't know if from your perspective there's a risk of regressions caused by pulling the new upstream version
[16:36] <cnd> slangasek, let me take a look at debian's changes, but I can't imagine it would be a problem
[16:36] <cnd> my patch to x11proto-input is pretty large though :)
[16:36] <cnd> it includes the prototype xinput 2.1 support
[16:37] <cnd> but that should be rather self-contained away from the rest of xinput 2.0 and earlier stuff
[16:41] <cnd> slangasek, looks like it should be fine save for one trivial conflict
[16:41] <cnd> I pushed a small patch upstream that landed in 2.0.2
[16:41] <cnd> that change was rolled up as part of my 1_xi2.1.patch, instead of being a separate patch
[16:42] <cnd> I should have made it a separate patch back when I added it :(
[16:43] <cnd> removing lines 94-101 (a small diff hunk) of 1_xi2.1.patch should do the trick
[16:49] <slangasek> bdmurray: /usr/share/apport/general-hooks/ubuntu.py
[17:06] <apw> pitti: do you know how often the ddebs.ubuntu.com packages files are rebuilt ?
[17:07] <pitti> 10 3,7,11,15,19,23
[17:07] <pitti> apw: ^ for oneiric
[17:07] <apw> pitti: and for older releases ?
[17:08] <pitti> 10 2,10,18
[17:08] <apw> pitti: thanks :)
[17:48] <sveinse> What is the difference between dh_install and dh_auto_install ?
[17:49] <cjwatson> have you read the man pages?  they have quite good descriptions
[17:52] <sveinse> Yes, but admit skimming them. Let me rephrase: dh_install handles the debian/install files while, dh_auto_install takes care of calling make install, right?
[18:01] <sveinse> I have a rule here where I override install. How should I pass $DESTDIR to the target makefile?    override_dh_auto_install:  \n   make INSTALL_ROOT=$(DESTDIR) install      does not work, INSTALL_ROOT is empty
[18:16] <cjwatson> sveinse: dh_install/dh_auto_install> right, that's a good summary
[18:19] <sveinse> It seems DESTDIR environment variable is not set when going into the override_dh_auto_install rule
[18:29] <sveinse> Hmm. I'm clueless and google doesn't tell me much.
[18:29] <sveinse> How do you guys handle install if the Makefile wants to install to INSTALL_ROOT instead of DESTDIR?
[18:30] <sveinse> Can't patch Makefile, as it's auto generated
[18:31] <slangasek> sveinse: patch the non-auto-generated source file
[18:32] <sveinse> This is a Qt application. That would mean to patch upstream qmake in another package...
[18:32] <nigelb> sveinse: look at how other qt apps have been done maybe?
[18:33] <nigelb> "apt-cache search qt" may give you a few pointers of other qt-based applications
[18:34] <sveinse> Doing a quick search of qt4-x11 sources, it seems qmake is not patched for chaning INSTALL_ROOT to DESTDIR at least. Checking apps...
[18:35] <sveinse> But override_dh_auto_install of qt4-x11 reveals it:   $(MAKE) install INSTALL_ROOT=$(CURDIR)/debian/tmp/
[18:36] <sveinse> Not what I expected thou
[18:39] <slangasek> sveinse: oh, sorry - INSTALL_ROOT and DESTDIR are equivalent except for the name?  Yeah, no need to patch that, the described override is pretty much what one would expect
[18:39] <slangasek> (provided that dh_auto_install doesn't actually know how to detect qmake)
[18:41] <sveinse> Hmm. Not quite. If I remove my override_dh_auto_install, I see dh running "make -j1 install DESTDIR=/home/user/packages/lmas/debian/lmas", while the above override uses debian/tmp
[18:47] <cjwatson> sveinse: that depends on the dh compat level; with a modern package, $(CURDIR)/debian/lmas is correct
[18:47] <cjwatson> it also differs for multi-binary packages
[18:48] <cjwatson> qt4-x11 is unlikely to be a good example to refer to for Qt *application* packaging
[19:03] <sveinse> cjwatson: This should be a single-binary package. Are there any other places than debian/control that control if it's a multi or single binary package?
[19:05] <cjwatson> sveinse: nope
[19:06] <sveinse> Given a newer dh compat level and if $(CURDIR)/debian/lmas is correct, then I need to find my own package name unless I want to hardcode the latter "lmas" part of the path
[19:07] <cjwatson> $(shell dh_listpackages)
[19:07] <cjwatson> (assuming single-binary)
[19:09] <sveinse> excellent, now things look better. Thanks
[19:57] <carldani> Hi!
[20:05] <carldani> I'm not familiar with the development process of Ubuntu. I read the wiki, but I'm still a bit unsure about the significance of DebianImportFreeze.
[20:07] <carldani> The flashrom package in Debian unstable is a bit outdated and the release of a new upstream flashrom version is expected to happen in the next few weeks. Is there a chance to get that new (mostly bugfixes) flashrom version included in Oneiric, and if so, can it be made a copy of the Debian flashrom package which is hopefully updated directly after the flashrom release?
[20:12] <geser> carldani: DebianImportFreeze only means that automatic copies of packages Debian -> Ubuntu will stop, once the updated flashrom package is in Debian someone has to request a sync from Debian (assuming the upload to Debian happens between DebianImportFreeze and FeatureFreeze)
[20:18] <carldani> geser: Thanks for the info!