[00:57] <asomething> how would I pass --install-layout=deb in this rules file? http://paste.ubuntu.com/125541/
[01:00] <directhex> pass to what specifically?
[01:01] <james_w> asomething: does dh work for setup.py?
[01:01] <directhex> looks like a lot of unneeded rules in there to me
[01:01] <james_w> if so it probably needs to be patched
[01:02] <asomething> it's the rules file from deluge, which uses setup.py
[01:03] <directhex> at what point is setup.py used?
[01:03] <directhex> sorry, i don't know python at all
[01:05] <asomething> it's called by dh build
[01:06] <directhex> okay, got it
[01:06] <directhex> dget http://ftp.de.debian.org/debian/pool/main/w/wicd/wicd_1.5.9-3.dsc
[01:06] <directhex> then look at its debian/rules
[01:06] <james_w> asomething: it should be added to the "setup.py install" step
[01:06] <directhex> does exactly what you want - dh7 with setup.py mangling
[01:08] <asomething> thanks
[02:17] <leonel> what's used for  dget in dapper ??
[02:17] <leonel> get each file then dpkg-soruce ??
[02:17] <dtchen_> no, you can still dget some.dsc
[02:18] <dtchen_> just make sure devscripts is installed, as per Debian
[02:18] <leonel> ii  devscripts     2.9.10         Scripts to make the life of a Debian Package
[02:18] <leonel> leonel@dapper:~$ dget
[02:18] <leonel> -bash: dget: command not found
[02:19] <leonel> there's this note :  NOTE: dget is not included in the devscripts package for Ubuntu dapper.
[02:19] <leonel> in https://wiki.ubuntu.com/PbuilderHowto#Downloading Source Packages Using dget
[02:20] <dtchen_> you could manually backport devscripts.
[02:20] <leonel> dtchen_: thanks ..   just   wget the   orig.tar.gz  dsc and diff.gz  ..
[02:21] <ScottK> leonel: Did you see we did the Dapper clamav update today?
[02:31] <leonel> ScottK great news  ..  any test or package that needs  work ??
[02:32] <ScottK> leonel: No.  It's done and in dapper-backports.  Just waiting for rdepends to finish building now.
[02:32] <leonel> great ..
[02:43] <ScottK> james_w: Your most recent post on planet has me curious who the idiot was as I'm reasonably certain you aren't a crap maintainer.
[02:56] <leonel> scottK I'm working with  upstream and debian maintainers for   www.cherokee-project.org,   am I still on time to include the just released  0.99.2 version in  Jaunty ??   cherokee does not have  rdepends
[02:56] <ScottK> leonel: It needs an FFe.  Convince me.
[02:57] <leonel> ok .. I'll work on convince you ..
[02:58] <leonel> scottK I can do more   clamav  work ...
[02:58] <leonel> haha
[02:59] <ScottK> Great.  Go start porting stuff to 0.95.  The RC is out.
[02:59] <leonel> https://edge.launchpad.net/~cherokee-webserver/+archive/ppa   <-- this is the  PPA  for  cherokee ..
[03:00] <ScottK> I saw that.
[03:00] <leonel> scottK Ok  the 0.95 is for jaunty right ??
[03:00] <ScottK> leonel: Assuming we get the rdpends ported, yes.
[03:00] <ScottK> Then we get to start the backports dance all over.
[03:01] <leonel> scottK ok ..
[03:11] <ScottK> leonel: The link to common-licenses for GPL should link to GPL-2 since GPL may at some point point to another version and your package is GPL v2 only.
[03:32] <leonel> scottK thanks
[03:39] <leonel> scottK so  I'll work on https://wiki.ubuntu.com/FreezeExceptionProcess    for Cherokee to see if it can be included ??
[03:39] <ScottK> Yes.
[03:40] <ScottK> For server packages like this, I have delegated authority to approve them by myself.  No 2nd approval needed.
[03:41] <leonel> ScottK Great ..  so  I must to  clamav  prior  the FFe  ..  :(
[03:41] <leonel> jejeje
[03:41] <ScottK> No.
[03:41] <leonel>  s/so/to
[03:41] <leonel> so I can convice you  hehehe
[03:43] <leonel> let me get it packaged for  debian unstable  so it can be made a sync or merge ..
[05:45] <Laibsch> Hi, can somebody please rebuild python-4suite-xml, python-kaa-base and python-kaa-metadata against python 2.6 in Jaunty?
[05:45] <Laibsch> It is currently preventing some upgrades for me in Jaunty
[05:49] <anakron> Hi all
[05:49] <anakron> https://bugs.launchpad.net/ubuntu/+source/memaker/+bug/290531
[05:50] <anakron> someone can accept it?
[05:57] <Laibsch> done (as far as LP is concerned)
[06:12] <freeflying> how to use schroot with a encrypted home partition?
[07:08] <eMerzh> If a MOTU want to review my package that was waiting for too long in revu ( http://revu.ubuntuwire.com/details.py?package=sqliteman )
[08:13] <Toadstool> g'morning!
[08:29] <mok0> james_w: ping
[08:47] <billybigrigger> is there a process to request an app for packaging to be included into well KK i guess since jaunty is already at alpha 5? or is left up to me to test it out and package it myself if i want it in repos?
[08:48] <mok0> !revu
[08:48] <mok0> billybigrigger: ^
[08:49] <billybigrigger> thanks, but i havent packaged it
[08:49] <mok0> billybigrigger: ah, well... off you go :-P
[08:49] <billybigrigger> but what im asking is can end-users like myself package something and submit it somewhere for approval to be included?
[08:50] <billybigrigger> ahh
[08:50] <billybigrigger> answered my own question....
[08:50]  * billybigrigger continues to read the REVU wiki
[08:50] <mok0> billybigrigger: yes, you package it and upload to REVU
[08:53] <billybigrigger> is there any packaging guidelines i must follow?
[08:57] <mok0> billybigrigger: yes, there's a guide on the wiki
[08:57] <mok0> !packaging | billybigrigger
[09:33] <tarzeau> will jaunty sync once more from debian sid? or
[09:33] <tarzeau> is there someone syncing single packages manually? i have a bunch that i upgraded
[09:34] <StevenK> tarzeau: We don't automatically sync, and haven't for sometime.
[09:34] <StevenK> tarzeau: If you want packages sync'd, file a sync request.
[09:38] <tarzeau> StevenK: ok
[09:42] <directhex> NCommander, ever tried getting other arches going in qemu? i'm failing to get sparc or ppc to be useful
[09:43] <sistpoty|work> hi folks
[10:00] <james_w> mok0: pong
[10:16] <directhex> james_w, context for blog post?
[10:17] <james_w> directhex: debian-devel@
[10:17] <ogra> directhex, talk to ScriptRiper in #ubuntu-arm, he works on the suse build service ....
[10:17] <Laney> train internet is awful
[10:17] <ogra> *Ripper
[10:18] <Laney> ps afternoon all
[10:18] <directhex> ogra, i didn't think OBS did anything other than x86/amd64
[10:18] <directhex> Laney, yes, it is. relying on 3g mobile reception = suck
[10:18] <ogra> they do armel and ppc afaik
[10:18] <ogra> so at least for the ppc side he should be helpful
[10:19] <directhex> Laney, also, relying on $MOBILE_NETWORK's content filtering (orange think ubuntuforums is adult-only)
[10:19] <ogra> not sure about sparc
[10:19] <Laney> I know I wouldn't let my kids near there :(
[10:19] <directhex> Laney, they might get ideas about running arch!
[10:20] <Laney> gah
[10:20]  * Laney tries ssh -D
[10:25] <Laney> bah
[10:26] <directhex> james_w, any specific thread? i mainly read d-d@ to giggle at j00rg
[10:26] <savvas> "mobile-broadband-provider-info" couldn't you find a bigger name? :P
[10:27] <james_w> directhex: the manpages one
[10:41] <savvas> anyone working on mobile-broadband-provider-info?
[10:42] <savvas> could use some updating, I'll check
[10:44] <slytherin> savvas: IIRC #mbca is the channel.
[10:45] <savvas> oh thanks slytherin :)
[10:45] <directhex> tseliot, any major reason why uploading nvidia-graphics-drivers-180_180.35-0ubuntu1 to my intrepid ppa wouldn't work as a short-term fix?
[10:46] <tseliot> directhex: no, what's the problem?
[10:46] <tseliot> it should just work
[10:46] <directhex> tseliot, well, lack of support for my card in 180.11. i was just checking for hidden pitfalls
[10:46] <directhex> seems fine in a pbuilder
[10:47] <tseliot> directhex: yes, it should be ok
[10:48] <directhex> tseliot, can i do the same thing with the latest fglrx? i've got a 4870 i'm meant to benchmark
[10:48] <tseliot> directhex: I wouldn't know. You should ask superm1 about it
[10:48] <directhex> ah, okay. superm1, i choose you!
[10:50] <slytherin> savvas: Further references - http://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders http://live.gnome.org/NetworkManager/MobileBroadband
[10:52] <savvas> slytherin: I found that, I'm checking  :)
[10:55] <savvas> slytherin: er.. one question, should I use tabs or spaces? Both seem to be used
[10:55] <slytherin> savvas: I don't think it will matter. It is xml after all. I prefer spaces.
[10:56] <savvas> ok
[10:57] <stryd_one> hi all
[10:59] <stryd_one> i'm following the packaging guide in a first attempt at deb packaging. It instructs me to run 'pbuilder create' but when I do, the first message from the app is "Distribution is jaunty."... but I'm running hardy, and want to build the package for hardy. Should I worry about this message and if so do you know how I can fix it?
[11:03] <slytherin> stryd_one: Event though I don't have a link to the tutorial at hand, I am sure there is one page on wiki about pbuilderrc.
[11:05] <savvas> slytherin: there's one who used italian in the name, should I ask for the english translation?
[11:05] <savvas> +-		<name>H3G (pre-paid)</name>
[11:05] <savvas> ++		<name>H3G (abbonamento)</name>
[11:05] <stryd_one> thanks slytherin i'm searching for it now
[11:05] <slytherin> savvas: depends, is the service only available in italy?
[11:06] <slytherin> savvas: if yes, the having italian name won't matter much.
[11:06] <savvas> alrighty
[11:06] <savvas> I'll check their site
[11:07] <stryd_one> got it thanks slytherin
[11:07] <stryd_one> is there some reason it defaults to jaunty if i don't specify?
[11:08] <slytherin> stryd_one: are you running jaunty?
[11:09] <stryd_one> no hardy
[11:09] <slytherin> stryd_one: check your /etc/pbuilderrc and also check if you have at any point of time created ~/.pbuilderrc
[11:10] <stryd_one> the ~/,pbuilderrc i created has one line in it: COMPONENTS="main restricted universe multiverse" as per the video
[11:10] <slytherin> stryd_one: What about DISTRIBUTION?
[11:10] <stryd_one> nothing
[11:11] <stryd_one> i'm putting that line in there now and forcing it to hardy
[11:12] <stryd_one> it just seemed not right, that it defaulted to jaunty
[11:22] <slytherin> stryd_one: did you install debootstrap from backports repository?
[11:23] <stryd_one> possiblly, checking....
[11:24] <stryd_one> yep
[11:25] <stryd_one> backports is enabled and i guess it's chosen that one automatically
[11:30] <jcfp> Need some help: when building (in  a jaunty pbuilder) a package with debian/pyversions set to 2.5, and the program using /usr/bin/python2.5 in the shebang line, ${python:Depends} expands into "python (<< 2.6), python2.5, python-support (>= 0.7.1)" making it uninstallable in jaunty?
[11:35] <jcfp> making pyversions include 2.6 (e.g. by setting it to "2.5-" or similar), it changes to "python (>= 2.5), python-support (>= 0.7.1), python2.5" which is installable, but makes python-support add *.pyc for python 2.6 that are not needed.
[11:35] <jcfp> any idea?
[11:37] <geser> jcfp: perhaps doko has an idea
[12:05] <doko> jcfp, geser: not without knowing about the package
[12:06] <jcfp> doko: want me to send you the sources?
[12:08] <doko> jcfp: no
[12:41] <savvas> when a package closes multiple bugs we use LP: #nnnn,#nnnn,#nnnn,... right?
[12:46] <geser> yes (check the .changes files to be sure, there should be a header listing all bug numbers so they get automatically closed)
[12:48] <savvas> alrighty :)
[12:54] <savvas> geser: is python 2.5 for aptoncd necessary or not? I just made a patch for it to build for both python 2.5 and 2.6, could you take a look and comment? :) http://paste.ubuntu.com/125756/
[12:55] <savvas> https://edge.launchpad.net/%7Emedigeek/+archive/ppa/+build/889635/+files/buildlog_ubuntu-jaunty-i386.aptoncd_0.1.98-0ubuntu5~ppajaunty7_FULLYBUILT.txt.gz
[12:55] <savvas> I was thinking maybe I could send the patch to debian
[12:57] <savvas> hm.. the debian package looks pretty outdated
[13:00] <geser> savvas: your patch looks good, can you try to move aptoncd to using python-shared or python-central? so the package doesn't contain the .py files twice?
[13:00] <savvas> geser: I'll try :)
[13:02] <geser> and for some reason the Depends line from your build log misses the python dependency
[13:02] <geser> savvas: thanks
[13:03] <savvas> dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
[13:03] <savvas> dpkg-gencontrol: warning: unknown substitution variable ${python:Versions}
[13:04] <savvas> this one?
[13:04] <geser> yes
[13:04] <savvas> I think it needs dh_gencontrol -a, I could be wrong though - anyway, I'll test it :)
[13:06] <geser> I guess it's because it's no good idea to only process arch-dependent packages in build-indep (and with a arch:all package too)
[13:06] <geser> drop the -a again from your patch
[13:06] <savvas> oki doki!
[13:09] <savvas> geser: er.. you mean I should use binary-arch instead of binary-indep? or both?
[13:12] <geser> savvas: any reason why you touched that part of debian/rules in your patch?
[13:13] <savvas> geser: I added -a because it wouldn't include the 2.5 files
[13:14] <savvas> and the other dh_ commands from another package I took as a reference (still learning :) )
[13:15] <geser> it shouldn't have an influence on this and your changes to the build-indep target broke the variable subsitution
[13:17] <savvas> I see
[13:20] <savvas> thank you very much! :)
[13:56] <eMerzh> if some MOTU want to review my package.... it is waiting on the revu ( http://revu.ubuntuwire.com/details.py?package=sqliteman ) ...thanks a lot
[14:13] <incorrect> I am struggling to sign my repository
[14:15] <Hobbsee> if that's a ppa, you want #launchpad
[14:15] <incorrect> i meant that for ubuntu-server
[14:27] <james_w> thanks sistpoty|work, ScottK :-)
[14:33] <sistpoty|work> you're welcome, james_w ;)
[14:50] <_ruben> hmm .. the dependencies for dkms have some "odd" results
[14:51] <_ruben> install dkms on intrepid yields:
[14:51] <_ruben> The following extra packages will be installed: linux-firmware linux-headers-2.6.25-2-386 linux-image linux-image-2.6.27-11-generic linux-image-generic linux-ports-headers-2.6.25-2
[14:52] <RainCT> ScottK: afaik Pidgin has never had notifications by default; it's an opt-in plugin
[14:53] <ScottK> RainCT: Except the option in seeded in ubuntu-desktop so Ubuntu users do get it by default.
[14:53] <ScottK> If that's appropriate, then I don't see why pidgin users from other flavors shouldn't get the same?
[14:54] <RainCT> ScottK: Ah, is that new? I'm not using Pidgin anymore (switched to empathy a few months ago), but I've never had notifications
[14:55] <ScottK> Yes.  I think it's new in Jaunty.
[14:56] <ScottK> Unfortunately pidgin-libnotify is broken with libnotify1 currently, so one either has the new system or nothing, but presumably the regression will be corrected.
[14:57] <superm1> directhex, well.. sure you should be able to do it.  the latest is actually on amd's website though not in jaunty
[14:57] <superm1> directhex, grab the .run file, and run ./FILE.run --buildpkg Ubuntu/source
[14:57] <superm1> and then edit the changelog to be intrepid and push it to your ppa
[14:58] <directhex> superm1, oh. um... can i ask why jaunty's behind, without causing offence?
[14:59] <superm1> directhex, no point in pushing the latest one to jaunty if it doesn' work w/ xorg 1.6
[14:59] <superm1> you can go and !stab AMD for that one
[14:59] <directhex> eek, it doesn't?
[14:59] <directhex> bloody amd
[15:01] <_ruben> superm1: the dkms issue i mentioned above (pulling in "odd" kernel headers), is it a known one (must admit i havent checked lp yet)
[15:02] <superm1> _ruben, so there is no way to currently define which package you need as depends when there are virtual dependencies
[15:02] <superm1> so the way it works right now is depends: linux-headers-generic | linux-headers
[15:02] <superm1> so if you don't have linux-headers-generic, it just grabs one that would satisfy linux-headers on your architecture
[15:04] <_ruben> superm1: it depends on "linux-image, linux-headers" actually
[15:05] <_ruben> i guess its most likely the result in an "incapable" dependency resolver and not really dkms' fault
[15:05] <superm1> _ruben, yeah exactly
[15:05] <superm1> _ruben, no one has really come up with a good solution for it as of yet unfortunately
[15:07] <_ruben> superm1: ok .. wasnt sure if i had possibly missed something (obvious)
[15:07] <_ruben> just gotta make sure to install the proper headers along with dkms myself :)
[15:07] <superm1> _ruben, well so for the general case (desktop users), your packages should work fine
[15:07] <superm1> it's the corner cases, and headless installs you have to worry about
[15:08] <_ruben> superm1: i dont think general would work .. as it pulls in linux-headers-2.6.25-2-386 and not linux-headers-2.6.27-11-generic for instance
[15:08] <directhex> superm1, any idea why fglrx has such oddball version numbers these days? o_o
[15:09] <superm1> directhex, yeah so the version number of the web release is the external version number based on the time of release (eg 9-2)
[15:09] <superm1> when you do a --buildpkg, you get their internal build number which is more relevant
[15:13] <directhex> superm1, any word on whether a 1.6-capable version will actually be prepared before jaunty, or are we in for another painful switch to the free driver?
[15:14] <superm1> directhex, so the current plan as I last heard it was that if 1.6 capable version isn't ready by beta, it's painful switch in dist-upgrade
[15:14] <directhex> joy!
[15:14] <superm1> hopefully the EXA & Xv patch for r6xx and r7xx at least gets applied then so that hardware isn't entirely crippled
[15:15] <superm1> older hardware than that at least works well with the open driver
[15:15] <directhex> i wonder if jaunty's intel driver will let me play world of goo without x segfaulting on exit
[15:16] <bddebian> Heya gang
 heya bddebian :)
