[00:04] <directhex> bizarre bug: nspluginwrapper seems to interfere somehow with audio, causes flash to always use the wrong output
[01:58] <ripps> What's the proper way to name a package pulled from a git repository?
[02:01] <ScottK> ripps: Do you know with reasonable certainty what the next version of the package is when it's released.
[02:02] <ripps> ScottK: Yes, 0.18.
[02:03] <ScottK> ripps: I'd do 0.18~git090305-0ubuntu1
[02:03] <ScottK> The '~' means it's a lower version than 0.18
[02:03] <ripps> ScottK: okay, I'll do that.
[02:14] <maxb> most examples of that use a full 4-digit year
[02:15] <maxb> Though I accept that if 0.18 hasn't been released by 2100, we're unlikely to care about the package any longer :-)
[02:16] <ripps> While I'm on the topic; what's the proper naming scheme for svn packages?
[02:16] <itachi> hi all
[02:18] <ScottK> maxb: The only rule is to have a scheme that's monotomically increasing.
[02:19] <ScottK> ripps: svn you can do either by date or by committ.  I prefer by committ because it's very easy to find where the snapshot was taken from in the svn.
[02:21] <ripps> ScottK: what do I name svn packages that haven't had an official release yet.
[02:22] <ScottK> If you know what the first release will be numbered, then use the same scheme.
[02:22] <ScottK> If not, I'd do 0-svn....
[02:23] <ripps> hmm... okay
[02:31] <ripps> I've gotten into the habit of building all my test packages with pdebuild using cowdancer. It allows me to make sure that the package will easily compile in PPA.
[02:32] <ScottK> Test building is a good habit to be in.
[02:34] <ripps> I'm trying to get GMPC working with plugins. I've built a bunch of plugins in my PPA, but some of the one's that fetch data online make gmpc crash. I filed a bug report with the maintainer and he said to try the git. So I'm building a git version of gmpc to see if it works.
[02:35] <ripps> Okay, how do I make pbuilder install a package from it's result directory install from the online repository?
[02:35] <dtchen> directhex: note: just because 6stack-dig didn't work for your intrepid kernel doesn't mean it isn't in fact correct.
[02:36] <ripps> I need an updated version of libmpd, I've built it using pdebuild, now I need pdebuild to use that very package to build gmpc.
[02:36] <dtchen> directhex: (i.e., in -kmirror git HEAD, the relevant quirk is 6stack-dig)
[02:37] <dtchen> i'll look through the codec output later and may have some suggestions for you with hda-verb
[02:59] <leonel> scottK is there a  git or svn or cvs  for  clamav in alioth ??
[02:59] <ScottK> git
[02:59] <leonel> so that's what we must  use to jaunty ?
[02:59] <leonel> i mean for the  0.95 clamav for jaunty
[03:18] <maxb> ripps: For that to happen, the packages you build using pbuilder need to go into an apt repository that pbuilder is configured to read from
[03:21] <ScottK> The or pbuilder login --save-after-logout and install them by hand.
[03:21] <ScottK> The/That
[03:50] <Hobbsee> is anyone going to update eclipse before release?  Please?  ;)
[03:51] <ScottK> Hobbsee: That's what everyone says and no one is willing to do.
[03:51]  * ScottK will be glad to vote for an FFe.
[03:51]  * Hobbsee wonders how people could be persuaded
[03:51]  * ScottK couldn't be.
[03:51]  * Hobbsee found a patch to let a slightly newer version build, in launchpad, but it's sitll .2 versions old
[03:51]  * ScottK has touched it before when he was younger and way less experienced.
[03:52] <ScottK> That'd be progress.
[03:52] <ajmitch> Hobbsee: you could always touch eclipse
[03:52] <Hobbsee> ajmitch: i'm trying to specifically *avoid* doing that.
[03:52] <ajmitch> & then everyone else could disavow all knowledge of it for future releases!
[03:52]  * Hobbsee just went the "grab the tarball from the eclipse site" method
[03:53] <ajmitch> wasn't jdong the last sucker to look at it?
[03:54] <Hobbsee> pochu, mainly
[03:55] <Hobbsee> he might be bribable.
[03:56] <ajmitch> or he may run a mile
[03:56] <ajmitch> think of the users, Hobbsee, you don't want to disappoint them...
[03:56] <Hobbsee> in the case of eclipse, i'm a user, not a developer ;)
[03:57] <ajmitch> you could try & hunt down Koon
[03:57] <Hobbsee> now there's an idea!
[03:57] <ajmitch> he does java stuff
[03:58] <ScottK> ajmitch: It's Debian where you have to promise to care about the users.  Here we just have to be nice.
[03:59] <ajmitch> OK
[04:00] <ScottK> Note that there was some irony embedded in there.
[04:00] <ajmitch> Hard to tell
[04:00] <ScottK> Mutually.
[04:06] <jdong> and yes, I think I was unfortunate enough to mention looking at eclipse :)
[04:06] <jdong> and I think I did mention I got scared away.
[04:07] <jdong> the we we've got it all intertwining with the other eclipse-y things it provides other than the Java IDE just scares me :)
[04:07] <jdong> maybe we should just have an eclipse-fugly-standalone build :)
[04:08] <ajmitch> jdong: You've confessed an interest, that's good enough for a TIL
[04:11] <jdong> haha
[04:18] <ScottK> Anyone know what "distribution.canonical.bookmarksProcessed" in Firefox about:config is about?
[04:18] <ScottK> Google confesses to know nothing about it.
[05:06] <Zarel> Hey, can someone help me submit a request for backports?
[05:16] <fabrice_sp> Hi Zarel. Did you had a look at https://help.ubuntu.com/community/UbuntuBackports ?
[05:19] <Zarel> fabrice_sp: yep, but it's not that clear.
[05:20] <Zarel> Do you know how I can tell if Warzone is already in backports?
[05:20] <fabrice_sp> Zarel, you mean, the sync request from yesterday?
[05:20] <Zarel> The sync request only covered jaunty, which isn't released yet.
[05:21] <fabrice_sp> no: you have to explicitly request it
[05:21] <Zarel> Yeah, and I'm not sure how I'd go do that.
[05:22] <fabrice_sp> first, fill a bug report requesting the backport at https://launchpad.net/products/intrepid-backports/+filebug for Intrepid
[05:23] <Zarel> Hmm, I might want to wait for 2.1.2 to be released first.
[05:25] <fabrice_sp> Why not. Anyway, if the version in Jaunty compile as-is in Intrepid, I could upload it to my ppa
[05:25]  * fabrice_sp is building warzone2100 2.1.1 in an Intrepid schroot to check
[05:26] <Zarel> I don't know much about that. I'm a Windows developer. I'm mainly here because many of our users are complaining about how hard it is to get an up-to-date version of Warzone.
[05:26] <Zarel> :/ I mean, they say _Debian_ is supposed to be slow...
[05:27] <Zarel> It's just weird that you would release a beta version, and not update to the stable because of stringent update requirements...
[05:28] <fabrice_sp> Zarel, I can take care of that. Don't worry. Anyway, we upgrade each 6 months
[05:29] <fabrice_sp> I you can point me very severe bugs that makes the beta version unusable, I could ty to process a SRU
[05:29] <fabrice_sp> (Stable Release Update), otherwise it's easier with a ppa or a backport request
[05:29] <Zarel> There aren't any severe bugs that I know of.
[05:29] <Zarel> Yeah, I'm thinking backports might be better.
[05:29] <fabrice_sp> so ppa
[05:30] <Zarel> Well, anything. You're probably better at this than I have.
[05:30] <fabrice_sp> it's still building, but if it builds fine, I'll upload it to my ppa
[05:30] <Zarel> Once you have that ready, do you have a set of instructions I can tell users?
[05:30] <fabrice_sp> yes. It's like using an 'extra' repository
[05:31] <fabrice_sp> https://launchpad.net/~fabricesp/+archive/ppa
[05:31] <fabrice_sp> (just the link to the ppa. It's not yet published :-) )
[05:34] <JanC> is this package new in jaunty?
[05:34] <Zarel> Define "new"
[05:34] <Zarel> I mean, the current version was only added a day or two ago.
[05:34] <Zarel> But Warzone's been in Ubuntu for years.
[05:34] <fabrice_sp> JanC, no. It's just an upgrade to a stable version
[05:35] <fabrice_sp> since gutsy, at least (with version 2.1.0~0.svn1436-1)
[05:36] <JanC> ah, currently I see 2.1.1 in the repository, no mentioning of "beta" ?
[05:36] <fabrice_sp> warzone2100 2.1.1-1 still building...
[05:36] <Zarel> JanC: That's in Jaunty. Intrepid has 2.1-beta4
[05:36] <fabrice_sp> http://packages.ubuntu.com/search?searchon=names&keywords=warzone2100
[05:37] <Zarel> I'm not sure why Ubuntu's policies are stringent enough that betas can't be updated to finals, yet lax enough for a pre-alpha build to be included with gutsy/hardy.
[05:37] <JanC> Zarel: oh, right, then a backport would be useful maybe
[05:38] <Zarel> I mean, Warzone _does_ have a reputation for having trunk stabler than the latest stable most of the time, but it still seems weird.
[05:38] <JanC> or if that's not allowed, a package in a PPA  ;)
[05:39] <Zarel> That's apparently what people are doing now.
[05:39] <Zarel> Hmm. I estimate 2.1.2 is going to be released in a week. Do you think that's soon enough to make it into Jaunty?
[05:40] <fabrice_sp> Zarel, but most of packages are not, and sometime, it's worst: the first stable release is not stable either, and you have to wait until stable.1 to have a real stable version
[05:40] <Zarel> It fixes a moderately important bug - crashes in multiplayer games larger than 6 players.
[05:40] <fabrice_sp> Zarel, if it's a bug fixing only, and Debian package it, yes
[05:40] <fabrice_sp> ok then
[05:40] <Zarel> 2.1.1 done building?
[05:40] <fabrice_sp> and we can even apply the fix directly in the actual version and sync later
[05:41] <fabrice_sp> not yet...
[05:41] <JanC> Zarel, if you have proof about maintaining stability, it might be useful to provide that to fabrice_sp
[05:42] <fabrice_sp> I'll upload it to my ppa and see what happen
[05:42] <Zarel> JanC: "Maintaining"? You imply Warzone was stable in the first place. :P
[05:43] <JanC> Zarel: I mean, if new versions have no regressions...
[05:43] <Zarel> Does a developer saying "I'm pretty sure there are no new regressions" count?
[05:43] <JanC> e.g. if you have strong regression tests...  ;)
[05:43] <fabrice_sp> Well, I just played half an hour yesterday, and didn't find problems ;-)
[05:44] <fabrice_sp> lol
[05:44] <fabrice_sp> I don't think so Zarel
[05:44] <fabrice_sp> :-)
[05:44] <Zarel> Nope, but all our users say 2.1.1 is much stabler than 2.1-beta4. Does that count?
[05:44] <Zarel> I mean, all our users other than Ubuntu users who don't build from source are using 2.1.1...
[05:46] <JanC> well, then a PPA build is probable good enough...
[05:47] <fabrice_sp> I would say, for a backport, it's not a problem
[05:47] <fabrice_sp> but actually, the team a long queue to process, so that's why a ppa is quicker, if you find someone to process it :-)
[05:47] <fabrice_sp> yes
[05:47] <fabrice_sp> I already backport some programs, even mupen64plus :-)
[05:48] <fabrice_sp> (in my ppa, I mean)
[05:49]  * fabrice_sp shouldn't be building 3 programs at the same time ...
[05:53] <Zarel> :P
[05:54] <Zarel> The weird thing about Ubuntu is that it doesn't report versions at all.
[05:54] <Zarel> "Add/Remove Applications" isn't telling me which version of Warzone it has available. >_<
[05:54] <fabrice_sp> what do you mean?
[05:54] <Zarel> That's actually one of my biggest gripes with Ubuntu. It's hard to find the version of anything.
[05:55] <Zarel> You know the "Add/Remove Applications" thing? Some sort of GUI for apt. It doesn't report which version of Warzone it has.
[05:55] <fabrice_sp> you have it in zynaptic or with  a apt-cache policy warzone2100 command
[05:56] <fabrice_sp> synaptic
[05:56] <fabrice_sp> in bug reports, that's generally what I request: output of 'apt-cache policy <package>' to know the version
[05:58] <Zarel> That's silly. I have to drop down to command-line just to figure out what version I'm installing?
[05:58] <fabrice_sp> synaptic, then
[05:58] <fabrice_sp> system/admin/package management
[06:06]  * fabrice_sp already uploaded half of the source code of warzone to his ppa
[06:21] <fabrice_sp> Zarel, warzone2100 2.1.1 is built in my ppa for amd64 and lpia for Intrepid. i386 still building
[06:23] <dholbach> good morning
[06:29] <fabrice_sp> Hey dholbach ! Good morning ;-)
[06:30] <dholbach> hiya fabrice_sp
[06:30] <fabrice_sp> it has been a long time :-)
[06:30] <dholbach> since when? :)
[06:31] <fabrice_sp> since I saw you at that time :-)
[06:31] <dholbach> ah, yes - I was in Boston from Monday to Wednesday - just came back to Europe yesterday :)
[06:34]  * dholbach takes the dog for a walk, brb
[06:34] <fabrice_sp> Ohh. not too cold there? Some of my colleagues at work are working there and thy told me it was -16ºC yesterday :-/
[06:34] <fabrice_sp> CU
[06:34] <dholbach> fabrice_sp: it was REALLY cold and they got quite a bit of snow :)
[06:34] <fabrice_sp> yeah :-) good walk!
[06:34] <dholbach> when I came back to Berlin yesterday I was greeted by -8°C -> 12°C :-)
[06:34] <dholbach> thanks - brb
[06:35] <fabrice_sp> lol
[07:32] <savvas> does anyone know if localisation for gdebi is stripped from the package? I was wondering how does it get in language-pack-xx-base package and installed in /usr/share/locale-langpack ... http://tinyurl.com/av2vtr
[07:48] <savvas> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[07:48] <savvas> dpkg: error processing /var/cache/apt/archives/xulrunner-1.9_1.9.0.7+nobinonly-0ubuntu1_amd64.deb (--unpack): short read in buffer_copy (backend dpkg-deb during `./usr/lib/xulrunner-1.9.0.7/libxul.so')
[08:09] <savvas> bug 338607
[08:14] <Toadstool> good morning!
[08:18] <jpds> Morning Toadstool.
[08:19] <Toadstool> hello jpds
[10:04] <sistpoty|work> hi folks
[10:06] <directhex> hello sistpoty|work
[10:06] <sistpoty|work> hi directhex
[10:07] <directhex> hm, what's the easiest way to update a package with a bugfix release which needs nothing more than "uupdate" running on it?
[10:07] <directhex> debdiff from previous upstream? i always hated those, but seems easiest
[10:09] <slytherin> directhex: do you need sponsorship? if yes then diff.gz.
[10:09] <directhex> slytherin, and orig?
[10:09] <persia> directhex, orig can be gotten with uscan, right?
[10:10] <directhex> persia, with get-orig-source ideally, but yes
[10:10] <persia> Does uupdate do get-orig-source?
[10:10] <directhex> nah, gotta go through that pain manually. just finished though
[10:11] <directhex> not THAT much pain given i started when sistpoty|work said hi ;)
[10:11] <persia> Then, right.  Your sponsor can use the get-orig-source rule to get the orig, and then match that with your diff.gz, and upload.
[10:12] <slytherin> directhex: ideally get-orig-source should call uscan <appropriate options>
[10:13] <directhex> slytherin, looks like this particular package IS a simple uscan-based one. some are a lot more complex though due to repackaging
[10:14] <persia> Well, some people use uscan to repackage.  It can do basic things like .bz2 -> .gz and .zip -> .gz
[10:14] <persia> For extra points, someone ought define a syntax for watch files that removes files during repackaging, and a patch to uscan to support that, and submit to Debian.
[10:16] <directhex> you know, that's not a half bad idea. whose work is uscan?
[10:16] <slytherin> persia: In some of the java packages, I have seen a separate script orig-tar.sh which is then mentioned in the watch file
[10:17] <persia> slytherin, Indeed.  I spent some time arguing against people doing that on Debian lists, but apparently not everyone believes they know make well enough to do it cleanly (even when I presented examples, some of the examples were used to refine the shell-based orig-tar.sh scripts).
[10:18] <persia> I still think it's better to do it in get-orig-source (without a shell script), and would be nice if uscan could handle simple file deletion, but I'm not going to argue about it anymore for a while.
[10:19] <directhex> my most obscene get-orig-source by FAR is ikvm
[10:20] <directhex> but my repackaged ikvm appears to be made of awesome - builds on at least 4 more arches than it used to as per https://buildd.debian.org/pkg.cgi?pkg=ikvm
[10:21] <directhex> okay then, u-u-s subscribed to bug #338665 - anything visibly done wrong?
[10:56] <slytherin> directhex: by the way, forgot to tell you. ikvm fails even basic swing test. :-)
[10:56] <directhex> slytherin, it runs hello world! :p
[10:56] <directhex> slytherin, i know, it's useless for gui things, the code's marked "proof of concept" for a reason
[10:56] <slytherin> :-)
[10:57] <directhex> i'm pleased that swing hello world works ^_^
[10:57] <directhex> i did some testing a few days ago
[10:58] <directhex> slytherin, one thing you might notice, though, is the number of arches for pre/post directhex packagin on http://packages.debian.org/search?keywords=libikvm-native
[10:59] <persia> directhex, You're clearly the best maintainer for that, although I suspect you won't be surprised if you don't have that many users
[11:00] <directhex> persia, there are packages with far fewer users in the archive
[11:00] <directhex> persia, mostly i find it both a technically fascinating app, and a packaging challenge
[11:00] <persia> Precisely why you're the best maintainer :)
[11:01] <directhex> persia, i'm wondering if there's any value in other Iron* type packages, e.g. ironscheme & ironruby & ironlisp
[11:01] <slytherin> directhex: no swing hello world does not work. But in any case I am not bothered with that as much.
[11:01] <directhex> slytherin, worked for me :/
[11:01] <persia> directhex, Not to me, but if you find them interesting, by all means...
[11:02] <slytherin> directhex: I will send you the program I used tonight.
[11:02] <directhex> slytherin, go ahead!
[11:04] <_ruben> man .. if only i had known dkms was in fact so damn easy (especially compared to m-a)
[11:07] <c_korn> is the config.log of a build that failed available somewhere?
[11:09] <directhex> nay!
[11:14] <geser> c_korn: no. you need to cat it in rules so it appears in the build log
[11:15] <Laney> meow
[11:15] <directhex> morning Laney!
[11:15] <Laney> howdy compadre
[11:16] <c_korn> geser: ok, but the configure fails so the cat would never be executed
[11:17] <Laney> you can set up a pbuilder hook to drop you into a shell after build failures
[11:17] <directhex> c_korn, ./configure || cat config.log
[11:18] <c_korn> btw. it only fails on some archs like powerpc. can PPAs build for those archs? otherwise I don't know how to test
[11:19] <directhex> no
[11:19] <directhex> the only arch i even got qemu to work with was arch
[11:19] <directhex> which package is this?
[11:19] <c_korn> https://launchpad.net/ubuntu/jaunty/+source/scilab/5.1-0ubuntu2
[11:19] <c_korn> scilab
[11:19] <slytherin> c_korn: you can't figure out the reason for failure from LP's build log?
[11:20] <c_korn> Sylvestre (maintainer of scilab) requested the config.log
[11:21] <persia> c_korn, Just insert cat config.log after the ./configure call in debian/rules
[11:21] <directhex> ebay + second hand mac. best way.
[11:21] <c_korn> is it mandatory that scilab builds on all archs?
[11:21] <directhex> no.
[11:22] <c_korn> ok so the official build machines are the only which can build for those archs?
[11:22] <directhex> yup
[11:22] <c_korn> then scilab had to be reuploaded only to get the config.log
[11:23] <c_korn> it is not worth it, is it?
[11:24] <slytherin> c_korn: the build failure looks familiar. Let me take a look
[11:26] <directhex> hm, jni woe
[11:26] <directhex> yay for JNI
[11:31] <directhex> without JNI, mono wouldn't exist
[11:34] <pmjdebruijn> directhex: that's doesn't make sense to me?
[11:35] <_ruben> i wonder if there's any source packages that result in a binary package (userland) and a dkms package (kernelland) .. couldnt find any atleast
[11:35] <directhex> pmjdebruijn, why not?
[11:37] <pmjdebruijn> directhex: what does JNI have to do with Mono?
[11:37] <pmjdebruijn> directhex: it possibly related to ikvm
[11:37] <pmjdebruijn> but not to Mono itself
[11:38] <directhex> pmjdebruijn, .net exists because microsoft were sued for creating their non-sun-compatible jvm (which had a non-crap JNI replacement), and they still wanted something damn close to java but with less lawsuits. mono appeared based on their EMCA specifications
[11:38] <directhex> pmjdebruijn, if JNI wasn't an irredeemable pile of shit, there'd be no .net (or mono by extension)
[11:39] <pmjdebruijn> directhex: if you put it like that
[11:51] <persia> Apparently 0.0~20080608-1ubuntu1 < 0.0~20080628-1 which is annoying.  Further, it appears that 0.0~20080628-2 is also less than 0.0~20080628-1.  Anyone have any suggestions on how to update this version?
[12:03]  * persia seeks the typo, and retracts the query
[12:23] <hyperair> how does a package appear on merge-o-matic?
[12:24] <slytherin> is powerpc considered 64 bit arch?
[12:25] <broonie> slytherin: The G5 is 64 bit but normally you run a 32 bit user space with select 64 bit applications/libs
[12:25] <slytherin> ok
[12:26] <slytherin> hyperair: when debian package is updated and last version in ubuntu is -nubuntux.
[12:26] <persia> And merge-o-matic is running, and the package isn't in the blacklist
[12:26] <hyperair> slytherin: it's automatic?
[12:26] <hyperair> hmm i guess i'll just wait for banshee to appear then. i think it just got uploaded
[12:27] <slytherin> c_korn: I give up. Looking at the configure script gives no idea about build failure.
[12:28] <c_korn> slytherin: http://pastebin.com/d61eb934
[12:29] <slytherin> c_korn: so you found the solution?
[12:29] <c_korn> no, sylvestre then asked for the config.log
[12:30] <elmargol> dholbach, do you know if there is a screencast how to do debian packaging using git? (I'm asking you since you did some screencasts about debian packaging)
[12:35] <slytherin> c_korn: you can patch m4/java.m4 around line 412
[12:36] <slytherin> c_korn: I think the LDFLAGS passed to configure script are not used at all. hence this problem.
[12:37] <slytherin> what is significance of LD_LIBRARY_PATH ?
[12:51] <c_korn> slytherin: I don't know. sylvestre has to take a look at it
[13:19] <lfaraone> I have a suite of packages (about 4) that need to have the python version bumped; do I have to make a debdiff for all of them>
[13:19] <lfaraone> *?
[13:20] <geser> 4 source packages?
[13:20] <lfaraone> geser: yes.
[13:21] <geser> if you want credits for the uploads then provide debdiffs :) else tell me the package names and I'll look at it
[13:23] <lfaraone> geser: kk.
[13:37] <lfaraone> geser: odd, I don't see where in the package it depends on python 2.6...
[13:38] <lfaraone> geser: ( https://edge.launchpad.net/ubuntu/+source/sugar-datastore/0.83.2-0ubuntu1 )
[13:39] <geser> it probably just needs a rebuild to get updated dependencies
[13:40] <lfaraone> geser: ah.
[13:40] <lfaraone> geser: while I'm at it I'm going to import a new upstream version.
[13:40] <lfaraone> geser: I assume it's OK since it's a bugfix release, before we were shipping an alpha. (upstream was in FF before we were)
[13:41] <geser> you know that we are in FF and you need an exception if it's not a bugfix release?
[13:41] <geser> in that case it's ok
[13:42] <lfaraone> geser: goody.
[13:42] <geser> lfaraone: so I should leave bug 338626 for you?
[13:42] <lfaraone> geser: yeah.
[13:43] <geser> I've just uploaded a rebuild for sugar-toolkit
[13:44] <dholbach> elmargol: sorry, no idea about that
[13:47] <lfaraone> geser: there were bugfixes to *all* of those packages :)
[14:10] <didrocks> hey dholbach, thanks for the publication :)
[14:11] <dholbach> didrocks: sure :)
[14:23] <hggdh> dholbach, ping
[14:23] <dholbach> hggdh: pong
[14:24] <hggdh> dholbach, could you please sponsor http://revu.ubuntuwire.org/p/libpst? Séb is quiite busy, and we have not had success on getting a MOTU to do so
[14:25] <hyperair> hmm i thought there was a featurefreeze?
[14:25] <dholbach> hggdh: let's take this to #ubuntu-desktop
[14:26] <dholbach> hyperair: we are, it's needed for something in evolution
[14:26] <hyperair> aah i see
[14:26] <hggdh> it is a pre-req for a new plugin
[14:33] <eMerzh> I'm Looking for advocating for my package at http://revu.ubuntuwire.com/details.py?package=sqliteman
[14:35] <DrHalan> can somebody explain me what this does? i am new to building packages http://paste.ubuntu.com/127249/
[14:37] <dholbach> hi mterry, hi bdrung
[14:37] <dholbach> hiya bfiller
[14:37] <bfiller> dholbach: wassup
[14:38] <dholbach> bfiller: I'm tired - and catching up with mountains of email
[14:38] <dholbach> bfiller: how are you?
[14:38] <dholbach> :)
[14:38] <bfiller> dholbach: I bet you are, sorry I didn't see you guys off on Weds
[14:39] <bfiller> dholbach: jet lag is difficult (:
[14:39] <dholbach> don't worry, I'm sure you were busy as always - it was great meeting you
[14:45] <mterry> dholbach: Hello!
[14:45] <mterry> dholbach: Did you guys have an awesome sprint?
[14:47] <dholbach> mterry: absolutely - lots to talk about, but also lots of stuff that got done - so I'm happy
[14:47] <dholbach> as much as like hanging out with all you guys I look forward to this WE too :-)
[14:48] <mterry> dholbach: :)
[14:54] <sistpoty|work> siretart: what do you think about getting xine-lib updated? (FF bug #329572)
[14:56] <sistpoty|work> siretart: oh, it's in main... so not motu-release duty :)
[14:56] <siretart> sistpoty|work: in any case that merge would be a very good idea, IMO
[14:56] <sistpoty|work> :)
[14:57] <siretart> sistpoty|work: btw, didn't we agree at some point that minor upstream release do not need an freeze exception?
[14:57] <sistpoty|work> siretart: yep, bugfix only versions don't need a FFe
[14:58] <sistpoty|work> siretart: I just thought I'd ask you, because you should know best about xine-lib before wondering myself if its a bugfix only (or if it makes sense in the first place) ;)
[14:58] <siretart> this is clearly a bugfix only release
[14:59] <siretart> it seems nixternal is already working on that. less work for me :-)
[14:59] <sistpoty|work> heh
[15:00] <jcfp> in case ${Python-Depends} expands to something unusable (see LP #338392), is it acceptable to set the dependencies manually as they should be?
[15:00] <ScottK> jcfp: It's better to figure out why it expanded that way and fix it.
[15:03] <jcfp> I have no clue whatsoever why it comes up with the python (<< 2.6) part, the rest seems fine
[15:04] <ScottK> Did you try it with Deiban's pysupport?
[15:05] <jcfp> ScottK: how? by building in debian sid?
[15:05] <ScottK> Install the Debian pysupport in your Ubuntu pbuilder
[15:05] <ScottK> Since Debian doesn't have 2.6, no way to check there.
[15:07] <leonel> scottK  does debian has already a  clamav 0.95rc package  or we need to  start testing  the  rdpends  with our own  ?
[15:07] <ScottK> They don't have it packaged yet.
[15:07] <ScottK> I haven't had time to look into how hard it would be.
[15:08] <leonel> scottK ok   I'll start  checking that package  just to start the engines with the rdepends ..
[15:08] <jcfp> ScottK: how do I add debian packages to a jaunty pbuilder?
[15:09] <ScottK> jcfp: Use pbuilder login then inside the chroot grab the source, build it, and install it.
[15:09] <jcfp> tx on it
[15:09] <sistpoty|work> siretart: oh, from the activity log of the xine-lib bug, someone else assigned nixternal... not too sure if that was on purpose
[15:11] <jcfp> ScottK: use the one from unstable or experimental?
[15:11] <ScottK> I'd try both.
[15:25] <siretart> sistpoty|work: oh
[15:26] <siretart> nixternal: are you actually working on bug 329572?
[15:38] <jcfp> ScottK: no difference with any of the debian python-support versions other than the version of the dependency on python-support itself; the weird python (<< 2.6) dep is still there.
[15:39]  * ScottK doesn't use python-support, so I'd suggest ask on #debian-python
[15:51] <dholbach> sistpoty|work: anything else required on bug 334813?
[16:01] <bddebian> Heya gang
[16:04] <sistpoty|work> dholbach: nope, seb granted the FFe
[16:04] <sistpoty|work> hi bddebian
[16:04] <bddebian> Heya sistpoty|work
[16:05] <dholbach> sistpoty|work: gracias
[16:05] <sistpoty|work> dholbach: you're welcome ;)
[16:13] <nixternal> siretart: that would be a no
[16:13] <nixternal> I am not working on the xinelib bug
[16:15] <siretart> nixternal: okay, I'll steal that bug then from you
[16:15] <nixternal> roger that
[16:48] <RainCT> python-awn-extras needs rebuild
[16:49]  * RainCT does it
[16:52] <RainCT> ah, it's blocking on avant-window-navigator being built
[17:09] <DrHalan> in deb scripts i find the command "p". what does it do?
[17:22] <pmjdebruijn> DrHalan: can you put it on a pastebin?
[17:22] <pmjdebruijn> DrHalan: isn't 'p' a predefined function in the same script?
[17:24] <DrHalan> pmjdebruijn: oh osrry i think there was a c missing and "cp" was meant
[17:27] <DrHalan> still i cant execute this line but it seems fine "cp -r * ../"
[18:12] <fabrice_sp> Hi. I fixed a FTBFS in a package but now, it's FTBFS because of the transition to python2.6. Where can I find instructions on what to do to do the transition?
[19:12] <maxb> Can anyone think of a convenient command to take a directory full of debs and classify them according to whether they belong to intrepid or jaunty?
[19:27] <amikrop> Hello. The ipod-convenience package really should not require the gtkpod and the amarok packages.
[19:27] <amikrop> I can't find a reason.
[19:27] <amikrop> It is just extra unnecessary software.
[19:42] <jdong> directhex: I just found BeginInvoke/EndInvoke. It's like a kid in a candy store all over again.
[19:57] <sebner> huhu sistpoty :D
[19:57] <hanska> sebner: you here?! :P
[19:57]  * hanska runs
[19:59] <fabrice_sp> Hi. setup.py is installing the python extension in usr/local/lib/python2.6/dist-packages for python2.6 but in usr/lib/python2.5/dist-packages for python2.5. What do I miss?
[20:08] <sistpoty> hi sebner
[20:09] <sistpoty> sebner: how's the army? when will you'll be a civilian again? ;)
[20:11] <sebner> sistpoty: 4 months :( but my chances to get a nice job in ~1 month (office job ..) aren't that bad
[20:11] <AnAnt> Hello, I have a question, I am maintaining sl-modem in Debian, which uses either DKMS or module-assistant to build its modules, the question is, when DKMS enters Debian (it has been in NEW & BYHAND for 2 weeks), won't it be better that I drop support for module-assistant ?
[20:11] <pochu> sebner: don't you like the field? ;)
[20:11] <sistpoty> sebner: well, then get that job ;)
[20:12] <sebner> sistpoty: I hope so :P
[20:12] <sebner> pochu: nahh, too dirty :P
[20:13] <sistpoty> AnAnt: does dkms support custom build kernels?
[20:14] <AnAnt> sistpoty: dunno, I think superm1  can better answer this question
[20:14] <superm1> sure why not
[20:14] <superm1> as long as the headers are in place
[20:14] <goshawk> RainCT: hi, submitted the debdiff for hardy right now
[20:15] <sistpoty> AnAnt: then I guess supporting only one system can be better tested than two independent module building systems?
[20:15] <goshawk> RainCT: i'm looking for new bitesize/s bugs.. .or should i do another thing?
[20:16] <Laney> fix miro for me :(
[20:19] <goshawk> Laney: point me bug number
[20:19] <goshawk> and i'll have a look :)
[20:19] <AnAnt> sistpoty: yup
[20:19] <Laney> goshawk: haha, it's a difficult ftbfs
[20:19] <Laney> try and build miro out of jaunty and you'll see
[20:20] <AnAnt> RainCT: http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard#Resistance_to_adoption
[20:22]  * sistpoty is confused about trigger in debian/games svn, because it contains *two* imo unreleased changelog entries
[20:24] <sistpoty> aha, bad commit in the past... /me cleans up
[20:37] <sistpoty> bddebian: happen to know if the new physfs is through binary new on all arches yet? (i.e. if not, should I add a versioned b-d for trigger on the new one?)
[20:40] <bddebian> sistpoty: 1.0.1 or 1.1.1?
[20:41] <sistpoty> bddebian: 1.1.1
[20:41] <sistpoty> bddebian: i.e. your last upload to unstable ;)
[20:42] <bddebian> eeks 1.1.1 should be going to experimental
[20:42] <bddebian> 1.0.1 should be in unstable
[20:44] <sistpoty> bddebian: maybe I've misread the changes entry, that was just what i recalled right now
[20:45] <sistpoty> bddebian: indeed, 1.1.1 is in new/experimental
[20:46] <bddebian> whew
[20:47] <sistpoty> bddebian: ok, then I guess my question is moot, since there's no soname bump involved?
[20:47] <bddebian> Not for 1.0.1 no, but there will be if I upload 1.1.1 to unstable :)
[20:47] <sistpoty> heh
[20:47] <sistpoty> thanks bddebian
[20:51] <sistpoty> bddebian: does an upload of trigger than make sense now? (it would need to go through binary new itself, since it changes package names from trigger to trigger-rally, trigger-data likewise)
[20:52] <bddebian> I'd like to get 1.1.1 in but I don't know about all the rdepends yet :(
[20:52] <bddebian> I have the same issue with asc right now
[20:56] <bddebian> sistpoty: Are you trying to do this for Jaunty?
[20:56] <sistpoty> bddebian: no, for unstable ;)
[20:57] <bddebian> Ah then if you could wait I'd appreciate it.  Even better if you could test with libphysfs-1.1.1 from experimental. ;-)
[20:57] <sistpoty> bddebian: actually, there aren't too many changes worth for jaunty, as the old package includes all upstream changes via patches :)
[20:57] <sistpoty> bddebian: sure, I'll try that.
[20:58] <bddebian> sweet, thanks
[21:02] <sistpoty> (/me will have to patch it upstream wise if it fails anyways, and I recall to have played with the physfs interaction in the past *g*)
[21:26] <RainCT> geser: I've given-back the failed builds of awn-extras-applets ;)
[21:30] <lfaraone> Is there a reason we don't ship the DoD root CA certs in Ubuntu?
[21:31] <ScottK> lfaraone: Does anyone?
[21:32] <ScottK> lfaraone: I can imagine that "Automatically trust US DoD" would not be considered a feature by some fraction of the user base.
[21:32] <sistpoty> bddebian: got a source package of 1.1.1 physfs? (or preferred binary packages for amd64)?
[21:33] <lfaraone> ScottK: well, if the DoD wanted to they could seize VeriSign's certs.
[21:34] <lfaraone> ScottK: and most likely prolly already have.
[21:34] <lfaraone> ScottK: I think Windows 7 might.
[21:34] <bddebian> sistpoty: I don't have a binary for amd64 as I don't have one sorry.  But here is a source package: http://people.debian.org/~pabs/tmp/debs/libphysfs_1.1.1-1.dsc
[21:37] <bddebian> It builds pretty quickly
[21:41] <sistpoty> thanks bddebian :)
[21:42] <bddebian> NP.  Gotta run, let me know how it goes. :)
[21:56] <dblick> If I want to install jaunty from a fresh install of intrepid on a VirtualBox image, what's the right way to start?  https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases is a little unclear on how to actually do an upgrade
[22:01] <sistpoty> dblick: I assume the best path is to first backup your image and then do a "sudo do-release-upgrade" (eventually changing /etc/apt/sources.list beforehand)
[22:01] <sistpoty> dblick: oh, and of course to cross finger for the latter part ;)
[22:03] <dblick> sistpoty, thanks, i didn't know about that command
[22:03]  * sistpoty admits that he looked it up himself
[22:49] <ianto> If I was in a team with a DD, if he were to upload to  Debian, would I be able to then make changes from his package and place that in Ubuntu when Debian & Ubuntu package merge or is that dealt with by an external person who has MOTU rights for example?
[22:50] <Laney> it would be no different from taking any other change from Debian
[22:50] <Laney> so yes, sync and merge would be available to you as normal
[22:50] <Laney> infact this is a fairly common thing
[22:51] <hanska> Laney knows it :P
[22:51] <hanska> Laney: ;)
[22:51] <Laney> \o/
[22:51] <Laney> working in Debian is clearly far better
[22:52] <hanska> Laney: eheh, remember who is +bugs :P
[22:52]  * hanska runs fast
[23:16] <dtchen> jcastro: are you noticing lower "cpu usage" with my PPA debs?
[23:17] <duairc> Would this be the right place to discuss the way a piece of software is packaged in Ubuntu and possibly suggest improvements?
[23:17] <duairc> Or seeing as the package(s) I have in mind come from Debian, would there be a better place to go?
[23:17] <dtchen> for source packages in Ubuntu universe and multiverse, yes.
[23:18] <RainCT> dtchen: contacting the Debian Maintainer would be better
[23:18] <dtchen> ^ duairc
[23:18] <duairc> RainCT: dtchen: Okay, thanks for that :)
[23:19] <RainCT> dtchen: err, sorry :)
[23:46] <ploum> Hello
[23:46] <ploum> Do you use some tool to format the changelog of your package?
[23:47] <ploum> I do it by hand and always forget to change the date
[23:47] <ploum> And I guess that the changelog file should become really long after some times
[23:47] <Laney> ploum: dch
[23:47] <Laney> in devscripts
[23:49] <ploum> Laney: thanks a lot !
[23:49] <ploum> it will help :-)
[23:50] <ploum> Is there a way to automatically take the upstream source changelog ?
[23:52] <sistpoty> ploum: you shouldn't do this... debian/changelog should describe mainly the changes to *packaging* (but of course you could highlights of new upstream features there as subitems of "new upstream release"
[23:53] <ploum> sistpoty: ok, thanks for the information
[23:53] <sistpoty> np ;)
[23:54]  * sistpoty goes to bed now... gn8 everyone