[00:00] <tumbleweed> broder: r1229
[00:01] <broder> tumbleweed: +1
[00:02] <Laney> r1230?
[00:02] <Laney> hohohohoho
[00:02] <tumbleweed> Laney: if you want that, find a bug
[00:02] <tumbleweed> I still need to make a more generic report editor, that doesn't talk about Ubuntu deltas
[00:03] <tumbleweed> (and in fact, the rest of requestsync.common needs to go away, too)
[00:03] <tumbleweed> but that's non-urgent, I'll probably get to that tomorrow
[00:03] <broder> tumbleweed: uh, if you want a 1230, maybe change "installs and removes cleanly" to "installs cleanly and runs". removes cleanly is nice, but not traditionally part of our standard
[00:04] <tumbleweed> and runs doesn't apply to libraries
[00:06] <tumbleweed> but I assume we can assome some intelligence in the user
[00:06] <broder> i always hold out hope
[00:06] <Laney> python-gnomekeyring managed to make a return :(
[00:07] <broder> ...are there not GI bindings for gnome-keyring?
[00:08] <tumbleweed> the problem isn't GI, but that it needs a running dbus
[00:09] <tumbleweed> it probably should be GIed, though, yes
[00:10] <broder> does it not just throw an exceptoin or something if there's no session bus or gnome-keyring-daemon isn't running?
[00:10] <Laney> thanks equivs
[00:11] <tumbleweed> yes, which launchpadlib doesn't deal with very well
[00:11] <broder> oh, ugh
[00:11] <Laney> it shows the rdeps stuff even if there aren't any
[00:11] <tumbleweed> that is true
[00:11] <broder> (hmm...there's a gir1.2-gnomekeyring-2.0 in debian. why don't we have one?)
[00:12] <tumbleweed> sounds new, I don't have that (/me shakes his fist at the local mirror which is on the blink again)
[00:12] <Laney> is it going to post this whole thing to the bug report?
[00:12] <tumbleweed> Laney: yes
[00:13] <Laney> interesting
[00:13] <tumbleweed> I'll skip the reverse dependencies section, if there are none
[00:13] <broder> hmm. nope, it's old. shipped in lucid, then got removed in maverick with a reference to bug #677382
[00:13] <broder> err, sorry. removed in natty
[00:14] <Laney> nn
[00:16] <broder> is there a specific channel for udd stuff? i want to figure out what http://package-import.ubuntu.com/status/lintian.html#2011-03-15 15:14:12.494272 means and if there's any hope of fixing it simply
[00:20] <tumbleweed> not that I know of
[00:25] <tumbleweed> Laney: r1231
[00:26] <wgrant> broder: That looks like it's running into a limitation of the current bzr format: filenames can't contain backslashes.
[00:29] <broder> Laney: do you not like the checklist going into the bug report? it seems to me like a good way to present the state of the bug
[00:29] <broder> i'm also planning to write bots that operate on that checklist (e.g. pick out bugs where all the testing has been finished)
[07:39] <JackRichards> Hello
[07:39] <JackRichards> I am just wondering is it possible to become a MOTU without learning a program launge
[07:40] <JackRichards> ?
[07:43] <JackRichards> ANyone can help?
[07:47] <siretart> JackRichards: there are many tasks you can do as MOTU without really knowing how to code
[07:47] <siretart> JackRichards: it is otoh a great opportunity to learn one ;-)
[07:50] <siretart> :-/
[07:52] <ajmitch> siretart: hi, haven't seen you around here for awhile
[07:54] <siretart> hi ajmitch, yeah, I've been pretty busy lately
[07:54] <siretart> ajmitch: how are you doing these days?
[07:54] <ajmitch> I'm well, been busy enough as well
[07:55] <siretart> :-)
[07:55] <ajmitch> trying to find my way back into development at some point :)
[07:55] <siretart> so I've learned from the news that revu is going to be deprecated? do you know details who is working on this?
[07:56] <ajmitch> it's something that's been talked about for a few months, and will take some time to do as the plan is to use mentors.debian.net, afaik
[07:56] <siretart> programming, yeah, I'm actually doing quite a lot of programming these days (shameless plug: http://vamos.informatik.uni-erlangen.de/trac/undertaker)
[07:57] <ajmitch> it'd mean that spooky could finally have its rest :)
[07:57] <siretart> yeah, that's what I understand. I'm not sure though who is actually working on it
[07:58] <ajmitch> I don't know if anyone has stepped up to help out with debexpo yet, if not then revu will likely stay around for a bit longer
[07:58] <siretart> and yes, spooky is giving me some worries. AFAIUI, the yellow light tells me that the cpu fans are failing. but that's already the case for several months and the machine didn't blow up yet :-)
[07:59] <siretart> in any case, I don't think that spooky will be a good machine for that.
[07:59] <siretart> do we have some other machine where we relocate revu to?
[07:59] <ajmitch> right, I don't think that spooky will still be needed
[07:59] <ajmitch> yes, I was meaning to relocate it to a VM on the ubuntuwire host
[07:59] <siretart> otoh, that will be quite some work. not sure if its worth the efford
[08:00] <siretart> effort
[08:00] <ajmitch> would you like me to move it so the old hardware can be taken down before it burns? :)
[08:00] <siretart> if you have the time and energy to do it, I think that would be a safe option
[08:00] <ajmitch> OK
[08:01] <ajmitch> thank you for providing spooky for all these years :)
[08:01] <siretart> I really don't know how much I can trust the machine, it's an old sunfire sparc server, that has served us for over a decade
[08:01] <ajmitch> still running hardy, isn't it?
[08:01] <siretart> you're welcome :-)
[08:02] <siretart> siretart@spooky:~$ lsb_release -c -s
[08:02] <siretart> hardy
[08:04] <ajmitch> probably getting a little hard to upgrade still :)
[08:05] <siretart> oh, hardy isn't EOL, yet :-)
[08:05] <ajmitch> no, but the fun of backporting dpkg & lintian & other packages wears thin
[08:05] <siretart> indeed
[08:12] <StevenK> siretart: It's a Sparc, it will just warn you with red lights as the processor melts.
[08:18] <siretart> StevenK: isn't it then a bit to late to worry?
[11:02] <Laney> broder: i did not say that, it just wasn't clear to me
[11:09] <Laney> do we care about 'upgrades cleanly'?
[11:10] <Laney> also, putting the submitter's lp ID in the backportpackage call isn't right
[11:10] <Laney> nobody else will be able to upload there :-)
[11:22] <tumbleweed> Laney: might aswe ll avoid substitution for at least one person, right?
[11:23] <Laney> you could give it to the user when they file
[11:23] <tumbleweed> right
[11:24] <Laney> or "replace <myusername> with your own"
[11:28] <Laney> or, if you offer to run it for the user before they file, then you can put that in the report
[11:30] <tumbleweed> that sounds sensible
[14:02] <rigved> hi everyone. i was following this Ubuntu Open Week session on Getting Started with Ubuntu Development by dholbach. I cannot seem to find any bitesize bug on harvest that has not already been fixed. Is there any simple bug that I can get started on?
[14:24] <astraljava> rigved: Probably new bitesize bugs will creep in more and more as the devel cycle progresses. We're still in the early stages of Precise.
[14:30] <rigved> astraljava: ok.
[15:05] <Kiall> is anyone use around who knows how to enable universe while creating a image with git-pbuilder?
[15:05] <tumbleweed> "creating a image" ?
[15:06] <tumbleweed> just sounds like you don't have universe enabled in your pbuilder
[15:06] <Kiall> creating the base, not sure if its called an image or what ;)
[15:06] <Kiall> oh, i thought I'd have to enable it in git-pbuilder..
[15:06] <Kiall> I'll google for enabling it in plain pbuilder
[15:06] <tumbleweed> I assume git-pbuilder is just a wrapper that calls pbuilder
[15:07] <tumbleweed> COMPONENTS="main universe multiverse restricted" in your .pbuilderc should do the trick
[15:07] <Kiall> Ah, I had tried that as a env var while running git-pbuilder create, I guess it needs to be in the config..
[15:08] <tumbleweed> pbuilderrc even
[15:08] <Kiall> tumbleweed: thanks, giving the create another run now..
[15:23] <Kiall> tumbleweed: that worked a charm, thanks
[19:11] <tumbleweed> broder, Laney, bdrung: I'll merge the requestbackport branch into trunk. I think it's done
[19:12] <tumbleweed> (and yes, the branch is full of not-really-related stuff)
[19:12] <broder> tumbleweed: the backportpackage example lines don't actually include a package name :)
[19:13] <broder> but +1 other than that
[19:16] <tumbleweed> fixed
[19:49] <cemc> [11/11-202059] <broder> cemc: is it possible you had installed your own backport before hand, where you hadn't changed the rules file?
[19:49] <cemc> I don't think so, because I installed a fresh hardy in a VM for the test
[20:26] <hrw> can someone take a look at fuse debdiff in bug 884907 and give opinion? (cjwatson did all previous merges from Debian - I hope to get this package properly)
[20:26]  * hrw -> off
[20:43] <cjwatson> hrw: argh
[20:44] <cjwatson> hrw: I was in the middle of a merge, now I have to reconcile?
[20:44] <cjwatson> hrw: you're meant to ask the previous merger *before you start* to avoid duplicated work :-/
[20:44] <cjwatson> hrw: and it's in bzr, so honestly, I'm not sure it's easier to review a debdiff ...
[20:44] <cjwatson> I could have told you that if you'd just askked
[20:44] <cjwatson> *asked
[20:51] <cjwatson> (sorry, I meant last uploader in the above, not last merger)
[20:58] <cjwatson> yay for powerpc builders having caught up
[20:59] <Laney> we getting the new one soon?
[20:59] <cjwatson> Laney: no sooner than a week and a bit from now, last I heard
[20:59] <cjwatson> (which wasn't a commitment to then, either :-/)
[21:00] <cjwatson> I've been hassling from time to time
[21:01] <Laney> the wheels of change turn slowly
[21:02] <Laney> yay for discovering mismerges
[21:52] <broder> cemc: ok, let me get a vm going. now that i think about it, i was working in a chroot, so it wouldn't have tried to start services or anything
[22:11] <cemc> broder: let me know if I can help with anything
[22:12] <Resistance> broder:  any progress on that bug blocking the natty backport?
[22:13] <broder> Resistance: no, not yet, but it is the weekend
[22:13] <Resistance> true :P
[22:13] <Resistance> was just curioius :P
[22:13] <Resistance> curious*
[22:50] <broder> cemc: i just spun up a hardy EC2 instance and installed the package and still didn't get an error, so i'm not sure how to debug this
[22:50] <broder> uh, what arch were you testing with?
[22:53]  * cjwatson is disappointed to find that the lintian description of more-than-one-patch-system is quite restrained
[22:53] <cemc> broder: i386. let me check again, ok?
[22:54]  * broder is terrified by the number of packages overriding more-than-one-patch-system
[22:54] <broder> cemc: great, thanks. please double-check when you do that you get the right package out of my ppa
[22:54] <micahg_> well, cdbs + quilt can be normal
[22:54] <micahg_> depending on how it's figuring it
[22:55] <broder> micahg_: it just looks at dpatch and quilt
[22:58] <cemc> broder: http://pastebin.ubuntu.com/737759/
[22:59] <broder> huh, that certainly looks right. need to run for a few, but i'll test it myself when i get back
[23:00] <cemc> broder: ok, thanks. I need to sleep (1am here), but we can continue tomorrow, just leave me a message
[23:34] <broder> cemc: yeah, it looks like (a) i typo'd something when i was fixing the rules file, and (b) a different postinst is getting generated on amd64 and i386, which means i probably screwed up my targets
[23:40]  * cjwatson fails to see why the yorick diff is still needed (or was ever needed in the first place, given that there are no matches for lcr or libcr in the source code) and syncs it instead
[23:40] <cjwatson> (test-built cleanly)
[23:42] <broder> bah, does anybody remember how pre-override_* dh sequencer works? https://launchpadlibrarian.net/84899905/pdns-recursor_3.3-2~hardy1.debdiff is only working on the i386 build, not amd64
[23:43] <cjwatson> I think your problem is binary vs. binary-arch
[23:44] <cjwatson> s/binary:/binary-arch:/ and append 'binary-indep:' and 'binary: binary-arch binary-indep'
[23:45] <cjwatson> also "defaults 19 852" looks like a typo
[23:45] <broder> yeah, i was going to get that as well :)
[23:45] <broder> what do you mean by append binary-indep:? just add it as an empty target?
[23:45] <cjwatson> yes, it has to exist but empty is fine
[23:45] <cjwatson> oh, wait, you still have %:
[23:46] <cjwatson> ignore that part then, just binary -> binary-arch
[23:48] <cjwatson> so that was untested; looking at a vintage dh you might actually need to be a bit smarter
[23:48] <cjwatson> dh_installinit is in the install sequence, while dh_strip is in the binary-arch sequence
[23:48] <cjwatson> so I think I would be inclined to do:
[23:48] <cjwatson> install:
[23:49] <cjwatson>         dh $@ --before dh_installinit
[23:49] <cjwatson>         dh_installinit --error-handler=initscript_error -- defaults 19 85
[23:49] <cjwatson>         dh $@ --remaining
[23:49] <cjwatson> binary-arch:
[23:49] <cjwatson>         dh $@ --before dh_strip
[23:49] <cjwatson>         dh_strip --dbg-package=pdns-recursor-dbg
[23:49] <cjwatson>         dh $@ --remaining
[23:50] <cjwatson> s/^binary-arch:/binary-arch: install/
[23:50] <cjwatson> overrides are so much nicer - I never really put lots of thought into learning the early dh7 style
[23:52] <broder> yeah, i considered it to be an unacceptable replacement for cdbs until overrides came along
[23:52] <broder> thanks, though - i'll play with that