[00:53] <aboudreault> How to extract a source package (to rebuild it) with dpkg-source
[00:53] <aboudreault> i get an error "public key not found"
[00:53] <directhex> ignore that error
[00:54] <aboudreault> but my package is not extracted
[00:54] <aboudreault> ha..... wait.
[00:54] <aboudreault> i think it's another problem.
[00:54] <aboudreault> my old dpkg-buildpackage replace the proper .dsc.
[00:54] <aboudreault> thanks.
[02:24] <ScottK> superm1: I'm looking at http://www.dell.com/home/laptops and wondering what happened to Latitude laptops.  Are they gone or just renamed?
[02:24] <superm1> ScottK, they're not for general consumer purchases, you have to come from a different entrance to the website
[02:24] <superm1> "For Small and Medium Business"
[02:25] <ScottK> superm1: OK.  Thanks.  I guess I never saw the consumer version before.
[02:25] <ScottK> Right.
[02:25] <lifeless> latitude get worldwide warranty and stuff
[02:25] <lifeless> consumer models don't
[02:27]  * ScottK has only ever had Latitude.
[02:33]  * masterkernel wonders if it has always been this quiet in here
[02:36] <ajmitch> it varies in here
[02:36] <masterkernel> when are most of the motu reviewers in here
[02:38] <ajmitch> probably during the day in the US or europe, I think
[02:38] <ajmitch> again, it varies
[04:05] <aboudreault> what does that mean? dpkg-shlibdeps: failure: no dependency information found for /opt/pdflib-lite/lib/libpdf.so.6
[04:06] <aboudreault> What can I do for that ?
[04:08] <RAOF> aboudreault: It looks like that means that something in your package is linking to /opt/pdflib-lite/lib/libpdf.so.6, and this file isn't being managed by dpkg, so dpkg-shlibdeps can't work out what package add to Depends.
[04:10] <aboudreault> How can I make it to be managed with dpkg ?
[04:10] <aboudreault> In fact, I did an apt-get source, added an option and tried to recompile
[04:11] <RAOF> Ah.  So, that's not actually being linked in to your package?
[04:12] <aboudreault> yes it is. because I've added a "--with-pdf" option to the package. So, now it's a dependency
[04:13] <RAOF> So, this won't be a problem if you're just trying to make a local package.
[04:13] <RAOF> Because that file isn't in a package, but you don't care because you don't need correct dependencies.
[04:14] <aboudreault> haa... your are right. I've installed that library manually because there is no package.
[04:14] <aboudreault> So, I can surely tell dpkg to ignore that dependency?
[04:15] <RAOF> The build isn't failing, is it?  I didn't think that was a fatal error.
[04:15] <aboudreault> yes it is
[04:16] <RAOF> Hm.  Well, you could write a shlibs.local file, I guess.
[04:16] <aboudreault> good, I'll google that. thanks for the hint :)
[04:32] <aboudreault> it's look like I have to specify a "package name" that is supposed to contain the file in the shlibs.local file
[04:36] <RAOF> Yeah.  Pick an installed package; let's call it libc6
[04:37] <aboudreault> that's what's I thought.... strange hack, but that will work.
[04:37] <mattschafer> 'Evening.
[04:49] <mattschafer> I'm new to packaging and would like to work on one of the pieces of software that I use.  I found several pages in the Ubuntu wiki about how to get started.  There's a lot there, and I'm trying to get my brain wrapped around it all.  Can someone give me a few tips and pointers?
[04:52] <mattschafer> Or perhaps answer a few introductory questions?
[04:52] <RAOF> !packagingguide
[04:52] <RAOF> That's probably where you want to be :)
[04:52] <ScottK> mattschafer: As questions as you have them and people will generally answer.
[04:53] <mattschafer> RAOF:  I've read through all of those.  Thanks for the links.
[04:55] <mattschafer> So my first basic question is this:  I found the package I want in the Debian being_packaged list.  However, it's been there with no other activity I can find for over 19 months.  Does this mean that I ought not to start an Ubuntu packaging attempt?
[04:55] <ScottK> mattschafer: Is it an RFP bug or an ITP bug?
[04:56] <mattschafer> Oh, let me check.  I think it was ITP, but I'll confirm.
[04:56] <mattschafer> It's an ITP:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449031
[04:57] <ScottK> mattschafer: Either way if it's been that long it shouldn't stop you.  Since it's an ITP, you might email the person and see if they are still interested, got any useful work done you might leverage, or perhaps ran into some reason it couldn't reasonably be packaged.
[04:58] <mattschafer> ScottK:  Right.  That's a good idea.
[04:59] <mattschafer> Okay, I need to read the PackagingGuide in detail.  There are many large areas where the package doesn't comply with the Debian guide.  Same is probably true for Ubuntu.
[05:00] <ScottK> Debian/Ubuntu packaging are about 98% the same.
[05:01] <persia> And it's not important if the package complies with the guide, so long as it complies with policy.
[05:01] <persia> There's lots of ways to construct a correct package.
[05:02] <mattschafer> One of the developers of Chandler Desktop said that he started the process of learning packaging about 18 months ago, but then had to pull back from the project.  He said that there are some MOTUs that may have history from his initial discussions back then.  I think he even went to a MOTU conference.  How might I find those folks?  Or is it not important, as others will pick up when I dig into it?
[05:02] <mattschafer> persia:  So the guide is not policy?  Is there an Ubuntu packaging policy doc somewhere?
[05:02] <persia> mattschafer, I believe the Ubuntu policy is in the Ubuntu debian-policy package.
[05:03] <mattschafer> Ah.  I was looking for it online.
[05:03] <persia> But except for a few minor notes related to maintainers, merge changes, etc. they are the same.
[05:03] <mattschafer> I see that there is both a debian-policy package and an ubuntu-policy package.
[05:04] <mattschafer> I'll install those.  Thanks.
[05:04] <persia> Then it's the ubuntu-policy package :)
[05:05] <persia> As for finding people, I suspect the majority were just helping package, rather than specifically interested in chandler (although I may be mistaken).  If there's a package on REVU, you might check the comments, but I think you"re better off just taking a fresh start.
[05:05] <mattschafer> Okay, here's another question.  Is it better to start by packaging for Ubuntu; or is it better to package in Debian, then let Ubuntu pick it up?
[05:05] <mattschafer> persia:  Probably true.  Those efforts happened so long ago.
[05:05] <persia> Doesn't really matter where you start.  Best to have it in Debian when you finish.
[05:06] <persia> In other words, the answer to that question depends on whether you personally find us or the debian-mentors group a better match to your personal work methods.
[05:06] <mattschafer> Ahhhh.  I don't know any of you.  :)
[05:07] <mattschafer> I just started looking into this about 3 days ago.
[05:07] <persia> Well then.  Start here.  When you get your package in good shape, get it into Debian.  Maintain it there, unless you need to have a difference especially for Ubuntu.
[05:08] <mattschafer> Sounds good.  Thanks.
[05:09] <mattschafer> I think my first steps are to contact the Debian maintainer in the ITP, start reading the packaging guides and policy manuals, and create an account in Launchpad.
[05:09] <persia> That's a good start :)
[05:09] <mattschafer> Then start digging into the source tree to see how I might tame that beast.  (It's pretty wicked in there.)
[05:10] <persia> Indeed.  When you get stuck with that part, ask specific questions here.
[05:10] <persia> (we might just point you at the policy manual, but we might have a good answer)
[05:10] <mattschafer> I know of three packages that they compile and include within Chandler Desktop that have modifications not integrated by upstream.
[05:10] <mattschafer> In at least one case, the modifications are "bordering on a fork"
[05:11] <mattschafer> So I'll have my work cut out for me, I bet.
[05:12] <mattschafer> Do you think the weekly packaging training sessions would be useful?
[05:13] <ajmitch> I'd hope they have some use :)
[05:14] <persia> You might want to review the logs.  They tend to explain one or another way of doing things fairly verbosely.
[05:14] <mattschafer> Hmm.  More specifically:  Do you think they'd be useful for someone literally completely new to packaging?  Or do you need some familiarity to make sense of it?
[05:14] <persia> Attending them regularly can be interesting, if you'd like to learn about other ways of packaging stuff.
[05:15] <mattschafer> Okay, great.  Just found the page of logs.
[05:15] <persia> Depends on the class.  Some assume familiarity, and some don't.  it also depends on who attended: they are usually structured to be educational to those present, rather than to make educational logs.
[05:16] <mattschafer> Well, thanks for all of your help.  I think I have enough to keep me busy for the next several evenings.
[07:28] <dholbach> good morning
[07:39] <MTecknology> dholbach: hi
[07:39] <dholbach> hiya MTecknology
[07:40] <MTecknology> dholbach: so, how's life?
[07:40] <dholbach> I'm slowly waking up and reviewing a bunch of patches atm
[07:40] <dholbach> how are you?
[07:41] <MTecknology> doing ok
[07:41] <MTecknology> feeling kinda sad, I might need to make a ban
[07:59] <iulian> G'morning dholbach!
[07:59] <dholbach> heya iulian!
[08:07] <slytherin> persia: geser: Can either of you please try building lucene2 from debian unstable and file a sync request if it builds? I tried twice on my laptop but unit tests are failing. Not sure what the issue is, but I suspect it is because of space constraint. The unit test seems to write a lot of data.
[08:07] <persia> slytherin, I'm having some HW limitations right now.  Dunno if I can build it.
[08:08] <slytherin> persia: ok. By the way, did you manage to check the powerpc chroot taken from buildd?
[08:09] <persia> slytherin, I did.  It didn't fail for me.  Dunno why.
[08:09] <slytherin> surprising
[09:10] <geser> slytherin: trying to build right now, but given that I've seen "[junit] Test org.apache.lucene.search.TestRemoteCachingWrapperFilter FAILED" I don't know if it makes sense to let it build further
[09:17] <cjwatson> nhandler: my karma's been rising fairly steadily for a while - I think I've just been busy in ways that LP notices ;-)
[09:26] <slytherin> geser: I don't remember which test was failing. I had kept the laptop on overnight as the build takes lot of time (specifically unit tests).
[10:08] <ttx> iulian: ping
[10:09] <iulian> ttx: Hey
[10:10] <ttx> iulian: thx for looking after the tomcat6 merges :)
[10:10] <ttx> iulian: I was wondering if we should not just sync them though.
[10:11] <ttx> iulian: Debian might actually be right in their use of openjdk- vs default-
[10:12] <ttx> iulian: on the build-depends side, tomcat6 doesn't build with gcj so it makes sense to force openjdk-6-jdk
[10:12] <ttx> iulian: on the runtime depends side, as long as they keep the "| java6-runtime-headless" it isn't worth keeping the delta
[10:12] <iulian> ttx: Oh, so, do you recommend to change it back to openjdk?
[10:13] <iulian> I can do that right now.
[10:13] <ttx> iulian: well, the package was originally done in Ubuntu and later adopted by debian, so it's not really "changing it back"
[10:13] <ttx> iulian: it's more accepting their changes :)
[10:13] <iulian> Ah
[10:13] <iulian> Right
[10:14] <ttx> iulian: the only somewhat wrong thing in there is the libservlet2.5-java depends
[10:15] <ttx> but that's not worth keeping the delta
[10:17] <iulian> ttx: Hmm, could you please enlighten me a bit about libservlet2.5-java?
[10:18] <ttx> iulian: it all comes from the default-java things, that point to different options based on arch
[10:18] <ttx> iulian: default-jre-headless usually points to openjdk-6-jre-headless but can also point to gcj on some arch
[10:19] <ttx> iulian: if the library requires Java 6 it makes sense to write "openjdk-6-jre-headless | java6-runtime-headless"
[10:20] <ttx> to force Java 6 options
[10:20] <iulian> Ah-ha.
[10:20] <ttx> iuian: however if it requires only Java 2...
[10:20] <ttx> iulian: "openjdk-6-jre-headless | java2-runtime-headless" is a bit too much
[10:20] <ttx> "default-jre-headless | java2-runtime-headless" is better
[10:20] <ttx> but that's just being picky
[10:21] <ttx> and it's more for affecting debian than us (since we have our default-java uising openjdk-6)
[10:21] <ttx> iulian: so if they are happy with it, we should probably be as well
[10:24] <iulian> ttx: That being said, should we accept their changes and stay in sync with Sid?
[10:25] <ttx> iulian: I'd say so. Haven't tested the last release though.
[10:27] <ttx> iulian: let me check how they did the tomcat-juli.jar thing
[10:28] <iulian> ttx: Excellent, thanks!
[10:30] <iulian> My lappy somehow freezes when building packages or removing large files, I have no idea why :-(
[10:31] <hyperair> bad i/o scheduler?
[10:32] <iulian> Probably, no clue.
[10:34] <iulian> I don't remember it freezing in this way back when I was using the ext3 fs.
[10:35] <hyperair> oho.
[10:35] <hyperair> are you an intel gpu user?
[10:38] <iulian> hyperair: Nah.
[10:40] <iulian> hyperair: Is this bug known?
[10:55] <hyperair> iulian: i had it when intel's GEM memory usage hit ~2G or so. then it'd start fighting with disk io for cache
[12:25] <up_the_irons> is this the right channel to ask whether it is possible to view the changelog of a package w/o installing it?  (like hypothetical "apt-cache showchangelog <foo>")
[12:33] <dupondje> up_the_irons: not really, but u can just check it on packages.ubuntu.com
[12:34] <up_the_irons> dupondje: ok thanks
[12:35] <directhex> apt-listchanges
[12:43] <up_the_irons> directhex: thanks
[13:29] <DktrKranz> Laney: have you already read at mok0's email in ubuntu-motu?
[13:29] <Laney> no
[13:29]  * mok0 wakes up..
[13:30] <Laney> good timing, I only *just* came back online
[13:30] <Laney> was reading my emails
[13:30] <DktrKranz> \o/
[13:30] <Laney> oh
[13:30] <Laney> yeah don't do anything about that just yet
[13:30] <mok0> Laney: You care about Haskell?
[13:30] <Laney> 6.10.4 is coming soon
[13:30] <Laney> I do!
[13:30] <mok0> Laney: cool
[13:30] <mok0> (Must admit I know nxt to nothing about it)
[13:31] <Laney> I was wondering if there's some kind of status page to write stuff like this
[13:31] <Laney> "don't worry about this, it's under control"
[13:31] <mok0> Laney: just reply to my message.
[13:31] <Laney> I will, but I bet most people won't see it
[13:31] <Laney> it would be better if we had a whiteboard
[13:31] <Laney> replying anyway
[13:32] <mok0> Laney: yes... some kind of status of all packages, like MoM perhaps
[13:32] <Laney> even more coarse than that, just a list of bullets
[13:32] <Laney> MOTU current affairs or something
[13:33] <Laney> dholbach: do you know of anything like this?
[13:33] <mok0> Laney: why don't you make one on the wiki and link to it from MOTUs team page?
[13:33] <Laney> I will if nothing exists already
[13:33] <mok0> Laney: the hard thing about these pages is keeping them current
[13:34] <Laney> yeah
[13:34] <Laney> Don't know what we can do about that, besides recording date + submitter
[13:34] <mok0> Laney, Even MoM has problems, if a merged package appears in a new version, the old comments still hang around
[13:35] <mok0> Laney: yes, and target release
[13:35] <Laney> maybe split it up by release cycle
[13:35] <mok0> :)
[13:35] <mok0> Beat you to that one :-)
[13:35] <dholbach> Laney: I hope that harvest will have something like that for all kinds of things in a few weeks, I'll just be quite busy in the next 2 weeks and not get around to doing something about it
[13:36]  * mok0 thinks we need to ask the supreme leader to relax the release schedule... releases are getting increasingly buggy
[13:37] <Laney> we're just guinea pigs for the LTS release anyway:)
[13:37] <mok0> Laney: well the ground troops can wear out
[13:38] <mok0> Laney: and the LTS can become a "phhhfft" rather than a "BOOOM"
[13:38] <dholbach> so for now I guess the wiki is the best option
[13:38]  * mok0 hugs dholbach
[13:38] <dholbach> soon I'd hope we could have a ftbfs.csv generated and add it to harvest
[13:38] <dholbach> or unmetdeps.csv or whatever
[13:46] <gaspa> dholbach: here I am ... :P
[13:46] <gaspa> i was thinking to put geser's page results on harvest.
[13:47] <dholbach> gaspa: sure do it :)
[13:48] <gaspa> is that what you said before?
[13:49] <gaspa> dholbach: I mean... you said that you'd like to have a ftbfs.csv ... if results like geser's page goes well, we had already much work done.
[13:50] <dholbach> sure, add it to harvest-data
[13:53] <Laney> wait, wasn't there an ubuntu developers news thing?
[13:53]  * Laney starts the cogs spinning
[13:54] <Laney> james_w: I think you were involved with it?
[13:54] <Laney> hi jcfp
[13:54] <jcfp> hi Laney
[13:55] <jcfp> thanks for looking at that patch :)
[13:55] <Laney> no worries, sorry I forgot about it in the house move... :(
[13:56]  * mok0 excuses his ignorance, but what is this harvest thing you're talking about?
[13:57] <hyperair> isn't that the low hanging fruit thing?
[13:57] <Laney> yeah
[13:57] <mok0> url?
[13:57] <Laney> some way of finding stuff to work on... I never figured out how to get anything from it sadly
[13:57] <dholbach> http://daniel.holba.ch/harvest
[13:58] <dholbach> it's not superduperhelpful at the moment
[13:58] <dholbach> but I plan to put some work into it this cycle
[13:58] <Laney> there's a big list of patches, and you're supposed to check if we want to take them AFAICS
[13:58] <mok0> dholbach: of course you could make a tutorial in #ubuntu-classroom
[13:59] <Laney> there were tutorials in open week
[13:59] <gaspa> there's also the output of edos on karmic :P
[13:59] <dholbach> mok0: what kind of tutorial?
[13:59] <gaspa> edos-{build,}decheck, I mean
[13:59] <mok0> dholbach: you know, teaching a class
[13:59] <dholbach> about what?
[13:59] <mok0> dholbach: harvest
[13:59] <dholbach> I hope to make it intuitive soon :)
[14:00] <mok0> dholbach: of course
[14:01] <mok0> dholbach: oh, I see you have patches from fedora too cool
[14:02] <dholbach> it's a bit broken right now, that's why I'd prefer to not put too much work into it in its current form
[14:02] <dholbach> the plan is to django-ify it
[14:02] <dholbach> and I'll put some work into kicking that effort off into two weeks or something
[14:03] <mok0> dholbach: ah, django... have been wanting to learn that a long time now
[14:03] <dholbach> cool, I'll note you down as people to speak to when it becomes a bit clearer what needs doing to make harvest useful again :)
[14:04] <mok0> dholbach: please do!
[14:04]  * dholbach hugs mok0!
[14:04] <mok0> :-)
[14:06] <highvoltage> hey motus
[14:06] <mok0> What kind of device does the armel buildd run on, does anyone know?
[14:07] <mok0> Marks mobile phone perhaps...
[14:07] <highvoltage> I'm doing a cat << EOF | uudecode > image.png
[14:07] <highvoltage> but the data that follows contains backticks that are interpreted
[14:07] <highvoltage> what can I do so that everything that follows just goes to uudecode?
[14:08] <mok0> highvoltage: why do you need that cat << EOF stuff? uuencode will handel embedded input
[14:08] <mok0> s/handel/handle
[14:08] <highvoltage> mok0: I want to put it in a dpatch file, persia suggested I do it like that
[14:09] <mok0> highvoltage: you are supplying a png for the app?
[14:09] <highvoltage> mok0: yes
[14:10] <mok0> highvoltage: just uuencode the file, and save it as *.png.uu in debian/
[14:10] <mok0> highvoltage: at install time, uudecode the file from debian/ and install it
[14:10] <highvoltage> mok0: I could do that, but persia said I get extra points if I do it inside the patch :)
[14:11] <mok0> highvoltage: I understand the challenge, but I don't see the point
[14:11] <mok0> highvoltage: better to make it as simple as possible
[14:11] <highvoltage> mok0: ok
[14:11] <mok0> highvoltage: you can _create_ a png.uu file via a patch, and then uudecode it
[14:12] <persia> Hrm?  That doesn;t make sense.
[14:12] <mok0> highvoltage: personally, I like putting stuff like that in debian/ easier to maintain
[14:12] <persia> dpatch is an executable shell script.  Makes sense to use it.
[14:12] <persia> Otherwise, yeah, just stuff a file in debian/ and unpack in rules.
[14:13] <mok0> persia: that's mis-use of dpatch IMHO
[14:13] <persia> mok0, Hrm?  Why.  dpatch is shell scripts precisely to support odd stuff like that.
[14:13] <Laney> whoops, I think I posted to ubuntu-motu from the wrong address
[14:14] <mok0> persia: I think that's not very intuitive. dpatch is for applying patches
[14:14] <persia> Laney, just cancel when you get the moderation mail and repost.
[14:14] <persia> mok0, Well, it depends.
[14:14] <soren> Laney: I'll accept it
[14:14] <Laney> I'll just wait for it to be accepted
[14:14] <Laney> thanks soren
[14:14] <soren> Laney: There.
[14:14] <persia> it's not intuitive to create, but it's intuitive to use, because the patch changes the file, as one would expect.
[14:14] <Laney> too kind
[14:14] <mok0> persia: can you give me an example of a package where dpatch is used to run scripts?
[14:15] <persia> Every single dpatch is a shell script.
[14:15] <soren> Laney: And added that address as an acceptabl sender.
[14:15] <Laney> oh, awesome
[14:15] <mok0> persia: well, they have the shebang line I know that
[14:15] <highvoltage> persia: so if I'd want to use cat in the dpatch file, would I need to escape all the backticks?
[14:15] <Laney> I try not to use it for Ubuntu stuff but that's not the fist time I've got it wrong
[14:15] <persia> highvoltage, Yes.
[14:15] <highvoltage> persia: perhaps in this particular instance mok0's way would be better?
[14:16] <persia> highvoltage, mok0's way is both more common and easier.
[14:16] <mok0> persia: but that's just used to start dpatch in a "clever" way
[14:16] <mok0> highvoltage: ;-)
[14:16] <persia> mok0, and this is why :)
[14:17] <highvoltage> ok I'm not going to do the cat thing in dpatch then to make things simpler for a future maintainer
[14:17] <mok0> persia: so I could hide an evil script in there and take over the buildd's hehehe
[14:17] <persia> The point being that using dpatch to place the binary allows one to comply with the guideline to easily allow the source to be patched with debian/rules patch and no fuss.
[14:17] <highvoltage> (I'll get my extra points some other way ;) )
[14:17] <persia> otherwise, one needs to make debian/rules more complicated
[14:17]  * persia prefers simple debian/rules
[14:17] <persia> mok0, No, you could take over the build instance, same as you could if you just stuck something in debian/rules.
[14:17] <mok0> persia: rules is a documentation of how the package is built
[14:18]  * Laney wonders what the MOTU Reporting Page is for
[14:18] <mok0> Laney: reporting indecent behaviour among the MOTU?
[14:18] <persia> Laney, We're supposed to do a monthly report.  Nobody has volunteered to be our monthly reporter for a very long time.  Are you up for it?
[14:19] <persia> mok0, Well, it depends.  I like the idea that one gets the patched source with a single command more than I like the idea that debian/rules documents the build.
[14:19] <Laney> persia: Not really. Apart from a lack of time, I see a lack of interest too. I was just searching for an existing MOTU whiteboard
[14:19] <mok0> persia: matter of taste I guess...
[14:19] <persia> I suppose one could do uudecode stuff in patch:, but I don't like to complicate things.
[14:19] <persia> Laney, whiteboard?  Towards what end?
[14:20] <persia> mok0, Indeed :)
[14:20] <Laney> documenting goings on of note
[14:20] <Laney> specifically "Don't panic about all the uninstallable haskell packages" in my case
[14:20] <persia> Wasn't there an initiative to coordinate with the News team to publish those?
[14:20] <mok0> persia: our chat started with my ML email a while ago
[14:20] <persia> Oh, for that, send a note to ubuntu-devel@
[14:20] <Laney> yeah, I pinged James earlier because my distant memory has something like this
[14:21] <mok0> persia: the point is that email are not remembered very long. What we need it Google Wave :-)
[14:21] <mok0> s/it/is
[14:22] <persia> mok0, Erm, maybe.  In this instance, I think email is better, because the information is only meaningful for a moderate amount of time.
[14:22] <mok0> persia: that's true, and a wiki page needs to be kept up-to-date
[14:23] <Laney> I guess I'd intend it to contain ongoing items of work, not really sure
[14:23] <persia> Right.  Wikis are bad for this sort of thing, unless you've only a few people.
[14:23] <persia> Laney, For ongoing work, there was MOTU/TODO, but it's now very out of date.
[14:23] <mok0> Laney, persia, if you Re: the original status message in email, it will be grouped by a modern threaded mail client
[14:24] <mok0> Actually, it might be better just to have a continuing thread on the mailing list, where new versions of the text are posted
[14:25] <Laney> I'm not worried about updating the status, it's more about letting people know what's going on so they don't worry or duplicate work or ...
[14:25] <persia> Right.  Because this is a one-time notice, use email.
[14:25] <persia> For lots of other things, email isn't best.
[14:25] <persia> Personally, I very much dislike the update-through-email model.
[14:25] <persia> But then again, I don't much like email, so perhaps I'm biased.
[14:26] <Laney> reminds me of Usenet FAQs
[14:26] <mok0> Perhaps, if there was an automated posting at the beginning at each month, it would appear at every web summary page
[14:26] <mok0> Laney: right
[14:27] <Laney> that's too much imo
[14:27] <Laney> the point of a wiki was to be simple, but it's been pointed out that this is perhaps unnecessary
[14:27] <mok0> Laney: 90% of the info on the wiki is outdated
[14:28] <mok0> Laney: or feels that way
[14:28] <Laney> I am very much not surprised by that
[14:29] <Laney> I find the wiki clunky and hard to navigate and use, so pretty much don't.
[14:30] <mok0> Laney: when google wave appears we should replace it
[14:30]  * Laney runs before he gets himself into "you fix it" territory :)
[14:30] <mok0> Laney: it's like archaeological culture layers... you have to live on top of them
[14:31] <Laney> it's fine to read as individual pages of documentation (where it's still current) though
[14:32] <mok0> Laney: right. There are 10% of the pages that are relatively maintained
[14:33] <persia> Well, I'm not sure that as much as that is maintained, but there's lots that hasn't gotten that stale as well.
[14:34]  * mok0 sighs
[14:35] <Laney> Maybe we need something more like the git community book and less like a wiki
[14:35] <persia> Hrm?  Why?
[14:36] <Laney> (for MOTU docs)
[14:36] <persia> How does that change anything?
[14:36] <Laney> mainly with regards to organisation and consistency
[14:36] <persia> Changing the format doesn't change the contents meaningfully.
[14:37] <Laney> Well it wouldn't just be a straight port, but editing too
[14:37] <Laney> I don't think that organic growth is producing the best quality documentation
[14:38] <persia> Ah, but that would require editors and structure, which would require people doing it.
[14:38] <persia> I'd personally rather those who can be developers be developers, and I don't trust those who can't be developers to document it correctly.
[14:38] <Laney> yes, it would require a big initial push
[14:38] <persia> In other words, it's up to us to document it best we can.
[14:38] <slytherin> does anyone have any idea if the package sync script will be run at least once before DIF?
[14:39] <persia> We've done a couple reviews and edits of the MOTU sections of the wiki previously.  Feel free to lead another :)
[14:39] <Laney> slytherin: It was going to be done today if it hasn't already
[14:39]  * mok0 has argued for a MOTU blog
[14:40] <slytherin> Laney: it hasn't already.
[14:40] <persia> slytherin, Should be run every ArchiveAdmin day through DIF day.
[14:40] <Laney> mok0: You could hack wordpress to use lplib auth!
[14:40] <persia> mok0, Doesn't really help.  Timeliness, lack of utility over time, etc.
[14:41] <mok0> persia: perhaps but it's not as  prolific as a wiki
[14:41] <persia> mok0, Hrm?  How do you mean?
[14:42] <mok0> persia: there will be "pages" and there will be "blog entries". The former typically for documentation, the latter for temporary messages.
[14:42] <persia> Erm, except what temporary messages don't belong on ubuntu-devel@ ?
[14:43] <mok0> persia: the "pages" will be a single text file, not a bunch of #included segments from who knows where
[14:43] <persia> Oh, I don't like that either, but dholbach was the last person to drive a wiki cleanup, and did it that way.  Feel free to unwind it if you have the time and patience.
[14:43] <mok0> persia: I don't :-)
[14:44] <persia> Right.  I don't think changing the format changes anything.
[14:44] <mok0> persia: I propose moving everything to a blog :-)
[14:44] <persia> Hard to have static docs in a blog.
[14:44] <mok0> persia: no, you just have a "page"
[14:45] <persia> And pages link to other pages, and we can all edit the pages?
[14:45] <mok0> persia: yep
[14:45] <persia> And there's a special page that shows the recently changed pages, and another than shows the new pages?
[14:45] <mok0> persia: sort of like a wiki ;-)
[14:45] <persia> and you can get RSS feeds from these?
[14:45] <mok0> persia: yes
[14:45] <persia> Yeah.  That's my point :)
[14:46] <persia> You're just changing the format of the entries.
[14:46] <mok0> persia: seriously, Google Wave will turn everything around
[14:46] <persia> Seriously, I don't think this is a problem that technology can address.
[14:46] <persia> The problem is that nobody wants to handle the docs.
[14:46] <mok0> persia: have you watched the video?
[14:46] <persia> And the one person who did step in an try to do it did it in a way nobody else wants to use.
[14:47] <persia> I've watched the video, but I still say it's irrelevant.
[14:47] <slytherin> Laney: persia: looks like sync has been done but the changes are not advertised on karmic-changes mailing list.
[14:47] <mok0> persia: well, that's your prerogative if you do the work
[14:47] <persia> slytherin, autosync generally isn't advertised there.
[14:47] <slytherin> I thought it was
[14:48] <persia> mok0, Indeed.  I don't blame that person, I just say that's where we are.  Redoing everything is just makework.
[14:48] <mok0> persia: I guess
[14:48] <mok0> persia: we are too pressed with these damn semi-annual releases
[14:49] <persia> So, I'd rather fix it.  If there's a specific issue with our specific underlying technology, that's diffe3rent.  To me, the problem is entirely social.
[14:49] <mok0> persia: with all this release work, there is no time to improve our infrastructure. That is my point
[14:50] <mok0> persia: -devs are wearing out fast, and newcomers don't know the history
[14:50] <persia> mok0, Well, that's not strictly true.  Some of us could, and some of us have in the past.  Just nobody is doing it now.
[14:50] <mok0> persia: you said that last year :-)
[14:50] <mok0> persia: and will be saying it a year from now
[14:50] <persia> Yes.  Nothing much has changed since then.  It remains true.
[14:51] <mok0> persia: I could change if we were heard by the top of the pyramid
[14:51] <persia> I doubt I'll be saying that a year from now.  if we don't update the infrastructure, we will lose the game.
[14:51] <mok0> persia: exactly
[14:51] <persia> What do you mean "I could change if we were heard by the top of the pyramid"?
[14:51] <mok0> persia: many MOTUs move on to do main work
[14:52] <persia> Ah, yes.
[14:52] <persia> That's why I believe in ArchiveReorganisation.
[14:52] <mok0> persia: I mean that the semi-annual schedule is wearing everybody out
[14:52] <persia> Well, the schedule isn't going to change.
[14:52] <persia> Perhaps we're not doing it right, as less of us used to do it before.
[14:52] <mok0> persia: we are just patching the same bugs over and over b/c there is no time to submit to upstream
[14:53] <persia> We spend a lot of time doing more merges past DIF.  This is good for users, but not specifically required.
[14:53] <persia> Hrm.  That's an interesting perspective.
[14:53] <mok0> persia: that's because many bugs are solved by upstream updates
[14:53] <persia> I know.  They also cause some bugs.  It's not clear what is the right answer.
[14:54] <persia> Originally, the right answer was to sync sid, and fix all the bugs over six months in a small subset of packages for each flavour.
[14:54] <persia> Of course, that has changed significantly, and MOTU is a large part of that change.
[14:54] <mok0> persia: they do, but ultimately the responsibility is in upstream's hands
[14:54] <persia> But it does make the problem different.
[14:55] <mok0> persia: was there any discussions at UDS along these lines=
[14:55] <mok0> ?
[14:55] <mok0> s/was/were
[14:56] <mok0> Of course, we could choose to just make 1 release of Universe every year
[14:56] <persia> Not that I attended, but UDS tends to be light on MOTU topics, mostly because nobody schedules any, usually because only a minority of active MOTU are present.
[14:56] <mok0> I see
[14:56] <persia> See, I'm not sure how one release of universe could work.
[14:57] <persia> But again, I don't think Universe is a useful entity to consider.
[14:57] <mok0> No, it would be hard esp. if the toolchain is updated
[14:57] <persia> Right.
[14:57] <persia> So, we're stuck doing what we can.
[14:57] <persia> And we do best if we can pass patches, etc. upstream.
[14:57] <mok0> persia: you are right unfortunately
[14:57] <persia> Just remerging stuff is probably a waste of time.
[14:58] <persia> Of course, if there's a package you use, and you want it newer, go ahead.
[14:58] <mok0> persia: well, at the same time we  all have an ambition that a release be the "latest and greatest"
[14:58] <persia> But if you aren't using it, and it's not horribly broken, I'm not sure why it's being updated.
[14:58] <persia> I don't.
[14:58] <persia> My ambition is that my computer works better each release.
[14:58] <mok0> persia: users do, and so do the tech bloggers
[14:59] <persia> As a result, I tend to only fuss about patches on packages that happen to be installed on my computers.
[14:59] <mok0> persia: of course
[14:59] <persia> Sure.  We all have different motivations to do what we do.
[15:00] <mok0> There are things that have been really good, f.ex. the Python 2.6 transition
[15:00] <persia> Right.
[15:00] <mok0> I think user's appreciate that
[15:00] <persia> Indeed.  Those are good for lots of reasons, which is why more of us chip in to get them done.
[15:11] <bddebian> Heya gnag
[15:11] <bddebian> Err gang
[15:13] <masterkernel> can someone tell me what constitutes a package review?
[15:14] <persia> masterkernel, In what sense?
[15:15] <masterkernel> persia: what do motu developers do when they review packages?
[15:15] <persia> How do you mean "review".  As in a new package?
[15:15] <masterkernel> sorry, yes
[15:16] <directhex> masterkernel, check it against debian packaging policy & guidelines, usually
[15:16] <directhex> masterkernel, or some approximation thereof
[15:16] <persia> Generally check for policy compliance (including licensing), following of best practices, that the package compiles, installs, and works, etc.
[15:17] <fenris-> persia: sorry dc
[15:18] <masterkernel> it just seems like my package is screaming "stay away from me!!!", esp. on mentors.debian, because the sponsor there would bear responsibility for the package since i am anonymous
[15:19] <mypapit> fakap fenris-, misscall aku pg td
[15:19] <mypapit> fenris-, wtf with that
[15:19] <fenris-> tersalah tekan
[15:19] <mypapit> fenris-, lepas tu x jawab sms
[15:19] <persia> masterkernel, I believe being anonymous is not policy complaint, although being pseudonymous is, although I may be mistaken.
[15:19] <mypapit> wtf wtf
[15:21] <masterkernel> persia: theres a debate on that over on mentors: http://lists.debian.org/debian-devel/2009/06/msg00601.html
[15:21] <persia> masterkernel, I'm not surprised.  There's been debates here before.
[15:23] <masterkernel> persia: it seems like pseudonyms are legal copyright holders, as long as the person can be verified (according to country)
[15:25] <masterkernel> i guess it would be in my best interest to promote it within the debian community and see if i can get users to push for it to be added
[15:25] <persia> masterkernel, From what I understand, that is true in most jurisdictions, but I've never heard of anywhere that anonymous was OK.
[15:27] <masterkernel> as long as I can go to the office and easily identify myself, there is a checkbox on the form that says "this work is registered under a pseudonym" and the work would use that
[15:31] <persia> masterkernel, It depends on where you are.  I actually looked stuff up for someone once.  They lived in the US, and in their state, it wasn't possible, but in Virginia it was, and Virginia was nearby.  I don't remember their state.
[15:31] <persia> The issue was with the registration of aliases, and how that worked.
[15:43] <ryanprior> Hello there. I'm a developer for the Ecere project (http://ecere.com) and our first free and open-source release is in the release candidate stage. We expect to put out our official release within the next couple weeks. We really want to get our packages into Universe for Karmic -- is anyone interested in sponsoring us?
[15:45] <directhex> ryanprior, are you intending on doing the packager work yourselves (sponsorship) or requesting that someone else do that work (needs-packaging)?
[15:50] <slytherin> slomo: Do you mind me updating the gst-plugins-*-multiverse packages to bring them in sync with their universe counterparts?
[15:50] <slomo> slytherin: no, please do that
[15:53] <ogra> directhex, is there a chance we could get mono-desbugger on armel ? :)
[15:53] <ogra> *debugger even
[15:53] <directhex> ogra, the debugger needs to be partially rewritten per-arch o_o
[15:53] <ogra> its currently not Architecture: any
[15:54] <ogra> ok
[15:54] <directhex> ogra, i.e. if you write that support, i'll love you forever, and probably miguel too ;)
[15:54] <directhex> but it's not arch:any because it just isn't :(
[15:54] <ogra> NCommander, ^^^^ your way to get a rupert signed by miguel :)
[15:54] <ogra> yeah, understood
[15:54] <NCommander> What's a rupert?
[15:55] <ogra> something you urgently want :)
[15:55] <ogra> belive me
[15:55] <NCommander> So port mono-debugger to ARM?
[15:55] <ogra> really
[15:55] <directhex> ogra, ruperts ran amok at UDS!
[15:55] <ogra> yeah ... after your TB excess :)
[15:55] <NCommander> Christ, after finishing TB2, I probably can easily make that happen
[15:55] <ogra> directhex, i know, you gave me one :)
[15:55] <ogra> its sitting on my desk
[15:56] <ogra> NCommander, rupert > chumby
[15:56] <ogra> (though not as multifunctional i must admit)
[15:56]  * NCommander hasn't plugged his chumby in
[15:56] <NCommander> I'd like to see if I can stream TV to it
[15:57] <ogra> the advantage of a rupert is that you *dont need to plug it in* :)
[15:57] <ryanprior> directhex: we intend to do the package work ourselves, but we are not expert debian packagers, so we could use some guidance. I think sponsorship is most appropriate.
[15:57] <directhex> ryanprior, then you want revu
[15:58] <slytherin> slomo: oh, by the way, do you plan to upload next version of totem to Debian unstable (instead of experimental)?
[15:58] <ryanprior> directhex: That would be #ubuntu-revu ?
[15:58] <directhex> ryanprior, https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:58] <slomo> slytherin: of course not :) it needs new totem-plparser and the api of it can still change and that would be a nightmare
[16:00] <slytherin> slomo: Ok. I will try adding experimental repository and see how good new totem works.
[16:01] <slomo> slytherin: very good but you probably want totem and gstreamer git for even better experience ;)
[16:05] <slytherin> slomo: I am particularly looking for better DVD playback.
[16:05] <slomo> slytherin: except the missing support for non-ac3 audio it works good... with menus and everything
[16:06] <slytherin> slomo: sound good.
[16:06] <directhex> yays!
[16:07] <directhex> that reminds me, i need to try out vlc's supposed support for bloo rays
[16:07] <slytherin> slomo: I suppose I can do apt-get upgrade from testing. I mean I hope appropriate conflicts/replaces are added to the new packages.
[16:07] <slytherin> directhex: do you have blu ray drive?
[16:08] <slytherin> directhex: one of my friend tried on Windows, it didn't work. Not sure what all things he tried.
[16:08] <directhex> slytherin, i have a drive, and have dumped most (some?) of my discs. afaik vlc doesn't have any aacs cracking functions, but it now has support for disc dumps
[16:14] <slomo> slytherin: should work, yes
[16:31] <Adri2000> bddebian: around? how did you generate the autotools changes for djplay?
[16:45] <bddebian> Adri2000: I think just autoreconf -fvi
[16:46] <bddebian> Hmm, maybe it needs a gettextize run?
[16:49] <Adri2000> I ran lots of auto* things, including autoreconf with -f and -i, but it is still looking for glib-config
[16:51] <kpirc> I need a reviewer for my 'cadabra' package on REVU (it's a symbolic computer algebra system with graphical notebook frontend). Any takers?
[16:56] <mok0> Hm, twtr is vry good fr learng 2 mking shrt & concse sntences
[16:57] <iulian> Heh.
[16:57] <mok0> :)
[16:59] <ville__> according to https://wiki.ubuntu.com/KarmicReleaseSchedule, Aug 27 is the FeatureFreeze time. So I suppose I have time until that to package a new app for Karmic?
[16:59] <ville__> karmic universe that is
[17:00] <bddebian> Adri2000: You applied my patch first?
[17:00] <mok0> kpirc: I'll bit
[17:00] <mok0> kpirc: bite
[17:00] <kpirc> mok0: thanks!
[17:00] <Adri2000> bddebian: no
[17:01] <kpirc> mok0: it should be relatively painless, it has been on REVU for quite a while now and I think most obvious problems have been fixed.
[17:01] <mok0> kpirc: oh, yes, I remember it now, I've revu'ed it before
[17:02] <bddebian> Adri2000: yeah, you would have do do that first, I think I hacked out the glib-config with pkg-config
[17:02] <mok0> kpirc: ... and modglue made it into jaunty afair
[17:02] <kpirc> mok0: yes, modglue is in, so all dependencies are now in the official repos
[17:02] <mok0> kpirc: Super, should be easy then
[17:03] <mok0> kpirc: gimme 10-15 mins
[17:03] <kpirc> mok0: ok, no prob
[17:04] <Adri2000> bddebian: ok, will try that. but I'd be interested in what changes you made
[17:05] <bddebian> Adri2000: Isn't there a patch on BTS?
[17:06] <Adri2000> there is
[17:06] <bddebian> Those should be the changes I made and then just autoreconf'd
[17:06] <Adri2000> but I mean what changes besides autoreconf
[17:06] <Adri2000> the patch includes the autoreconf changes
[17:06] <Adri2000> so I don't know what is from you and what is from autoreconf
[17:07] <Adri2000> (apart from the debian/changelog and debian/control changes of course)
[17:14] <Adri2000> your patch works indeed
[17:16] <mok0> kpirc? Oh, you left
[17:18] <bddebian> Adri2000: Oh, sorry I usually strip those out.  I think the only real change I made was the one to configure.ac
[17:20] <Adri2000> bddebian: ok
[17:31] <geser> al-maisan: Hi, I've looked at some of your sync requests and wondered myself why you didn't find any remaining changes
[17:32] <al-maisan> hello geser, I saw your comments yesterday but did not have time to follow up.
[17:33] <al-maisan> let me take another look and I will come back to you.
[17:33] <al-maisan> another look at the packages in question that is,
[17:33] <geser> ok, no hurry
[18:39] <masterkernel> Anybody want to review kernelcheck? - automated tool used to (custom) compile any 2.6 kernel with any user patches
[18:40] <masterkernel> http://revu.ubuntuwire.com/p/kernelcheck
[19:12] <hyperair> masterkernel: don't bump the ubuntu version in every upload to revu
[19:13] <hyperair> masterkernel: a NEW package should always be either -1 or -0ubuntu1, depending on whether it's debian or ubuntu's NEW
[19:22] <hyperair> ah kernelcheck's a python app eh... why don't you go maintain it in debian-python then? =p
[19:22] <hyperair> much easier than poking random people on debian-mentors
[19:22] <hyperair> masterkernel: you're missing copyright headers for your .py files by the way
[19:32] <masterkernel> hyperair: so for each edit to the package i should do -1ubuntu1 -2ubuntu1 and so forth?
[19:32] <hyperair> nonoo
[19:32] <hyperair> only for each upload to the ubuntu archive, must the version be different
[19:32] <hyperair> as long as you're still uploading into revu, just use -0ubuntu1
[19:32] <masterkernel> oh ok
[19:33] <c_korn> hello. why does this autoconf test fail if there is libavutil-dev, libavcodec-dev and libavformat-dev installed? http://pastebin.com/d30a49a85
[19:33] <masterkernel> and the copyright headers should have that short gpl segment at the top?
[19:50] <hyperair> masterkernel: yes.
[19:51] <hyperair> c_korn: pkg-config isn't installed, i suppose.
[20:00] <c_korn> hyperair: pkg-config is installed. "checking pkg-config is at least version 0.9.0... yes"
[20:06] <hyperair> c_korn: how very strange. why don't you pass it through sh -x =\
[20:06] <hyperair> sh -x ./configure
[20:06] <hyperair> or bash -x ./configure
[20:07] <c_korn> hyperair: ah, nice. I did not know this option. will give it a try.
[20:07] <hyperair> have fun. it's got very cryptic output, considering it's an autoconf script =p
[20:07] <hyperair> i'd poke around the configure script myself
[20:08] <hyperair> add a few echo's here and there
[20:13] <ryanakca> Is there a reason why dpkg-source -x <foo>.dsc would hang?
[20:16] <ryanakca> rgreening: Are you in a reviewing mood? Feel like reviewing and ack'ing http://revu.ubuntuwire.com/p/kobby , please?
[20:17] <hyperair> ryanakca: plenty. e.g. patch hung, or tar hung, due to some disk i/o failure..
[20:17] <ryanakca> hyperair: Is there a way to manually extract it?
[20:20] <\sh> tar -xvzf <upstream>_<version>.orig.tar.gz
[20:21] <\sh> cd <upstream>-<version> ; gunzip ../<upstream>_<version>-<package release>.diff.gz ; patch -p1 < ../<upstream>_<version>-<package release>.diff.
[20:21] <rgreening> ryanakca: If I get some time tomorrow, though my week I booked with $WORK :(
[20:21] <c_korn> hyperair: sh -c ./configure did not output many debug lines: http://pastebin.com/de50c570
[20:21] <ryanakca> rgreening, \sh: thanks
[20:22] <nellery> I think just cd <upstream>-<version>; zcat ../<upstream>_<version>-<package release>.diff.gz | patch -p1 should work shouldn't it?
[20:23] <\sh> nellery: yeah..that could be a  shortcut...but to understand how a debian source package works in general...the long version is much better ;)
[20:24] <nellery> ah
[20:24] <nellery> ryanakca: having a look at kobby.
[20:27] <\sh> c_korn: are you trying to build it in pbuilder or sbuild ?
[20:27] <\sh> c_korn: if not, and you are building it on your local system, just type e.g. pkg-config --libs-only-l libavcodec e.g.
[20:28] <c_korn> \sh: it is sbuild. I need to test it locally in a schroot actually.
[20:28] <hyperair> c_korn: i said sh -x, not sh -c
[20:29] <hyperair> that said, you should use bash -x instead
[20:29] <c_korn> hyperair: that was a typo in my message. I used sh -x
[20:29] <c_korn> hi j
[20:29] <c_korn> hi joaopinto
[20:29] <\sh> c_korn: and pkg-config --list-all will give you all known pkg-config package names
[20:29] <hyperair> #
[20:29] <hyperair> + exec /bin/bash ./configure --build i486-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info CFLAGS=-g -O2 LDFLAGS=-Wl,-z,defs
[20:30] <hyperair> see that?
[20:30] <joaopinto> hello c_korn :P
[20:30] <hyperair> if it's not run in bash, it'll exec /bin/bash
[20:30] <c_korn> hm, configure is a sh script actually.
[20:31] <dupondje> somebody in here can release a new version of busybox into karmic ? :s
[20:31] <\sh> dupondje: ->
[20:31] <hyperair> c_korn: yes it is, but it ends up calling exec /bin/bash in the end
[20:31] <\sh> #ubuntu-devel is the right place
[20:31] <hyperair> c_korn: either way i'd poke around the actual configure script. are you sure the configure script is up to date?
[20:35] <ryanakca> nellery: Thanks
[20:36] <c_korn> hyperair: autoreconf failed. said it could not find libtoolize but the libtool package has been installed in the schroot. I will try the pkg-config from the configure script first
[20:37] <hyperair> =\
[20:37] <hyperair> try which libtoolize
[20:45] <dupondje> how can I get a update of busybox into Karmic ?
[20:57] <c_korn> hyperair, \sh: eh, it was a missing comma in control avoiding that all dependencies have been installed. shame on me :-(
[21:02] <andrew_sayers> c_korn: I don't suppose you've been bitten by bug 391165, by any chance?
[21:04] <andrew_sayers> (If so, how do we nudge someone into fixing it quick?)
[21:04] <c_korn> andrew_sayers: the comma was missing at the end of a line.
[21:04] <andrew_sayers> In Build-Depends?  That sounds the same to me.
[21:06] <andrew_sayers> (The bug is that debuild should catch that stuff, but doesn't)
[21:07] <c_korn> andrew_sayers: yes, in Build-Depends
[21:09] <andrew_sayers> c_korn: Hmm, okay.  I've tracked a bug in Kaffeine back to the same cause.  If it's a common issue, I'll make a bigger noise about it if it doesn't get any attention.
[21:10] <ryanakca> nellery: Fixed
[21:11] <c_korn> andrew_sayers: as I see you already attached a patch.
[21:11] <nellery> ryanakca: excellent, I'll have another look shortly
[21:11] <ryanakca> nellery: thanks
[21:12] <andrew_sayers> c_korn: Yeah, it's a trivial fix, it's just a matter of getting someone to apply it... then rebuilding every package in Ubuntu :s
[21:13] <c_korn> why that?
[21:13] <c_korn> do they all depend on dpkg?
[21:14] <andrew_sayers> Okay, more precisely, any debian/control file could have the same bug, and nobody would notice until people filed a report on the resulting problem.
[21:14] <andrew_sayers> I guess we could just download all the debian/control files, and see which have missing line-end commas.
[21:15] <james_w> andrew_sayers: subscribe the sponsors to your report to get it reviewed
[21:16] <andrew_sayers> james_w: You mean ubuntu-main-sponsors?
[21:16] <james_w> yup
[21:17] <andrew_sayers> james_w: Ta :)  Should I do the same for Kaffeine?  It's a fairly serious regression with a one-character patch.
[21:18] <andrew_sayers> (bug 365770)
[21:18] <james_w> andrew_sayers: yeah
[21:20] <andrew_sayers> james_w: Done.  Thanks for the pointer.
[21:52] <ryanakca> nellery: replied, I don't think there's anything to do about the watch file, I explained the situation in the comment
[22:40] <masterkernel> hyperair: copyright headers added. i'll be back on later
[23:54] <mok0> Heh, watching Trailer Park Boys -- hillarious