[08:26] <lanoxx_> when i run 'bzr dh-make ...' it shows a list of some properties such as maintainer name and email address, but the email address and license that is shows are wrong, where does dh-make pull these variables from?
[10:14] <tumbleweed> lanoxx_: I thought one had to tell it the license
[10:14] <tumbleweed> it can't guess that
[11:29] <jokerdino> hey devs, any idea when epiphany-browser 3.6 will land in quantal? i see only the source of it
[11:29] <Laney> jokerdino: when webkit gets fixed :/
[11:31] <jokerdino> it doesn't build on armhf, does it?
[11:32] <Laney> right
[11:32] <jokerdino> aww, so i have a choice to build it from source on amd64
[11:33] <cjwatson> Hopefully it won't take that long and all you need is a few days' patience
[11:33] <jokerdino> i'll wait
[11:33] <cjwatson> Sorting it out one way or another is release-critical ...
[11:34] <jokerdino> i would just install it and remove it in a matter of minutes anyway.. :/
[11:59] <tumbleweed> kirkland: now that I see the uplead that you were pinging me about, thanks
[12:00] <tumbleweed> I don't like checking for the existance of /etc/dpkg/origins/ubuntu, though. I have that on my Debian desktop... :)
[13:26] <micahg> tumbleweed: the alternative for sks would be a .in file for the maintainerscripts so you can substitute in from debian/rules
[13:27] <tumbleweed> micahg: yes
[13:27] <tumbleweed> the danger of testing SRUs in build chroots :)
[13:38] <micahg> tumbleweed: I'm surprised there's not a lintian check for that, would think it might be common
[13:39] <cjwatson> marga: I just remembered the problem with '. /etc/lsb-release' (myunity)
[13:39] <cjwatson> marga: bug 214861
[13:39] <cjwatson> marga: you might want to lift the shell code from either Debian or Ubuntu's localechooser package instead - it's battle-tested, it should be about as quick as sourcing the file, and it's safer
[13:45] <marga> cjwatson, ok, I'll look at it
[13:45] <marga> cjwatson, I'm a bit depressed about the sponsoring of this, though
[13:46] <marga> I spent 2 weeks waiting for it to be in the "yellow" zone, and since whoever looked at it didn't like the description, it's back at the end of the queue.
[13:46] <cjwatson> I think you got caught up in process confusion around -backports
[13:46] <cjwatson> and I'm not convinced it's back at the end of the queue - didn't Laney say he'd uploaded it?
[13:46] <Laney> yes. It's done.
[13:47] <ogra_> yeah
[13:47] <marga> Oh, I missed that.
[13:47] <Laney> and it didn't take /that/ long. Try and get an SRU :-)
[13:47] <marga> Laney, thanks!
[13:47] <cjwatson> (I wouldn't put quite as much stock in the queue ordering as you do, BTW - it's not uncommon for sponsors not to work in the obvious order)
[13:48] <cjwatson> I certainly often do easiest first
[13:48] <marga> ok :)
[13:49] <micahg> and backports is certainly not a queue
[13:49] <marga> I'm hoping to get upload rights to universe, but first I need to clear some stuff regarding copyright at my current job.
[13:49] <cjwatson> after that it shouldn't be too difficult for a DD
[13:52] <Laney> yeah, also that wouldn't strictly help for backports
[13:53] <Laney> unless you also decided to join the backporters
[13:53] <marga> I think it would be helpful.
[13:53] <Laney> we certainly wouldn't turn down competent help
[13:54] <marga> Just so it's clear, I work for a derivative distro and we intend to use precise, probably until the next LTS, so having access to uploading patches to precise-backports would make my life easier and happier.
[13:55] <Laney> You should be aware that myunity is a special case because it's removed from Q. Generally we backport packages wholesale.
[13:55] <marga> Yes, I know.
[13:55] <Laney> so it's not "uploading patches" in the usual sense
[13:55] <marga> Right.
[13:57] <micahg> we could consider PPU rights in precise which would grant backports uploading privs (bugs would still have to be filed and such, but would just need a review/acceptance in queue)
[13:58] <Laney> well, that logically extends to all uploaders
[13:59] <Laney> which brings us closer to the Debian model... maybe that's alright
[13:59] <marga> I don't understand exactly what micahg suggested.
[14:00] <Laney> extending the set of people who can directly upload backports
[14:00] <marga> per package?
[14:00] <Laney> yeah
[14:00] <marga> Isn't that too complicated?
[14:00] <Laney> which probably isn't what you're after, since you indicated that you want to go for MOTU
[14:00] <Laney> the ACL is technically the same across components
[14:01] <Laney> I haven't given it much consideration from a policy POV
[14:02] <cjwatson> Well, as you say this is just social policy; if you can upload $package to $series then you can upload it to $series-backports too, as far as the ACLs are concerned
[14:03] <Laney> it will still always land in the queue to be approved by a backporter
[14:03] <cjwatson> Sure
[14:03] <cjwatson> But that probably isn't a big deal
[14:03] <Laney> I think that is what we want in any event
[14:03] <cjwatson> (Queue review's easier than sponsoring)
[14:05] <Laney> We look for some specific things in backports bugs though (which requestbackport gives you checkboxes for)
[14:05]  * jokerdino pokes.
[14:05] <Laney> So it would be good if most uploaders were aware of this if we were to extend the set
[14:06] <jokerdino> i was looking at minitube src a while ago and they don't have any patch :|
[14:07] <cjwatson> hmm?
[14:07] <jokerdino> they just imported from upstream
[14:07] <cjwatson> <cjwatson@sarantium ~/minitube-1.7>$ ls debian/patches/
[14:07] <cjwatson> assure-quit-keybinding  disable-update-check  gcc-4.7.patch  proper-tempfiles  series
[14:07] <jokerdino> and given recent changes for Youtube API, the one in quantal wouldn't work
[14:08] <jokerdino> cjwatson: the same patches exist in 1.9 in debian
[14:08] <cjwatson> bug 1057718, I guess
[14:08] <jokerdino> yes that
[14:08] <cjwatson> jokerdino: your comment was sufficiently ambiguous that I genuinely didn't understand what you were talking about at first
[14:09] <jokerdino> i am extremely sorry.
[14:09] <jokerdino> was on another room :|
[14:09] <jokerdino> anyway, i tried building it and it fails.
[14:10] <cjwatson> I'm reviewing the feature freeze exception now
[14:11] <jokerdino> thank you
[14:25] <cjwatson> jokerdino: I guess your build environment must be wonky somehow, or else it's an architecture-specific failure; it builds cleanly in a quantal/i386 sbuild chroot.
[14:26] <jokerdino> ah, it fails on amd64
[14:26] <jokerdino> i was using pbuilder amd64
[14:26]  * cjwatson kicks off an amd64 test build
[14:27] <cjwatson> how did it fail?
[14:27] <jokerdino> i'll test it again.
[14:27] <cjwatson> don't bother, mine's running
[14:27] <cjwatson> it was only if you already had it
[14:28] <jokerdino> i did but closed it.
[14:40] <cjwatson> jokerdino: Builds fine on quantal/amd64 too.
[14:41] <jokerdino> should be a PEBKAC then
[14:41] <jokerdino> bah, i purged the minitube source. too lazy to download it again
[14:54] <jtaylor> what happened to default-jdk in ubuntu?
[14:54] <jtaylor> or what should be used instead now?
[14:55] <micahg> hrm?
[14:55] <micahg> jamespage: ^^
[14:55] <jtaylor> it can't be installed in quantal
[14:55] <jamespage> jtaylor, still there as far as I can see
[14:56] <micahg> wfm in a clean chroot...
[14:56] <jtaylor> hm maybe I messed up my indices
[14:56] <Laney> indeed
[14:56] <jtaylor> was playing around with ports before
[14:57] <jtaylor> a it works now sorry for the noise
[15:38] <kirkland> tumbleweed: okay, well, then perhaps you can suggest another solution, that doesn't depend on dpkg-vendor?
[15:40] <kirkland> tumbleweed: perhaps "lsb_release -si"
[16:49] <micahg> kirkland: you need a binary depends on lsb-release for that
[16:54] <micahg> bdrung: why did you tell that person to get those bugs for new packages in the sponsorship queue when they need an FFe?
[17:11] <ScottK> Particularly when the odds of a new package FFe at this point are 'very small'.
[17:12]  * micahg sees them as candidates for backports
[18:32] <jtaylor> someone got a machine with sse4?
[18:33] <jtaylor> I'd like to fix bug 1027977 but can't reproduce it on my machine :(
[18:33] <micahg> jtaylor: sse4_1 sse4_2 ?
[18:33] <jtaylor> yes
[18:34]  * micahg doesn't have time for anything complicated ATM though
[18:35] <jtaylor> hm lets see if amazon as a suitable machine ._.
[18:37] <jtaylor> is quantal backports open already?
[18:38] <micahg> yes
[18:38] <jtaylor> how does that work?
[18:38] <jtaylor> there is no series to copy from
[18:38] <micahg> unstable/experimental
[18:38] <micahg> but the requestbackport script doesn't recognize them yet
[18:38] <jtaylor> k, the usual procedure file bug and wait 6 month? ;)
[18:40] <micahg> well, wait until the backporters see it, Laney's been busy with release duties and I'm trying to finish up stuff so I can +1
[18:40] <micahg> s/see/have time to process/
[18:54] <Laney> join the team?
[18:55] <jtaylor> I was thinking about that
[18:56] <jtaylor> though I doubt I could put much time in it
[19:03] <jtaylor> great valgrind breaks if rebuilt
[19:11] <jtaylor> mmh memory corroption
[19:12] <jtaylor> lets see if I can run valgrind on valgrind
[19:15] <Laney> ah, good ctte
[20:00] <ScottK> Laney: ?
[20:01] <Laney> ScottK: The Python question was put to rest finally
[20:01] <ScottK> Oh.
[20:01]  * ScottK looks.
[20:03] <ScottK> Not a bad ending.
[20:05] <Laney> aye
[20:10] <jtaylor> success :D
[20:31] <jtaylor> ops valgrind isn#t universe
[20:42] <micahg> jtaylor: I can sponsor if it's bug fix
[20:42] <jtaylor> its bugfix
[20:42] <jtaylor> quite important even
[20:46] <micahg> jtaylor: bug # w/debdiff?
[20:47] <micahg> jtaylor: also, if I sponsor, you take responsibility to fix any fallout as I won't be available until after final freeze
[20:47] <jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/quantal/valgrind/various-fixes/+merge/128314
[20:50] <micahg> jtaylor: do you agree to take responsibility for any fallout resulting from the upload?
[20:51] <jtaylor> k
[20:51] <micahg> ok, looks good
[20:51] <jtaylor> all fixes are from upstream/debian
[20:52] <micahg> right, I don't expect any, but I won't be available :)
[20:56] <cjwatson> Hah, apparently I dodged having to be on record one way or the other on the Python question by forgetting to read my -ctte mailbox. :-/
[20:59] <cjwatson> But my preferred option on the ballot won so that's OK.
[21:16] <dlentz> i would like to discuss bug 1060813
[21:16] <jtaylor> micahg: as we are on the topic suggestion on what to do with minitube?
[21:16] <jtaylor> its broken in quantal and fixed in unstable
[21:16] <jtaylor> we could sync the major update, and hope it won't break again
[21:16] <jtaylor> or remove it
[21:17] <micahg> well, if we can get an MRE, I'd say sync latest version and keep up to date
[21:17] <micahg> otherwise, remove, but not blacklist, and we can throw it in backports
[21:18]  * micahg wanted an MRE for gnash as well
[21:18] <micahg> but it seems development on it has slowed
[21:18] <jtaylor> for the mre there is the question who files it, I really don't care about them ._.
[21:18] <jtaylor> but I do care about packages being unusable in the archive
[21:19] <micahg> cjwatson: would the tech board IYHO be willing to grant an MRE to something like minitube and youtube-dl which need to be kept up to date and belong in something like volatile?
[21:19] <cjwatson> jtaylor: I already granted an FFe for the minitube update
[21:20] <jtaylor> just saw it in the list
[21:20] <cjwatson> micahg: we've established the general principle in the past; I expect it would depend on having a developer take responsibility more than anything else
[21:20] <cjwatson> I'd rather we updated it properly in the mainline repositories rather than going to the effort of creating a volatile, though
[21:21] <micahg> cjwatson: well, I would think it's in archive or backports
[21:21] <dlentz>  cjwatson that's why I SRU'd
[21:21] <cjwatson> I don't see why it shouldn't be updateable in -updates
[21:23]  * jtaylor syncing minitube
[23:30] <tumbleweed> kirkland: I'm fine with that approach for now :)