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