[00:28] <warner> iulian: I just updated #419510 to hopefully make it into a proper sync request for foolscap (which is the remaining dependency for tahoe)
[02:41] <LaserJock> ok, this could maybe be a stupid question, but update-maintainer doesn't seem to be working, it just puts in me as Maintainer and not MOTU/Core Dev, is something wrong?
[02:54] <dtchen> LaserJock: probably a bug; see the changes in ubuntu-dev-tools 0.76
[03:15] <LaserJock> ohh, update-maintainer now checks to see if the packages is in Debian unstable
[03:15] <LaserJock> hmm
[06:27] <Laibsch> good morning
[06:27] <Laibsch> why does the PPA try to build for lpia architecture when the control file looks like http://paste.debian.net/45594/ ?
[06:46] <dholbach> good morning
[07:06] <therm> Hello, could somebody please sync velocity from debian? bug 423284
[07:34] <therm> could somebody please sync velocity from debian? bug 423284
[10:48] <suji> hi
[10:48] <PartyBoi2> hi suji
[10:50] <suji> i have fixed some bugs in xkeyboard-config, where to i send the patch file?
[10:50] <runasand> suji: to the bug report
[10:50] <runasand> suji: just write a comment and add the patch
[10:50] <suji> runasand:in where?
[10:51] <runasand> suji: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config
[10:51] <runasand> suji: if there's no bug report open for the bugs that you have fixed, report them and add the patch
[10:52] <suji> runasand: okey
[10:53] <dreamcat4> i've made a package for a new php5 variant
[10:54] <dreamcat4> 'php5-fpm' - a faster alternative to php5-fcgi
[10:54] <dreamcat4> REVU: http://revu.ubuntuwire.com/p/php5
[10:54] <dreamcat4> Needs review
[12:59] <therm> could somebody please sync velocity from debian? bug 423284
[13:00] <andv> therm, you need an FFe for it
[13:01] <andv> therm, we are past FF as you may know
[13:01] <pochu> !ffe
[13:01] <andv> pochu, ty
[13:02] <andv> :)
[13:02] <Laney> oldskool
[13:02] <pochu> hey andv, yw :)
[13:02] <pochu> hiya Laney
[13:02] <Laney> afternoon pochu
[13:02] <Laney> goocanvasmm was accepted pretty fast
[13:02] <therm> andv: but isnt it just an update, not a really feature?^^
[13:03] <Laney> ...now we can update glom
[13:03] <andv> pochu, ;)
[13:03] <andv> therm, it's a new upstream release
[13:03] <andv> therm, so you need an FFe, check the link below for more informations.
[13:03] <therm> andv, ok
[13:04] <pochu> Laney: :)
[13:05] <andv> therm, document which tests you've done on karmic with the latest package
[13:05] <andv> therm, move it to an FFe
[13:05] <andv> therm, subscribe motu-release for processing it
[13:05] <Laney> the new ftpmasters seems to have done the trick, eh
[13:06] <directhex> pochu, oh, that g-d-s package ought to be ready, i think
[13:06] <directhex> pochu, give it a test-build in sid
[13:06] <pochu> great, where can I find it?
[13:06] <pochu> directhex: or do you mean you're giving it?
[13:06] <directhex> pkg-cli-libs on alioth
[13:07] <pochu> alright
[13:07] <pochu> svn?
[13:07] <directhex> yeah
[13:07] <pochu> cool
[13:07] <directhex> i'm too lazy and/or stupid to convert to git
[13:07] <pochu> svn works just fine
[13:07] <pochu> it could be faster though :)
[13:08] <james_w> can anyone tell me what the code is likely doing wrong to trigger the segfault in bug 414576?
[13:18] <pochu> directhex: it builds, but lintian output is scary ;)
[13:18] <directhex> pochu, which lintian output isn't simple "whaaaa NMU" stuff?
[13:19] <pochu> directhex: it's not about NMU :)
[13:19] <pochu> well that too, but that doesn't make it scary
[13:19] <directhex> which bits are scary then? i have no sid pbuilder on here
[13:22] <pochu> http://paste.debian.net/45611/
[13:22] <pochu> there are many errors, but fixing debian/copyright should get rid of all of them
[13:24] <directhex> bleh. i tend to only notice source errors from lintian
[13:24] <directhex> okay, so the package needs a little love
[13:27] <AnAnt> is it alright to add a new package in multiverse now ?
[13:27] <AnAnt> or is that freezed ?
[13:28] <AnAnt> sorry, I meant universe
[13:42] <bigon> dholbach: hi, I'm adjusting the dependencies of meta-telepathy pkgs and telepathy-devel-gtk will pull nothing any more as I remove the 2 last depends
[13:56] <directhex> pochu, apparently sid is unpbuilderable again today, but try now?
[13:58] <directhex> W: Failure while configuring base packages.
[13:58] <directhex> pbuilder: debootstrap failed
[14:16] <dholbach> bigon: sure, do whatever you like with the package :)
[14:17] <dholbach> bigon: I might still have an interest in telepathy in general, but I can't call myself a maintainer there, so I'll trust you :)
[14:18] <bigon> dholbach: ok
[14:18]  * dholbach hugs bigon
[14:18] <dholbach> great work!
[14:29] <pochu> directhex: much better now :)
[14:29] <pochu> directhex: want me to upload? if so, shall I ignore the NMU warnings?
[14:29] <pochu> -> #d-cli
[14:47] <blackxored> hello everybody
[14:57] <andv> hello
[14:58] <andv> blackxored, so the automatic updates for vuze are only done to plugins?
[14:59] <blackxored> andv, effectively
[14:59] <blackxored> mandatory and non-mandatory plugins only
[14:59] <blackxored> no core, no core patcher, and no swt, at the moment
[14:59] <andv> blackxored, so you disabled all core / swt libraries except plugins
[15:00] <andv> which don't do any harm to the archive
[15:00] <andv> looks ok
[15:00] <blackxored> andv, exactly my point
[15:00] <andv> perfect then
[15:00] <blackxored> the patches are simple as you may see, no big deal, but since I got revision from upstream devs, I
[15:00] <blackxored> am pretty comfortable with it ;)
[15:01] <andv> ScottK, did you read the follow ups about azureus?
[15:01] <ScottK> andv: I did.  I plan to look into it a bit later today.
[15:01] <andv> ScottK, looks great, thanks
[15:04] <blackxored> andv, if no more questions and you're ok with it, that seems fine to me, back to work, don't you mind, right?
[15:05] <andv> blackxored, you've explained everything on the bug report
[15:05] <andv> blackxored, we just need scott to check it later today
[15:05] <andv> and then should be fine
[15:05] <blackxored> andv, great, BTW sorry about the FFE
[15:05] <blackxored> see you around
[15:05] <andv> np
[15:05] <andv> cya
[15:26] <trip0> i need to run aclocal+automake+autoconf before I configure for my package.  Where do I add that to my debian/rules file for it to work properly?
[15:30] <james_w> trip0: add "autoreconf -i" as before the ./configure call in the "configure:" target
[15:36] <bddebian> Heya gang
[15:41] <bigon> shouldn't gallago completely dropped from the archive?
[16:00] <maco> i was going to package up mypaint, but i just noticed its in sid. how do i go about asking for it to be pulled from sid into karmic?
[16:01] <geser> usually with a sync request but we are in feature freeze now, so you need an exception to sync it right now
[16:35] <dholbach> Ubuntu Developer Week will start in 25 minutes in #ubuntu-classroom
[17:45] <andv> bdrung_, please update the audacity sync request into a proper FFe
[18:41] <RainCT_> dyfet: Hey. Are you a MOTU?
[18:41] <dyfet> Not yet :)
[18:44] <dreamcat4> RainCT; Brand new php package uploaded 'php-fpm'
[18:45] <dreamcat4> faster / more effecient php
[18:45] <dreamcat4> Can check it out at REVU: http://revu.ubuntuwire.com/p/php5
[18:45] <ScottK> Get your box rooted even faster than before. ...
[18:45] <dreamcat4> Just writing out a freeze exception request for Karmic
[18:45] <RainCT_> haha
[18:46] <dreamcat4> Paired with nginx = much more memory effectient than apache 2
[18:46] <RainCT_> ScottK: don't like PHP? :)
[18:47] <ScottK> RainCT_: I'd say I have a realistic perspective on php.
[18:47] <dreamcat4> I built it with all the php security patches
[19:03] <mok0> Why
[19:03] <mok0> can't I send to channel #ubuntu-classroom?
[19:04] <AntoineLeclair> the channel is muted for the week
[19:04] <AntoineLeclair> you have to talk on #ubuntu-classroom-chat
[19:04] <AntoineLeclair> to avoid the chaos ;)
[19:04] <mok0> AntoineLeclair: ... even if I'm the instructor?
[19:04] <AntoineLeclair> ha, lol!!!
[19:06] <RainCT_> mok0: you're getting answers in -chat
[19:06] <mok0> RainCT_: thx
[19:18] <RainCT_> dyfet: hm, have you tested pocketsphinx? pocketsphinx_wsj runs here but I can't get it to recognize anything
[19:19] <dyfet> RainCT_: are you trying on karmic or jaunty?
[19:19] <RainCT_> dyfet: karmic
[19:19] <dyfet> RainCT_: I recall there are some audio issues in Jaunty/gstreamer/pulse audio...
[19:20] <dyfet> RainCT_: (I meant karmic :)
[19:20] <RainCT_> (julius is working though)
[19:20] <RainCT_> dyfet: well, I'll trust you if you say it works :)
[19:21] <dyfet> RainCT_: I was going to re-test Jaunty, though, just to be sure nothing indeed got broken :).
[19:22] <dyfet> RainCT_: The only other question I saw with the current package is that the source patches are also part of the deb diff, and not handled as separate patches in a debian/patches directory like with dpatch for example...
[19:22] <RainCT_> dyfet: It's only the one change at the top of a source file, right?
[19:24] <RainCT_> ie the declaration for ps_get_prob
[19:24] <dyfet> RainCT_: true, just a header.  If its not an issue for it being promoted, then that is good :)
[19:26] <RainCT_> dyfet: It's okay by me, especially as it will probably only be necessary for this release
[19:27] <RainCT_> dyfet: It needs to be documented in debian/changelog however. I'm about to upload a new revision fixing this and some other stuff (like a missing dependency on python-sphinxbase, missing copyright holder in debian/cpoyright, etc.)
[19:28] <dyfet> RainCT_: that I missed spotting....
[19:34] <RainCT_> dyfet: Wanna fill the FFe? :)
[19:35] <dyfet> RainCT_: Sure...Do I just add a short explanation to the bug in launchpad and subscribe motu-release?
[19:36] <RainCT_> dyfet: Yes, I'd say use the stuff from the mailing list, and include a link to the package on REVU.
[19:36] <dyfet> RainCT_: which stuff from the mailing list? :)
[19:38] <RainCT_> dyfet: You should know, you answered to the thread :P. (Ie. blueprint, gnome-voice-control, no effect on other stuff..).
[19:39] <dyfet> RainCT_: lol!  Yes, I recall that...I just could not find the original message about ffe's in general ;).
[19:40] <dyfet> RainCT_: speaking of which I should also move the lubuntu meta into revu properly and do that for it's ffe....
[19:40] <fabrice_sp> Hi. Can any MOTU check Bug #416262, to see if I need some MOTU release ack?
[19:41] <fabrice_sp> there is no upstream new functionalities since a long time, but I prefer to be sure
[19:42] <fabrice_sp> or should I subscribe MOTU Release, just in case?
[19:42] <RainCT_> fabrice_sp: if those releases are bugfix only that shoudln't be necessary
[19:44] <fabrice_sp> RainCT_, Should I bring some upstream changelog then, to justify that?
[19:45] <RainCT_> fabrice_sp: Yes, that's usually a good thing to do
[19:46] <fabrice_sp> ok. Thanks :-)
[19:50] <dyfet> RainCT_: I will subscribe motu-release to #129758 as soon as you upload your changes...
[19:53] <RainCT_> looks like dput is hanging on the last kb...
[19:58] <RainCT_> dyfet: ok it's up
[21:16] <j^> any chance that http://revu.ubuntuwire.com/p/oggvideotools gets into ubuntu?
[21:19] <fabrice_sp> j^, you have 3 lintian warnings in the source. Yo ushould fix them
[21:24] <fabrice_sp> commented in REVU. Have to go. Bye
[21:25] <LinuxDruid> whats the best way for me to get involved with Motu?
[21:30] <hyperair> learn how to package, fix bugs, package new things
[21:30] <hyperair> sync/merge stuff from debian
[21:30] <hyperair> oh wait he disappeared =.=
[21:32] <MDC1> i'd need some packaging advice; i've created a patch for nautilus and have a git repo for it as well. It adds a lot of files and therefor Makefile.am and Configure.in is changed BUT nautilus don't use autogen when building the package - whats the best thing to do? create an additional patch that patch the Makefiles and configure files or is there a better solution?
[21:34] <dreamcat4> you can
[21:34] <dreamcat4> submit a contribution to upstream SCM for nautilus
[21:35] <dreamcat4> (after regenerating with new makefiles, confiure file, etc)
[21:36] <MDC1> dreamcat4, well, upstream is aware of the patches but this is WIP and i'd like to provide a PPA for people to test the features
[21:37] <hyperair> MDC1: there are three ways.
[21:37] <mzz> I'm pretty new to this myself, but when facing something similar I just added an additional patch that touched just the generated files (using autoreconf, but running autotools more selectively might be a good idea)
[21:37] <dreamcat4> You can make your own orig.tar.gz
[21:37] <hyperair> MDC1: one is to edit the corresponding snippets in Makefile.in, which is what i do if it isn't too complex
[21:38] <hyperair> MDC1: another is to have a 99_autoreconf.patch which basically runs autoreconf -vfi over it. quite ugly, and makes for a large patch.
[21:38] <hyperair> MDC1: the third, which i use if #1 isn't feasible, is to have my clean rule remove all Makefile.in's
[21:38] <hyperair> and run autoreconf -vfi during build, prior to configure
[21:38] <mzz> MDC1: personally I'm allergic to patching generated files, but perhaps that's just me. Seems a little too easy to accidentally drop changes because some build system decides to regenerate files.
[21:39] <dreamcat4> yeah - if you patched the autogen files, then must touch -r after patching
[21:39] <hyperair> touch -r?
[21:39] <hyperair> don't have to bother, really
[21:39] <hyperair> diff.gz doesn't take note of time
[21:40] <mzz> MDC1: so I just went for the 99_autoreconf.patch approach, which should work reliably. I'm too new to debian patching to comment on which works better in practice, that or regenerating at build time.
[21:40] <MDC1> hmm.. so no obvious thing to do then..
[21:40] <hyperair> it also doesn't take note of deleted files, which is why #3 that i suggested works.
[21:40] <hyperair> MDC1: i suggest that you either patch all the Makefile.in's accordingly, or run autoreconf -vfi at build time and remove your Makefile.in's at clean time
[21:40] <mzz> yay, disagreement
[21:41] <hyperair> the autoreconf method works well
[21:41] <hyperair> i just don't like it because it makes for a large patch
[21:41] <mzz> it does make for a large patch, but when is that really a problem? Someone who actually wants to look at it should be able to notice that this particular patch inside the patch is ignorable.
[21:41] <hyperair> not just large, but humongous
[21:42] <hyperair> i don't like big patches, for whatever reason
[21:42] <mzz> but sure, they'll easily make up 90% or so of your total diff
[21:42] <MDC1> hyperair, thanks a lot the tips, i think i'll go with patching the .in files, seems the easist to do as it's just for ppa
[21:42] <mzz> same's true when diffing upstream release tarballs :)
[21:42] <mzz> MDC1: if you go that route do doublecheck the patch actually takes (if whatever it does doesn't result in a build failure if it's not applied)
[21:42] <hyperair> MDC1: it can get tedious, and if you've made enough changes, you may miss out something.
[21:43] <hyperair> mzz: who asked you to diff your upstream release tarballs?
[21:43] <dreamcat4> Yeah, just don't forget that patching some files and not others in the autoconf dependancy chain will cause make issues
[21:43] <mzz> hyperair: me!
[21:43] <hyperair> mzz: too bad for you the.
[21:43] <hyperair> then*
[21:43] <hyperair> such huge diffs are crazy to review
[21:43] <mzz> hyperair: I tend to at least diff configure.ac to see if there are any new switches I should be aware of. Also check for any new documentation or the like I should make sure gets installed.
[21:43] <MDC1> hyperair, trial and error then ;-)
[21:43] <mzz> hyperair: I don't actually review the diffs, but the diffstat can be interesting.
[21:44] <hyperair> yes, it is interesting. but we're going off topic already.
[21:44] <hyperair> i'm complaining that it makes for an enormous diff that stays within the tree
[21:44] <mzz> sorry! I shall wander off again
[21:44] <MDC1> as karmic is feature freeze - there's no way a toolbar editor for nautilus could make it - right?
[21:45] <hyperair> especially if you keep packaging work within a VCS of some sort, it's annoying to refresh the patch every time you make a build change, considering the patch only contains auto-generated changes.
[21:45] <hyperair> MDC1: toolbar editor.. probably not.
[21:46] <hyperair> not unless you can provide a good enough reason in an FFe
[21:46] <mzz> I haven't figured out a nice workflow for that yet (branch upstream's source and add the debian/ dir or version-control just the debian/ dir separately?) I guess I should've attended the -class session on this earlier :(
[21:47] <MDC1> hyperair, ok, well - first i need people testing the patches and reviewing the code...
[21:48] <hyperair> mzz: read up git-buildpackage's docs
[21:49] <mzz> this sounds like it would involve me learning git
[21:49] <hyperair> each VCS-buildpackage tool has its own workflow(s)
[21:49] <hyperair> well if you don't like git then use bzr builddeb or something
[21:49] <hyperair> or svn buildpackage
[21:49] <mzz> bzr builddeb sounds promising. Thanks for the pointer :)
[21:49] <hyperair> =)
[21:50] <mzz> (I figured I must be missing something when debuild went and tried to stuff my .bzr dir in the .diff.gz)
[21:50] <hyperair> i rather like git buildpackage because of pristine-tar deltas
[21:50] <hyperair> heh
[21:50] <hyperair> debuild -i.bzr
[21:50] <mzz> yeah, I found that, but it still felt like I must be missing something.
[21:50] <mzz> also, weird upstream dist tarballs are annoying.
[21:50] <hyperair> heh of course
[21:51] <hyperair> it's the packager's job to either work around it, or convince upstream to fix it
[21:51] <hyperair> the latter is a better option
[21:51] <mzz> yep (if upstream's using autotools or some other well-tested system their dist tarballs should end up mostly sane)
[21:52] <hyperair> heh not always
[21:52] <hyperair> if they use make dist, usually it's sane
[21:52] <hyperair> but some of them insist on using tar -c(z|j)f
[21:52] <mzz> if they use make distcheck chances of sanity improve further
[21:52] <hyperair> there was bansheelyricsplugin which had a tarball created using that method sometime back
[21:52] <hyperair> had all kinds of cruft
[21:52] <hyperair> like .svn, and Makefile files with plenty of hardcoded paths
[21:52] <hyperair> and missing Makefile.in's
[21:53] <hyperair> it had me pulling my hair out
[21:53] <mzz> this thing had a bunch of .DS_store (or something similar) files in it that iiuc were an artifact of the archiving tool used
[21:53] <mzz> they obviously weren't in their version control system, which interfered a bit with what I was trying to do
[21:53] <hyperair> artifact of it sticking around on a mac system.
[21:53] <hyperair> .DS_store is for mac metadata iirc
[21:53] <hyperair> either trash or something
[21:54] <mzz> also a patches/ dir that greatly confused me until I noticed it wasn't in their version control either, so I'm assuming they're patches whoever rolled the release had stashed away there for some reason
[21:54] <hyperair> you can leave a patches/ dir around
[21:54] <hyperair> don't clean up unnecessary cruft
[21:55] <mzz> well, I was trying to do something screwy where I was using a source control branch with the debian/ dir added in to do my packaging, while using the upstream release tarball as .orig.tar.gz, and iirc debuild complained it couldn't represent the file "deletions" that were occurring
[21:56] <mzz> which really just indicates my workflow's broken and I shouldn't mix a source control checkout and original tarball like that
[21:58] <mzz> still, I'm making progress! May even end up contributing to MOTU instead of just doing silly ppa things at some point :)
[22:23] <hyperair> mzz: it's a start. don't need to learn how to use VCSes to contribute, but when you get deeper, you will ahve to know.
[22:25] <hyperair> also file deletions are fine imo. it's the reason why i suggested the clean rule purging all Makefile.ins in the first place
[22:48] <neversfelde> bug 221531 needs a SRU
[22:49] <neversfelde> to whom can I talk to speed the process up a bit?
[23:55] <HiGuys> Hi Everyone :). I have a problem. debuild -S -sa returns the error:  debuild: fatal error at line 1329:
[23:55] <HiGuys> dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed
[23:57] <dtchen> HiGuys: could you provide more context, e.g., pastebin the entire command (including PWD) and stdout/stderr?