[15:17] <bddebian> Heh, hello savvas
[15:26] <slytherin> directhex: is it currently segfaulting?
[15:26] <directhex> slytherin, if i quit WOG, then X restarts, yes
[15:31] <slytherin> directhex: wow. :-)
[15:31] <slytherin> I am glad I am using ATI card.
[15:34] <directhex> slytherin, i'm not. fglrx ftbfs here :/
[15:36] <slytherin> directhex: I don't need fglrx. :-P
[15:36] <directhex> slytherin, i have a radeon 4870 i'm meant to benchmark. i doubt it even works in 2d with the free driver.
[15:37] <slytherin> directhex: Have you tried free driver? One of my friend has same card and i remember 2d working fine on his machine on intrepid.
[15:40] <savvas> does this debian/rules look ok? :) http://paste.ubuntu.com/125836/
[15:41] <directhex> superm1, are you interested in bugfixes for fglrx packaging, or should i speak to someone else?
[15:53] <Laibsch> Hi, can somebody please rebuild python-4suite-xml, python-kaa-base and python-kaa-metadata against python 2.6 in Jaunty? It is currently preventing some upgrades for me in Jaunty. -> bug 331461
[15:56] <savvas> what's with all the netsplits?
[15:56] <savvas> woohoo!  Depends: python (<< 2.7), python (>= 2.5), python-central (>= 0.6.11), python2.6, libgnomevfs2-0, genisoimage | mkisofs, apt-utils, synaptic (>= 0.57.7), python-gnome2, python-apt, python-glade2, python-dbus, lsb-release, gksu, python-gtk2, gnome-icon-theme
[15:57] <savvas> hm.. why python2.6 :\
[16:03] <_ruben> savvas: WALLOP Md:  sorry for the splits, one of our new servers is unstable and will be terminated
[16:07] <savvas> thanks _ruben!
[16:07] <savvas> wallops.. was that +w?
[16:07] <jpds> Yes.
[16:11] <Q-FUNK> howdy!  can anybody help with bug #335741 ?
[16:22] <savvas> ScottK: is it possible to revert patches? can you remove your patch from libtorrent-rasterbar and sync with debian? they use boost1.37 in debian/control, e.g.: "libboost1.37-dev | libboost-dev (>= 1.34.1)"
[16:27] <slytherin> savvas: no it is not possible to revert patches. you will have to wait for another debian revision to request sync
[16:29] <savvas> thanks slytherin, what should we do for libtorrent-rasterbar? attempt a merge with debian or just patch it for python 2.6?
[16:29] <slytherin> savvas: patch it for python2.6
[16:30] <savvas> alrighty I'll try
[16:30] <savvas> ScottK: ignore the question before, answered :)
[16:31] <RainCT> revert patches?
[16:33] <savvas> RainCT: nvm, it was a patch to enable boost1.35 :P
[16:33] <savvas> enable=use
[16:55] <Laibsch> RainCT: I've tried here and in other places for days now.  Can I ask you to please upload python-4suite-xml, python-kaa-base and python-kaa-metadata so they can be rebuild against python 2.6?
[16:55] <Laibsch> nobody else seems game to take it up
[16:57] <RainCT> Laibsch: I can't see them in the sponsors queue
[16:58] <Laibsch> does that have to happen first?
[16:58] <Laibsch> who should I contact about that, then?
[16:58] <Laibsch> I thought you were a member of motu-sponsors?
[16:59] <superm1> directhex, i'm interested
[16:59] <superm1> what's up?
[17:00] <RainCT> Laibsch: I am. The usual procedure to get something uploaded is to attach a debdiff (or .diff.gz if it's an update) to a bug and subscribe ubuntu-universe-sponsors to it (or ubuntu-main-sponsors for stuff in main/restricted)
[17:00] <Laibsch> RainCT: I know
[17:00] <Laibsch> I don't see much point in this case
[17:00] <Laibsch> There are no changes
[17:01] <Laibsch> The packages just need to be rebuilt
[17:01] <Laibsch> The debdiff would only contain the change in Changelog
[17:01] <Laibsch> changelog
[17:03] <Laibsch> RainCT: makes sense?
[17:03] <RainCT> OK
[17:05] <RainCT> ar.. I've just tried to upgrade but do-release-upgrade is hanging since minutes at something after "Reading state information: Done".. Any idea guys?
[17:08] <Laibsch> RainCT: thanks, appreciated
[17:10] <geser> Laibsch: does python-4suite-xml build for you with python2.6? I aborted my build when the build started using 1 GB of swap (with 4 GB of RAM)
[17:11] <Laibsch> geser: to be honest, I haven't tried
[17:11] <Laibsch> I just blindly assumed
[17:12] <Laibsch> assumed it was a simply rebuild just like all the other packages that were preventing me upgrading
[17:12] <RainCT> Laibsch: Not all are rebuilds. Packages that aren't using plain CDBS with distutils have pretty much of a chance of needing changes
[17:14]  * RainCT takes a shot at kaa-base
[17:15] <Laibsch> thanks
[17:16] <savvas> Laibsch: if you are familiar how to use Launchpad's PPA you could try to rebuild yourself and see where's the problem :)
[17:17] <Laibsch> yes, good idea.  But I'm not a compile expert.  geser, RainCT, I'll take a look at python-4suite-xml, OK?
[17:18] <geser> RainCT: kaa-base is a rebuild, just done with the test-build
[17:18] <RainCT> geser: yep
[17:19] <geser> RainCT: do you upload or should I? don't want to make a race for it :)
[17:19] <RainCT> geser: uhm.. doesn't ubotu have a dice function? :P
[17:19] <RainCT> geser: go for it :)
[17:21] <RainCT> geser: but kaa-metadate is for me ;)
[17:22] <geser> RainCT: no problem, you can have python-4suite-xml too :)
[17:23] <RainCT> nah, I don't like the name of that one *g*
[17:23]  * savvas waits for a "please, I insist" :p
[17:25] <savvas> how do I stop pycentral from changing the application version?
[17:25] <savvas> -APP_VERSION="0.1.98-0"
[17:25] <savvas> +APP_VERSION="0.1.98-0ubuntu5~ppajaunty9"
[17:27] <savvas> ..or is that normal? :P
[17:32] <geser> savvas: still improving aptoncd? I've seen that it already uses python-central but has "nomove" set as an python-central option
[17:32] <geser> I didn't dig in the packaging if there is a reason for this
[17:34] <savvas> geser: yes, this one proved much better: http://paste.ubuntu.com/125912/ http://launchpadlibrarian.net/23374440/buildlog_ubuntu-jaunty-i386.aptoncd_0.1.98-0ubuntu5~ppajaunty9_FULLYBUILT.txt.gz
[17:34] <savvas> geser: but I think I need dh_pycentral and dh_python afterwards, I'll try it some other day :P
[17:35] <savvas> It's harder without cdbs :)
[17:36] <geser> savvas: try also out commenting out "export DH_PYCENTRAL=nomove" so the *-packages dirs get managed by python-central
[17:36] <savvas> geser: I was afraid that the app might not work afterwards, but I'll try it, thanks :)
[17:37] <geser> savvas: and the Depends like looks ok now too, only one minor thing: it has a dependency on python2.5, try to figure out why (probably a script using python2.5 as interpreter)
[17:37] <savvas> ahhh
[17:37] <savvas> I wanted to ask you that!
[17:37] <geser> savvas: yes, you need to check if afterwards
[17:38] <savvas> oki doki
[17:40] <savvas> geser: that python2.5 is weird, I've tried "debuild -b" locally, and it had dependency on python2.6
[17:40] <savvas>  Depends: python (<< 2.7), python (>= 2.5), python-central (>= 0.6.11), python2.6, libgnomevfs2-0, genisoimage | mkisofs, apt-utils, synaptic (>= 0.57.7), python-gnome2, python-apt, python-glade2, python-dbus, lsb-release, gksu, python-gtk2, gnome-icon-theme
[17:41] <geser> I guess it depends on the order of the build first 2.5 and then 2.6 or vice versa
[17:41] <RainCT> (kaa-metadata can't be fixed until python-kaa-base has built)
[17:42] <savvas> geser: ok, I'll look into it a bit later :)
[17:48]  * savvas tests a libtorrent-rasterbar patch - http://paste.ubuntu.com/125917/
[17:56] <savvas> copying build/lib.linux-i686-2.6/libtorrent.so -> /tmp/buildd/libtorrent-rasterbar-0.14.1/debian/tmp/usr/local/lib/python2.6/dist-packages
[17:56] <savvas> [...]
[17:56] <savvas> dh_install: python-libtorrent missing files (usr/lib/python*/*-packages/libtorrent.so), aborting
[17:56] <savvas> ah local
[18:08] <EagleScreen> I am receiving docens od mail each day, related with motu, I must be in a mailing list, I thouhgt I was in ubuntu-motu mailing list, ubuntu-motu@lists.ubuntu.com, but an admis has teold me that my address is not in the list
[18:12] <EagleScreen> may be i am in ubuntu-universe-sponsors@lists.ubuntu.com
[18:13]  * sistpoty|work heads home... cya
[18:19] <RainCT> EagleScreen: perhaps you have subscribed to bugmail for some package?
[18:20] <RainCT> EagleScreen: (in case what you get is bugmail, dunno what you mean by "odd mail" :))
[18:22] <EagleScreen> ubuntu-motu; ubuntu-motu-mentors and ubuntu-universe-sponsors, what is the difference between these lists?
[18:24] <Laibsch> python-4suite certainly is a long build: https://launchpad.net/~r0lf/+archive/ppa/+build/890212
[18:24] <directhex> Laibsch, 40 mins is long?
[18:24] <directhex> Laibsch, apt-get source --build openoffice.org
[18:24] <Laibsch> directhex: Done that in the PPA
[18:25] <Laibsch> I know it takes much longer
[18:25] <Laibsch> But 40 mins is on the longer end
[18:25] <Laibsch> for something I have never heard of before and thus is likely very much a little used lib
[18:26] <Laibsch> geser was saying earlier he stopped the built half-way through because of memory issues
[18:26] <directhex> try ikvm - needs 1.1 gig of ram to build ^_^
[18:26] <slytherin> doko: do you mind if I take care of bug 330613? Seems to be a simple copy paste error.
[18:27] <slytherin> Laibsch: openjdk build on armel was going for 5 days. :-)
[18:28] <savvas> :o
[18:30] <DktrKranz> mok0, have you some time to process 272264?
[18:30] <DktrKranz> bug 272264
[18:31] <directhex> slytherin, you mean that finished successfully?
[18:32] <slytherin> directhex: I am assuming that it did.
[18:32] <slytherin> DktrKranz: are syncs from PPA allowed?
[18:33] <directhex> slytherin, well, if not, there's always IKVM :)
[18:33] <slytherin> directhex: is ikvm better than openjdk on powerpc?
[18:34] <DktrKranz> slytherin, no (not the common way at least). It has to be uploaded manually or synced from Debian (if feasible)
[18:34] <directhex> slytherin, pass. i think the swing implementation is still proof-of-concept, but it's certainly built
[18:35] <slytherin> directhex: what is the simplest procedure to use ikvm for a helloworld application?
[18:37] <directhex> slytherin, assuming you're on jaunty (as i claim no responsibility for dajobe's packaging in previous releases)?
[18:37] <slytherin> directhex: yes, I am on jaunty
[18:41] <directhex> slytherin, well, for .class files, just use "ikvm classname" instead of "java classname"
[18:41] <slytherin> directhex: ok, will try.
[18:43] <directhex> slytherin, as a compiler, you process a .class to produce a .exe/.dll, using "ikvmc -target:exe foo.class". you can run the .exe with mono
[18:47] <ScottK> savvas: As a followup ... we've been trying to sync up on boost1.35 for this release. Boost1.38 is expected in Debian shortly and is what they will aim for with Squeeze.  I think it's a good goal for Karmic to push on to 1.38, but for Jaunty we should leave stuff at 1.35.
[19:40] <fabrice_sp> Hi. I'd like to sync wide-dhcpv6 20080615-5 from unstable, to fix a FTBFS, as it seems to have only fixes since 20080615-2 (the one in Jaunty). How do I confirm that? It's to know if I can avoid a FFe. Thanks
[19:41] <fabrice_sp> forget what I've written before: the version in unstable also FTBFS...
[19:50] <directhex> FFE shouldn't be needed for fixes-only
[20:23] <Laibsch> alright, the python-4suite results are in: http://launchpadlibrarian.net/23387460/buildlog_ubuntu-jaunty-amd64.python-4suite_1.0.2-7_FAILEDTOBUILD.txt.gz  But I'm not sure how to interpret that ("150 minutes of inacticity"?)
[20:23] <Laibsch> Is the call for setup.py correct?
[20:24] <Laibsch> geser, RainCT: comments?
[20:27] <RainCT> It's missing the --install-layout=deb
[20:31] <Laibsch> alright
[20:31] <Laibsch> I was wondering about that
[20:31] <Laibsch> I'll retry
[20:42] <savvas> W: libtorrent-rasterbar source: missing-comma-after-substvar in depends field near ${misc:Depends}
[20:42] <savvas> is this minor?
[20:49] <RainCT> Laibsch: I don't think that not having that options is the cause for the odd error you got, though
[20:49] <Laibsch> alright
[20:49] <Laibsch> I'll have to leave this for now, then
[20:50] <Laibsch> Maybe tomorrow
[21:18]  * RainCT grumbles something about texlive pulling in at least 100 MB of documentation packages and about moving those to suggests :P
[21:23] <savvas> wow, texlive-latex-base-doc texlive-latex-extra-doc texlive-latex-recommended-doc texlive-pictures-doc texlive-humanities-doc texlive-fonts-recommended-doc texlive-base-bin-doc
[21:23] <savvas> try installing lyx :P
[21:23] <RainCT> yeah
[21:23] <RainCT> I'd move them to suggests and add a generic texlive-doc with them as recommends for those who want them
[21:24] <RainCT> or without generic -doc (not sure how that would work if you don't want -extra and so on)
[21:24] <savvas> 136.78MB in total :p
[21:29] <Laibsch> RainCT: Yes, please do
[21:29] <Laibsch> The other day I stumbled across a few unsplit Java packages: package size: 25MB, out of that 24,5MB in /usr/share/doc
[21:30] <RainCT> :/
[21:30] <RainCT> let's file a spec: kill-the-docs XD
[21:33] <savvas> argh
[21:33] <Laibsch> I have a good idea for it
[21:33] <savvas> is there a way to grab them all?
[21:33] <Laibsch> (stolen from openembedded.org)
[21:34] <Laibsch> enhanve the build process so that anything in /usr/share/doc is automatically packaged as a doc file
[21:34] <Laibsch> enhance
[21:34] <RainCT> o_O
[21:34] <Laibsch> doc package
[21:34] <RainCT> ah
[21:34] <Laibsch> sorry
[21:34] <RainCT> no, won't work
[21:34] <Laibsch> My typing is really bad
[21:34] <Laibsch> why?
[21:34] <Laibsch> It is possible to define exceptions if necessary
[21:35] <Laibsch> for embedded devices, small packages are of course imperative
[21:35] <RainCT> beside that copyright, changelog, etc. should really be in the main package, there are applications which depend on documentation
[21:35] <RainCT> being present.. I maintain some like that myself
[21:36] <RainCT> and significant amounts of docs should usually be in a -doc anyway
[21:36] <Laibsch> IIRC, the build process in OE does put copyright,etc. in the right place, IOW, the main package
[21:37] <RainCT> it may be worth a thought, but it would need an archive wide transition to fix stuff that expects docs to be there..
[21:39]  * RainCT watches do-release-upgrade uninstall his stuff without permission ¬_¬
[21:40] <directhex> aptitude purge RainCT
[21:40]  * RainCT is purged x_O
[21:41] <RainCT> see? mono applications are evil ^^
[21:41] <savvas> arghhhhhhhh
[21:41] <RainCT> bah now it killed my music xDDD
[21:41] <savvas> RainCT: a moment of your time? :)
[21:42] <RainCT> savvas: nope, I can't work without music *g*
[21:42]  * savvas whistles :p
[21:42] <RainCT> savvas: well.. okay.. what's up?
[21:42] <savvas> lol
[21:42] <savvas> I can't manage to patch libtorrent-rasterbar properly
[21:42] <savvas> copying build/lib.linux-i686-2.6/libtorrent.so -> /tmp/buildd/libtorrent-rasterbar-0.14.1/debian/tmp/usr/local/lib/python2.6/dist-packages
[21:42] <savvas> dh_install: python-libtorrent missing files (usr/lib/python*/*-packages/libtorrent.so), aborting
[21:43] <RainCT> savvas: and you've added the  --install-layout=deb (or whatever it is)?
[21:43] <RainCT> after every "setup.py install"
[21:43] <savvas> I tried every way I could think of, this is the latest one: dh_install: http://paste.ubuntu.com/126024/
[21:43] <savvas> there's no python reference in the rules :(
[21:44] <savvas> let me check again
[21:44] <RainCT> am I still online?
[21:44] <savvas> yes you are :)
[21:44] <RainCT> nm-applet died :P
[21:44] <savvas> hehe
[21:44]  * savvas scans for setup.py
[21:45] <RainCT> savvas: so what is it using? Makefile?
[21:45] <savvas> er... autoconf and make I think
[21:45] <RainCT> I've no idea then :(
[21:46] <RainCT> look at what the MAkefile says
[21:47] <savvas> I have, but my knowledge is limited.. oh well. I'll send my work at bug 335741 and comment on this last one
[21:48] <Laibsch> RainCT: Maybe you want to grab the debdiff from debian bug 513661 which I prepared and upload it to Jaunty
[21:48] <savvas> woa!!!
[21:48] <Laibsch> I did not consider it important enough for a separate ubuntu bug
[21:48] <Laibsch> but relied on the normal process instead
[21:49] <Laibsch> the same applies to the libjaxen-java package
[21:51] <savvas> I think I found it, thanks RainCT :)
[21:53] <RainCT> great :)
[21:53] <Laibsch> RainCT: I got another fairly important fix, ready for upload
[21:54] <Laibsch> bug 335891
[21:54] <RainCT> Laibsch: subscribe me and I'll look at it tomorrow
[21:54] <Laibsch> OK
[21:54] <Laibsch> It's getting late over there, hm?
[21:54] <RainCT> uhm, nice.. I like how Firefox asks to be restarted now :D
[21:55] <RainCT> miro and python-pgsql need rebuild
[21:55] <RainCT> or patching
[22:31] <savvas> darn, asomething already made the merge
[22:31] <savvas> oh well, I included my modest patch :)
[22:55] <anakron> hi all
[22:55] <anakron> someone can look this bug? https://bugs.launchpad.net/ubuntu/+source/memaker/+bug/290531
[23:32] <goshawk> does cdbs applies patches when doing debuild -S -sa?
[23:34] <goshawk> yes
[23:34] <goshawk> i did debuild and it patched
[23:48] <savvas> is dd_rescue actively developed?
[23:49] <savvas> hm.. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505831