[00:00] <superm1> RainCT, i guess you can nuke that fake team then alltogether
[00:01] <superm1> it's not gonna serve any purpose ever
[00:01] <RainCT> Yeah
[00:02] <RainCT> superm1: uhm, the confirmation page has no "OK" button, only "Cancel" :P
[00:02] <superm1> yay launchpad
[00:03] <RainCT> superm1: Also, I'm not sure whether that will send a mail to everyone. Maybe I should just leave it.
[00:03] <superm1> i found the same problem trying to delete ~ubuntu-mythtv yesterday when i was doing other team cleanup
[00:51] <happyaron> Can I request for syncing a package that is still in Debian new queue?
[01:01] <crimsun> anything that's dgetable.
[01:01] <crimsun> probably best if you wait til it's accepted, though.
[01:03] <happyaron> oh, thanks
[01:03] <happyaron> one of may package is in the new queue from Jan 2nd till now, don't know when will it be accept to archive
[01:06] <micahg> \sh: libjs-dojo made it into unstable :)
[01:22]  * StevenK bugs wgrant 
[01:33] <wgrant> StevenK: Hi.
[01:33] <StevenK> wgrant: Isn't there a timeout to kill builds that sit there and spin?
[01:34] <StevenK> (See https://edge.launchpad.net/builders/sejong )
[01:40] <wgrant> StevenK: Yes, but it's slave-side.
[01:40] <wgrant> So if the slave dies, no timeout.
[01:41] <StevenK> Ah, so sejong might have just rolled over and died
[01:41] <wgrant> Not completely.
[01:41] <wgrant> It's still responding to XML-RPC.
[01:41] <wgrant> But maybe sbuild has hung.
[01:41] <StevenK> Mmmm
[01:50] <micahg> RAOF: file a bug if you need dh_xulrunner updated :)
[01:50] <RAOF> micahg: I was going to, with a patch attached.
[01:50] <micahg> cool :)
[02:00] <hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think there are no more Bugs, Errors and no lintian warnings. qt-shutdown-p is a small program to shutdown the computer. http://revu.ubuntuwire.com/p/qt-shutdown-p
[05:26] <RAOF> Yes!  I (finally) win!
[05:26] <RAOF> gnome-shell (and anything else that depends on gjs, which is nothing at the moment) now builds!
[05:29] <SevenMachines> i can sense the relief :)
[05:31] <micahg> RAOF: BTW, xulrunner is moving to universe...
[05:31] <ScottK> menesis: There is a Debian/Ubuntu Zope team that works mostly by getting stuff into Debian first.  I would recommend you contaxt them.
[05:33] <RAOF> micahg: You mean the current xulrunner package, which is 1.8, right?  Not xulrunner-1.9.1, which is needed for Firefox?
[05:33] <micahg> RAOF: xulrunner-1.8 shoudl have been dropped already
[05:33] <RAOF> And xulrunner-dev is still going to point to xulrunner-1.9.1-dev, right?
[05:33] <micahg> xulrunner-1.9.2 for lucid will be in universe
[05:33] <micahg> once the ff migration is done
[05:34] <RAOF> What's FF migrating to?
[05:34] <micahg> RAOF: all in one package
[05:34] <RAOF> No longer pretending you can use it as a lib, eh? :)
[05:34] <RAOF> Wait.  Does that mean we'll have two copies of the xulrunner code?
[05:35] <micahg> RAOF: no, it's so we can jump major upgrades for FF without breaking all the rdepends on xulrunner
[05:35] <micahg> RAOF: yes
[05:35] <ScottK> Sounds like xulrunner needs to be removed then.
[05:35] <ScottK> No way we can maintain it.
[05:35] <RAOF> Eeep.
[05:35] <micahg> that's why it's going to universe
[05:35] <micahg> apps still build against it
[05:35] <ScottK> micahg: What do you think we do here?
[05:35] <micahg> ScottK: I know
[05:35] <micahg> sorry
[05:35] <ScottK> "Going to Universe" doesn't mean doesn't need maintaining.
[05:36] <RAOF> We should, instead, have libs building against the firefox package?
[05:36] <ScottK> If it's too hard for mozillateam to maintain in Main, what hope do we have?
[05:36] <micahg> RAOF: no -dev packages
[05:36] <ScottK> Sounds like time for a pile of removal bugs then
[05:36] <RAOF> Man, this would be so much easier if gecko was an actual library.
[05:37] <micahg> RAOF: I already showed you the bug for that :)
[05:37] <micahg> ScottK: you'll have to talk to asac about that
[05:37] <RAOF> micahg: No, that was the bug to make SquirrelMonkeyFish an actual library :)
[05:37] <micahg> it seems like most upstreams are moving away from xulrunner anyways
[05:38] <RAOF> On the basis that it's a huge pain in the arse, I'd guess.
[05:38] <ScottK> No.  I'll take it up with the release team.
[05:38] <RAOF> Apart, of course, for gnome-shell.  This could make MM... interesting.
[05:39] <RAOF> I presume we'll want gnome-shell in main for MM, which means gjs in main, which means some form of libmozjs in main available for it to link to.
[05:39] <micahg> ScottK: here's the blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model
[05:39] <ScottK> I'm familiar with the Firefox part, not the dumping unsupportable crap on the community part.
[05:42] <micahg> sorry ScottK, I never thought of it like that
[05:42] <ScottK> micahg: That's the effect.
[05:43] <RAOF> Presumably something's been done about couchdb, too, which I presume we still want in main for Lucid?
[05:43] <ScottK> Seems like an odd thing for a database to depend on.
[05:44] <RAOF> Javascript!
[05:44] <micahg> RAOF: idk, we might help them port to webkit if they're willing
[05:44] <RAOF> Chromium has an actual javascript library, doesn't it.
[05:44] <RAOF> libv8 IIRC.
[05:45] <micahg> RAOF: they're worse than mozilla about versioning
[05:46] <micahg> ScottK: can I ask you about the zend framework backport?
[05:46] <RAOF> Does *anyone* have a javascript library that has an actual stable ABI?
[05:46] <zooko> Greetings, folks!  We're hard at work on a new version of Tahoe-LAFS.  Our plan for releasing a new version in time to get uploaded into Lucid has slipped twice now: http://allmydata.org/pipermail/tahoe-dev/2010-January/003621.html
[05:46] <micahg> RAOF: I think webkit does
[05:46] <RAOF> Dear lord!
[05:47] <ScottK> micahg: What bug?
[05:47] <micahg> bug 488633
[05:47] <zooko> And by the way, check out this praise of Tahoe-LAFS from a blue-ribbon panel of USA national cyber defense experts: http://tinyarro.ws/zooko
[05:48] <micahg> ScottK: there was a security alert for that version and we pushed 1.9.7 already
[05:48] <micahg> can I change the bug to that version?
[05:48] <ScottK> micahg: Yes.
[05:48] <micahg> can you reack afterwards?
[05:48] <ScottK> Let me know when you're done and I'll ack the change.
[05:49] <fabrice_sp> Does it makes sense to drop .la files from a -dev package ? I'm looking after a merge, and the main difference is that .la files are not installed anymore
[05:50] <micahg> ScottK: done
[05:50] <micahg> oops, I should confirm too
[05:51] <RAOF> fabrice_sp: .la files aren't useful at best and are annoying at worst.  If the new debian revision doesn't install the .la files, that's perfectly fine.
[05:51] <micahg> ScottK: really done this time :)
[05:51] <fabrice_sp> RAOF: thanks! That means that one can be a sync ;-)
[05:52] <fabrice_sp> is it the same with .a files?
[05:52] <fabrice_sp> aren't they used for static linking?
[05:52] <RAOF> Yes, they are.
[05:52] <RAOF> That't exactly what they are.
[05:53] <fabrice_sp> ok. Thanks again :-)
[05:53] <siretart> fabrice_sp: libtool requires them. they are not strictly needed by ld(1)
[05:53] <RAOF> .la are quite different, though.  They do a similar job to pkg-config, but in a more convoluted way that everyone seems to hate.
[05:53] <siretart> they are plain text files with various meta information
[05:54] <siretart> oh, I'm talking about .la files. .a files are ar(1) archives of object files (.o)
[05:55] <fabrice_sp> ok. Just in case, I'll check that rdepends still builds then
[06:01] <ScottK> micahg: Ack'ed.
[06:01] <micahg> ScottK: thanks
[07:04] <dholbach> good morning
[07:24] <kees> YokoZar: wine isn't installable.
[07:24] <kees> YokoZar: wine (1.1.36-0ubuntu2) Depends: wine1.2, but wine1.2 (1.1.36-0ubuntu2) Conflicts: wine (<< 1.2)
[08:03] <andruk> how do i tell pbuilder to add my ppa from launchpad to its sources.list?
[08:17] <Hobbsee> andruk: othermirror in .pbuilderrc
[08:27] <andruk> so i put the line 'OTHERMIRROR="deb http://ppa.launchpad.net/csm-ticc/tablettray/ubuntu karmic main"' in my ~/pbuilderrc, but how do i add my gpg key?
[08:32] <directhex> andruk, you don't need your gpg key, apt in pbuilder runs unauthenticated
[08:34] <andruk> tell that to: http://pastebin.ubuntu.com/360524/
[08:35] <andruk> on second look though, thats only a warning...
[09:47] <andruk> thanks Hobbsee and directhex
[09:47] <andruk> :-)
[10:12] <BlackZ> I have this error when I run "debuild -S": http://paste.ubuntu.com/360560/
[10:12] <BlackZ> and I can't sign the public key
[10:13] <randomaction> BlackZ: debuild -S -us -uc will create an unsigned package
[10:14] <BlackZ> randomaction, yes, but I should sign it, or not?
[10:15] <geser> signing is only important when you want to upload it
[10:16] <BlackZ> geser, yes, I should upload it
[10:16] <randomaction> signing is necessary when you are uploading to archive or PPA
[10:16] <BlackZ> so I must sign it
[10:16] <randomaction> you need a key, then
[10:16] <BlackZ> I have created, but I can't sign it
[10:17] <geser> try "debsign -k0x22C75AE3 autotrash_0.1.1-0ubuntu1_source.changes"
[10:19] <BlackZ> geser, http://paste.ubuntu.com/360563/
[10:19] <randomaction> your key ID must match your name/address in changelog
[10:19] <geser> he did specify the key id in the last attempt
[10:21] <randomaction> it may be a problem with your gpg setup, as it can't find the key
[10:22] <geser> BlackZ: does "gpg --list-secret-keys" list your key?
[10:24] <BlackZ> geser, yes
[10:26] <geser> hmm
[10:32] <geser> have you tried if you can sign a file (doesn't matter what kind of file) with gnupg?
[10:33] <BlackZ> geser, Successfully signed dsc and changes files
[10:33] <BlackZ> solved
[10:33] <BlackZ> thank you
[10:34] <BlackZ> I have re-created the key
[10:34] <BlackZ> without "BlackZ" as comment in the key
[12:22] <^arky^> Hi, any compiz packing team member help me patch bug 507964
[12:26] <dholbach> ^arky^: try #ubuntu-dekstop
[12:26] <dholbach> ^arky^: try #ubuntu-desktop
[12:26] <dholbach> sorry :)
[12:27] <^arky^> thanks dholbach will do that
[13:10] <YokoZar> kees: yeah I meant to do it the other way (and have wine >> wine1.2)
[13:58] <hakaishi> Hello everyone! Anyone up to advocate/review qt-shutdown-p? - I think I've done everything that fabricesp said. http://revu.ubuntuwire.com/p/qt-shutdown-p
[14:02] <sebner> hakaishi: I don't really have time to review it but another point would be the changelog. Use -0ubuntu1 instead of -0ubuntu2
[14:03] <sebner> hakaishi: maybe make rules files more readable too (some newlines wouldn't be bad)
[14:04] <hakaishi> sebner: I thought that it should be -0ubuntu2 if it is a second upload with the same source...
[14:04] <hakaishi> sebner: okay, thanks
[14:04] <sebner> hakaishi: oh, I didn't know it's already in the archive
[14:06] <hakaishi> sebner: ah^^ ... seems I mistook something right now
[14:06] <sebner> hakaishi: nah it's not in the archive. New stuff enters the archive generally with -0ubuntu1, then you increment the versionsnumber for further uploads
[14:21] <hakaishi> sebner: Is it okay now?
[14:26] <sebner> hakaishi: looks better now but wondering about your rules file anyways. Normally, http://pastebin.com/m4b8274cf should be enough but it fails. What's with this permissioned deniend stuff?
[14:30] <sebner> hakaishi: found the issue
[14:30] <sebner> hakaishi: proper solution: http://pastebin.com/m5e497858
[14:30] <sebner> hakaishi: that's all you need in your rules file
[14:36] <sebner> wb hakaishi , got my messages?
[14:39] <persia> hakaishi: sebner: Why call dh_auto_build in override_dh_auto_build if the right thing to do is "qmake" ?
[14:39] <persia> Just don't bother including that line :)
[14:40] <sebner> persia: ah right, was confused with his $(MAKE) so I replaced it the sane command :)
[14:40] <persia> sebner: Ah, if was previously qmake; ${MAKE}, then it's correct to call dh_auto_build
[14:41] <persia> (or at least this does no harm)
[14:41] <sebner> persia: haha, right. DON'T confuse me!
[14:41] <sebner> persia: yeah, just testbuild. auto_build is necessary
[14:42] <persia> But dh_auto_install oughtn't drop out of a build if it can't do anything.  That seems like a bug.
[14:43] <sebner> persia: well, dh_auto_install normally calls make install and there is no such thing, he installs the stuff manually with dh_install (.install file), so you have to skip it or it fails imho
[14:44] <persia> sebner: Right, I understand the application here.  I just think it's a workaround for a bug.
[14:44] <sebner> persia: sure, bug of debhelper. shouldn't fail but skip automatically
[14:44] <persia> I think dh_auto_install ought fail gracefully if there isn't an install rule.
[14:44] <persia> Right.
[14:45] <sebner> persia: poor people like us have to use workarounds :)
[14:45] <persia> sebner: Why?  Surely your perl is sufficient to fix it :)
[14:45] <sebner> persia: no perl et al :P
[14:46] <persia> Oh well.
[14:46] <sebner> persia: C#, java and after some dirty haXX0ring and copying python. nahh, .. the youth of today. such useless languages :P
[14:46] <Laney> date
[14:46] <sebner> hi Laney
[14:47] <Laney> excuse me
[14:47] <persia> Fri Jan 22 14:46:58 UTC 2010
[14:47] <Laney> hi sebner
[14:47] <sebner> Laney: haha, we now have persia bot :P
[14:47] <hakaishi> persia: just a moment please. I'm a little confused. I just have to override_auto_build: with qmake? But pbuilder will fail with permission denied... so I'll have to add a override_auto install: dh_install. Is that right?
[14:47] <sebner> hakaishi: proper solution: http://pastebin.com/m5e497858
[14:48]  * persia agrees with sebner
[14:48] <hakaishi> okay, thank you
[14:48] <sebner> hakaishi: auto_install only fails because there is nothing to install
[14:48] <sebner> dh_install is for the .install file
[14:48] <persia> Well, at least it's as proper as we're going to get without hacking debhelper.
[14:48] <sebner> which would be override_dh_install what you don't need
[14:48] <persia> Or creating an install: rule and overriding the entire sequence.
[14:48] <persia> (which you also don't need)
[14:48] <sebner> persia: I'll check if there is already an open dh bug about it
[14:49] <persia> sebner: The workaround is mentioned in the manpage :)
[14:49] <sebner> hakaishi: the easiest for now is really my proposed solution
[14:49] <sebner> persia: haha, fail by design then
[14:49] <hakaishi> ^^
[14:49] <persia> sebner: Well, it still works for 90% of packages, which was the point.
[14:50] <sebner> persia: you are right but speaking about sanity ...
[14:51] <persia> heh.
[14:51] <hakaishi> perhaps this ist because I have a install rule in the Makefile
[14:51] <sebner> hakaishi: you should make sane makefiles then :P
[14:53] <persia> hakaishi: If you put an install rule in your makefile that respects DESTDIR, you should be able to drop your install file and let dh_auto_install do it's magic.
[14:53] <sebner> persia: wah wah wah, the manpage speaks about 90% working packages and "Skip it and ***run make install manually***", and the manpage says: if there's a Makefile and it contains a "install" target. The word here is ***if*** so it's a real bug imho as it seems that it should work/skip automatically
[14:53] <persia> sebner: Interesting point.  I can see that argument.  File the bug :)
[14:54] <hakaishi> ahm, the Makefile is generated like that, because I want the possibilty to install from Source to
[14:54] <Laney> why does it fail here?
[14:55]  * Laney has projects where the makefile doesn't have an install target which dh7 copes with fine
[14:55] <sebner> persia: Laney : Oh, it might be another bug. It fails with "permissioned" deniend for some files so the makefile might be b0rken and not dh_auto_install itself
[14:55] <persia> hakaishi: have your upstream Makefile install to ${DESTDIR}/${PATH} rather than /${PATH}.  If DESTDIR is unset, it will install to system locations.  If it is set, it will install for packaging.
[14:55] <persia> Indeed.  It sounds like an issue with the Makefile.
[14:55] <Laney> I would guess that is the case
[14:56] <Laney> it's probably trying to install into the system
[14:56]  * sebner says sorry to his beloved dh7 and gives it a cookie :)
[14:56] <hakaishi> persia: why do I need to upstream the Makefile, if it is generated by qmake?
[14:57] <persia> hakaishi: You don't.  In that case, you want to draft a qmake source file that generates an install rule that installs to ${DESTDIR}/${PATH}
[15:00] <hakaishi> persia: Sorry, I don't get it...
[15:00] <persia> OK.  Let's set qmake aside for the purposes of discussion.  We'll get back to it once the desired behaviour is clear.
[15:01] <persia> So, you have a Makefile with an install rule.  You want this to be able to be used by people who don't use the package, so they can run make; make install
[15:01] <persia> But when you run that install rule inside a package build, it fails, because it doesn't have permission to write to system locations.
[15:01] <hakaishi> persia: but this is what it already does, isn't it?
[15:01] <persia> Yes.
[15:02] <persia> The Makefile probably has lots of lines like `install -m 755 /usr/bin/foo`
[15:02] <c_korn> can someone explain me what the deploy.tar.gz here is for ? I thought in source format 3 there is only a orig.tar.gz and debian.tar.gz file: http://packages.debian.org/source/sid/jxplorer
[15:02] <persia> If the Makefile instead had lines like `install -m 755 ${DESTDIR}/usr/bin/foo`, then if DESTDIR is unset, the behaviour would be unchanged.
[15:03] <persia> This is good for the `make; sudo make install` case.
[15:03] <persia> Within the packaging, DESTDIR will be set, so it ends up installing in /foo/bar/baz/quux/debian/tmp/usr/bin/foo
[15:03] <hakaishi> aha, I get it. thanks
[15:04] <persia> Which means that the *same* rule in the Makefile can work for both the non-packaged case and the packaged case.
[15:04] <persia> So you just need to change the qmake source to do that.
[15:05] <persia> c_korn: See the .dsc.  As I understand it, one can have an arbitrary number of objects defined, and the dsc ties them together.
[15:05] <sebner> persia: isn't it about multiple tarballs?
[15:06] <persia> c_korn: In this specific case, it appears that upstream has a separate source release and installer release, and these have been packaged together.
[15:06] <^arky^> Modifying site packages variable, need help with bug 499990
[15:06] <persia> sebner: "objects" can be "tarballs", if one likes :)  I believe one can also use zip archives, flat files, etc.
[15:06] <sebner> c_korn: http://wiki.debian.org/Projects/DebSrc3.0  ... samples: # sample1: 3.0 (quilt) with orig.tar.gz / debian.tar.gz and additional tarballs with all compressions schemes   <-- this might be
[15:07] <sebner> persia: ohh, I didn't know zip and that stuff is allowed too
[15:07] <sebner> persia: ah, *all* compressions schemes
[15:08] <persia> sebner: I'm not 100% sure that other stuff works now, but I believe that was the long-term intent.
[15:08] <c_korn> sebner, persia: thank you
[15:08] <sebner> persia: nvm. I'm just happy that now .gz and .bz2 is allowed as upstream tarball :)
[15:08] <sebner> c_korn: yw
[15:14] <^arky^> dholbach: a quick question about labyrinth package
[15:16] <dholbach> ^arky^: shoot
[15:18] <^arky^> dholbach: bug 499990  'site-package' is hardcoded
[15:19] <^arky^> in bin/labyrinth and labyrinth/defs.py
[15:19] <dholbach> ^arky^: if you want to fix it, please go ahead, I'm happy to sponsor it or take a look at it
[15:22] <hakaishi> persia: I don't know how do this in the .pro file, can you tell me?
[15:22] <persia> hakaishi: Sorry, I've never used qmake.
[15:22] <^arky^> dholbach: Thanks, doing just that. My question is should I patch all the files under debian/ directory ?
[15:23] <hakaishi> persia: okay, then I'll just try another time. cu
[15:27] <dholbach> ^arky^: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS with Simple Patchsys
[15:31] <^arky^> dholbach: thank you
[15:31] <dholbach> no worries :)
[15:31] <dholbach> thank YOU
[15:37] <jariq> Upload to revu via ftp from network behind the proxy does not work for me ? Is there any way to upload via http ?
[15:40] <persia> jariq: There isn't.
[16:40] <ockham> hi, i'm a newbie with a rather trivial question: what do i have to specify in debian/rules if the actual sources (including autotools files and everything) are in a subdirectory of a package?
[16:44] <^arky^> dholbach: you still around man
[16:45] <dholbach> ^arky^: yep
[16:46] <ockham> anyone? i tried  dh $@ --sourcedirectory=src, but that doesn't seem to do the trick
[16:46] <^arky^> dholbach: source uses '@PYTHONDIR@' variables where does this get site in debian package?
[16:46] <ockham> there's a line: AUTOMAKE=automake-1.9 autoreconf -ivf
[16:46] <ockham> that causes a choke: autoreconf: `configure.ac' or `configure.in' is required
[16:47] <ockham> (in override_dh_auto_clean)
[16:47] <^arky^> dholbach: Is it the  'configure' file  that gives '@PYTHONDIR@' values ?
[16:48] <dholbach> ^arky^: I don't know - might be worth forwarding that bug to upstream
[16:49] <^arky^> dholbach: ok
[17:01] <jdong> AAAH stupid PPA!
[19:51] <sistpoty> hi folks
[19:51] <geser> Hi sistpoty
[19:51] <sistpoty> hi geser
[19:52] <sistpoty> haha, I'm so lazy, I don't even upload anything myself anymore: bug 495772 :)
[19:53] <BlackZ> hello geser ;)
[19:53] <ajmitch> hi
[19:53] <geser> Hi BlackZ, ajmitch
[19:53] <sistpoty> hi ajmitch
[19:54] <sistpoty> (so ctrl-w closes a kvirc window, as I just figured *g*)
[19:56] <ajmitch> heh
[19:56]  * ajmitch wonders when wgrant will be around this morning
[19:58]  * sistpoty grumbles a little bit about ScottK for sagemath... downloading a 57MiB tarball doesn't suggest getting it in shape again will be a simple task
[19:59] <ScottK> sistpoty: I think we're going to have to remove it.
[19:59] <sistpoty> ScottK: oh? so I should focus my work elsewhere?
[19:59] <ScottK> Debian maintainer said it needs a new upstream release to work with Python 2.6.
[19:59] <ScottK> Yes.
[19:59] <ScottK> Unless you really want to package it (it's a beast I understand)
[20:00] <sistpoty> ScottK: not really
[20:00] <ScottK> Boost transition is done.
[20:00] <ScottK> My suggestion is work on FTBFS or NBS.
[20:00] <ScottK> I don't have a hard one handy.
[20:00] <sistpoty> ok, will do, thanks ScottK!
[20:05] <siretart> sistpoty: I noticed a bunch of ftbfs packages while rebuilding ffmpeg's reverse depends
[20:05] <sistpoty> hi siretart
[20:05] <siretart> sistpoty: I didn't check all logs, but none of those I've seen were because of ffmpeg, all were because of other problems
[20:05] <siretart> hi sistpoty  :-)
[20:05] <sebner> huhu sistpoty siretart :D
[20:05] <sistpoty> hi sebner
[20:06] <siretart> hi sebner!
[20:06]  * sebner reads the backlog in case somebody already asked siretart about gstreamer-plugins-bad
[20:07] <sistpoty> siretart: got a package you want me to look at in particular?
[20:08] <siretart> sistpoty: http://paste.ubuntu.com/360846/
[20:08] <siretart> is a copy of my ftbfs folder
[20:09] <sistpoty> thanks siretart, I'll start with k9copy
[20:10] <sistpoty> hm, where is k9copy from? marillat?
[20:11] <sistpoty> oh, looks like ubuntu native one :)
[20:13] <geser> siretart: you can strike out smilutils from that list, this one is already fixed
[20:16] <randomaction> sebner: I'm not sure what's the deal with gstreamer-plugins-bad, but we have a ftbfs fix for gst-plugins-bad0.10 waiting to be sponsored
[20:16] <sebner> randomaction: sounds interesting :D
[20:16] <siretart> geser: excellent. thanks
[20:16] <sebner> hola hola geser :)
[20:17] <geser> Hi sebner
[20:21] <Quintasan> hello
[20:23] <wgrant> ajmitch: Hi.
[20:25] <ajmitch> wgrant: morning, going to head out & enjoy the sunshine today? :)
[20:25] <wgrant> ajmitch: Ahem.
[20:27]  * ajmitch has had breakfast but probably needs some caffeine to function for the day
[20:31] <sistpoty> hm.... /var/lib/dpkg/info/tex-common.postinst: 1011: kpsewhich: not found (dependency problem? worked fine after a dpkg --configure -a)
[20:48] <randomaction> could it be somehow related to texlive-base binaries sitting in the NEW queue?
[20:54] <geser> bah :( no new TeX before next week
[21:03] <siretart> oh, tl2009 is in lucid NEW? \o/
[21:06] <geser> siretart: actually texlive-base 2009-7 is already through NEW
[21:06] <geser> thanks to out-of-order processing done by jdstrand :)
[21:07] <jdstrand> jeez, give me a second to get through it! ;P
[21:08] <jdstrand> geser: what else is needed besides that?
[21:09] <geser> jdstrand: I don't see anything TeX related in the NEW queue left
[21:10] <jdstrand> k
[21:10] <jdstrand> fyi, texlive was the only thing I deNEWed related to that
[21:45] <nixternal> hello
[21:46] <highvoltage> !ops
[21:46] <xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <nixternal> !ops +R this channel
[21:46] <ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <xvd> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <ybtbk> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <hxukurq> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <hxukurq> Your machine COULD BE INFECTED by the recent spam attacks - visit http://fix.freenode.pl/ for a quick and easy solution.
[21:46] <nixternal> thanks tsimpson
[21:46] <jussi01> just a note, do not click that link
[21:47] <nigel_nb> okay, now i understood what those attacks were
[21:48] <nixternal> lol
[21:48] <nixternal> tsimpson: no worries, you got it under control
[21:48] <tsimpson> ahh, SECURE is set
[23:01] <dhillon-v10> hi all, I filed this bug a little while ago: https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/507778 so can anyone sponsor it, it been on the queue for a while
[23:04] <geser> you need a core-dev for that as it's in main
[23:05] <jpds> dhillon-v10: slangasek and mathiaz discussed that request yesterday.
[23:05] <dhillon-v10> geser: alright
[23:05] <dhillon-v10> jpds: so what happens now, I should wait for some time right
[23:07] <jpds> I'd talk to thme firsyt.
[23:07] <dhillon-v10> mathiaz: ping regarding a merge :)
[23:07] <dhillon-v10> jpds: alright :)
[23:08] <mathiaz> dhillon-v10: well - the question is whether the new version of acpid (2.0.0) should be pulled in lucid - considering that it's new code (?) for a an LTS
[23:09] <mathiaz> dhillon-v10: as I'm not familiar enough with acpid, I defer to slangasek on wether 2.0.0 should be pulled in
[23:09] <dhillon-v10> mathiaz: alright that makes sense, well the good thing is that I am getting better at merges (slowly)
[23:10] <mathiaz> dhillon-v10: right - the issue here is not wether your work is should be improved, but rather if we should *actually* merge the new version
[23:10] <dhillon-v10> mathiaz: understood :) thanks for the info.
[23:10] <mathiaz> dhillon-v10: some packages are more touchy - it may well turn out that 2.0.0 should be included in Lucid
[23:11] <mathiaz> dhillon-v10: in which case your merge proposal will be reviewed again
[23:11] <dhillon-v10> mathiaz: true, this one goes to main so its understandable
[23:12] <dhillon-v10> mathiaz: oh wait, while you are around, can you tell me why one of my patches isn't applying, let me get you the link
[23:13] <dhillon-v10> mathiaz: alright this one: https://bugs.launchpad.net/ubuntu/+source/cln/+bug/508995
[23:14] <mathiaz> dhillon-v10: which package did you merge from?
[23:14] <mathiaz> dhillon-v10: the changelog entry in the diff shows an entry for unstable
[23:14] <mathiaz> dhillon-v10: so you haven't probably merged from the *latest* version of debian
[23:15] <dhillon-v10> mathiaz: the testing one, here: http://packages.debian.org/changelogs/pool/main/c/cln/current/changelog
[23:16] <mathiaz> dhillon-v10: the base debian package you've used is 1.3.1-1
[23:16] <mathiaz> dhillon-v10: in the diff, you can see entry for 1.3.1-2 - that shouldn't be there
[23:17] <mathiaz> dhillon-v10: you wanna attach the debdiff between the debian version and the merged ubuntu version
[23:17] <mathiaz> dhillon-v10: the *latest* debian version - which in this case is 1.3.1-2
[23:18] <dhillon-v10> mathiaz: alright I see what I did wrong, but the merge was mostly done by bzr so I don't understand what went wrong there
[23:18] <mathiaz> dhillon-v10: probably that the bzr branch for the Debian package wasn't up-to-date
[23:19] <dhillon-v10> mathiaz: alright I guess I am better off merging by hand :)
[23:19] <dhillon-v10> mathiaz: would you be around in like 5 mins. so i can show you my diff
[23:20] <mathiaz> dhillon-v10: I should be
[23:28]  * persia idly notes that #ubuntu-devel may be a more appropriate place to discuss issues with seeded packages.
[23:29] <persia> (or some more specific channel)
[23:34] <dhillon-v10> persia: alright so there's a different package and when I merge that, it turns out that the only change is in changelog and control file, that's it, I double checked and nothing is there, is that possible
[23:35] <persia> Yep.  I just fixed FTBFS for plymouth on four architectures with a change like that to libdrm recently.
[23:35] <geser> sure, if Debian merged our changes, then only our changelog entries and the updated Maintainer field are left after a merge (which should be a sync then)
[23:36] <persia> The important thing to check is *which* changes to debian/control
[23:37] <persia> Another example would be the outstanding tiemu merge, which just has some dependency changes because we don't have iceweasel.
[23:38] <dhillon-v10> persia: yeah I checked that like 4 times, and the last upload fixed got about everything so :)
[23:40] <persia> As geser said, if all the fixes have been applied upstream, you can just sync and drop the changelog and maintainer changes.
[23:41] <persia> Just make sure there's nothing missing.