[00:04] bizarre bug: nspluginwrapper seems to interfere somehow with audio, causes flash to always use the wrong output === JanC_ is now known as JanC [01:58] What's the proper way to name a package pulled from a git repository? [02:01] ripps: Do you know with reasonable certainty what the next version of the package is when it's released. [02:02] ScottK: Yes, 0.18. === valles_ is now known as effie_jayx [02:03] ripps: I'd do 0.18~git090305-0ubuntu1 [02:03] The '~' means it's a lower version than 0.18 [02:03] ScottK: okay, I'll do that. [02:14] most examples of that use a full 4-digit year [02:15] 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] While I'm on the topic; what's the proper naming scheme for svn packages? [02:16] hi all [02:18] maxb: The only rule is to have a scheme that's monotomically increasing. [02:19] 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] ScottK: what do I name svn packages that haven't had an official release yet. [02:22] If you know what the first release will be numbered, then use the same scheme. [02:22] If not, I'd do 0-svn.... [02:23] hmm... okay [02:31] 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] Test building is a good habit to be in. [02:34] 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] Okay, how do I make pbuilder install a package from it's result directory install from the online repository? [02:35] directhex: note: just because 6stack-dig didn't work for your intrepid kernel doesn't mean it isn't in fact correct. [02:36] 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] directhex: (i.e., in -kmirror git HEAD, the relevant quirk is 6stack-dig) [02:37] i'll look through the codec output later and may have some suggestions for you with hda-verb [02:59] scottK is there a git or svn or cvs for clamav in alioth ?? [02:59] git === asac_ is now known as asac [02:59] so that's what we must use to jaunty ? [02:59] i mean for the 0.95 clamav for jaunty [03:18] 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] The or pbuilder login --save-after-logout and install them by hand. [03:21] The/That [03:50] is anyone going to update eclipse before release? Please? ;) [03:51] 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] That'd be progress. [03:52] Hobbsee: you could always touch eclipse [03:52] ajmitch: i'm trying to specifically *avoid* doing that. [03:52] & 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] wasn't jdong the last sucker to look at it? [03:54] pochu, mainly [03:55] he might be bribable. [03:56] or he may run a mile [03:56] think of the users, Hobbsee, you don't want to disappoint them... [03:56] in the case of eclipse, i'm a user, not a developer ;) [03:57] you could try & hunt down Koon [03:57] now there's an idea! [03:57] he does java stuff [03:58] ajmitch: It's Debian where you have to promise to care about the users. Here we just have to be nice. [03:59] OK [04:00] Note that there was some irony embedded in there. [04:00] Hard to tell [04:00] Mutually. [04:06] and yes, I think I was unfortunate enough to mention looking at eclipse :) [04:06] and I think I did mention I got scared away. [04:07] 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] maybe we should just have an eclipse-fugly-standalone build :) [04:08] jdong: You've confessed an interest, that's good enough for a TIL [04:11] haha [04:18] Anyone know what "distribution.canonical.bookmarksProcessed" in Firefox about:config is about? [04:18] Google confesses to know nothing about it. [05:06] Hey, can someone help me submit a request for backports? [05:16] Hi Zarel. Did you had a look at https://help.ubuntu.com/community/UbuntuBackports ? [05:19] fabrice_sp: yep, but it's not that clear. [05:20] Do you know how I can tell if Warzone is already in backports? [05:20] Zarel, you mean, the sync request from yesterday? [05:20] The sync request only covered jaunty, which isn't released yet. [05:21] no: you have to explicitly request it [05:21] Yeah, and I'm not sure how I'd go do that. [05:22] first, fill a bug report requesting the backport at https://launchpad.net/products/intrepid-backports/+filebug for Intrepid [05:23] Hmm, I might want to wait for 2.1.2 to be released first. [05:25] 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] 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] :/ I mean, they say _Debian_ is supposed to be slow... [05:27] It's just weird that you would release a beta version, and not update to the stable because of stringent update requirements... [05:28] Zarel, I can take care of that. Don't worry. Anyway, we upgrade each 6 months [05:29] I you can point me very severe bugs that makes the beta version unusable, I could ty to process a SRU [05:29] (Stable Release Update), otherwise it's easier with a ppa or a backport request [05:29] There aren't any severe bugs that I know of. [05:29] Yeah, I'm thinking backports might be better. [05:29] so ppa [05:30] Well, anything. You're probably better at this than I have. [05:30] it's still building, but if it builds fine, I'll upload it to my ppa [05:30] Once you have that ready, do you have a set of instructions I can tell users? [05:30] yes. It's like using an 'extra' repository [05:31] https://launchpad.net/~fabricesp/+archive/ppa [05:31] (just the link to the ppa. It's not yet published :-) ) [05:34] is this package new in jaunty? [05:34] Define "new" [05:34] I mean, the current version was only added a day or two ago. [05:34] But Warzone's been in Ubuntu for years. [05:34] JanC, no. It's just an upgrade to a stable version [05:35] since gutsy, at least (with version 2.1.0~0.svn1436-1) [05:36] ah, currently I see 2.1.1 in the repository, no mentioning of "beta" ? [05:36] warzone2100 2.1.1-1 still building... [05:36] JanC: That's in Jaunty. Intrepid has 2.1-beta4 [05:36] http://packages.ubuntu.com/search?searchon=names&keywords=warzone2100 [05:37] 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] Zarel: oh, right, then a backport would be useful maybe [05:38] 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] or if that's not allowed, a package in a PPA ;) [05:39] That's apparently what people are doing now. [05:39] 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] 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] It fixes a moderately important bug - crashes in multiplayer games larger than 6 players. [05:40] Zarel, if it's a bug fixing only, and Debian package it, yes [05:40] ok then [05:40] 2.1.1 done building? [05:40] and we can even apply the fix directly in the actual version and sync later [05:41] not yet... [05:41] Zarel, if you have proof about maintaining stability, it might be useful to provide that to fabrice_sp [05:42] I'll upload it to my ppa and see what happen [05:42] JanC: "Maintaining"? You imply Warzone was stable in the first place. :P [05:43] Zarel: I mean, if new versions have no regressions... [05:43] Does a developer saying "I'm pretty sure there are no new regressions" count? [05:43] e.g. if you have strong regression tests... ;) [05:43] Well, I just played half an hour yesterday, and didn't find problems ;-) [05:44] lol [05:44] I don't think so Zarel [05:44] :-) [05:44] Nope, but all our users say 2.1.1 is much stabler than 2.1-beta4. Does that count? [05:44] I mean, all our users other than Ubuntu users who don't build from source are using 2.1.1... [05:46] well, then a PPA build is probable good enough... [05:47] I would say, for a backport, it's not a problem [05:47] 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] yes [05:47] I already backport some programs, even mupen64plus :-) [05:48] (in my ppa, I mean) === rgreening_ is now known as rgreening [05:49] * fabrice_sp shouldn't be building 3 programs at the same time ... [05:53] :P [05:54] The weird thing about Ubuntu is that it doesn't report versions at all. [05:54] "Add/Remove Applications" isn't telling me which version of Warzone it has available. >_< [05:54] what do you mean? [05:54] That's actually one of my biggest gripes with Ubuntu. It's hard to find the version of anything. [05:55] 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] you have it in zynaptic or with a apt-cache policy warzone2100 command [05:56] synaptic [05:56] in bug reports, that's generally what I request: output of 'apt-cache policy ' to know the version [05:58] That's silly. I have to drop down to command-line just to figure out what version I'm installing? [05:58] synaptic, then [05:58] system/admin/package management [06:06] * fabrice_sp already uploaded half of the source code of warzone to his ppa [06:21] Zarel, warzone2100 2.1.1 is built in my ppa for amd64 and lpia for Intrepid. i386 still building [06:23] good morning [06:29] Hey dholbach ! Good morning ;-) [06:30] hiya fabrice_sp [06:30] it has been a long time :-) [06:30] since when? :) [06:31] since I saw you at that time :-) [06:31] 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] 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] CU [06:34] fabrice_sp: it was REALLY cold and they got quite a bit of snow :) [06:34] yeah :-) good walk! [06:34] when I came back to Berlin yesterday I was greeted by -8°C -> 12°C :-) [06:34] thanks - brb [06:35] lol [07:32] 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] dpkg-deb: subprocess paste killed by signal (Broken pipe) [07:48] 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] bug 338607 [08:09] Launchpad bug 338607 in xulrunner-1.9 "dpkg: error processing /var/cache/apt/archives/xulrunner-1.9_1.9.0.7+nobinonly-0ubuntu1_amd64.deb (--unpack)" [Undecided,New] https://launchpad.net/bugs/338607 [08:14] good morning! [08:18] Morning Toadstool. [08:19] hello jpds [10:04] hi folks [10:06] hello sistpoty|work [10:06] hi directhex [10:07] 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] debdiff from previous upstream? i always hated those, but seems easiest [10:09] directhex: do you need sponsorship? if yes then diff.gz. [10:09] slytherin, and orig? [10:09] directhex, orig can be gotten with uscan, right? [10:10] persia, with get-orig-source ideally, but yes [10:10] Does uupdate do get-orig-source? [10:10] nah, gotta go through that pain manually. just finished though [10:11] not THAT much pain given i started when sistpoty|work said hi ;) [10:11] 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] directhex: ideally get-orig-source should call uscan [10:13] slytherin, looks like this particular package IS a simple uscan-based one. some are a lot more complex though due to repackaging [10:14] Well, some people use uscan to repackage. It can do basic things like .bz2 -> .gz and .zip -> .gz [10:14] 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] you know, that's not a half bad idea. whose work is uscan? [10:16] 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] 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] 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] my most obscene get-orig-source by FAR is ikvm [10:20] 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] okay then, u-u-s subscribed to bug #338665 - anything visibly done wrong? [10:21] Launchpad bug 338665 in moon "New upstream bugfix release: 1.0.1" [Undecided,New] https://launchpad.net/bugs/338665 === ogra_ is now known as ogra === korn_ is now known as c_korn [10:56] directhex: by the way, forgot to tell you. ikvm fails even basic swing test. :-) [10:56] slytherin, it runs hello world! :p [10:56] slytherin, i know, it's useless for gui things, the code's marked "proof of concept" for a reason [10:56] :-) [10:57] i'm pleased that swing hello world works ^_^ [10:57] i did some testing a few days ago [10:58] 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] 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] persia, there are packages with far fewer users in the archive [11:00] persia, mostly i find it both a technically fascinating app, and a packaging challenge [11:00] Precisely why you're the best maintainer :) [11:01] persia, i'm wondering if there's any value in other Iron* type packages, e.g. ironscheme & ironruby & ironlisp [11:01] directhex: no swing hello world does not work. But in any case I am not bothered with that as much. [11:01] slytherin, worked for me :/ [11:01] directhex, Not to me, but if you find them interesting, by all means... [11:02] directhex: I will send you the program I used tonight. [11:02] 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] is the config.log of a build that failed available somewhere? [11:09] nay! [11:14] c_korn: no. you need to cat it in rules so it appears in the build log [11:15] meow [11:15] morning Laney! [11:15] howdy compadre [11:16] geser: ok, but the configure fails so the cat would never be executed [11:17] you can set up a pbuilder hook to drop you into a shell after build failures [11:17] c_korn, ./configure || cat config.log [11:18] 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] no [11:19] the only arch i even got qemu to work with was arch [11:19] which package is this? [11:19] https://launchpad.net/ubuntu/jaunty/+source/scilab/5.1-0ubuntu2 [11:19] scilab [11:19] c_korn: you can't figure out the reason for failure from LP's build log? [11:20] Sylvestre (maintainer of scilab) requested the config.log [11:21] c_korn, Just insert cat config.log after the ./configure call in debian/rules [11:21] ebay + second hand mac. best way. [11:21] is it mandatory that scilab builds on all archs? [11:21] no. [11:22] ok so the official build machines are the only which can build for those archs? [11:22] yup [11:22] then scilab had to be reuploaded only to get the config.log [11:23] it is not worth it, is it? [11:24] c_korn: the build failure looks familiar. Let me take a look [11:26] hm, jni woe [11:26] yay for JNI [11:31] without JNI, mono wouldn't exist [11:34] 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] pmjdebruijn, why not? [11:37] directhex: what does JNI have to do with Mono? [11:37] directhex: it possibly related to ikvm [11:37] but not to Mono itself [11:38] 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] pmjdebruijn, if JNI wasn't an irredeemable pile of shit, there'd be no .net (or mono by extension) [11:39] directhex: if you put it like that [11:51] 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? === orly_owl_ is now known as orlyowl === orlyowl is now known as orly_owl [12:03] * persia seeks the typo, and retracts the query [12:23] how does a package appear on merge-o-matic? [12:24] is powerpc considered 64 bit arch? [12:25] slytherin: The G5 is 64 bit but normally you run a 32 bit user space with select 64 bit applications/libs [12:25] ok [12:26] hyperair: when debian package is updated and last version in ubuntu is -nubuntux. [12:26] And merge-o-matic is running, and the package isn't in the blacklist [12:26] slytherin: it's automatic? [12:26] hmm i guess i'll just wait for banshee to appear then. i think it just got uploaded [12:27] c_korn: I give up. Looking at the configure script gives no idea about build failure. [12:28] slytherin: http://pastebin.com/d61eb934 [12:29] c_korn: so you found the solution? [12:29] no, sylvestre then asked for the config.log [12:30] 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] c_korn: you can patch m4/java.m4 around line 412 [12:36] c_korn: I think the LDFLAGS passed to configure script are not used at all. hence this problem. [12:37] what is significance of LD_LIBRARY_PATH ? [12:51] slytherin: I don't know. sylvestre has to take a look at it [13:19] 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] *? [13:20] 4 source packages? [13:20] geser: yes. [13:21] if you want credits for the uploads then provide debdiffs :) else tell me the package names and I'll look at it [13:23] geser: kk. [13:37] geser: odd, I don't see where in the package it depends on python 2.6... [13:38] geser: ( https://edge.launchpad.net/ubuntu/+source/sugar-datastore/0.83.2-0ubuntu1 ) [13:39] it probably just needs a rebuild to get updated dependencies [13:40] geser: ah. [13:40] geser: while I'm at it I'm going to import a new upstream version. [13:40] 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] you know that we are in FF and you need an exception if it's not a bugfix release? [13:41] in that case it's ok [13:42] geser: goody. [13:42] lfaraone: so I should leave bug 338626 for you? [13:42] Launchpad bug 338626 in sugar-datastore "[jaunty] python-olpc-datastore: Depends: python (< 2.6)" [Undecided,New] https://launchpad.net/bugs/338626 [13:42] geser: yeah. [13:43] I've just uploaded a rebuild for sugar-toolkit [13:44] elmargol: sorry, no idea about that [13:47] geser: there were bugfixes to *all* of those packages :) [14:10] hey dholbach, thanks for the publication :) [14:11] didrocks: sure :) [14:23] dholbach, ping [14:23] hggdh: pong [14:24] 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] hmm i thought there was a featurefreeze? [14:25] hggdh: let's take this to #ubuntu-desktop [14:26] hyperair: we are, it's needed for something in evolution [14:26] aah i see [14:26] it is a pre-req for a new plugin [14:33] I'm Looking for advocating for my package at http://revu.ubuntuwire.com/details.py?package=sqliteman [14:35] can somebody explain me what this does? i am new to building packages http://paste.ubuntu.com/127249/ [14:37] hi mterry, hi bdrung [14:37] hiya bfiller [14:37] dholbach: wassup [14:38] bfiller: I'm tired - and catching up with mountains of email [14:38] bfiller: how are you? [14:38] :) [14:38] dholbach: I bet you are, sorry I didn't see you guys off on Weds [14:39] dholbach: jet lag is difficult (: [14:39] don't worry, I'm sure you were busy as always - it was great meeting you [14:45] dholbach: Hello! [14:45] dholbach: Did you guys have an awesome sprint? [14:47] mterry: absolutely - lots to talk about, but also lots of stuff that got done - so I'm happy [14:47] as much as like hanging out with all you guys I look forward to this WE too :-) [14:48] dholbach: :) [14:54] siretart: what do you think about getting xine-lib updated? (FF bug #329572) [14:54] Launchpad bug 329572 in xine-lib "[jaunty] Please merge xine-lib 1.1.16.2 from debian sid" [Undecided,New] https://launchpad.net/bugs/329572 [14:56] siretart: oh, it's in main... so not motu-release duty :) [14:56] sistpoty|work: in any case that merge would be a very good idea, IMO [14:56] :) [14:57] sistpoty|work: btw, didn't we agree at some point that minor upstream release do not need an freeze exception? [14:57] siretart: yep, bugfix only versions don't need a FFe [14:58] 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] this is clearly a bugfix only release [14:59] it seems nixternal is already working on that. less work for me :-) [14:59] heh [15:00] 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] Launchpad bug 338392 in python-support "Creates uninstallable packages on jaunty when only python 2.5 is wanted" [Undecided,New] https://launchpad.net/bugs/338392 [15:00] jcfp: It's better to figure out why it expanded that way and fix it. [15:03] I have no clue whatsoever why it comes up with the python (<< 2.6) part, the rest seems fine [15:04] Did you try it with Deiban's pysupport? [15:05] ScottK: how? by building in debian sid? [15:05] Install the Debian pysupport in your Ubuntu pbuilder [15:05] Since Debian doesn't have 2.6, no way to check there. [15:07] scottK does debian has already a clamav 0.95rc package or we need to start testing the rdpends with our own ? [15:07] They don't have it packaged yet. [15:07] I haven't had time to look into how hard it would be. [15:08] scottK ok I'll start checking that package just to start the engines with the rdepends .. [15:08] ScottK: how do I add debian packages to a jaunty pbuilder? [15:09] jcfp: Use pbuilder login then inside the chroot grab the source, build it, and install it. [15:09] tx on it [15:09] 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] ScottK: use the one from unstable or experimental? [15:11] I'd try both. [15:25] sistpoty|work: oh [15:26] nixternal: are you actually working on bug 329572? [15:26] Launchpad bug 329572 in xine-lib "[jaunty] Please merge xine-lib 1.1.16.2 from debian sid" [Undecided,New] https://launchpad.net/bugs/329572 === JanC_ is now known as JanC [15:38] 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 === azeem_ is now known as azeem [15:51] sistpoty|work: anything else required on bug 334813? [15:51] Launchpad bug 334813 in evolution-rss "installing evolution-rss removes evolution" [Undecided,Confirmed] https://launchpad.net/bugs/334813 [16:01] Heya gang [16:04] dholbach: nope, seb granted the FFe [16:04] hi bddebian [16:04] Heya sistpoty|work [16:05] sistpoty|work: gracias [16:05] dholbach: you're welcome ;) [16:13] siretart: that would be a no [16:13] I am not working on the xinelib bug [16:15] nixternal: okay, I'll steal that bug then from you [16:15] roger that === ubott2 is now known as ubottu [16:48] python-awn-extras needs rebuild [16:49] * RainCT does it [16:52] ah, it's blocking on avant-window-navigator being built [17:09] in deb scripts i find the command "p". what does it do? [17:22] DrHalan: can you put it on a pastebin? [17:22] DrHalan: isn't 'p' a predefined function in the same script? [17:24] pmjdebruijn: oh osrry i think there was a c missing and "cp" was meant [17:27] still i cant execute this line but it seems fine "cp -r * ../" === dblick is now known as blick === blick is now known as dblick [18:12] 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? === jussio1 is now known as jussi01 === pochu_ is now known as pochu [19:12] 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? === Mez_ is now known as Mez [19:27] Hello. The ipod-convenience package really should not require the gtkpod and the amarok packages. [19:27] I can't find a reason. [19:27] It is just extra unnecessary software. === paul_ is now known as Elbrus [19:42] directhex: I just found BeginInvoke/EndInvoke. It's like a kid in a candy store all over again. === santiago-pgsql is now known as santiago-ve [19:57] huhu sistpoty :D [19:57] sebner: you here?! :P [19:57] * hanska runs [19:59] 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] hi sebner [20:09] sebner: how's the army? when will you'll be a civilian again? ;) [20:11] sistpoty: 4 months :( but my chances to get a nice job in ~1 month (office job ..) aren't that bad [20:11] 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] sebner: don't you like the field? ;) [20:11] sebner: well, then get that job ;) [20:12] sistpoty: I hope so :P [20:12] pochu: nahh, too dirty :P [20:13] AnAnt: does dkms support custom build kernels? [20:14] sistpoty: dunno, I think superm1 can better answer this question [20:14] sure why not [20:14] as long as the headers are in place [20:14] RainCT: hi, submitted the debdiff for hardy right now [20:15] AnAnt: then I guess supporting only one system can be better tested than two independent module building systems? [20:15] RainCT: i'm looking for new bitesize/s bugs.. .or should i do another thing? [20:16] fix miro for me :( [20:19] Laney: point me bug number [20:19] and i'll have a look :) [20:19] sistpoty: yup [20:19] goshawk: haha, it's a difficult ftbfs [20:19] try and build miro out of jaunty and you'll see [20:20] 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] aha, bad commit in the past... /me cleans up [20:37] 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] sistpoty: 1.0.1 or 1.1.1? [20:41] bddebian: 1.1.1 [20:41] bddebian: i.e. your last upload to unstable ;) [20:42] eeks 1.1.1 should be going to experimental [20:42] 1.0.1 should be in unstable === hggdh_ is now known as hggdh [20:44] bddebian: maybe I've misread the changes entry, that was just what i recalled right now [20:45] bddebian: indeed, 1.1.1 is in new/experimental [20:46]