[02:36] <TheMuso> Anybody seen this error with schroot on a recent fres precise install? E: Access not authorised
[02:41] <broder> TheMuso: is that the thing where you need to generate a key for the temporary local apt repositories?
[02:41] <TheMuso> broder: No.
[02:41] <TheMuso> Thats for sbuild, this is trying to use schroot.
[02:41] <broder> ok. no idea then :)
[02:47] <TheMuso> Ah right, seems in Oneiric and earlier I was a member of admin, which is listed in the valid groups for my schroots, but I am no longer in that group for precise, so adding myself to sbuild fixed it.
[02:49] <broder> are we changing the semantics of the admin group or something, or was that just a personal choice on your part?
[02:50]  * micahg things admin is no longer created in precise
[02:50] <TheMuso> I don't remember ever adding myself to admin, and I used a schroot.conf snippet from mk-sbuild a while back, so other than adding chroots/overlays to my schroot.conf, I have not changed groups etc.
[02:50] <TheMuso> micahg: I think you're right.
[02:50] <micahg> https://launchpad.net/ubuntu/precise/+source/user-setup/1.39ubuntu1
[02:52] <broder> cool, i had been wondering if we were going to do that at some point
[04:44] <CrazyThinker> Where can I find ubuntu source code?
[04:52] <pitti> Good morning
[07:19] <doko> bjsnider, ?
[07:51] <dholbach> good morning
[08:16] <janimo> pitti, morning this ARM kernel SRU has been tested, but I just recently (now) commented on it being validated https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/874264
[08:17] <janimo> can you please push it to updates when your time allows? thanks
[08:21] <pitti> janimo: done
[08:21] <janimo> \o/
[08:42] <CrazyThinker> What tool can display the inode structure of a system beautifully?
[11:16] <hrw> does someone know how to force udisks to refresh list of block devices?
[11:17] <hrw> bug 601351
[11:40] <pitti> ev: btw, you know that you can reconstruct .crash files pretty easily from LP bugs, using python-apport?
[11:41] <pitti> ev: we can even get .crash files with core dumps if you get the bugs tagged "apport-failed-retrace"
[11:41] <ev> ah brilliant, though I do think it would still be worthwhile to have some that are retraceable
[11:41] <ev> (as mentioned, whether these are manually constructed or come from that data set is up to you)
[11:44] <pitti> ev: for example, bug 754358 is not exactly bad for testing, it's just not considered good enough for automatic duplication (the way we do it right now)
[11:45]  * pitti checks the retracer logs whether they already picked up a dupe since yesterday
[11:46] <pitti> right, seems so; bug 891503 is one example
[11:48] <ev> pitti: ah, fair play.  I'll just work with that data then.
[11:51] <pitti> hmm, I looked at a few, and the addresses are differing a lot :(
[11:56] <pitti> ev: I changed the DC retracer to keep ProcMaps.txt as well; working with offsets in the libraries instead of with absolute addresses might be better after all
[11:56] <ev> hm, okay
[11:57] <pitti> I'll do some research, I have nothing urgent to do this afternoon
[12:08] <pitti> ev: ah, so it seems addresses in the actual executable remain stable, but libraries get relocated at each run; that's what misled me on my quick try at UDS
[12:09] <pitti> but it's not really a surprise indeed
[12:09] <ev> phew
[12:29] <pitti> ev: \o/ offsets FTW (http://paste.ubuntu.com/741116/)
[12:29]  * pitti goes to turn that into code
[12:29] <ev> YAY!
[12:29] <pitti> doing this stuff with a calculator is a bit tedious
[12:30] <ev> :D
[12:30]  * cjwatson attempts to construct a reproduction case for bug 891257 that's smaller than "upgrade Steve's laptop"
[12:31] <ev> lol
[12:33] <cjwatson> I guess if I C-z at a particular point ...
[12:50] <hyperair> pedro_: ping
[12:50] <pedro_> hyperair, hello
[12:50] <hyperair> pedro_: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/744257 <-- please verify if the fix in oneiric-proposed works.
[12:50] <pedro_> hyperair, ok I'll check it in a minute
[12:50] <hyperair> thanks
[12:50] <pedro_> you're welcome
[13:05] <zul> can someone review python-keystoneclient for me please?
[13:06] <doko> jamespage, do you an idea about the java component mismatches?
[13:12] <Kalidarn> hi quick question, is thunderbird major releases maintained in between releases?
[13:13] <Kalidarn> ie 7.0.1 to 8.0 or would i need to wait till Precise Pangolin for support?
[13:13] <Kalidarn> it appears ppa:mozillateam/thunderbird-stable does not support oneric, and ppa:mozillateam/thunderbird-next as of this morning replaced 8.0 with 9.0b1
[13:14] <Kalidarn> according to the release notes for 8.0 a couple of security fixes occured
[13:14] <Kalidarn> Thunderbird 8 closes six security holes. Three of these were rated as critical issues: memory corruption while profiling using firebug, code execution via NoWaiveWrapper and miscellaneous memory hazards have been fixed. The remaining high-risk vulnerabilities include two cross-origin theft bugs and a potential cross-site scripting (XSS) hole.
[13:16] <jdstrand> Kalidarn: for 11.10, we are following the rapid release, so it will get tbird 8. updates are being prepared.
[13:16] <Kalidarn> I'd assumed so especially as the I don't like outstanding security issues with my system :)
[13:17] <jdstrand> indeed
[13:17] <Kalidarn> thanks for answering my question even though #ubuntu-devel may not have been the correct place nobody seemed to know in #ubuntu or in #thunderbird on irc.mozilla.org :P
[13:17] <jdstrand> Kalidarn: if you have questions about security, please visit #ubuntu-security (or #ubuntu-hardened, which is the same channel)
[13:18] <Kalidarn> hmm i might add that to my znc idle listing :)
[13:18] <Kalidarn> because that is of interest to me.
[13:55] <feldgendler> hello!
[13:55] <feldgendler> I'm Alexey Feldgendler from Opera Software
[13:56] <feldgendler> mvo: I was told I should talk to you about this issue
[13:56] <feldgendler> I'm responsible for packaging Opera for Debian and Ubuntu.
[13:56] <feldgendler> i'm currently struggling with the following problem: on every distribution upgrade done by the upgrade manager, our third-party package source that we add to /etc/apt/conf.d gets disabled
[13:56] <feldgendler> I know it's deliberate
[13:57] <feldgendler> if the rationale behind this problem is to prevent third-party packages from breaking the upgrade due to e.g. outdated dependencies, fair enough, but is there a way for us to bypass this mechanism?
[13:57] <feldgendler> we routinely test in all new Ubuntu releases and take care that our dependencies are correct
[13:57] <feldgendler> worse still, not only do upgrades of Opera get disabled, but also the existing Opera package gets removed as “obsolete”, in the worst case leaving the user without a browser
[13:58] <mvo> hey feldgendler, I'm on the phone right now, but I come back to you in some minutes (once the call is over). ok?
[13:58] <feldgendler> mvo: sure, thanks a lot!
[14:06] <jamespage> doko: libcommons-discovery-java switched build system from ant -> maven
[14:06] <jamespage> I'll fix it up next week - sprinting this week
[14:29] <Chipzz> feldgendler: if it gets disbaled deliberately, maybe you're simply not *meant* to work around it?
[14:31] <bjsnider> doko, still there?
[14:33] <rye> kenvandine, ping, re: bug #874501 - it looks like the SRU for Oneiric for that specific bug is blocked. What's the bug for "Return password results with the most recent result first"?
[14:36] <kenvandine> rye, ugh...
[14:38] <kenvandine> rye, there isn't a bug referenced in the upstream Changelog
[14:40] <kenvandine> however, I would imagine that returning the older entry should never been what is intended and if anything this fixes stuff
[14:41] <kenvandine> but i am not an expert on gnome-keyring
[14:41] <rye> kenvandine, mmm... is there atestcase? So that we could file it, test it, provide the test result and give the info on regression potential
[14:42] <kenvandine> rye, not sure if that would really help in this case... the problem would be determining if anything is actually expecting the older entry
[14:42] <kenvandine> i think the regression potential is the change in behavior, and maybe other apps depended on the broken behavior
[14:43] <kenvandine> i doubt that is the case, but it is hard to determine that
[14:46] <kenvandine> rye, all the other fixes in this release are clear wins... and i suspect this fix could be a good thing too... i doubt anyone expects to get the older result... if they even know that multiple entries are created
[14:47] <rye> kenvandine, true, I will file a separate bug which can be referenced to
[14:48] <kenvandine> rye, there was a test included in the upstream commit for it... but I am sure it is just to ensure the latest is returned
[14:48] <kenvandine> that doesn't help us measure risk of regression
[14:49] <seb128> you have two options there, revert the commit in the sru or do a "check that nothing you use get broken"
[14:50] <seb128> the number of keyring users is a reasonable set, the default desktop contains a good part of it
[14:51] <feldgendler> Chipzz: maybe I can take that as an answer, but not until I understand the rationale
[14:53] <feldgendler> Chipzz: still, something is wrong if the user installs Opera, then upgrades Ubuntu and loses Opera in the process. I fail to see how this benefits the user.
[14:58] <dobey> feldgendler: the updater doesn't know whether or not the new release is supported by those archives that were added; or that the packages in the archive for the previous release will necessarily install/work/notbreaktheworld on the new release
[14:58] <dobey> feldgendler: also, packages shouldn't be adding archives when they get installed
[14:58] <feldgendler> dobey: I see. so the updater doesn't know if our source is prepared for the new release. but is there a way for us to indicate that?
[14:59] <dobey> feldgendler: no there isn't
[14:59] <feldgendler> dobey: before we had automatic addiing of archives, we used to recommend the user a manual prodecure with the same result, and which would have the same problem
[15:00] <feldgendler> dobey: also, we ask a debconf question before we add our acrhive, so I don't believe we're violating anything
[15:00] <OdyX> .oO(Making Opera distributable by others would help…)
[15:01] <feldgendler> we're working on that
[15:01] <feldgendler> still, some Debian-based distributions never accept non-free software, so it's a non-option for them
[15:02] <OdyX> feldgendler: then make Opera DFSG-free. .-p
[15:03] <Laney> the user can set an environment variable or condifuration option to turn off the disabling
[15:03] <Laney> and from reading the source I just noticed that the env var has a typo(!)
[15:04] <Laney> "RELEASE_UPRADER_ALLOW_THIRD_PARTY" in os.environ
[15:04] <feldgendler> mvo: what can you say about it?
[15:05] <feldgendler> Laney: I know. that's equivalent to setting AllowThirdParty=True in the update manager config overrides
[15:05] <geser> feldgendler: have you tried to get opera into the Ubuntu partner archive? that could be one option to avoid getting opera deinstalled on upgraded
[15:05] <Laney> indeed
[15:05] <dobey> is the precise release schedule not final yet?
[15:06] <feldgendler> Laney: however, I tried it and it didn't work. looking at the code, I see that it only keeps the entries that mention the name of the current release as the distro name.
[15:06] <feldgendler> Laney: the name gets changed to the name of the new release
[15:06] <Laney> that is what i would expect, yes
[15:06] <feldgendler> Laney: the whole AllowThirdParty feature seems to be designed for local Ubuntu mirrors (that would use Ubuntu release names) rather than third-party software sources.
[15:08] <feldgendler> geser: yes, we're working on that. still, Opera would then only appear in multiverse, right? which means that by default, if you download and install Opera by clicking “download” on the official website, you'll end up with no updates
[15:08] <mvo> feldgendler: sorry for the delay, indeed, there is a global way to override it
[15:08] <feldgendler> geser: using a browser which doesn't get updated is risky because of the vulnerabilities that get fixed all the time
[15:09] <feldgendler> mvo: I'm currently considering the following as a workaround; enable AllowThirdParty=True and mention the current distro name in our source lines
[15:09] <feldgendler> mvo: that way, the updater will change the distro name to the new release name but otherwise keep our sources intact
[15:09] <mvo> feldgendler: so there is currently no really good answer, I would *love* to see opera in e.g. archive.canonical.com or integrated via the new developer.ubuntu.com archive so that it could become part of the "official" archive in some way, but I understand that this is not easy from your side
[15:10] <feldgendler> mvo: we're working on that
[15:10] <feldgendler> mvo: but see above about downloading Opera from the official website
[15:11] <geser> feldgendler: the partner repository (partner.ubuntu.com) is different from the multiverse component of the main repositories
[15:11] <mvo> feldgendler: indeed, that will work, but this will enable third party archives globally, let me have a look at the code to see if we can hve a more fine grained solution. I think the distro release name in the sources.list is a good step, essentially you need a way to tell update-manager that opera is a official mirror
[15:11] <feldgendler> mvo: I've exlored that possiblity
[15:12] <mvo> feldgendler: if opera would be in partner/multiverse for all users that have multiverse/partner enabled (that is the default) it would just work, when there is a update that is newer than the version downloaded from the web you would get it
[15:12] <feldgendler> mvo: but the list of mirrors comes in /usr/share/update-manager/mirrors.cfg which is not a conffile
[15:12] <mvo> feldgendler: indeed, but I can add you code for 12.04 to make it possible to have additional mirrors :)
[15:12] <feldgendler> mvo: I would love that!
[15:13] <feldgendler> mvo: while you're at it, maybe you could remove the disabling of those sources that don't mention an Ubuntu release?
[15:14] <mvo> feldgendler: do you have a example what your current deb line looks like for me?
[15:14] <feldgendler> mvo: things like Opera, Skype, Google Chrome don't usually make different builds for different Ubuntu releases. in fact, Chrome has its own releases, and uses “stable”, “testing” and “unstable” as the release name
[15:14] <feldgendler> mvo: deb http://deb.opera.com/opera/ stable non-free #Opera Browser (final releases)
[15:14] <feldgendler> the word “stable” we use there is arbitrary
[15:15] <feldgendler> we only have one Opera
[15:15] <mvo> thanks feldgendler
[15:16] <feldgendler> we also have this one:
[15:17] <feldgendler> deb http://deb.opera.com/opera-beta/ stable non-free #Opera Browser (beta releases)
[15:21] <mvo> feldgendler: thanks, I check the source in u-m now to see what I can do about this and get back to you, ok?
[15:22] <feldgendler> mvo: sure, thanks!
[15:35] <Chipzz> mvo: maybe the distro upgrade should output a question along these lines "Hi. You haz 3rd party repository enabled. We recommendz you to disable it in orde nt to break upgrades. Disable yes/no?"
[15:36] <Chipzz> with a default "Yes"
[15:36] <pitti> cjwatson, stgraber, mdz, kees, soren: TB is still at 1800 UTC today, i. e. an hour earlier now with winter time?
[15:38] <cjwatson> damn, I haven't had time to process the doodle output
[15:38] <cjwatson> yes, I guess so
[15:39] <stgraber> pitti: I assumed so. Hopefully we'll have a new meeting time after this meeting
[15:40] <stokachu> _jmp_, o/
[15:41] <soren> cjwatson: Are my e-mails to the mailing list not getting through? I sent one earlier today about this.
[15:48] <stgraber> soren: only e-mails I saw today were from Steve and Kate
[15:51] <pitti> I did a moderation run today
[15:52] <cjwatson> soren: I've approved your mail now
[16:08] <pitti> debfx: fontforge-extras> please note that we dno't need to keep a delta for Section: changes, we can fix that in our archive overrides
[16:18] <SpamapS> slangasek: seen the fervor around bug 856810 ? Seems like people aren't getting /run symlinks maybe?
[16:22] <debfx> pitti: so I should revert the diff, file a bug and subscribe ubuntu-archive?
[16:27] <pitti> debfx: I don't actually think that the section will change if you change it in an upload
[16:27] <pitti> sections are defined when binNEWing
[16:27] <pitti> (or changing manually)
[16:27] <pitti> not with every upload, AFAIK
[16:27] <pitti> at least that's how Debian works, and I'm 90% sure that LP works the same
[16:27] <pitti> debfx: it's not urgent, just wanted to point out that next time you can just sync :)
[16:37] <debfx> pitti: if it's not done automatically, who handles section/priority mismatches (especially for packages synced from Debian)?
[16:38] <cjwatson> nobody :-/
[16:38] <cjwatson> well, priority mismatches are handled by a script and synced up with seeds
[16:38] <cjwatson> section mismatches are regrettably unhandled right now
[16:38] <cjwatson> and pitti is correct AFAIK, changing the section in an upload achieves nothing
[16:39] <Laney> why isn't the package just used for sections?
[16:45] <cjwatson> more wrong than average, I think
[16:46]  * debfx wonders why there is a need to have a different section in the archive vs. package control file
[16:48] <cjwatson> I believe Debian ftpmasters wanted to be able to shift packages about between sections in bulk without having to wait ages for a load of uploads
[16:48] <cjwatson> it dates back well over a decade, what do you want of me ...
[16:49] <pitti> cjwatson: ah, Mon 21:00 UTC -- somehow I was afraid it would be during sleep time :)
[16:49] <pitti> but oh well, it's only biweekly, no biggie
[16:50] <slangasek> SpamapS: hadn't seen that one, but <sigh>
[16:50] <cjwatson> it's not ideal for me either, but it was the best available
[16:50] <pitti> cjwatson: thanks for doing the poll
[16:52] <SpamapS> slangasek: it looks like a grouping of dupes around the dbus problems (fixed right?) and a few upset about not being able to use /etc/network/interfaces for certain things
[16:53] <slangasek> SpamapS: which dbus problems?
[16:54] <SpamapS> slangasek: I thought there was a problem with dbus and the /run transition
[16:54] <SpamapS> slangasek: but I may be conflating things :-P
[16:54] <slangasek> sure, there are a number of things that fail miserably if /var/run isn't properly transitioned, dbus being the most obvious
[17:13] <infinity> cjwatson: Hrm.  So, debootstrap is still brain-dead in the face of multiple versions of a package, isn't it?
[17:14] <infinity> cjwatson: (the archive skew fix/workaround means multiples exist in indices, leading to, for instance, armel not being debootstrapable right now)
[17:16] <cjwatson> oh, hah
[17:16] <cjwatson> possibly.  although Debian has that same fix/workaround so I'm surprised it hasn't been noticed there ...
[17:16] <infinity> cjwatson: I'm testing on amd64 right now, cause you'd think it would have the same problem.
[17:17] <infinity> cjwatson: But basically, debootstrap is picking perl 5.14 and perl-modules 5.12 (despite both versions of perl-modules being in the index).
[17:17] <infinity> cjwatson: And yeah, amd64 just failed the same way.
[17:17] <infinity> cjwatson: Which makes sense.
[17:18] <infinity> cjwatson: (--variant=buildd required to pick up perl, I guess)
[17:18] <cjwatson> how come old perl-modules is still in the index anyway?
[17:19] <cjwatson> new perl has been built everywhere for some time
[17:19] <cjwatson> is it upset that armhf hasn't done it yet?
[17:19] <infinity> You'd think not, since there's no build record for armhf.
[17:19] <infinity> But Julian might be in a better position to answer that.
[17:20] <infinity> Either way, the cruft issue aside, this should probably work.
[17:20] <cjwatson> agreed ...
[17:20] <infinity> Or, since dependency resolution is hard at that stage, at least fail in the other direction (always pick the package with the higher sort order)
[17:21] <cjwatson> it should just pick the newest, yes
[17:21] <cjwatson> however we don't yet have dpkg --compare-versions ...
[17:21] <cjwatson> we could pick the last in Packages and trust that it's version-sorted
[17:21] <cjwatson> (which it apparently is, at least in this case)
[17:22] <infinity> It's LC_COLLATE=C sorted.
[17:22] <infinity> As in, it's the order they appear on the filesystem.
[17:22] <infinity> Which is wrong for certain version comparisons, but 99% right. :P
[17:22] <cjwatson> we could fix that in LP
[17:22] <cjwatson> or rather in apt-ftparchive
[17:22] <cjwatson> it's much better-placed to do version-sorting than debootstrap is
[17:23] <infinity> Oh, actually, yeah, I was thinking of a raw apt-ftparchive scan without a config and pre-gen indexes.  In LP, it might actually be correct.
[17:23] <dobey> cjwatson: is the precise release schedule supposed to still be a draft?
[17:23] <cjwatson> LP presumably gives it a file list
[17:23] <cjwatson> dobey: -> skaet
[17:23] <dobey> ah right
[17:23] <infinity> Yeah, LP gives file lists, so it might be doing the right order anyway.  Would have to dig.
[17:23] <dobey> skaet: is the precise release schedule supposed to still be a draft? :)
[17:23] <infinity> But "latest is highest" is normally true for Packages files, except for oddball corner cases anyway. :P
[17:24] <skaet> dobey, yes,  I still need to apply the changes discussed at UDS
[17:24]  * skaet getting blueprints wrangled first
[17:24] <cjwatson> infinity:         files.sort(key=package_name)
[17:24] <dobey> skaet: ah ok; do you know when that should be done by?
[17:24] <cjwatson> infinity: so any version sorting is either in apt-ftparchive or by luck
[17:25] <skaet> dobey:  will be done by planning freeze.   Is there a specific date or some info you need before then?
[17:25] <infinity> cjwatson: Assuming that maps back to a SQL lookup (and everything in LP does), it's going to end up with a FIFO of versions as they appeared in the tables.
[17:25] <infinity> cjwatson: But yeah, that's pure luck, not design.
[17:26] <SpamapS> slangasek: any chance you can upload mysql-5.5 5.5.17-3 to experimental today?
[17:26] <cjwatson> infinity: files is a python list
[17:26] <infinity> cjwatson: Yes, but the list came from a table.
[17:26] <infinity> cjwatson: And since it's only sorting on package name, the version order would remain intact, as retrieved from the DB.
[17:27] <infinity> cjwatson: I'd assume.
[17:27] <SpamapS> slangasek: I'd like for it to land there before I upload the merged version to precise and start the libmysqlclient transition.
[17:27] <infinity> cjwatson: (Still, pure luck)
[17:27] <cjwatson> infinity: ah, yes, since Python 2.3 list.sort() is guaranteed stable
[17:28] <infinity> cjwatson: I'm trying to decide if that was sarcasm, or quoting an API ref.  Or both. ;)
[17:28] <dobey> skaet: i need to set up milestones on all the u1 projects, for releases we're going to make for the cycle, and don't want the dates to change out from under me right after i finish doing it :)
[17:28] <cjwatson> infinity: the latter :)
[17:28] <cjwatson>         result_set.order_by(
[17:28] <cjwatson>             BinaryPackagePublishingHistory.id, BinaryPackageFile.id)
[17:29] <cjwatson> is what the file list is actually sorted on in the SQL lookup
[17:29] <cjwatson> (about five levels up)
[17:29] <cjwatson> so, uh, first published will be first in Packages?  I guess.
[17:29] <infinity> cjwatson: Yeah.
[17:29] <skaet> dobey, gotcha. :)  will ping you when I finish with the updates.
[17:29] <cjwatson> so that should in practice match version ordering
[17:29] <infinity> cjwatson: Which is more or less right.  But again, only accidentally.
[17:29] <cjwatson> well, guaranteed right because versions can't go backwards
[17:29] <cjwatson> although I'll grant you accidental
[17:29] <infinity> cjwatson: No, but IDs can.
[17:30] <cjwatson> oh
[17:30] <dobey> skaet: ok thanks. planning freeze == feature def freeze?
[17:30] <skaet> dobey, yup.  :)
[17:30] <infinity> cjwatson: Well, I don't know if they have.  But there's no reason they can't. :P
[17:30] <cjwatson> can or actually might?technically
[17:30] <cjwatson> bah
[17:30] <cjwatson> "technically can or actually might?"
[17:30] <infinity> Technically can.
[17:30] <infinity> Actually, dunno.
[17:30] <dobey> skaet: ok
[17:30] <infinity> Still, tiny corner case, not terribly concerned.
[17:31] <infinity> It's also probably possible to publish out of order.
[17:31] <infinity> But I don't really want to think about that right now.
[18:15] <slangasek> SpamapS: yeah, I can do that today - can you update the changelog in svn?
[18:16] <SpamapS> slangasek: done
[18:16] <SpamapS> wait
[18:17] <SpamapS> oops
[18:18] <SpamapS> slangasek: ok, committed now
[19:19] <mterry> doko, I'm going to merge pari if you don't shout
[20:59] <adam_g> is there some dh magic that takes care of creating link from /etc/init.d/$somejob -> /lib/init/upstart-job if it hasn't been created in postinst or rules?
[21:00] <hallyn> adam_g, I think if you just do dh_installinit --upstart-only it does it automatically yes
[21:01] <adam_g> hallyn: ahhh, will check that. thanks
[21:02] <hallyn> adam_g, and if you do 'dh_installinit --name xy -pz' I assume the same
[21:02] <hallyn> iow, I've never had to worry about it.  it's always done it for me
[21:02] <hallyn> np
[21:03] <roaksoax> adam_g: if you using dh7 and have the upstart job in debian/<package>.upstart should be done automatically
[21:04] <adam_g> im looking at a pkg that, via rules, installs both an upstart and a script to init.d.. was scratching my head how the /lib/init/upstart-job gets there
[21:04] <roaksoax> adam_g: its a symlink that gets handled by dh
[21:04] <adam_g> yup
[21:15] <slangasek> adam_g, hallyn: --upstart-only means "there was never an init script with the same name as this upstart job"; it has no effect on whether the symlink is created
[21:16] <hallyn> slangasek, thx, yeah, that's what i started to think after i spoke up
[22:25] <slangasek> SpamapS: <cough> test build done; now would you like to update the changelog to point to experimental instead of precise? ;)
[22:36] <SpamapS> slangasek: HAHAHHA ok ;)
[22:36] <slangasek> SpamapS: would be best if you also updated the uploader line to be you instead of nobse
[22:37] <SpamapS> slangasek: did that too
[22:37] <slangasek> ok cheers
[22:39] <SpamapS> slangasek: commit just finished
[22:39]  * SpamapS shakes svn... GO FASTER
[22:39]  * slangasek shakes svn... BE something else
[22:42] <SpamapS> slangasek: I will bring up migrating to bzr once the 5.5 dust has settled. :)
[22:42] <slangasek> :)
[23:13] <slangasek> SpamapS: OOI, why does libmysqlclient-dev ship /usr/lib/*/mysql/plugin/ha_*_plugin.a?  Is someone going to statically link these plugins?
[23:13] <SpamapS> slangasek: oh that may be a mistake
[23:13] <SpamapS> slangasek: I'm not entirely sure
[23:13] <slangasek> ok
[23:14] <slangasek> 5.5.17-3 uploaded now
[23:14] <SpamapS> slangasek: thanks, I'll take a look at the plugin bits
[23:16] <SpamapS> slangasek: I mean, THANKS!!! btw. ;)
[23:16] <slangasek> :)
[23:21] <SpamapS> slangasek: Hm, it seems all those plugin archive files are missing from 5.5 entirely...
[23:21] <slangasek> heh
[23:21] <SpamapS> slangasek: may have to ask to have them installed somehow.
[23:26] <slangasek> pitti: sorry for the procps breakage yesterday, btw... reuploaded now with a better fix