[00:46] <vivia> Hello everyone. aMSN 0.98 sources uploaded to sourceforge a few minutes ago, available from  http://sf.net/projects/amsn/files . I think the deadline for making it into karmic is today or something?
[00:47] <directhex> you have 23 hours
[00:47] <vivia> ok, anything i can do as a non-motu amsn developer?
[00:48] <directhex> i think the timing is awkward. how significant is the jump from 0.98 from whatever was previously in the archive?
[00:49] <vivia> uhh, new protocol in use, audio and a/v conferences supported, tons of bugfixes,
[00:49] <vivia> content roaming (share your display picture and personal message across various computers) supported
[00:50] <directhex> so "pretty significant" then
[00:50] <vivia> yup
[00:50] <vivia> that's just what i can think about OTOH
[00:50] <Laney> package it or convince someone else do
[00:50] <Laney> to*
[00:50] <Laney> hope you or they don't mess it up ;)
[00:51] <directhex> from a packager perspective, any changes that would affect packagers? changes to the build system, build dependencies, or binary files installed by "make install"?
[00:51] <vivia> hmm..
[00:51] <hyperair> pochu: congrats on becoming DD =)
[00:52] <vivia> if you want a/v support there's a dependency chaos with farsight
[00:52] <vivia> binary files - i think farsight and tclISF ?
[00:52] <vivia> wait i think a guy is already doing proper packages (of earlier svn revisions)
[00:52] <directhex> the he's got 23 hours!
[00:53] <vivia> they're non-official packages though :S
[00:53] <stochastic> directhex, speaking of 23 hours, any chance you'd be willing to give the second advocation for http://revu.ubuntuwire.com/p/xajdeo ?
[00:53] <vivia> ah they're for jaunty
[00:53] <vivia> hmm. i'll try poking Adri2000 for now :)
[00:55] <directhex> stochastic, apparently marked as already advocated
[00:56] <stochastic> directhex, whoops, typo http://revu.ubuntuwire.com/p/xjadeo
[00:58] <directhex> advocated. you owe me one piece of gushing praise about mono.
[00:59]  * stochastic loves the soft elegant structure of mono.  He can't think of a nicer piece of engineering.
[00:59] <vivia> thx ppl, see you~
[00:59] <Laney> thta was a quick review!
[01:01] <directhex> i analyse debdiffs at double speed after four pints
[01:01] <lifeless> 'analyse'
[01:02] <lifeless> after four pints I suspect that word becomes a pejorative
[01:03] <directhex> i would typically reject anything with an upstream debian/ still in orig, but if james-w is happy with it, then it'd be wrong for my personal distaste to be a deciding factor
[01:03] <directhex> and other than that, it seems to be in good shape
[01:03] <directhex> as much as cdbs nonsense is capable of such things
[01:03] <Laney> hah
[01:04] <Laney> stochastic: you could use .install files for some of the stuff in rules
[01:04] <directhex> see, i actually looked at it! and here you thought i merely clicked the shiny button in a drunked stupor
[01:05] <Laney> and you should reword the comment of your desktop file to be in line with http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html
[01:05] <Laney> but yeah I'd still upload it
[01:05] <directhex> Laney knows his shizzle, listen to Laney
[01:05] <stochastic> Thanks Laney, it's good to learn these things.  So this does mean that it's made feature freeze now, right? (provided the archive admin doesn't reject it)
[01:05] <directhex> also, Laney for DD!
[01:05] <Laney> provided directhex uploads it
[01:06] <Laney> and it will be ok to fix even after a reject
[01:06] <Laney> at least that's my interpretation
[01:30] <stochastic> directhex, should I be worried that xjadeo hasn't moved to "archived packages" and is still on the "new packages" listing of revu?
[01:30] <directhex> stochastic, no idea. RainCT knows about REVU, i'm a mere peon with it
[01:30] <bdrung> stochastic: please ask upstream to remove the debian directory in their next release.
[01:30] <directhex> now, bedtime!
[01:30] <stochastic> bdrung, will do.
[01:31] <bdrung> stochastic: and please contact the person who wants to package xjadeo for debian (see mail response)
[01:31] <stochastic> bdrung, will do.
[01:32] <bdrung> stochastic: thanks.
[01:32] <stochastic> bdrung, no thank you for your help.
[01:32] <bdrung> yw
[01:38] <LLStarks> any chance of fontconfig 2.7.1 getting into karmic?
[01:39] <binarymutant> will there be another debian sync before Karmic is released?
[01:40] <micahg> I believe syncs are by request only at this point
[01:40] <binarymutant> ah okay, thanks micahg
[01:40] <micahg> https://wiki.ubuntu.com/KarmicReleaseSchedule
[02:14] <warner> hrm, "./pbuilder-dist karmic create" on my sid box is complaining that "karmic" is an "Unknown suite"
[02:15] <zooko> Howdy, warner.
[02:15] <warner> maybe sid's /usr/bin/cdebootstrap doesn't know about karmic..
[02:15] <warner> heya
[02:17] <warner> indeed, /usr/share/cdebootstrap/suites doesn't mention "karmic". maybe if I just edit it..
[02:41] <warner> hrm. cdebootstrap is hanging on "P: Retrieving Release"
[03:34] <prefrontal> what's the correct chan for asking packaging questions?
[03:35] <binarymutant> this one
[03:35] <jtimberman> prefrontal: this channel, if you're packaging for universe (most people are)
[03:36] <jtimberman> binarymutant: ohai, i saw you on #debian-ruby :)
[03:36] <binarymutant> :D
[03:38] <prefrontal> can you peek at my rules file please, i am only getting stuff installed to /usr/share/doc. http://pastebin.ca/raw/1542672
[03:39] <prefrontal> basically, i only get the stuff i listed on the dh_installdocs line
[03:40] <prefrontal> debuild builds my package..
[03:40] <jtimberman> use dpkg-buildpackage -rfakeroot to build your package.
[03:41] <prefrontal> thanks. i also get many of these messages:  Compatibility levels before 4 are deprecated.
[03:41] <jtimberman> yeah, put '7' in compat.
[03:41] <jtimberman> debian/compat
[03:41]  * jtimberman isn't a motu btw, just a user that recently packaged some thigns
[03:42] <prefrontal> thats cool, thanks.
[03:42] <LLStarks> here's a live one.
[03:42] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/renpy/+bug/418992
[03:53] <prefrontal> is it necessary to find the package that provides every single library listed on ldd $(whatever lib) and put that package on the Depends line?
[03:54] <prefrontal> is it safer to do so in terms of getting pkg approved?
[04:00] <binarymutant> prefrontal, I think a lot of those will be taken care of with sh:Libs
[04:01] <prefrontal> ok
[04:46] <prefrontal> when i name this package libQuarter0 i get  `dpkg-source: error: source package name `libQuarter0' contains illegal character `Q'', and when I name it libquarter0 i get package-name-doesnt-match-sonames
[04:51] <TheMuso> prefrontal: You cannot have uppercase letters in package names.
[04:52] <TheMuso> If I recall correctly.
[04:52] <Laibsch1> Would some MOTU please be so kind to review (and hopefully advocate) the package ffgtk I just uploaded?  http://revu.ubuntuwire.com/p/ffgtk I'm shooting for upload before the Feature Freeze.
[05:11] <prefrontal> is lintian insane, or am i insane? either way, i'm going insane!
[05:31] <prefrontal> can someone please help me figure out what this means: native-package-with-dash-version http://lintian.debian.org/tags/native-package-with-dash-version.html
[05:31] <porthose> prefrontal, is you package up on REVU?
[05:31] <prefrontal> no i am workin on it
[05:32] <prefrontal> trying to nail these lintian errors
[05:33] <prefrontal> i download Quarter-1.0.0.tar.gz, open it up to Quarter-1.0.0, mv it to libquarter0-1.0.0. the package is called libquarter0
[05:33] <porthose> prefrontal, it would be easier for people to give you feed back if it was up on REVU
[05:37] <zooko> warner: what's the status of Tahoe-LAFS-in-Karmic?
[05:38] <porthose> prefrontal, https://wiki.ubuntu.com/MOTU/Packages/REVU/
[05:39] <warner> no change since this afternoon. I haven't been able to get a karmic pbuilder environment built on my home sid box, to conveniently fix the minor things which I already know about
[05:39] <warner> it's gotten no feedback yet
[05:40] <prefrontal> porthose, i'm all REVU-ready, i was just hoping to fix all this crap myself before pestering you guys 2 much. but i am about to upload this thing right now
[05:40] <zooko> iulian: you mentioned that you might be able to help with Tahoe-LAFS.  Brian Warner here has gotten it uploaded to REVU.
[05:44] <porthose> prefrontal, having it up on REVU is not pestering people :)
[05:47] <prefrontal> porthose, i just uploaded it, but i don't see it on revu yet
[05:48] <prefrontal> porthose, here it is: http://revu.ubuntuwire.com/p/libquarter0
[05:49]  * porthose looks
[05:51] <pochu> hyperair: :D
[05:52] <hyperair> pochu: :)
[05:52] <hyperair> pochu: weren't you interested about gtk2-engines-aurora the other day? ;-)
[05:52] <pochu> hehe, maybe :)
[05:53] <pochu> poke me about it tomorrow, ok?
[05:54] <prefrontal> porthose, fyi, this is just a dependency of the package i realy want to get into karmic, which we just released yesterday. so any advice you can provide will help me tons. its a neural network simulator called emergent: http://grey.colorado.edu/emergent
[05:54] <hyperair> pochu: sure :-)
[05:54] <prefrontal> ive been providing my own apt repo for years, but figured its time to do it right
[05:56] <zooko> prefrontal: are you at CU Boulder?  Emergent looks cool.
[05:56] <prefrontal> yep i am
[05:57] <zooko> Cool!  I did my undergrad studies there and now years later I've returned to live in Boulder.
[05:57] <prefrontal> hello fellow boulderite ;)
[06:10] <zooko> Okay, I have asked all the Ubuntu and/or Debian developers that I can think of if they will please review Tahoe-LAFS, and now I must go to bed, as I should have done two hours ago.  :-)
[06:12] <dholbach> good morning
[06:15] <zooko> Good morning, dholbach.
[06:16] <dholbach> hey zooko
[06:26] <MTeck> dholbach: did you ever have a chance to check out those videos?
[06:27] <dholbach> which one?
[06:28] <MTeck> I was looking at them a while ago and their seemed to have changes that made them hard to follow - I could be that thick too
[06:29] <dholbach> oh, now I see what you mean
[06:29] <dholbach> no, sorry - I didn't have the time to dive into them yet
[06:29] <MTeck> ok
[06:30] <MTeck> can you make vmware finish installing for me?
[06:30] <dholbach> I probably can't :)
[06:30] <MTeck> installing this thing is a painful process :( - so painful - I was using vbox but apparently that's not good for developing machines you want ot give to others
[06:59] <stochastic> I noticed a package of mine (xjadeo) that got it's second advocation on revu about five hours ago is still listed on the 'new' page.  Is this correct?  Has it been uploaded?  Do I need to click the "archive" link at the top of it's page?  I don't want it to get messed up and miss feature freeze.
[07:07] <porthose> prefrontal, I left a comment :)
[07:12] <porthose> good mornin dholbach
[07:14] <dholbach> hiya porthose
[07:30] <TheMuso> stochastic: You could check the new queue.
[07:30] <TheMuso> TO be sure.
[07:31] <stochastic> TheMuso, where is that?
[07:32] <TheMuso> stochastic: afaicr https://launchpad.net/ubuntu/karmic/+queue
[07:35] <stochastic> TheMuso, eek looks like directhex didn't upload it.  Do you have a second?
[07:38] <TheMuso> stochastic: Sure.
[07:39]  * TheMuso logs into revu.
[07:41]  * TheMuso gives it a cursary build/lintian run just to be safe.
[07:41] <TheMuso> Not that I mistrust the MOTU who gave it the ok.
[07:43] <sistpoty|work> hi folks
[07:43] <sistpoty|work> hey DktrKranz, thanks for the upload! :)
[07:44] <DktrKranz> sistpoty|work: you're welcome, I didn't commit to svn though (I forgot :/)
[07:44] <TheMuso> stochastic: Uploading now.
[07:44] <sistpoty|work> DktrKranz: no problem, will do that after work
[07:45] <DktrKranz> sistpoty|work: ... and thanks for let me do some practice ;)
[07:45] <sistpoty|work> heh
[07:47] <prefrontal> porthose, thank you
[07:48] <porthose> prefrontal, yw :)
[08:37] <rugby471> hi guys
[08:37] <rugby471> memaker has just had a new release
[08:37] <rugby471> and I have built a new package for it
[08:37] <rugby471> it has LOADS of bug fixes and some new features
[08:37] <rugby471> what is the best step to take to get it into the universe before feature freeze?
[08:37] <rugby471> do I need to make a bug?
[08:38] <iulian> rugby471: Yes.
[08:38] <iulian> Attach diff.gz.
[08:38] <rugby471> only the diff.gz
[08:38] <rugby471> what about orig.tar.gz
[08:38] <iulian> rugby471: We will get it.  We only need the diff.gz file.
[08:38] <rugby471> ok
[08:38] <iulian> rugby471: And subscribe ubuntu-universe-sponsors.
[08:38] <rugby471> what do I file the bug in, memaker?
[08:39] <iulian> rugby471: Yes, file it against memaker.
[08:39] <rugby471> and does it needs any specific tags?
[08:39] <iulian> rugby471: No.
[08:39] <rugby471> kl
[08:39] <iulian> Tell me when you're done.
[08:39] <rugby471> thanks iulian!
[08:39] <rugby471> kl
[08:39] <rugby471> I will
[08:40] <rugby471> is there any recommended title of the ubg I should use?
[08:40] <rugby471> ubg > bug
[08:40] <dholbach> hey rugby471!
[08:40] <dholbach> long time no see
[08:40] <rugby471> sorry one last question do I file it against the memaker project or the memaker package?
[08:40] <rugby471> hey
[08:40] <rugby471> I thought you ere walking the dog...
[08:40] <rugby471> :-)
[08:40] <rugby471> joking
[08:40] <dholbach> back now :)
[08:40] <iulian> rugby471: Against memkaer package in Ubuntu.
[08:40] <rugby471> thanks
[08:41] <iulian> Hello dholbach.
[08:42] <dholbach> hey iulian
[08:42] <iulian> How goes it?
[08:42] <dholbach> very good very good
[08:42] <dholbach> how 'bout you?
[08:43] <iulian> I'm happy.  I've just passed my driver's license test.
[08:44] <rugby471> congrats
[08:44] <iulian> Thanks!
[08:44] <dholbach> woohoo
[08:46] <rugby471> iulian: ok filed the bug here https://bugs.launchpad.net/ubuntu/+source/memaker/+bug/419077
[08:46] <rugby471> hehe thanks bot :-)
[08:47] <rugby471> dholbach: sorry forgot to ask how are you?
[08:47] <dholbach> thanks, I'm good, just very busy :)
[08:48] <dholbach> but that's nothing new :)
[08:48] <rugby471> hehe
[08:48]  * warner finally gets a karmic pbuilder environment set up on sid
[08:51]  * juanje hugs dholbach :-)
[08:51]  * dholbach hugs juanje back
[08:52] <warner> now, will it actually build the zfec package that I want to get into karmic..
[08:53] <warner> do people usually install lintian into their pbuilder environments? mine doesn't seem to have it..
[08:55] <warner> cool, it did. But, of course, without lintian in the karmic chroot, I can only run it against sid's lintian, which will probably complain about different things
[09:09] <jtimberman> Is a maintainer for the CouchDB package in Karmic around?
[09:18] <binarymutant> jtimberman, I think that the maintainer is motu as whole
[09:18] <jtimberman> binarymutant: indeed..
[09:19] <binarymutant> jtimberman, it's synced from debian
[09:19] <dholbach> I'll try to find somebody couchdb
[09:19] <dholbach> just a sec
[09:19] <jtimberman> binarymutant: not the version in karmic
[09:20] <binarymutant> ah :D
[09:20] <jtimberman> the version in karmic is 0.10, which has some backwards incompatible changes per one of the guys on #couchdb.
[09:20] <jtimberman> which also breaks chef-server.
[09:20] <jtimberman> they said 0.9.1 is stable on #couchdb.
[09:27] <prefrontal> pbuilder just blew my mind. what a nice tool
[09:43] <maxb> prefrontal: seen cowbuilder yet? :-)
[09:44] <jtimberman> or sbuild?
[09:45] <jtimberman> sbuild, as i understand, is used on the ubuntu infrastructure to build out packages across the board.
[09:46] <maxb> yes, but it's more complex to get going, and requires LVM for its copy-on-write functionality
[09:46] <maxb> So pbuilder is better when you're getting started
[09:46] <jtimberman> maxb: I'm a sysadmin with years of experience with LVM, so I'm not afraid :-D
[09:48] <slytherin> sbuild is hard to get setup.
[09:51] <\sh> slytherin: hmm..nope...you should just setup local package mirrors
[09:52] <\sh> mk-sbuild-lv does the rest
[09:52] <slytherin> That is why I said it is hard to setup. With pbuilder it is just 'sudo pbuilder --create'.
[09:53] <TheMuso> However sbuild + schroot gives you much more flexibility with having chroots on hand to test things as a normal user.
[09:53] <TheMuso> The same chroot can be used to test package functinality/build by hand, as well as a build run with sbuild.
[09:53] <prefrontal> maxb, pbuilder is actually not working for me bcz the packages im testing require opengl
[09:53] <TheMuso> And there is no waiting for tarballs to pack/unpack.
[09:54] <gnomefreak> does cups-ppdc replace cupsddk?
[09:54] <maxb> prefrontal: so?
[09:54] <prefrontal> cowbuilder?
[09:55] <prefrontal> alas, i resorted to vmware
[10:03] <prefrontal> oh man.. so far i have tried to test my package in pbuilder (no opengl), by installing alpha 4 to a vm (never booted up), and by upgrading jaunty to karmic (rebooted to busybox)
[10:03] <prefrontal> i am feeling screwed
[10:29] <boomer> when a motu gets a chance can you review my upload on revu, gnome-video-arcade. i've addressed rainct's comments, thanks. http://revu.ubuntuwire.com/p/gnome-video-arcade
[10:32] <logari81> hi, I want to remove some code from an upstream package, not because it is not free, but just because it has another license as the rest of the package, it contains files missing a license header and because there is already a ubuntu package with this part of code as a standalone lib.
[10:33] <logari81> My question is if I have to add the dfsg suffix to tha orig.tar.gz
[10:33] <slytherin> logari81: yes.
[10:36] <logari81> slytherin: thank you, I thought dfsg is only for the case that non-free code has to be removed
[10:37] <slytherin> logari81: as far as I know, files missing license header have ambiguity regarding dfsg freeness.
[10:37] <logari81> ok actually you are right
[10:39] <sistpoty|work> logari81: if the files in question are free (and this seems to be the case if they are in another package already in the archive), there's no need to remove them
[10:39] <sistpoty|work> logari81: just make sure that the library from the package, not the internal copy is used
[10:40] <sistpoty|work> logari81: and of course document the different license in copyright
[10:44] <logari81> sistpoty|work: but so I will still have a problem with the missing license headers
[10:45] <logari81> but I see in the standalone package (superlu_3.0) the problem has not been corrected
[10:46] <logari81> there are many files with no license
[10:46] <sistpoty|work> logari81: there's not too much of a (legal) problem with missing license headers (unless e.g. it's a gpl'd lib, and the license headers have been *removed*, which the gpl doesn't allow)
[10:46] <logari81> it is BSD code
[10:47] <sistpoty|work> logari81: a license is not bound to license headers. if there's a file that says "this is lib blabla, with the license foobar", that works as well
[10:47] <sistpoty|work> logari81: of course license headers are way preferred (exactly to find out about it, if used in a different project), but not mandatory
[10:53] <logari81> sistpoty|work: then what you suggest is to let the upstream package as is, to copy the same copyrights from the stand alone superlu to my debian/copyright even if during the building I use the ubuntu standalone superlu lib instead of the superlu copy provided with my upstream package. If that is right I ll prepare a new version and upload it for further proofing.
[10:54] <sistpoty|work> logari81: yes. Of course you should also doublecheck superlu lib files/the copied copyright to be in order
[10:57] <IntuitiveNipple> Can anyone recommend a relatively simply Python application package I can use as a guide to creating a package for a new Python application?
[11:02] <juanje> IntuitiveNipple: I recommend you to try Quickly (https://edge.launchpad.net/quickly) that makes all the stuff you need for a new Python app and package. After that you can see inside how the package has been done
[11:03] <IntuitiveNipple> Thank-you. I'm working on getting the video editor OpenShot packaged and went down the python-support route and then realised its mainly for supporting modules rather than applications
[11:03] <juanje> IntuitiveNipple: also you can check packages like gtg or usb-creator
[11:05] <juanje> IntuitiveNipple: ok, anyway, you can create som dummy app with quickly just to see how the package is and copy the stuff you need
[11:06] <IntuitiveNipple> I'll have a play around with those :0
[13:23] <slytherin> ttx: ping
[13:24] <ttx> slytherin: quick-pong
[13:24] <slytherin> ttx: is it ok to merge ivy from Debian unstable, if we skip maven related changes?
[13:25] <slytherin> The version in Debian is 2.1.0~rc2 (ubuntu has rc1).
[13:25] <ttx> any missing feature / bugfix as a reason why we should ?
[13:25] <slytherin> I haven't checked changelog. I will and let yuo know.
[13:26] <ttx> slytherin: I'm ok with it if tere is a compelling reason to do it. If it's just to have the latest, then I prefer we pass
[13:26] <slytherin> ok
[13:44] <IntuitiveNipple> I'm trying to understand the reasons for splitting a single upstream application into several logical binary packages, e.g. application, application-data, application-themes application-profiles, where 'data' 'themes' and 'profiles' are distinct data file sets. I thought it was so these packages could be updated without the application being updated, but it seems like from the same source package, the buildd will always build all the bin
[13:44] <IntuitiveNipple> ary-packages in the source, so what reason would there be to logically split like this?
[13:54] <slytherin> ttx: ivy rc2 changes - http://paste.ubuntu.com/259826/
[13:55] <RainCT> geser: Ping. I'm working on updating libwiimote. There's this patch from you http://paste.ubuntu.com/259827/ but just adding "-fPIC" to the CFLAGS:= line seems to be enough for it to build, so I'm wondering whether the other stuff is needed?
[13:56] <ttx> slytherin: hm. So nothing outstanding... if it were to move to the final release, I'd agree. But to move to rc2 ? I just don't need any risk introduced right now.
[13:58] <slytherin> Ok. I will check when final release is made.
[13:58] <slytherin> That will probably need FFE.
[14:08] <RainCT> geser: ah nevermind, upstream fixed the file so -fPIC can be set from debian/rules now
[14:20] <pochu> RainCT: hi! are you back from holidays?
[14:20] <RainCT> pochu: Hey. Not yet, but I thought I'd do some stuff before FF :)
[14:21] <pochu> RainCT: ah ok :) webboard can wait some more then ;)
[14:27] <huats> I have a question : I am maintaining a package in debian and I am dealing with it on Ubuntu too..
[14:27] <huats> I would like to have a ne release in ubuntu
[14:28] <huats> but since we are in sync currently
[14:28] <RainCT> pochu: Maybe I can get to it later today. You can sponsor the upload then :)
[14:28] <huats> I would avoid to create diversion...
[14:28] <pochu> RainCT: alright!
[14:28] <bakkdoor> hi. I get an error when logging in @ http://revu.ubuntuwire.com/ -> "MOD_PYTHON ERROR [...]"
[14:28] <huats> do I need a FFe to sync toward 1.1.10-1 if it's e.g. 1.1.10-0ubuntu1 in Ubuntu, and 1.1.10-1 in Debian ?
[14:29] <bakkdoor> does this happen for other people as well?
[14:30] <ScottK> RainCT: ^^
[14:30] <RainCT> huats: I don't think so, but if both versions are equal there isn't much point in requesting a sync for that. Just remember to sync once Debian has something interesting.
[14:30] <ScottK> huats: No.
[14:30]  * RainCT looks
[14:31] <huats> RainCT: The idea was to avoid diversion...
[14:31] <huats> RainCT: and ScottK thanks !
[14:31] <huats> than I will upload it right now to ubuntu...
[14:32] <RainCT> huats: (Well, being diverted isn't necessarily bad. You've to consider what is more important, the version number or giving the builds work and forcing people to download the package again)
[14:32] <Adri2000> is requestsync broken for everyone? bug #418802
[14:32] <RainCT> bakkdoor: Works here. Can you paste the error on http://paste.ubuntu.com, and check if Ctrl+F5 fixes it or the error is persistant?
[14:32] <huats> RainCT: sure
[14:33] <huats> I'll keep that in mind
[14:33] <huats> thanks RainCT
[14:38] <Riddell> "every package needs a "needs-packaging" bug in Launchpad" when did that become a requirement and what's its purpose?
[14:38] <bakkdoor> RainCT: http://paste.ubuntu.com/259838/ <- its persistent
[14:38] <ScottK> I don't think it is a requirement.
[14:39] <ScottK> ITP isn't even a strict requirement in Debian.
[14:39] <ghostcube> Riddell: this spreads on getdeb too
[14:39] <ghostcube> anyone started it
[14:39] <ghostcube> -_-
[14:39] <lfaraone> Riddell: where'd you see that?
[14:40] <Laney> REVU tells you off if you don't have one too
[14:40] <Riddell> yeah it's on https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList
[14:40] <Riddell> and I've seen commenters moan about it too
[14:40] <Riddell> on revu
[14:40] <lfaraone> Riddell: well, it *should*.
[14:41] <Laney> it's a good idea to prevent duplication of work, but nothing more imo
[14:41] <ScottK> lfaraone: Why?
[14:41] <ScottK> Laney: Definitely.
[14:41]  * RainCT agrees
[14:42] <sistpoty|work> Riddell: iirc, that was discussed some time ago on the -motu list, let me try to find the thread again
[14:43] <RainCT> bakkdoor: Sorry, no idea why that happens. Maybe ask in #launchpad?
[14:44] <bakkdoor> RainCT: alright
[14:49] <sistpoty|work> Riddell: https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002694.html (iirc the idea came up to avoid duplication and to be able to link to a itp, but I'm no longer 100% sure)
[14:51] <flohack> Hi! Can someone please give me a hint how to change the ownership of files to install when creating a package?
[14:52] <boomer> RainCT: when you get a chance, can you review my upload on revu, gnome-video-arcade. i've addressed your comments, thanks. http://revu.ubuntuwire.com/p/gnome-video-arcade
[14:52] <RainCT> flohack: chmod? :)
[14:52] <flohack> RainCT: I tried a 'chown -R www-data:www-data $(CURDIR)/debian/mypackage/www-data-dir' within the binary-install/mypackage target in rules, but that does not seem to work
[14:53] <RainCT> (or if you use 'install' instead of 'dh_install', the former has an option for ownership)
[14:53] <flohack> RainCT: I use a .install file to copy files from the source tree, which command would then be best to change the ownership?
[14:53] <RainCT> yeah I'd go with chmod then
[14:53] <RainCT> *chown
[14:54] <flohack> RainCT: Hmm...any ideas why my commands from above don't work?
[14:55] <flohack> I see the command being executed when running 'debuild binary', but neither the ownership is right after installing with dpkg, nor is the ownership correct when looking at the debian/mypackage directory
[14:58] <flohack> Which seems reasonable to me, as changing the ownership to www-data is 'permission denied' when attempting to do that as a normal user
[14:58] <flohack> Any ideas?
[14:58] <RainCT> debian/rules runs as root (or fakeroot)
[15:03] <slytherin> flohack: try to see how it is done in apache2 package.
[15:21] <vivia> Hello... aMSN 0.98 sources is released... any kind soul available to package it before FeatureFreeze? :)
[15:22] <RainCT> Is CDBS capable of calling autoconf? Else, what's the best way to handle a tarball where autoconf wasn't run (and which requires patching of .in files to work for Ubuntu)
[15:23] <slytherin> vivia: Don't you think it is a bit high expectation.
[15:26] <sistpoty|work> RainCT: without cdbs: "autreconf -i" should do the right thing
[15:26] <vivia> slytherin: yeah I know it's a last-moment
[15:26] <vivia> but there's a huge load of new features of bugfixes
[15:27] <slytherin> vivia: if the features and bug fixes are important I am sure the packagers will apply for FFE.
[15:27] <slytherin> RainCT: Do you need to run it at the build time? How about create a patch.
[15:27] <RainCT> slytherin: It fails to unapply
[15:28] <slytherin> hmm, that is bad.
[15:28] <RainCT> sistpoty|work: Well I'm trying with that (well I tried with 'autoconf -f' but same with autoreconf) in makebuilddir:: which generated the files correctly (./configure; make works) but makefile.mk doesnt' seem to be running ./configure
[15:28] <vivia> slytherin: sorry, what is FFE?
[15:28] <slytherin> IIRC, cdbs has provision to do certain tasks before build. Btu I have never used it. cdbs manual may help.
[15:28] <RainCT> vivia: Feature Freeze Exception
[15:29] <slytherin> vivia: feature freeze exception
[15:29] <vivia> thanks :)
[15:29] <sistpoty|work> RainCT: hm... don't use cdbs then :P
[15:29] <sistpoty|work> (not a clue about cdbs, sorry)
[15:31] <james_w> has anyone ever seen "python setup.py install --root=blah" install scripts in /usr/local/bin?
[15:31] <james_w> I thought --root would be enough and e.g. --prefix wouldn't be needed?
[15:33] <vivia> ok so I'm off, if FFE is possible for a big difference in features and bugfixes. Thanks all! :)
[15:40] <flohack> How can I make sure that pbuilder keeps the build result, so I can examine what it did?
[15:42] <flohack> Or is there a way to tell pbuilder to drop me to a shell within the build environment if the build fails?
[15:44] <stefanlsd> flohack: --logfile will write the stdout to a file. you can also drop into the build env. by using hooks
[15:45] <flohack> stefanlsd: That would be great...by any chance have you got a working example how to drop into a shell.
[15:46] <stefanlsd> flohack: man pbuilder and look for hookdir. I use the following http://pastebin.ubuntu.com/259866/  . Its called C10shell
[15:47] <flohack> stefanlsd: Thanks a lot!
[15:50] <RainCT> OK got that working. How do I fix ldconfig-symlink-missing-for-shlib?
[15:50] <sluimers> Hi, I'm trying to upload a package to my PPA but I keep getting FAILEDTOBUILD errors due to incorrect build-dependencies. Is there any way to check this beforehand?
[15:50] <stefanlsd> flohack: np. good luck. oh yeah. dont forget to to tell pbuilder your hookdir, else it doesnt pick up the hook
[15:51] <flohack> stefanlsd: Thanks for the hint, I think I got it right.
[15:51] <slytherin> sluimers: pbuilder
[15:53] <flohack> Something different: I'm trying to backport alfresco for hardy, but the build fails with 'The import sun.security cannot be resolved', which suggests that the rt.jar (which contains the proprietory java extensions) is not added to the build. I simply took the jaunty package and changed the openoffice dependency to 2.4 ( from 3.0 ). Any ideas what the problem could be? The control file Build-Depends on sun-java6-jdk, so the sun compilier should 
[15:53] <flohack> in use...
[15:55] <slytherin> flohack: What is correct name of package?
[15:57] <flohack> slytherin: alfresco-community
[15:59] <slytherin> flohack: I can not find any such package on packages.ubuntu.com
[15:59] <slytherin> wait, fund it
[15:59] <flohack> it's in the partner repository
[16:01] <slytherin> flohack: sun-java6-jdk can not be installed interactively. On build servers this is solved by preseeding of debconf answer (to the question that requires acceptance of agreement). I believe this is not present on PPA. So the other JRE which is automatically pulled by ant is getting used. And my guess is that JRE is GCJ.
[16:01] <flohack> I did that, parts of it compile just fine
[16:01] <flohack> I executed: echo -e "sun-java6-bin shared/accepted-sun-dlj-v1-1  boolean true\nsun-java6-jdk shared/accepted-sun-dlj-v1-1  boolean true\nsun-java6-jre shared/accepted-sun-dlj-v1-1  boolean true" | debconf-set-selections
[16:02] <slytherin> flohack: Where did you do that?
[16:02] <flohack> in the pbuild chroot (sudo pbuilder login --save-after-login)
[16:03] <slytherin> flohack: What is the value of JAVA_HOME in debian/rules?
[16:04] <flohack> "alfresco-community-3.2/debian$ grep -R JAVA_HOME *" Does not return anythin
[16:05] <flohack> I'm currently in the pbuilder shell after the build failed (hook)
[16:05] <flohack> JAVA_HOME is not set there
[16:05] <flohack> "javac -version" in the chroot shows that it's ecj which is the default java compiler
[16:06] <slytherin> flohack: you can try setting JAVA_HOME to the sun java installation directory in debian/rules. See if that works. Other option is to use openjdk-6-jdk as build-dep instead of sun-java6-jdk.
[16:07] <zooko`> POX_: are you there?
[16:07] <POX_> zooko`: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[16:07] <slytherin> flohack: and ask the maintainer to use openjdk for builds henceforth.
[16:07] <zooko`> POX_: Wow!  Good script!
[16:07] <flohack> slytherin: Where exactly would I set that? which target? is setting it with 'export JAVA_HOME=/usr/lib/jvm/java-6-sun' correct?
[16:08] <zooko`> POX_: I gotta go to the bus to work now.  I hope you look at Tahoe-LAFS on http://revu.ubuntuwire.com/p/tahoe-lafs today.  Bye!  :-)
[16:09] <flohack> slytherin: Would depending on openjdk-6-jdk make that the default? Does the openjdk include the sun.security package?
[16:19] <flohack> slytherin: I wrote the email proposing the dependency change to the maintainer's address and tried setting JAVA_HOME. I'll report back!
[16:22] <kevdog> Anyone actually know the proper way to make a deb file -- not using checkinstall
[16:23] <slytherin> kevdog: read the topic
[16:24] <slytherin> flohack: using openjdk should fix it. But I don't remember exactly if it will. Setting correct JAVA_HOME is the best way.
[16:24] <porthose>  kevdog, https://wiki.ubuntu.com/PackagingGuide/Complete
[16:24] <kevdog> Oh -- sorry -- do you know where I can ask this question then?  #ubuntu told me to check here
[16:24] <Refried_> has the vuze question been asked in here a million times?
[16:29] <slytherin> kevdog: Have you gone through the packaging guide? If you have specific questions then ask here.
[16:29] <flohack> I just can't get the chown www-data:www-data within the rules to work. I looked at the apache2 package and can't find any differences there. I can see that the command is executed when running 'debuild binary'. After installing the dpkg, the directory is still owned by root:root.
[16:30] <sistpoty|work> flohack: do you run dh_fixperms afterwards?
[16:31] <flohack> sistpoty|work: Not yet, i'll try that...thanks!
[16:31] <sistpoty|work> flohack: actually the other way round... *if* you run it *after* the chown, it will reverse the effect (because it restores the owner to root)
[16:32] <flohack> dh_fixperms is not in my rules file...
[16:32] <sistpoty|work> flohack: cdbs? dh?
[16:33] <sistpoty|work> flohack: you could try: export DH_VERBOSE=1 at the start of your rules file to see if s.th. else runs it
[16:33] <flohack> sistpoty|work: I'm not that familiar with packaging yet, I see the dh_? scripts being executed when running 'debuild binary', is that a hint for dh?
[16:34] <sistpoty|work> flohack: it's a hint that debhelper is run during build... maybe you can just spot a dh_fixperms in there?
[16:34] <flohack> I just ran it with verbose, I'll have a look
[16:35] <geser> james_w: is this a bug in the new python-wadllib in karmic? http://launchpadlibrarian.net/30827431/Traceback.txt
[16:36] <james_w> ugh
[16:36] <james_w> not sure
[16:36] <james_w> please file it
[16:37] <flohack> sistpoty|work: I can see a fixperms after my chmod, how can I make sure my chown runs after that?
[16:37] <sistpoty|work> flohack: no idea, what does your rules file look like?
[16:38] <geser> james_w: it's already filed (bug #418802) but wanted to ask before I re-assign it to python-wadllib
[16:38] <james_w> ah
[16:38] <james_w> give me a few and I'll take a look
[16:41] <flohack> sistpoty|work: I'll pastebin it for you, give me a few minutes please
[16:44] <slytherin> anyone have any idea how good is epiphany-webkit?
[16:44] <flohack> sistpoty|work: http://pastebin.ubuntu.com/259897/
[16:46] <james_w> geser: looks like it, but I can' believe it would be that broken
[16:46] <james_w> geser: my guess is version skew between launchpadlib and waddlib
[16:49] <geser> james_w: do you know who to contact about it?
[16:49] <james_w> about what?
[16:49] <geser> about the bug or whose bug it is at all
[16:50] <james_w> you can talk to #launchpad
[16:50] <geser> or is a new python-launchpadlib upload planed in the near future anyway?
[16:50] <james_w> yeah
[16:50] <james_w> it's waiting on lazr.restfulclient from NEW
[16:51] <sistpoty|work> flohack: oh, you're using cdbs... I'm not really familiar with it, but I'm guess someone else here might have the answer for your problem
[16:53] <geser> ok, then I'll wait for it before I start pestering people
[16:53]  * sistpoty|work heads home... cya
[16:54]  * slytherin heads home too
[17:02] <dholbach> anybody familiar with dkms stuff? I was just pinged about bug 277556
[17:03] <ScottK> superm1 would be your dkms expert.
[17:21] <flohack> Is someone here familiar with cdbs? I would like to change the permissions of a few files, but dh_fixperms always reverts that....
[17:24] <dholbach> superm1: I'm sure you're superbusy, but if you have a bit of time and could have a look at bug 277556 I'd appreciate that :)
[17:29] <geser> james_w: doesn't the new bzr-gtk work with bzr 1.18 (which is currently in karmic)? a dist-upgrade wants to remove it
[17:36] <openQRM> Hi txx and Hi mathiaz, its Matt here from the openQRM team. The package should be good now :) BIG thanks for all your help
[17:45] <james_w> geser: oops, thanks, fixes
[17:51] <flohack> What is the recommended procedure for patching binary files when building a debian package?
[17:52] <geser> patching binary files? why?
[17:55] <flohack> geser: I'm packaging vtiger and it includes modules as zip files, which are extracted during the installation. I need to patch a module...
[17:56] <geser> and the module is already compiled?
[17:56] <geser> can't you unzip it, patch, rezip?
[17:56] <flohack> geser: It's just some php code
[17:56] <flohack> geser: But that's still a modification to the binary zip file, isn't it?
[17:57] <flohack> geser: Just to make it clear, vtiger extracts and installs the module zips during the 'installation / setup' which happens after package installation...
[17:58] <geser> flohack: can't it be done during the package build? so you already have the unzipped modules in the deb?
[17:59] <flohack> geser: not really, because installing the module includes a step where the module creates DB tables and registers with the system, by inserting a few DB lines. vtiger does that only if you actually deploy the module...
[18:00] <flohack> if I simply extract the module in place, vtiger does not pick it up and 'deploys' it
[18:00] <lfaraone> Now, I read through the current policy on the "Maintainer" field. From what I understand, I could use my "@ubuntu.com" email in Maintainer: rather than MOTU if I wish?
[18:01] <flohack> geser: Can I /add/ a new binary file with debdiff?
[18:01] <geser> lfaraone: yes, if you want to be the "dedicated" maintainer
[18:01] <lfaraone> geser: well, I'm the maintainer of the package in debian.
[18:02] <geser> flohack: yes, but you would need to uuencode it as diffs are plain-text
[18:02] <lfaraone> geser: in debian, I use my personal email, "luke at faraone dot cc". I have to change that, however, when I upload an 0ubuntu1 version, correct?
[18:04] <geser> lfaraone: not necessarily, you might need to convice dpkg-buildpackage perhaps (it warns about the Maintainer if DEBEMAIL contains @ubuntu.com) but after this nothing stops you anymore to upload it with your Debian maintainer field value
[18:05] <lfaraone> geser: Okay. Would a sponsor balk?
[18:05] <flohack> geser: Ok, hmmm...I reread your 'can't you unzip it, patch, rezip?'...What if I store the patch in the source package and when building the binary package, I simply unzip, patch, rezip...is that what you actually meant?
[18:06] <geser> yes, sorry for my bad wording
[18:06] <flohack> geser: ok, so that should work... Any ideas where I could put the unzip/rezip stage when using quilt with cdbs?
[18:08] <flohack> geser: I think there is a problem...I have to be able to reverse the zip patching process....
[18:09] <flohack> otherwise building the source package does not work, does it?
[18:09] <geser> flohack: make a backup of the unmodified zip which you can restore later
[18:10] <flohack> geser: Could you give me a few hints where to hook that into the cdbs rules file? I'm completely new to that...
[18:10] <lfaraone> Is Debian-Standards-Version 3.8.3 supported in Karmic?
[18:12] <pochu> bigon: hi, do you care about emesene?
[18:13] <pochu> (or is anybody who cares for emesene around?)
[18:14] <porthose> pochu, prefrontal was in here last night talking about it :)
[18:15] <pochu> is he a motu? :)
[18:15] <porthose> pochu, dont think so
[18:18] <geser> flohack: that's a good question; currently I don't have an idea
[18:19] <geser> lfaraone: what you mean by supported? I guess we already synced some packages with it, so it should be ok
[18:23] <flohack> geser: Alright, I'll crunch the cdbs makefiles in my head :-)
[18:26] <geser> flohack: take also a look at /usr/share/doc/cdbs/buildcore.png to see which targets depends on which other target
[18:27] <neversfelde> bug 221531 needs a review for SRU, anyone around who could do this?
[18:27] <prefrontal> porthose, my software is emergent, not emesene ;)
[18:30] <porthose> whoops my bad :(
[18:36] <randomaction> A package (glife, in universe) should IMO be removed from the archive. It's absent in Debian. Should I file a removal request, or someone will just remove such packages at some point?
[18:38] <boomer> when a motu gets a chance can you review my upload on revu, gnome-video-arcade. i've addressed rainct's comments, thanks. http://revu.ubuntuwire.com/p/gnome-video-arcade
[18:57] <mathiaz> openQRM: hey - I'll review the new packages soon
[18:58] <openQRM> mathiaz: :) great man, thanks a lot.
[19:06] <RoAkSoAx> hey guys I've got one question. What should we do with a lintian warning that says: debian-changelog-file-is-a-symlink
[19:08] <Daviey> RoAkSoAx: is it a symlink?
[19:08] <Daviey> i guess you have read, http://lintian.debian.org/tags/debian-changelog-file-is-a-symlink.html ?
[19:09] <RoAkSoAx> Daviey, yeah. I already did so. Though I mean, should we care to fix this warning, or should be ignore it since some say in Ubuntu it's not necessary: see bug https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/329060
[19:11] <RoAkSoAx> brb
[19:12] <ttx> openQRM: hey. Looking at the package now.
[19:12] <ttx> thanks for joining us :)
[19:15] <flohack> If the upstream version string is 185plus-build7489-20090819 (limesurvey), how should the debian version of a package look?
[19:16] <flohack> ...they produce multiple builds with chaning revision and date, under the 185plug umbrella
[19:16] <geser> 185plus-build7489-20090819-0ubuntu1 (the last - splits the upstream version from the Debian revision)
[19:17] <flohack> ok, thanks geser...btw I solved the zip patching task...the relevant targets were: makebuilddir/vtiger:: post-patches:: cleanbuilddir/vtiger::
[19:19] <RainCT> Hi again
[19:19]  * RainCT is going to create a package.. Mwhahaha. Who's up for reviewing?
[19:21] <RoAk> ok i'm
[19:21] <RoAk> back
[19:21] <RoAk> any ideas on the lintian warning of symlinking the changelog
[19:22] <RainCT> RoAk: Ignore that, it's an Ubuntu thing
[19:22] <RainCT> to save disk space
[19:22] <RoAk> RainCT: ok awesome, thanks :)
[19:24] <boomer> RainCT: if you get a chance, can you review gnome-video-arcade in revu again
[19:24] <openQRM> txx: :) cool, I am so excited.
[19:27] <zooko`> Folks: if anyone can review http://revu.ubuntuwire.com/p/zfec , http://revu.ubuntuwire.com/p/foolscap , or http://revu.ubuntuwire.com/p/pycryptopp , that would be much appreciated.
[19:27] <zooko`> Tahoe-LAFS has already been reviewed, but it depends on those three.
[19:28] <slytherin> zooko`: It is hard to find someone to review new packages this close to feature freeze.
[19:29] <zooko`> slytherin: yes, I know.
[19:29] <zooko`> We've been working on it for a while, getting it all lintian-clean and so forth.
[19:29] <zooko`> Actually two of those packages already have (older versions) in Debian.
[19:30] <slytherin> zooko`: Then why are these packages on revu? The .diff.gz should be attached to a bug.
[19:30] <zooko`> Hm.
[19:32] <zooko`> warner: if I understand correctly, foolscap and pycryptopp are both already in Debian, but the versions in Debian are too old.
[19:32] <zooko`> warner: is that right?
[19:32] <zooko`> slytherin: zfec is not in Debian or Ubuntu.
[19:33] <sebner> RainCT: what kind of package? :P
[19:33] <RainCT> sebner: nevermind, I've seen there's an ITP for it so I'll go do sth else
[19:33] <sebner> RainCT: haha, new package before FF? bad boy
[19:34] <slytherin> I planned to add two new packages. But figured out that copyright will perhaps take more time, so skipped them. :-P
[19:35] <RainCT> (in case you're curious, the package is wiipresent)
[19:36] <warner> zooko`: correct. foolscap is also in ubuntu, but it's the same too-old version.
[19:36] <sebner> RainCT: somewhere read about it iirc
[19:39] <RainCT> sebner: I just hope the guy doesn't package libwiimote (dependency) from scratch for Debian, as I spend several hours this morning updating it :P
[19:39] <sebner> RainCT: Did I already tell you that FF is nearing :P
[19:40] <RainCT> sebner: yeah if I leave it for Debian it's not going in but I don't care, will create a PPA :P
[19:40] <sebner> RainCT: what's the app about?
[19:41] <RainCT> sebner: controling presentations using the wii mote
[19:41] <zooko`> I forgot to mention that Tahoe-LAFS is the most awesome secure, privacy-preserving file storage system ever invented.
[19:42] <RainCT> boomer: Do you have a build version somewhere?
[19:43] <sebner> RainCT: isn't that a geeky 0.1% user app? :P
[19:43] <RainCT> sebner: yes, but I'm a geek :P
[19:43] <RainCT> and I bought a wiimote just for using it with the laptop! :P
[19:43]  * RainCT still needs to get LEDs to try out the touchscreen stuff
[19:44] <sebner> RainCT: omg xD
[19:45] <slytherin> what is wiimote?
[19:45] <RainCT> slytherin: Wii Remote
[19:45] <RainCT> (Wii as in that Nintendo thing ;))
[19:45] <slytherin> And for what purpose are you going to use it with PC?
[19:46] <RainCT> slytherin: controlling slides when I do presentations? trying out that touchscreen stuff (check videos on youtube :P), etc.
[19:47] <slytherin> hmm, looks like remuco needs a plugin for OOo/evince. hyperair do you have any idea if such plugin work is in progress?
[19:48] <slytherin> RainCT: If you had a Sony Ericsson phone you could have done that with the phone. :-)
[19:48] <RainCT> slytherin: the touchscreen stuff too?
[19:48] <RainCT> (and yes I can do the slide control stuff with my new phone too)
[19:49] <slytherin> RainCT: no, I meant only desktop control.
[19:49] <RainCT> (wouldn't have bought the wiimote if I had known I'd decide to get a smartphone :P)
[19:49]  * directhex has a phone made of win
[19:50] <RainCT> btw, OT, someone knows of some proper editor (with syntax highlighting et all) for Symbian (with touch screen)?
[19:50] <directhex> sadly evolution doesn't seem to be usable with PDA's unless they're antique palmpilots... so i'm using the departmental exchange server
[19:50] <directhex> symbian? ew!
[19:50] <RainCT> haha
[19:50] <hyperair> slytherin: hmm i don't think so. do they have a d-bus interface, or any other IPC accessible via python?
[19:50] <slytherin> hyperair: Not sure.
[19:51] <RainCT> directhex: What problem do you have with Symbian? -.-
[19:51] <directhex> RainCT, bitter experience!
[19:52] <hyperair> slytherin: okay, at least evince doesn't have any dbus interface to switch pages
[19:52] <RainCT> directhex: Works pretty good here, just some minor quirks (eg. no "mark all as read" option in the feed reader)
[19:52] <RainCT> but hey, I've even got a Python interpreter on it!
[19:53] <directhex> RainCT, n97?
[19:53] <RainCT> nokia 5800
[19:53] <directhex> i looked at that
[19:56] <RainCT> Is there some extremely awesome package on REVU waiting to get in before FF?
[19:56] <zooko`> Yes!  There is!
[19:57] <zooko`> But only if you think privacy preserving, decentralized storage is awesome.
[19:57] <RainCT> Not really, I have a big enough HD :P
[19:57] <zooko`> Darn.
[20:06] <Laibsch> Can I motivate a kind to take a look at (and hopefully endorse) http://revu.ubuntuwire.com/p/ffgtk ?  The karmic time window is closing.
[20:06] <Laibsch> s/a kind/a kind MOTU/
[20:08] <lamalex> Is there anyone here who can help me with some python packaging? I'm banging my head over distutils
[20:08] <zooko> lamalex: I might be able to help a bit.
[20:08] <DktrKranz> james_w: I've just uploaded new version of httplib2 in Debian, is it useful for you to have it in Karmic?
[20:09] <lamalex> zooko: so all my stuff is at lp:tictactoe, I can't get distutils to generate files from their .in counterparts
[20:09] <lamalex> zooko: if you'r prefer i just pastebin let me know, thought it might be easier to just branch
[20:10] <james_w> DktrKranz: sure
[20:12] <DktrKranz> ok, it'll get out of incoming in about half an hour
[20:13] <RoAkSoAx> DktrKranz, could you readvocate lekhonee please? since nxvl commented it cause of the warnings on the symlink changelog, and they should be ignored :) thank you!
[20:14] <zooko> lamalex: I haven't seen this technique of generating a file from a .in file before.
[20:15] <zooko> lamalex: Oh, it is for pot i18n?
[20:16] <mathiaz> openQRM: hey - so it seems that there is still some things written in /usr/share/openqrm - as there is a rm -rf /usr/share/openqrm in the postrm script
[20:16] <mathiaz> openQRM: what about using /var/lib/openqrm/ instead?
[20:16] <DktrKranz> RoAkSoAx: RoAkSoAx no need to readvocate, I already did it for the same upload
[20:16] <lamalex> zooko: how are you supposed to do it? I'm very new to distutils, used to autofoo
[20:17] <RoAkSoAx> DktrKranz, ohh ok cool then :) thanks.
[20:17] <zooko> lamalex: I haven't done i18n with distutils.
[20:17] <DktrKranz> np :)
[20:17] <RoAkSoAx> anyone willing on advocating http://revu.ubuntuwire.com/p/lekhonee please?
[20:18] <warner> RainCT: hey, so, zfec has priority "extra" for no particular reason.. I didn't know what it should be set to, and probably copied that from the package I was referencing
[20:18] <warner> RainCT: what should I set it to?
[20:18] <Daviey> Does someone have a moment to do two Debian syncs?
[20:18] <lamalex> zooko: how do you do it?
[20:18] <Daviey> One is new to Ubuntu and the other includes Ubuntu changes currently in karmic.. ? :)
[20:18] <slytherin> Daviey: do you have bugs for both of them?
[20:18] <zooko> lamalex: what is your goal?
[20:19] <Daviey> bug 419369
[20:19] <Daviey> bug 418293
[20:19] <Daviey> slytherin: ^^
[20:19] <slytherin> taking a look at dirac
[20:19] <lamalex> zooko: a source tarball with a .desktop instead of a .desktop.in file
[20:20] <openQRM> mathiaz: the rm in the postrm script should be almost not needed any more
[20:20] <slytherin> RoAkSoAx: I though lekhonee was already there in Debian
[20:20] <RainCT> warner: optional
[20:20] <warner> RainCT: ok, I'll fix that
[20:20] <RainCT> warner: i've left a comment with another little problem
[20:20] <warner> great, let me look at it..
[20:21] <RoAkSoAx> slytherin, no it isn't :)
[20:21] <openQRM> mathiaz: anyway there may still be some smaller left-overs so it is save to have for now
[20:21] <zooko> slytherin: cool! I like dirac.
[20:21] <mathiaz> openQRM: right. Which means that there are some processes that are writting to /usr.
[20:21] <slytherin> Daviey: what is transition plan for rdepends of libdirac.
[20:21] <mathiaz> openQRM: well - /usr/share/openqrm/.
[20:21] <zooko> lamalex: how are .desktop files produced from .desktop.in files?
[20:22] <mathiaz> openQRM: better use /var/lib/openqrm/ for that .
[20:22] <RainCT> (warner: except those binary packages would need a Feature Freeze Exception, in that case I'm happy if you do it for karmic+1)
[20:22] <openQRM> mathiaz: moving them to /var/lib/openqrm is accpted but really impossible to archive fast because it will require re-testing all 25-30 plugins
[20:22]  * mathiaz nods
[20:22] <warner> RainCT: huh, the first uploads I did included binary packages, but then I was told that I needed a _source.changes instead, so I built with -S, and then the .debs went away
[20:22] <openQRM> ?
[20:23] <warner> RainCT: or are you referring to the lack of zfec CLI tools, in a separate "zfec" or "zfec-tools" package?
[20:23] <RainCT> warner: the later :)
[20:23] <openQRM> mathiaz: what do you mean with "nods" ?
[20:23] <warner> RainCT: righto
[20:23] <mathiaz> openQRM: point taken.
[20:23] <mathiaz> openQRM: I'm pondering the options and what could be done for karmic.
[20:24] <openQRM> mathiaz: so can we have this as a bug-fix for later ?
[20:25] <RoAkSoAx> slytherin, can you review/advocate it please?? :)
[20:25] <slytherin> RoAkSoAx: I don't use it. So hard to say. I am already working on three packages. :-)
[20:26] <RoAkSoAx> slytherin, ok np :)
[20:27] <warner> RainCT: zfec has a copy of its GPL in ./COPYING.GPL . Is there any simple way to get REVU to notice that and clear the warning?
[20:28] <zooko> warner: I also don't object to "darcs mv COPYING.GPL COPYING" or somehow construct a symlink from COPYING to COPYING.GPL.
[20:28] <slytherin> warner: It is warning, not error.
[20:28] <RainCT> warner: ignore the warning :)
[20:28] <warner> ok, good enough :)
[20:30] <slytherin> Daviey: you haven't answered my question.
[20:30] <Daviey> slytherin: sorry.
[20:30]  * Daviey looks into it
[20:31] <lamalex> zooko: I don't know- that's why I came here
[20:32] <lamalex> I guess my actual goal isn't that though, that's a subgoal. My actual goal is a project with i18n support
[20:32] <warner> I want to run git-buildpackage and have it use "pbuilder-karmic".. any quick suggestions?
[20:32] <warner> do I need a "pdebuild-karmic" first?
[20:34] <zooko> lamalex: I'm sorry, I don't know how to do that.
[20:34] <lamalex> k, no problem
[20:34] <lamalex> is there anyone here who knows about disutils and i18n?
[20:35] <james_w> RainCT: "E: libcwiimote-0.4: ldconfig-symlink-missing-for-shlib usr/lib/libcwiimote-0.4.so usr/lib/libcwiimote.so.0.4.0 libcwiimote-0.4.so"
[20:35] <Daviey> slytherin: do you mean the rdepends of libdirac0c2a ?
[20:35] <slytherin> yes
[20:35] <james_w> RainCT: that's a new one on me :-)
[20:36] <Daviey> slytherin: well libdirac-dev will satisfy itself, surely?
[20:36] <RainCT> james_w: yeah asked before about that one and nobody answered :/
[20:36] <Daviey> slytherin: and ogmrip-dirac i'm not sure on.
[20:36] <slytherin> have you checked that?
[20:36] <james_w> RainCT: lintian says it's a certain error
[20:36] <RainCT> james_w: but at least the package isn't dropping it's header files directly into /usr/include now :P
[20:36] <james_w> RainCT: it doesn't tell me what the three arguments are though
[20:37] <Daviey> slytherin: Well libdirac-dev will be rebuilt, also rebuilding libdirac0c2a - surely?
[20:37] <james_w> "$link_file $shlib_file $SONAME{$shlib_file}"
[20:38] <slytherin> Daviey: Debian has libdirac-decoder0 and libdirac-encoder0. They should be drop in replacement for libdirac0c2a, but someone must check.
[20:39] <Daviey> slytherin: try to sync it locally and see what goes bang?
[20:39] <james_w> objdump -x usr/lib/libcwiimote.so.0.4.0 | grep SONAME
[20:39] <james_w>   SONAME      libcwiimote-0.4.so
[20:39] <james_w> RainCT: ^
[20:39] <james_w> so the package name is correct, but the link is wrong
[20:39] <RainCT> james_w: ?
[20:39] <james_w> it's usually the other way around
[20:40] <james_w> it's expecting usr/lib/libcwiimote-0.4.so because the soname includes -0.4
[20:40] <slytherin> Daviey: Also we already have schroedinger plugin for gstreamer (using libschroedinger) in default install. Even VLC uses libschroedinger. So I don't see much value in syncing this library without a proper transition plan for rdepends.
[20:40] <james_w> but as the library name doesn't include -0.4 I think it's just broked
[20:40] <RainCT> james_w: Ah. So the file needs to be renamed?
[20:40] <james_w> I *think* so
[20:41] <james_w> does anything build against it?
[20:41] <openQRM> mathiaz: on looking into it if i can do anything to fix it fast. Would it help to have a new package uploaded for reviewing again later ?
[20:41] <RainCT> james_w: Yeah. I tried with wiipresent, builds fine
[20:41] <mathiaz> openQRM: I'm reviewing it for now.
[20:42]  * warner builds a new python-zfec package. Sometimes pbuilder hates me.
[20:42] <Daviey> slytherin: Would it be better to just decline it and wait for karmic+1?
[20:42] <mathiaz> openQRM: we'll probably have to fix a bunch of stuff later
[20:42] <james_w> RainCT: how does it pick up the -l or whatever to link? pkgconfig?
[20:42] <mathiaz> openQRM: I'm looking if it would be accepted in karmic
[20:42] <RainCT> james_w: LDFLAGS just has "-lcwiimote"
[20:42] <openQRM> mathiaz: ok, I am here to do anything i can to get it in a good stage. Just worried about the deadline
[20:43] <james_w> RainCT: ok
[20:43] <james_w> RainCT: that should be -lcwiimote-0.4
[20:43] <james_w> so I guess broken is better here?
[20:43] <slytherin> Daviey: Right. I just also noticed that the upstream version in Debian and Ubuntu is same.
[20:43] <mathiaz> openQRM: thanks for sticking around - I'll do my best to find the best option/compromise
[20:43] <slytherin> so we are not really misisng anything.
[20:43] <Daviey> slytherin: yeah.. it's justthe packaging variance.
[20:43] <openQRM> mathiaz: you are welcome, thanks for all your time and effort !
[20:44] <RainCT> james_w: works as well with -lcwiimote-0.4
[20:44] <slytherin> Daviey: you can even chase it after FF. Since there is no difference in upstream version.
[20:44] <Daviey> slytherin: great.. no worries then
[20:44] <Daviey> slytherin: What about the other bug, would you mind looking at that?
[20:44] <james_w> RainCT: ok, this is beyond my knowledge level unfortunately
[20:44] <Daviey> (new to Ubuntu sync)
[20:45] <slytherin> Daviey: I am working on a merge, if I find after that, sure. It looks harmless to me.
[20:45] <Daviey> slytherin: appreciated.
[20:45] <openQRM> mathiaz: what about having /usr/share/openqrm/plugins|tftpboot|web in /var/lib/openqrm/* backlinked to origin ? That would result in a writeable base-dir, right ?
[20:46] <RainCT> james_w: so can this just get in and be fixed later? (/me is hoping for the guy who has an ITP for Debian to take it and fix that :P)
[20:46] <mathiaz> openQRM: What's left in /usr/share/openqrm then?
[20:46] <openQRM> mathiaz: eh, nothing expect sym links
[20:46] <james_w> RainCT: I guess so
[20:47] <james_w> I think I might leave it in the queue
[20:48] <slytherin> Daviey: By the way, never mark sync packages as confirmed. That is job of the sponsors team.
[20:48] <Daviey> slytherin: noted.
[20:49] <openQRM> mathiaz: sorry, was wrong, left over is bin, include, sbin, and var (which is just includes a sym link to /var/spool/openqrm)
[20:49] <openQRM> mathiaz: anyway the 3 dirs (tftpboot, plugins and web) are the dirs which includes files openQRM likes to write to
[20:49] <warner> gyah, I flubbed that last package..
[20:50] <mathiaz> openQRM: tftpboot and web should be moved to /var/lib/openqrm
[20:51] <mathiaz> openQRM: it seems that plugins contains a standard structure as well
[20:51] <openQRM> mathiaz: ... and each plugin has a web dir it may want to put hook files in it
[20:51] <warner> should I replace the -0ubuntu2 version that I just uploaded to REVU with an -0ubuntu3 version, or replace it with a (different -0ubuntu2) version?
[20:51] <RainCT> warner: replace it with an -0ubuntu1 version
[20:52] <warner> RainCT: ok
[20:52] <boomer> RainCT: thanks for reviewing gnome-video-arcade. i fixed the lintian error and warnings and reuploaded.
[20:52] <slytherin> Daviey: updated dirac bug with whatever we discussed plus a few more notes.
[20:54] <mathiaz> openQRM: IIUC there is some code in plugins/ - so that should not be in /var/lib/
[20:54] <RoAkSoAx> anyone willing to advocating http://revu.ubuntuwire.com/p/lekhonee please?
[20:54] <mathiaz> openQRM: usually packages should be overwritte files in /var/lib/
[20:54] <mathiaz> openQRM: as /var/lib/: State information is data that programs modify while they run, and that pertains to one specific host.
[20:55] <mathiaz> openQRM: usually packages should *not* overwrite files in /var/lib/
[20:55] <mathiaz> openQRM: so I don't think that putting plugins in /var/lib/ would solve the problem
[20:55] <mathiaz> openQRM: I meant /var/lib/openqrm/
[20:56] <openQRM> mathiaz: mhmmm, ok, what do you suggest ? (pls take your time, working already on the tftpboot + web dir changes)
[20:56] <mathiaz> openQRM: great - tftpboot is definetly worth working on.
[20:56] <mathiaz> openQRM: I'll come back to you about the plugins.
[20:57] <openQRM> mathiaz: :) cool, thank you so much
[20:57] <RainCT> james_w: renamign the file to -0.4.so gets ride of the warning
[20:57] <RainCT> *renaming
[20:57] <mathiaz> openQRM: I've successfully install openqrm in a test vm - so I have a better understanding of how things are laid out
[20:57] <warner> RainCT: ok, new zfec (-0ubuntu1) package is uploaded to revu, fixing the issues you raised
[20:57] <james_w> RainCT: but I think the .so.4.0.0 or whatever should be similarly renamed as well
[20:58] <openQRM> mathiaz: great to hear man
[20:58] <RainCT> james_w: yeah that's the file I'm talking about
[20:58] <mathiaz> openQRM: /var/spool/openqrm is rwxrwxrwx - why?
[20:59] <openQRM> mathiaz: to allow the webserver to put commands in the queue
[20:59] <mathiaz> openQRM: wait for working on moving web to /var/lib/openqrm
[20:59] <openQRM> mathias: ok
[21:00] <openQRM> mathiaz: ok
[21:00] <prefrontal> would someone be so kind as to review http://revu.ubuntuwire.com/p/libquarter0
[21:00] <mathiaz> openQRM: what is the role of openqrm-client.tgz in web/boot-service?
[21:01] <mathiaz> openQRM: is this host dependant?
[21:01] <mathiaz> openQRM: it seems that web/boot-service/openqrm-server-public-rsa-key is host dependent - and should be moved to /var/lib/ or /etc/
[21:01] <openQRM> mathiaz: arch dependent, servers managed by openQRM will download this file according their arch
[21:02] <mathiaz> openQRM: hm - I don't an i386 file there
[21:02] <openQRM> mathiaz: the plublic rsa key is needed in web/boot-servcie because the servers will download this and allow openQRM access
[21:02] <openQRM> mathiaz: right, for now we build with one arch client only
[21:03] <lfaraone> What's the proper way to make a change to a configuration file owned by another package? Example, a package I'm working on, "rainbow", modified /etc/nsswitch.conf injecting itself before "compat".
[21:03] <lfaraone> #debian-mentors said "don't do that", but unless I do that my package won't work OOTB.
[21:04] <warner> so, would it be easier (at this stage of the FF) to get the debian pycryptopp package synced into karmic, or to get a new independent pycryptopp package advocated-for in the REVU system?
[21:04] <slytherin> warner: sync would be easier
[21:05] <lfaraone> warner: Sync, unless you expect to make changes to the package.
[21:05] <mathiaz> openQRM: what's the role of web/action/image-auth/?
[21:05] <lfaraone> warner: with sync, it doesn't need approval by ftpmasters or manual checking by MOTU, since we assume it's "malware-free" from debian.
[21:05] <warner> I don't expect any changes, but debian currently has 0.5.14, and the main package we're trying to get into karmic (tahoe) requires 0.5.15
[21:05] <mathiaz> openQRM: I'm currently looking at web/ and see what should be  moved out of /usr to /var/lib/ or /etc
[21:05] <openQRM> openQRM puts crypted passwords in there which are used to set the password on the managed servers
[21:06] <warner> one option is to have the tahoe .diff.gz downgrade that requirement
[21:06] <slytherin> warner: revu is not the place for new versions.
[21:06] <warner> another is to get the debian version updated, then sync to ubuntu
[21:06] <warner> a third is to sync to ubuntu and then get it updated
[21:06] <warner> a fourth is to sync to ubuntu and then modify the tahoe .diff.gz to downgrade the requirement
[21:07] <mathiaz> openQRM: ok - so for web/ it seems that only web/boot-service/openqrm-server-public-rsa-key should be put in /etc/openqrm
[21:07] <mathiaz> openQRM: symlinking is fine
[21:07] <mathiaz> openQRM: as this is host specific
[21:07] <slytherin> warner: I would prefer 'update debian version and then sync to ubuntu with proper FFE'.
[21:07] <lfaraone> by the way, does anybody have time to sponsor a new upstream version of mine? bug 419344
[21:08] <mathiaz> openQRM: all the rest is code which is part of the package and thus should be overwritten on package upgrades.
[21:08] <warner> slytherin: thanks. I assume that sync-to-ubuntu is not likely to happen after the freeze?
[21:09] <openQRM> mathiaz: ok, that means web can stay as is but just moving the rsa key + symlink ?
[21:09] <mathiaz> openQRM: yes
[21:09] <RainCT> james_w: so, should I upload the fix as -0ubuntu2 or will you reject and I upload as ubuntu1 again?
[21:09] <slytherin> warner: FFE is feature freeze exception. If you can convince the respective release teams that there is strong reason for new version to be in Ubuntu then it can happen.
[21:09] <mathiaz> openQRM: and what is the purpose of web/action/image-auth/?
[21:09] <openQRM> mathiaz: ok, good, working on the fixes. Do you want me to upload a new package when it ready ?
[21:09] <warner> slytherin: cool, thanks for the info
[21:10] <openQRM> openQRM puts crypted passwords in there which are used to set the password on the managed servers
[21:10] <james_w> RainCT: -0ubuntu1 is gone
[21:10] <mathiaz> openQRM: once I have finished the review yes.
[21:10] <james_w> RainCT: any upload would have to be -0ubuntu2 whether or not I reject
[21:10] <slytherin> warner: if the package is in universe then motu-release team approves FFE. If it is in main then ubunut-release.
[21:10] <openQRM> mathiaz: ok, great + thx
[21:11] <mathiaz> openQRM: crypted passwords? Will this be site specific?
[21:11] <mathiaz> openQRM: and automatically generated during the operation of openqrm?
[21:12] <mathiaz> openQRM: if so, it should go in /var/lib/
[21:12] <openQRM> mathiaz: yes, if people are using the "set-password" option in openQRM this dir will be used
[21:12] <mathiaz> openQRM: ok - so it should go in /var/lib/openqrm/
[21:12] <openQRM> mathiaz: ok
[21:12] <slytherin> Daviey: is there any quick test for flvstreamer?
[21:13] <warner> slytherin: thanks!
[21:14] <RainCT> james_w: OK, uploaded
[21:15] <Daviey> slytherin: If you are in the UK, get-iplayer
[21:15] <mathiaz> openQRM: web/base/.htpasswd is world writable - you probably don't want that
[21:15] <slytherin> Daviey: I am not. Any other test.
[21:16] <openQRM> mathiaz: must b write able for the webserver to add/remove users
[21:16] <Daviey> slytherin: That is the only app i know of that currently uses it.
[21:16] <mathiaz> openQRM: hm - fair enough
[21:16] <Daviey> slytherin: I'll ping someone who might know.
[21:18] <mathiaz> jdstrand: kees: ^^ how would handle an .htpasswd file where users can be created from the web site?
[21:18] <RainCT> OK, I'm off unless there's something else
[21:18] <RainCT> Got bored and the laptop is running out of power :). Cya
[21:19] <warner_afk> RainCT: if you're interesting in tahoe, you might review it
[21:19] <slytherin> Daviey: Never mind. Package builds fine in pbuilder. So acked the sync. whether it gets synced or not depends on how loaded archive team is.
[21:19] <warner_afk> we've got one advocate so far, but a second wouldn't hurt :)
[21:19] <prefrontal> sry my last link was wrong. could someone please review: http://revu.ubuntuwire.com/p/libquarter
[21:19] <RainCT> warner_afk: nah I'm too lazy to upload yet another package now :P
[21:19] <prefrontal> greatly appreciated
[21:20] <warner_afk> RainCT: righto :)
[21:20] <Daviey> slytherin: thanks!
[21:20] <mathiaz> openQRM: AFAICT there aren't any plugins that require write access to /usr/share/openqrm/ in the openqrm package
[21:21] <mathiaz> openQRM: as there isn't any world writable directory/file under web/
[21:21] <mathiaz> openQRM: except for the ones we've already discussed
[21:22] <openQRM> mathiaz: ok
[21:24] <openQRM> mathiaz: sorry, but plugins creating files withing their web dir
[21:24] <mathiaz> openQRM: which one?
[21:24] <openQRM> different ones, depends on the plugin
[21:24] <mathiaz> openQRM: ok - I've just installed openqrm for now
[21:25] <openQRM> mostly statfiles which are then parsed and its content is displayed in the ui
[21:25] <mathiaz> openQRM: I'll get to openqrm-plugins laters
[21:30] <guardian> hello
[21:30] <guardian> someone here might have the necessary autoconf knowledge and help me please
[21:31] <guardian> on a 32 bit machine, is possible to use --build or --host options to build a 64bit version of a library?, so that -m64 is inserted in CFLAGS
[21:31] <guardian> or should i rather do something like make CC="gcc -m64" or else
[21:33] <mathiaz> openQRM: I don't see any world writable directory in /usr/share/openqrm/web/ after having openqrm-plugins installed
[21:34] <openQRM> mathiaz: the dirs are being created by commands from the command queue when you are using functionality from the plugins
[21:35] <openQRM> mathias: files then will be created in the web dir of the plugins and read by the webserver
[21:49] <jdstrand> mathiaz: that is a very complex question and would require in depth knowledge of the application. .htpasswd implies somewhere in the web root. That sounds risky. better a separate file for this application outside of the webroot or use non htpasswd
[21:49] <jdstrand> mathiaz: that's my drive-by opinion
[21:52] <mathiaz> jdstrand: great - thanks
[21:53] <binarymutant> how come songbird isn't in the repos?
[21:53] <ScottK> I'm guessing the usual reason.
[21:54] <binarymutant> was it license problems?
[21:54] <stevi> hello
[21:55] <stevi> can you tell me what's exactly the deadline for new programs in karmic?
[21:55] <james_w> about 3 hours
[21:55] <stevi> oh
[21:56] <stevi> thx
[21:56] <james_w> binarymutant: the first reason is that it requires a patched xulrunner or similar
[21:57] <binarymutant> james_w, does it? it works will on karmic :/
[22:01] <RoAkSoAx> anyone willing to advocate http://revu.ubuntuwire.com/p/lekhonee please?
[22:01] <mathiaz> openQRM: hm - ok. Could be fixed later then
[22:05] <mathiaz> openQRM: so I've got 3 points (already discussed):
[22:06] <mathiaz> openQRM: 1. tftpboot moved /var/lib/openqrm/
[22:06] <openQRM> mathiaz: ok, just let me quick summarize to not forget something, web will stay in /usr/share/openqrm, image-auth will move to /var/lib/openqrm/*, tftpboot will move to /var/lib/openqrm/*, .htpasswd will also move to /var/lib/openqrm/*, plugsins stay in /usr/share/openqrm and the public-rsa key will move to /etc/openqrm/dropbear, right ?
[22:06] <mathiaz> openQRM: yes
[22:07] <openQRM> mathiaz: ok, working full steam on the fixes, need to quickly re-test them. should i then upload a new package ?
[22:07] <mathiaz> openQRM: yes - please do so.
[22:08] <openQRM> mathiaz: ok, great, will do asap, thanks a lot again man
[22:12] <zooko> Howdy, iulian.
[22:13] <iulian> Hello zooko.
[22:14] <zooko> How are you today?
[22:15] <iulian> zooko: Tired.  I've just got back home.
[22:17] <zooko> From work?
[22:17] <ScottK> RoAkSoAx: Looking at it.
[22:17] <iulian> zooko: I see that kirkland advocated tahoe-lafs but the other three dependencies need to be uploaded as well.  I'm afraid I cannot review all of them today.
[22:17] <iulian> zooko: From pub.
[22:18] <zooko> iulian: ah.  :-)
[22:19] <zooko> iulian: Actually RainCT reviewed zfec already.
[22:19] <zooko> And pycryptopp which is already in Debian is sufficient if we can get that pycryptopp synced to Ubuntu.
[22:19] <zooko> That just leaves one that you could review, which I would be grateful for.
[22:20] <iulian> zooko: That would be foolscap?
[22:20] <iulian> Is it uploaded to REVU?
[22:20] <zooko> Yes.
[22:20] <zooko> http://revu.ubuntuwire.com/p/foolscap
[22:21] <zooko> Actually foolscap-0.3.2 is already in Ubuntu.  What Tahoe-LAFS needs is just an upgrade to foolscap-0.4.2, the current release version.
[22:21] <RoAkSoAx> ScottK, awesome, thanks :)
[22:21] <zooko> (And a sync of pycryptopp-0.5.14 from Debian to Ubuntu.)
[22:21] <iulian> zooko: Ah, then just file a bug against foolscap and attach diff.gz.
[22:21] <ScottK> I considered packaging that several months ago an never had time to do it.
[22:23] <zooko> iulian: excuse my ignorance, but what .diff.gz?  The one that Brian has built, here: http://revu.ubuntuwire.com/revu1-incoming/foolscap-0908252208/foolscap_0.4.2-1.diff.gz ?
[22:23] <iulian> zooko: That should work.
[22:29] <jtimberman> Should I be setting 'needs-packaging' tickets I opened as 'Fix released' for the packages that are accepted?
[22:31] <simon-o> Hi, when I want to request a merge which depends on another package being merged first (which I also requested), how do I mark that in the bug?
[22:32] <ScottK> RoAkSoAx: Uploaded.  Thank you for your contribution to Ubuntu.  I did slightly change your patch and debian/changelog.  Please now work with Debian PAPT to get it into Debian.
[22:32] <RoAkSoAx> ScottK, awesome, Thanks a lot :)
[22:33] <blizzkid> lo all, anyone here that is on planet.ubuntu and would like to do me a big favor please?
[22:34] <ScottK> RoAkSoAx: If you need help on PAPT, pochu or POX_ can help you.
[22:34] <POX_> and DktrKranz
[22:35] <POX_> and many others
[22:35] <RoAkSoAx> ScottK, thanks for the tip. I'll poke them sometime this week :)
[22:35] <zooko> iulian: like this?  https://bugs.launchpad.net/ubuntu/+source/foolscap/+bug/419510
[22:36] <zooko> Greetings, POX_.
[22:36] <prefrontal> is launchpad fundamentally incompatible with packages that use OpenGL?
[22:36] <prefrontal> PPA i mean
[22:37] <prefrontal> it won't build.. I thought these were real virtual machines, but they apparently are impoverished virtual machines
[22:37] <prefrontal> anyone know about this?
[22:38]  * RoAkSoAx away went to have dinner
[22:38] <iulian> zooko: Yes.
[22:38] <RoAkSoAx> ups
[22:39] <pwnguin> prefrontal: you have a PPA that is running openGL as part of the build process/
[22:39] <pwnguin> ?
[22:40] <ScottK> PPA questions are probably better in #launchpad.
[22:40] <prefrontal> no, but my package depends on QtOpenGL, which in turn doesn't work unless opengl is actually working
[22:41] <pwnguin> by "Actually working" do you mean "has nvidia headers"?
[22:41] <prefrontal> possibly yes, i don't think the mesagl is going to work
[22:41] <prefrontal> but i don't want to depend on nvidia headers.. although i could?
[22:41] <prefrontal> i have no experience with those pkgs
[22:42] <pwnguin> for reasons unknown to me, nvidia packages sometimes provide a GL.h
[22:42] <pwnguin> my memory is fuzzy
[22:44] <pwnguin> its possible the build scripts have an accidental build dep on the way nvidia installs things
[22:44] <prefrontal> here's the thing, libqt4-dev appears to have everything you need. it gets you the mesagl-dev guys, and the libqtopengl-dev guy, but actually trying to link against those in the ppa virtual machine doesn't work
[22:44] <pwnguin> prefrontal: have you tried a local pbuilder?
[22:44] <prefrontal> and, it works from my virtual machine which is a completely fresh karmic install with no video drivers
[22:44] <prefrontal> yes, it fails in local pbuilder as well.
[22:45] <prefrontal> (i'm now using vmware for testing)
[22:57] <c_korn> does anyone know why there is only the remuco-server in karmic but not the client? http://packages.ubuntu.com/source/karmic/remuco-server
[23:00] <openQRM> mathiaz: yo, implemented the fixes as discussed, tested them, working fine for me. New package uploaded. Enjoy and please keep me updated
[23:00] <mathiaz> openQRM: cool - I'll review the new package in a few
[23:01] <openQRM> mathiaz: Great man, looking forward for your comments ;) .... getting a beer now, brb
[23:06] <iulian> zooko: tahoe-lafs requires the latest version of pycryptopp (0.5.16).  Sid only has 0.5.14.  You need to update it as well.
[23:06] <iulian> zfec has just been uploaded to NEW btw.
[23:07] <zooko> iulian: Whoo!  Thanks!
[23:08] <iulian> zooko: But looking at debian bug #542878 it seems that tahoe-lafs requires 0.5.15.
[23:10] <zooko> iulian: so, POX is upgrading pycryptopp in Debian, which is good, and also warner might upload a new Tahoe-LAFS package which specifies that pycryptopp >= 0.5.14 is good enough (which it is).
[23:12] <iulian> zooko: OK.  I am revuing tahoe-lafs now.
[23:12] <zooko> iulian: great!
[23:21] <prefrontal> this is illegal to have in my debian/rules file under clean? is there a way to do it? clean:\n\t if [[ -e CMakeCache.txt ]]; then rm CMakeCache.txt; fi
[23:23] <Laney> try [[ -e xxx ]] && rm ...
[23:24] <prefrontal> rm -f!
[23:24] <Laney> works too
[23:24] <prefrontal> tx;)
[23:25] <iulian> zooko: tahoe-lafs advocated.
[23:26] <POX_> zooko: foolscap 0.4.2+dfsg-1 uploaded to unstable
[23:27] <iulian> Cool.
[23:27] <zooko> Whoohoo!
[23:29] <iulian> zooko: Could you please request a sync?
[23:33] <huats_> does anybody have an idea why .so in the  /usr/lib/pyshared/python-2.6/ are not taken into account by python ?
[23:34] <zooko> iulian: Hm, I added a comment to https://bugs.launchpad.net/foolscap/+bug/419510
[23:36] <POX> zooko: pycryptopp 0.5.15-1 uploaded to unstable. Save commands I gave you, I'll show you some more later (f.e. lintian) and we'll work together on next release
[23:37] <zooko> POX:will do
[23:37] <POX> zooko: about tahoe-lafs - it needs more work (some dependencies are not ready) - you know how picky I am ;P
[23:37]  * POX goes to bed
[23:38] <zooko> Good night!
[23:38] <POX> night
[23:39]  * SiDi needs someone to accept sponsoring the new exaile release for universe, please let me know if you wanna help
[23:54] <warner> iulian: so, if I created a ubuntu-ized .diff.gz for the debian foolscap and pycryptopp packages, would that make it easier for you (or someone else) to perform the necessary sync-to-ubuntu ?
[23:57] <iulian> warner: Please use 'requestsync' from ubuntu-dev-tools.  This tool does everything for you.
[23:57] <warner> ok, thanks
[23:58] <iulian> warner: When you're done please point me to the bug#.
[23:59] <iulian> I might ack them if I don't fall asleep.
[23:59]  * iulian yawns.
[23:59] <warner> I'm reading requestsync now.. it doesn't actually build anything, right? Can I run it from sid, or do I need to run it from a karmic chroot environment?
[23:59] <prefrontal> i am hoping to have the emergent neural network simulation system and libquarter which it depends on advocated and included in karmic.
[23:59] <prefrontal> i would really really appreciate if two motus could look at these packages, i am available to fix anything http://revu.ubuntuwire.com/p/emergent http://revu.ubuntuwire.com/p/libquarter
[23:59] <prefrontal> i've my own apt repo since hardy, i will always help maintain these packages
[23:59] <iulian> warner: It doesn't build anything.  It just creates the bug reports.