[00:31] argh [00:32] just realised that backports build depends bug is going to prevent me from doing agda backports [00:32] how frustrating [00:32] as i seem to recall, you were planning to learn more about how soyuz works :) [00:33] it's alright, it got escalated ^o) [00:35] yes, but there are 300 critical bugs [00:38] that reminds me, I was going to ask someone clueful about backports whether arb packages could depend on backported packages [00:39] ajmitch: in theory with backports on by default, there shouldn't be a reason not to [00:39] micahg: that's what I'd thought [00:39] ajmitch: but you'll want to make that clear in whatever describes extras [00:39] ajmitch: i assume that's a technical question and not a policy one, right? as long as the dependencies are versioned to pull in the backports, i think it would work [00:39] broder: that's what I was checking [00:40] uh....actually [00:40] ajmitch: I think it's worthwhile to pass it by the TB though just to be sure [00:40] wait, no that will hit the backports-can't-depend-on-backports bug [00:40] policy can be changed, I was checking whether it's technically possible [00:40] (because lp's sbuild has a dumb build-dep resolver) [00:40] yay for lp [00:40] bug #888665, in case you haven't seen it before [00:40] Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665 [00:40] broder: well, once that's fixed it would work :) [00:41] also, if it's a run time, not build time, it would work now [00:41] yeah, that's true [00:41] ok, I hadn't seen that bug, it probably answers a few of my questions about it :) [00:41] micahg: the use case is arb apps depending on libraries that weren't shipped in a stable version [00:41] also, PPAs might behave differently than the backports pocket [00:41] because bundling them is evil & wrong [00:42] ajmitch: we usually don't backport libraries :) [00:42] micahg: eh, that's not true [00:42] especially new libraries [00:42] broder: depends on the # of rdepeds [00:42] micahg: usually not, but I'm thinking more of new libraries, rather than new versions of existing libraries [00:42] *rdeps [00:42] ajmitch: ah, that's a fine use case then [00:43] though I can imagine the sheer fun & excitement of trying to backport a new version of Qt [00:43] ajmitch: short version of the bug: sbuild parses the build-deps without versions, passes just the package names to apt-get, cries when apt pulls from the default pocket instead of the lower-pinned one [00:44] * micahg is going to have enough fun backporting webkit 1.6 to lucid-oneiric [00:44] broder: right, because apt needs the version information to choose which package is appropriate [00:44] at least launchpad-buildd is split out as a separate project now [00:44] ajmitch: right. newer versions of sbuild create a dummy metapackage (with the actual depends list) and tell apt to install that instead [00:45] so http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/files has its own copy of sbuild [00:46] * broder squints [00:46] that looks like either a re-implementation or a *very* old version of sbuild [00:46] probably the latter [00:46] as in, pre-dates the first time i looked at the sbuild source [00:46] but i guess 2004-era fork would fulfil that requirement [00:47] this is why we can't have nice things... [00:50] * ajmitch wonders just how much they've diverged over time [00:51] i mean, the organization of current sbuild is totally different from that [00:51] yep [00:51] most of the code lives in the Sbuild perl module [00:51] it could make trying to fix that sbuild a bit of a challenge [01:03] broder: reading that bug, I see that wgrant has made some progress on getting sbuild to a more sane state [01:04] so maybe it's not quite as bad as I thought :) [01:04] ajmitch, broder: LP sbuild is a fork of Ubuntu's buildd sbuild from 2004, which is itself a fork of DSA sbuild from early 2004. [01:04] Which is a fork of Debian sbuild from earlier than that. [01:05] ...oh. oh, dear [01:05] The main thing keeping us on the fork is ddebs. [01:05] I have branches to port LP to almost-stock Ubuntu sbuild from ~a year ago. [01:05] I may just bite the bullet and reimplement the ddeb hack. [01:06] you would get much love if you get that in & make backports easier to deal with [01:06] Yeah [01:06] Might even take a stab at that today. [01:06] \o/ [01:06] Because it's been 7.5 years since we merged upstream :) [01:08] one thing that may cause deployment headaches: current sbuild (which i suppose is probably newer than what lp-buildd would be using) requires manually generating a gpg keypair in advance to sign the temporary apt repo it sets up with the dummy build-deps package [01:08] (see sbuild-update(1) and sbuild-update --keygen) [01:08] O_o [01:09] can apt not be made to use unauthenticated sources at that point? [01:09] i was just thinking about that [01:09] there may be an option to not sign the tmp repo and have apt not chcek signatures [01:10] which would probably be ok since this runs in DC [01:10] We already disable signature verification most of the time, but I don't really like that much. [01:11] there is an $apt_allow_unauthenticated sbuild.conf variable [01:13] ...but i can't find a way to disable the signing [01:15] sbuild-update manpage seems to say that the keys must be there, but they could be copied in or just live in the chroot [01:48] Hi [01:48] Hi [01:49] can partner repos be integrated with Ubuntu local deb mirror ? [02:03] checking in again for the query ? [02:22] can someone please comment ? [02:23] !patience | kaushal [02:23] kaushal: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/ [02:23] but i think you might have better luck in either #ubuntu-mirror or #ubuntu-mirrors - i forget which [02:23] broder: i did that already [02:37] broder: Sadly precise's sbuild needs libdpkg-perl, which is new in maverick. And new dpkgs don't obviously backport to hardy, which is what most of the buildds run :/ [02:38] isn't libdpkg-perl more or less standalone from dpkg core? [02:38] wgrant: oneiric's seems good though [02:38] oh, now it doesn't [02:38] *no [02:38] micahg: It hasn't changed since oneiric. [02:39] The last one I tried was Lucid's, which seems to work OK. [02:40] (we're stuck on hardy for a couple of reasons: dropped archs like hppa, ia64, and sparc; and the fact that some packages in old series don't like building on overly recent kernels. [02:41] wgrant: maverick's sbuild is the last without libdpkg-perl [02:42] but that needs a newer schroot [02:42] eh, so does the version in lucid [02:43] Backporting schroot is doable. Brand new dpkgs aren't. [02:45] * ajmitch hands wgrant some more chewing gum to hold LP together [02:45] Hey, it's not part of LP any more. It's a separate project :) [02:45] * wgrant disclaims all responsibility. [02:46] as of about a week ago, you mean :P [02:46] Shh === nxvl_ is now known as nxvl [04:17] any DD's around and interested in NMU'ing python-virtual for me? (maintainer is low-threshold, and this is a prereq for potentially multiarch-ifying the gtkmm stack) [04:24] err, python-visual [04:25] Actually doing the NMU, or sponsoring a NMU? [04:25] sponsoring :) [04:25] fixing http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633273 ? [04:25] Debian bug 633273 in python-visual "python-visual: Getting rid of unneeded *.la / emptying dependency_libs" [Normal,Open] [04:25] yep [04:25] debdiff is attached to the bug [04:27] package hasn't had a maintainer upload for >2 years now [04:28] i'm sure the maintainer ran away screaming from the tangle of cdbs in that package [04:28] * ajmitch should let StevenK deal with it then :) [04:28] Sure, let me convert it to yada. Can't be much worse [04:30] i was going to try and convert it to dh_python2, but i honestly have no idea how to do that with the way that package is set up [04:30] StevenK: you're in ~ubuntu-archive, why is yada still in the archive? [04:30] Reverse deps [04:31] burn them [04:32] there aren't many of them left, but they don't die off quickly enough [04:33] broder: Convert it to debhelper at the same time. [04:33] ScottK: seems like a *slight* subversion of the NMU rules :-P [04:33] and no, i'm *not* interested in taking over the package, before anybody says it [04:34] Ah, I thought it was orphaned. [04:34] last time I looked at that package, I ended up patching boost [04:34] Heh. [04:34] yay, oneiric fails to suspend *again* [04:36] StevenK: all 3 in Debian haven't been touched in Debian for quite a while, there are 2 we can drop in Ubuntu since Debian dropped them [04:36] There's only 3 revdeps? [04:36] 5 total [04:36] There was like 20 last I looked [04:36] * ScottK watches StevenK salivate. [04:36] http://paste.ubuntu.com/754482/ [04:37] ssh -v cocoplum [04:37] Oops [04:37] ssh -v cocoplum remove-everything.py [04:37] I still have the scars from libapache2-mod-auth-pam [04:39] It's got an RC bug against it that (I gather) requires it to be migrated away from yada to fix. [04:39] broder: Do that one. [04:40] apache, pam, and yada in the same package? that triggers my "run away screaming" response [04:41] Right, but your job is removing the yada, so it should be easy. [04:42] Do it now while you're still young and invincible. [04:42] Once you're old like StevenK you won't dare. [04:43] * StevenK beats ScottK with his walking frame. [04:43] * ScottK parries with his cane. [04:43] Like you're that limber. [04:43] great, the elderly are fighting again [04:44] I have an 8 year old child. I need to be able to move fast. [04:46] * micahg adds yada to his list of things to kill [04:47] quicky, What package contains the bluetooth app-indicator? [04:49] gnome-bluetooth afaik [04:51] ajmitch: I've installed it but don't see it in my indicator area, I'll give my sys another rebooth for good measure.. [04:51] thanks! [05:01] morbid curiosity is a $%^%$#, but it doesn't actually look like this package is...impossible to convert to modern packaging [05:03] i think the most annoying part is the lack of a functional install target === stalcup is now known as v === v is now known as Obama [06:20] ok, i'm upgrading the install target for libapache2-mod-auth-pam to "Tricky" [06:29] StevenK: http://paste.ubuntu.com/754525/ [06:34] it seems to generate .debs with *virtually* identical contents (mod-auth-sys-group used to ship a README.Debian.libapache2-mod-auth-sys-group; it now just ships a README.Debian) [06:34] but i haven't double-checked extensively [06:37] broder: Drop yada from the Build-Depends? [06:37] oh, hah [06:38] oh, actually one sec...that may not be the latest debdiff [06:40] there, that's more like it: http://paste.ubuntu.com/754530/ === Guest44296 is now known as jussi01 [07:45] oh, #$% [07:45] for once i actually *did* do dput ubuntu instead of dput ppa: [07:46] fortunately it was a package in main [08:01] good morning [08:06] morning dholbach [08:07] hey ajmitch === almaisan-away is now known as al-maisan [09:28] broder: so we must remember not to give you core-dev? :) === Quintasan_ is now known as Quintasan [09:55] everyone's done it once :P [09:55] needs moar dcut [09:56] * tumbleweed actually hasn't - don't play with main stuff much in my PPAs [09:57] I do worry about accidentally uploading to the wrongi distribution, but source vs binary uploads helps protect a bit there [09:59] i only did it once: https://launchpad.net/ubuntu/karmic/+source/ghc6/6.10.1+dfsg1-13~karmic1~ppa1 [10:00] * tumbleweed wonders if the archive should catch ~ppa\d+$ [10:00] but it's not a big problem [10:00] dput could [10:00] * tumbleweed really wants the archive to catch epoch bumps [10:09] I once managed to upload a PPA package to the main repository (universe) through uploading to ppa.launchpad.net [10:10] geser: how? [10:10] Laney: grumble, still getting some Signed-By: N/A [10:10] heh [10:11] geser: That sounds like you hit some bug. Or you did some /etc/hosts hacking ;) [10:11] still kernel? [10:11] yup [10:12] I was uploading through SFTP (it was pretty new at that time) and forgot to specify my PPA in the dput call so it got uploaded to a different upload directory (or something like that) [10:12] * tumbleweed is still waiting for SFTP support in debian... [10:13] I was surprised of the result myself (don't remember the details why it worked) [10:13] being suprised sounds totally reasonable :) [10:15] nested_email_re is nice [10:15] found it in my IRC logs: http://irclogs.ubuntu.com/2010/07/11/%23launchpad.html#t20:48 [10:17] not too many followed up on the packaging guide rename thread - are there generally any objections or further thoughts? [10:17] dholbach: my first thought was "urgh, *platform* guide?" [10:17] I still don't like the platform characterisation [10:17] but you are right that it's bigger than packaging and packaging might send the wrong message [10:18] I would go with Ubuntu Develop{ment,ers} Guide [10:18] in my mind platform sends the wrong message too [10:18] why? [10:18] can you try to explain? [10:18] Because there's nothing about writing code for Ubuntu platform itself in the packaging guide? [10:18] tumbleweed: ^ [10:19] nigelb: yeah, partly that. And platform just sounds big and horrible [10:19] nigelb, well, as soon as you make changes to any Ubuntu changes you are changing/writing code for the Ubuntu platform, no? :) [10:19] * tumbleweed can't quite articulate it [10:19] apropos renaming: wasn't it planed to rename UUC to something more clear? [10:19] because it's part of this platform / app separation [10:19] making Ubuntu into this base layer on which you run your app store [10:20] Laney, could you imagine that it's confusing to people who want to write applications for Ubuntu? [10:20] dholbach: Yeah, my point is what Laney articulated better. [10:20] we are Ubuntu Developers [10:20] so using that in the name would be right. [10:21] are people who develop an application for Ubuntu "Ubuntu developers" too? :) [10:21] That's the confusing there :) [10:21] are they in or seeking to be in ~ubuntu-dev? [10:22] that looks like a clear separation for somebody who is in the inner circles of Ubuntu [10:22] but I'm not sure it's a good way of explaining to somebody who is new to all of this [10:23] that's why I personally felt it'd make sense to bring a bit more clarity into the nomenclature [10:23] I don't think renaming us to Ubuntu Platform Developers is the right solution [10:23] isn't there also a platform team at canonical? [10:23] just noticed that the wiki page is still the top google hit for me [10:23] the things that are in the guide are how we do our development, not how people should write applications for Ubuntu [10:24] https://wiki.ubuntu.com/PackagingGuide ← should probably say something [10:24] about the new location [10:24] Laney: yeah, we gave an action item for that at UDS [10:24] I didn't suggest renaming the ~ubuntu-dev team - what I had in mind was to explain that you can develop applications for Ubuntu, but that you can also get involved in improving the platform [10:25] which is likely going to be news to new demographics of users/developers [10:25] we should explains what Ubuntu Developers do and that this is a guide to their work [10:25] * Laney stabs facebook chat [10:25] ok, I'm not sold to the name of platform guide yet, but what I'm trying to do is be clearer and more inviting [10:26] Ubuntu Developers and Ubuntu App Developers seems like a good separation. [10:26] As long as we explain it well. [10:26] packaging guide is clearly not right, because that is not what it is [10:26] dholbach: to some degree, I agree with the crazy teenagers (excuse the charictarisation) who wanted a "call for action" [10:26] I find "ubuntu platform" makes it even worse [10:26] Ubuntu Boring Stuff Guide [10:26] it makes it sound big and boring, yeah [10:27] Ubuntu Red Tape Guide ;) [10:27] :-(((((( [10:28] maybe we can try to revive the discussion on the list a bit? [10:28] yes, we should, I hadn't collected enough thoughts for a reply until now :) [10:29] I think it's worth taking into account that at some stage we might have more developers who are interested in bringing their application to Ubuntu and that they are not yet aware of the possibility to change the platform bits (or distro bits) [10:29] I consider this a huge selling point [10:30] and I don't want us to miss the opportunity to get them involved [10:30] is developer.u.c going to talk about ubuntu development? [10:30] it certainly is a different demographic of people, but sentiments of "us vs. them" (although none of you alluded to any of that) won't help [10:31] Laney, the current packaging guide lives there and there's a platform page which talks about Ubuntu the platform - I want us to be more present there :) [10:32] I think it would be good for the site to get a page explaining what Ubuntu Developers are [10:32] WARM FUZZIES! [10:33] Laney: oh, grumble, I think I had forgotten to clear the mboxes first [10:33] * tumbleweed runs it *again* [10:33] old data? [10:33] thanks a lot for your thoughts [10:33] could we run a couple of releases at a time, in parallel? [10:34] Laney: yes, did that before, but I still want to know that I'm fixing all the issues I've seen before I start from scratch [10:34] yeh [10:34] dholbach: I'll post a follow-up now [10:34] thanks :) [10:35] I added something to /PackagingGuide [10:35] micahg: aw, are we not ubuntu-desktop members any more? :) [10:36] I used to use that to push to Tomboy's bzr branches :P (since I have upload access through ubuntu-cli-mono-dev) [11:52] tumbleweed: what does UCT mean? [11:53] oh, university of capetown? [11:53] +space [11:56] yeah [11:57] eep, that extension changed [11:57] the only calls i have ever had on the university phone have been wrong numbers [11:58] most of my friends in other departments have graduated (not fair), but there are still a few people on the other side of campus who I regularly need to phone [12:00] in the renovations earlier this year I lost the phone on my desk. It's a pain [12:03] tumbleweed: what do you do? research? [12:03] for some reason, when dealing with university bureaucracy, phoning them makes things much more efficient. People generally assume you are staff, rather than undergrad. Of course my generally-scruffy appearance can't help much either :P [12:03] nigelb: yeah, I'm a MSc student [12:26] dear kernel. Please stop panicing. Everything's OK, I promise [12:26] (had one this morning too) === al-maisan is now known as almaisan-away === Amaranth_ is now known as Amaranth [13:40] tumbleweed: can reverse-depends src:foo (get an option to) exclude binary packages built by foo? === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [14:10] Laney: sounds like it should ignore them unless we are looking at build-dependencies [14:41] Laney: many of the remaining Signed-By: N/A are backports [14:42] but not all... [14:42] doubt we have enough data to do anything sane with backports [14:43] agreed [14:43] but why are you getting N/A? Aren't you setting it to changedby in those cases? Or do you just mean that is when this happens? [14:44] Laney, tumbleweed: where are you collecting the data? I assume you're parsing -changes lists(?) [14:44] dholbach: LP [14:44] launchpad [14:44] Laney: yes, I thought so too :P [14:44] but... [14:45] do you have a bit more info on what you're doing there? because I had a look at uploads before and was struggling with similar bits :) [14:46] dholbach: extracting LP upload history for the Debian UDD [14:46] we're using getPublishedSources in Launchpad's API to get all uploads and then cleaning up the data in various nasty ways [14:46] before putting it in a sensible format which is then imported into UDD [14:46] ahhhh ok [14:46] that sounds great [14:47] http://anonscm.debian.org/gitweb/?p=users/laney/ubuntu-upload-history.git;a=blob;f=lp-udd;h=01c00ea3dd6ae2fc815620e32ac93ca24f84fc99;hb=HEAD [14:47] sweet [14:47] * dholbach has a look [14:47] tumbleweed should put himself in copyright too [14:47] but doesn't getPublishedSources over all uploads take ages? [14:48] yes [14:48] Laney: so, I was only setting Signed-By = Changed-By for things without changes files (native syncs, presumably) [14:48] thought so :) [14:48] luckily you only have to do that once [14:48] after that you can just keep up to date [14:48] right [14:48] dholbach: yeah, if I thought ubuntu-sponsornig was painful to debug... [14:48] this takes a week for a full import [14:49] i'll do some in parallel if you want [14:50] that's why I tried to read -changes mboxes, but it's even more painful, as formats changed, when trying to get LPIDs for email addresses you get uploaders like katie, or -merged [14:50] i had a script for that (it's in the git repository) [14:51] worked ~well, but didn't catch everything (notably syncs) [14:51] * dholbach nods [14:51] Laney: ok, from a quick squiz at this, I think it's safe to do Signed-By = Changed-By everywhere [14:51] it's a world kept together by exceptions :) [14:52] tumbleweed: yeah, i thought thats what it was anyway so fine by me [14:52] Laney: for some reason at the timee I thought there were reasons not to... [14:53] gaah, every clone I have of this is set up differently [14:53] sometimes your branch is origin, sometimes mine [14:54] you could argue that we should only use signed_by when we know that it's right [14:55] with syncs that jsut gets messy. Signed-By is overloaded... [14:57] sure [14:57] i don't mind it [14:57] being always set [15:27] dholbach: I quickly ran that naming discussion past some non-ubuntu-dev friends (they may be silghtly biased by being my friends... :P ) [15:27] 17:16 <&Taejo> that is an idiotic name [15:27] 17:17 <&Taejo> I would have no idea what that was about, whereas the current name actually tells you [15:28] heh [15:30] well, ubuntu packaging guide tells you that it's about packaging [15:31] anyway, maybe we should just pick a name for the project, move on and think about what kind of additional content we need to make it all clear [15:31] what color should the bikeshed be? :) [15:31] ... [15:31] +1 for moving on (that's another reason why I didn't reply on that thread until today) [15:31] this is not a religious question to me [15:31] dholbach: I was told a long while back, "Don [15:31] bah [15:32] dholbach: "Don't wwait for majority, if something makes sense, do it unless someone brings a majority to oppose" [15:33] Or something to that effect :) [15:33] Of course, it doesn't apply for everything, but it was in the context of making a change to something and inactive discussion around it. [15:34] hey.. someone could help me ?... I'm some problem understanding the doko message in bug 896730 [15:34] Launchpad bug 896730 in policycoreutils (Ubuntu) "Please merge policycoreutils 2.1.0-3 (universe) from Debian unstable " [Wishlist,Incomplete] https://launchpad.net/bugs/896730 [15:36] l3on: the patch is incomplete [15:36] l3on: it ends with a hunk header [15:36] wth... why gmail does this to me!!! [15:36] heh [15:37] attaching it directly on lp should work :) [15:37] damnit [15:37] * tumbleweed makes the smug doesn't-use-gmail smile [15:39] ok, done... some sponsor here? :) [15:39] queue is fine [15:39] lol ok :) [15:40] well, is it a known problem? [15:41] I mean... everyone using gmail has the last '\n' trunked and replaced by blank space ? [15:41] l3on: that wasn't what happened here [15:42] oh, it was [15:42] :) [15:42] just remove that hunk, it's not useful :( [15:42] :) [15:43] ops... maybe next time I'll do.. [15:43] but, really, do you use your mail to upload patch ? [15:44] * tumbleweed normally uses lp web interface for things like that [15:44] I use e-mail when replying to comments often, if I want to quote without hassle (and writing in a real editor is easier than a web form) [15:45] i want to add libdrizzle_CFLAGS="-I/usr/include/libdrizzle-1.0/libdrizzle" to my debian/rules [15:46] but just exporting them before dh_auto_configure -- --disable-rpath doesnt seem to work [15:46] any ideas? [15:49] ah, just needed to install pkg-config? [15:52] yes, you probably want to detect things like that with pkg-config rather than hard-coded paths [15:54] well it's a launchpad problem 'cause if I send an email to myself, attachment is correct [15:58] tumbleweed: nope, so no uploading random desktop components for fun :) [15:59] yay for more tidying up (damn, I never got to abuse that) [16:25] tumbleweed, bug 898227 ... we'll see :) [16:25] Launchpad bug 898227 in Launchpad itself "Email attachments are corrupted when last line is '\n'." [Undecided,New] https://launchpad.net/bugs/898227 === alessio is now known as quadrispro [19:05] broder, did that bug which blocked the natty backport of znc ever get resolved or is it still just sitting there without a resolution? [19:06] Resistance: not yet (why don't you subscribe to it?) [19:06] tumbleweed, because i cant find said bug [19:06] * Resistance doesnt have a link to it [19:06] if you can provide me with said link i'll subscribe [19:07] it's bug 888665 [19:07] Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665 [19:07] Resistance: Ubuntu has "escalated" the bug (indicated to the LP devs that we consider it to be a serious issue) [19:07] wgrant said something about working on it, today, though [19:08] broder: did you find an NMU sponsor? [19:08] tumbleweed: i don't think so [19:08] i think everybody got distracted by purging yada from this earth with fire :) [19:08] sounds sensible [19:09] hehe [19:09] purging with fire [19:09] sounds like something i'd do [19:09] * Resistance tends to purge evil things with the equivalent of a computer technician's nuclear device rather than a smaller, specialized tool [19:10] Laney: I started the mass import [19:10] nice [19:10] all looking good? [19:10] (doing two batches of 7 releases in parallel) [19:11] err two parallel, each with 7 series [19:11] don't want to kill all the lp frontends [19:11] and there we go, i've subscribed to that bug now [19:11] tumbleweed: anyway, debdiff is attached to debian bug #633273 [19:11] Debian bug 633273 in python-visual "python-visual: Getting rid of unneeded *.la / emptying dependency_libs" [Normal,Open] http://bugs.debian.org/633273 [19:11] but i have to run at this very moment [19:11] Laney: too early to tell, but there are a good few DEBUG notices... [19:15] * tumbleweed spots something I should have NMUed [19:15] we should have a bot that finds patches you posted on the Debian BTS more than a month ago that haven't been applied to VCS [19:18] ah, the hilton -- cool [19:18] oops [19:23] tumbleweed: any idea when the ubuntu-dev alioth sponsor checker will show sponsors again? [19:24] micahg: ~ 3 days? [19:24] Laney: do you still have old data lying around? [19:25] :(, ok [19:25] micahg: I can ask LP if I can go faster... /me sticks his head in [19:26] tumbleweed: it's ok I guess, I think I found most of my sponsors [19:26] micahg: I can give you my old-school list-archive-scraping script for that if you want [19:27] ah, it's posted here: http://bazaar.launchpad.net/~stefanor/ubuntu-dev-tools/extra-scripts/view/head:/list-sponsorships [19:29] micahg: are you trying to look up people you've sponsored? [19:29] what python module provides Logger? [19:29] micahg: devscripts.logger [19:30] oh, do I have to run this from somewhere specific? [19:30] yeah, that was also designed for endorsements, you'll need to make minor modifications [19:31] you can run it anywhere, it'll cache the mboxes in ~/.cache/ubuntu-dev-tools/changelists/ [19:31] is python list-sponsorships not sufficient to run it? [19:32] should be [19:32] err, it takes arguments :) [19:32] you probably want -n '.*' [19:34] and a few -r s [19:34] err and you will want to modify it to state the sponsors [19:38] Any idea why "override_dh_auto_install: dh_auto_install; echo 'foo'" says "foo" first and runs dh_install/etc afterwards? [19:39] RainCT: dh_auto_install != dh_install [19:42] tumbleweed: uhm, so I need override_dh_install. ok, thanks === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [20:12]