[00:06] <anakron> hi all
[00:08] <anakron> someone can look this bug? https://bugs.launchpad.net/ubuntu/+source/pwman3/+bug/299130
[00:50] <savvas> dpkg: error processing /var/cache/apt/archives/python-wxgtk2.8_2.8.9.1-0ubuntu4_amd64.deb (--unpack): trying to overwrite `/usr/lib/python2.6/dist-packages/wx/__version__.py', which is also in package python-wxgtk2.6
[00:50] <savvas> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[00:51] <savvas> python-wxgtk2.8 breaks when python-wxgtk2.6 is already installed
[00:51]  * savvas files a bug :P
[00:53] <anakron> :O your first bug
[00:53] <anakron> XD
[00:56] <savvas> anakron: for today? yeah hehe
[00:56] <savvas> :)
[00:57] <anakron> :)
[00:57] <anakron> im a little bit angry with some packagers
[00:57] <anakron> :@
[00:58] <anakron> i like to fix some bugs with desktop file problems, but some of them have like 9 errors if you look it with desktop-file-validate
[00:59] <anakron> some entries duplicated ... i could go
[00:59] <JontheEchidna> Aren't upstreams generally responsible for .desktop files?
[01:00] <JontheEchidna> Although I suppose the packagers should report the problems upstream in the first place...
[01:00] <anakron> in one desktop file an icon  path sets an xml file
[01:00] <anakron> ...
[01:00] <anakron> yes i think too
[01:00] <anakron> but, trying to fix a bug, i found some others
[01:01] <Amaranth> an icon path sets an xml file?
[01:02] <anakron> yes
[01:02] <anakron> XD
[01:02] <savvas> anakron: there are more serious problems with .desktop files: http://groups.google.com/group/linux.debian.devel/browse_thread/thread/6f38b567c5684a60?pli=1
[01:07] <anakron> :O
[01:11] <savvas> :p
[02:02] <ScottK> Also some .desktop files predate the FDO spec.
[02:31] <fabrice_sp> Hi. How can I see why a package in Debian does not exist in Ubuntu? It's mig (http://packages.debian.org/lenny/mig)
[02:32] <fabrice_sp> weird: it's in Ubuntu, but it does not appear through packages.ubuntu.com
[02:33] <ajmitch> that generally happens if it failed to build
[02:33] <fabrice_sp> ajmitch, that's what I was looking for ;-) Thanks
[02:34]  * ajmitch can't recall where build logs are on LP now
[02:35] <fabrice_sp> you're right: there is a cyclic dependency between mig and  gnumach
[02:35] <ajmitch> that doesn't surprise me, given the intent of mig
[02:35] <StevenK> https://bugs.edge.launchpad.net/ubuntu/+source/mig/+bug/174851
[02:35] <fabrice_sp> (mig build depends on gnumach, but gnumach depends on mig?!)
[02:35] <ajmitch> why do you want it?
[02:35] <fabrice_sp> was just looking for all FTBFS to try to fix them
[02:35] <ajmitch> ah
[02:36] <ajmitch> ignore that one then :)
[02:36] <fabrice_sp> yep :-)
[02:36] <ajmitch> unless you really feel inspired to port ubuntu to the hurd
[02:36] <fabrice_sp> (already ignore some of them :-) )
[02:36] <fabrice_sp> hmmm, not really! :-)
[02:41] <Amaranth> shouldn't those packages be removed from ubuntu then?
[03:17] <pschulz01> anyone have a package which is a good example of 'debconf' settings?
[03:17] <pschulz01> s/have/know of/
[03:21] <dtchen_> pschulz01: just about any of the output from `apt-cache rdepends debconf|grep -v debconf-` should be a starting point
[03:25] <pschulz01> dtchen_: Ta.. 'adduser' seems to be a good (simple) one, and postfix gets a little more complicated.
[04:04] <ScottK> The postfix package combines a number of complex advanced packaging techniques and has accumulated some cruft over the course of the decade it's existed.  Probably not the best sample.
[04:12] <dtchen_> ScottK: hi, do you mind sponsoring both debdiffs for bug 336100, please?
[04:13]  * ScottK looks
[04:18] <ScottK> dtchen_: Is the man page the only thing that conflicts between the two packages?
[04:20] <dtchen_> ScottK: yes, but it doesn't make much sense to only remove the conflicting man page
[04:21] <dtchen_> kirkland made a similar fix for sysvconfig
[04:21] <ScottK> It seems odd that we patch service into sysvinit
[04:22] <ScottK> And then don't use the other one.
[04:24] <ScottK> dtchen_: From reading the man pages it looks like the chkconfig supports a status-all command that the sysvinit-utils one does not.
[04:30] <dtchen_> ScottK: unless i'm misreading sysvinit's debian/patches/94_service.dpatch, it does
[04:31] <ScottK> dtchen_: I thought it provided service, but not service-all.  I'm kind of tired though, so I might be misreading it.
[04:33] <dtchen_> there's no mention of service-all in either, but status-all is properly supported/compatible
[04:33] <ScottK> Sorry , status-all was what I meant.
[04:33] <ScottK> Did I mention I was tired ....
[04:34] <rgreening> o/ ScottK
[04:35] <ScottK> Heya rgreening.
[04:35] <rgreening> your not the only tired one. I think 4 hrs sleep in 2 nights
[04:37] <ScottK> dtchen_: Uploaded.  Thank you for your contribution to Ubuntu.
[04:37] <rgreening> ScottK: got any small jobs that need done. emphasis small... :)
[04:38] <ScottK> Plenty of Python bugs yet to squash.
[04:38] <rgreening> throw one at me
[04:38] <ScottK> rgreening: Are you on Jaunty?
[04:38] <rgreening> yes
[04:39] <ScottK> Then apt-cache rdepends python2.4 and pick anything not related to zope.
[04:39] <rgreening> ok. i'll look
[04:39] <ScottK> The only ones I've specifically looked and and not done already don't qualify as small.
[04:40] <rgreening> lol
[04:40] <dtchen_> ScottK: thanks
[04:51] <rgreening> ScottK: ok, I'll take a look at balder2d
[04:52] <ScottK> Great.
[04:56] <rgreening> no p0romises :)
[04:56] <rgreening> hehe
[04:57] <rgreening> ScottK: though, if I have luck like I did for the last python fix, who knows.
[04:57]  * ScottK is off to bed.  
[04:57] <ScottK> I can look at it tomorrow if no one else does.
[05:33] <superm1> dtchen_, is there a particular reason you're holding off requesting sponsorship to get bug 336965 resolved since you have a solution ready?
[05:34] <superm1> (like trying to convince kernel team to upload with a PREEMPT enabled kernel to solve the problem etc)
[05:47] <dtchen_> superm1: i already raised the possibility of enabling PREEMPT for -generic in jaunty with members of the kernel team
[05:47] <dtchen_> superm1: the proposal was disapproved
[05:48] <dtchen_> superm1: (it was deemed too late in the devel cycle to enable such a kernel config option)
[05:48] <dtchen_> (...nevermind that it used to be enabled many releases ago...)
[05:49] <TheMuso> Well if its any ocmfort, we are not the only ones who don't have it enabled.
[05:49] <dtchen_> superm1: so - the only other option is to disable glitch-free again
[05:49] <TheMuso> comfort
[05:49] <dtchen_> TheMuso: right
[05:50] <dtchen_> i'm not interested in laying blame anywhere. i've been given operating parameters by the kernel team, so i'll work within them.
[05:50] <dtchen_> if i wanted politics, i would have chosen another project ;)
[05:51] <dtchen_> disabling glitch-free isn't really a bad option. i'll continue hacking away at PA to not eat so many resources, but i'm not going to drastically alter its behaviour. lennart would have my skull.
[05:52] <dtchen_> anyhoo, it's Z time
[06:07] <Laibsch> rgreening: can you upload packages?
[06:28] <rgreening> not yet.
[06:28] <rgreening> ask me after March 13th MOTU meeting :)
[06:29] <TheMuso> Laibsch: WHat would you like looked at?
[06:35] <Hobbsee> bugs--
[06:36] <Laibsch> TheMuso: thanks
[06:36] <Laibsch> bug 335891, for example
[06:37] <Laibsch> should be ready to upload
[06:38] <Laibsch> furthermore, python-4suite-xml and python-kaa-metadata need to be made compatible with python 2.6, they depend on python < 2.6
[06:39] <Laibsch> It could be that unlike many other packages, it is not a simple recompile job
[06:40] <Laibsch> I tried simply recompiling python-4suite-xml yesterday and it failed: https://launchpad.net/~r0lf/+archive/ppa/+build/890212
[06:41] <Laibsch> It is lacking one of the new python options, but I did not get around to retrying, yet
[06:46] <TheMuso> Laibsch: uploaded the audacious debdiff, don't  have time for the others sorry.
[06:49] <Laibsch> TheMuso: great, thanks
[06:49] <Laibsch> One more to cross off
[06:56] <didrocks> hello there
[06:57] <slytherin> hi all. anybody here with acer laptop with atheros wireless card?
[07:07] <rgreening> ScottK: I have a working balder2d. Seems to behave just fine with python2.6 build dep.
[07:07] <rgreening> ScottK: I'll submit a bug report for sponsoring later.
[07:11] <AnAnt> superm1: dkms is in Debian's NEW & BYHAND since 2 weeks !
[07:12] <superm1> AnAnt, ah wonderful!
[07:12] <superm1> i'm not sure what BYHAND is
[07:12] <superm1> but NEW is good news
[07:12] <AnAnt> superm1: something like Ubuntu's queue (the stage after REVU)
[07:13] <superm1> AnAnt, great.  i'm hoping the packaging is very similar (or identical) to the Ubuntu packaging, but if not i'll have to work with those guys to come to a consensus
[07:15] <AnAnt> superm1: http://ftp-master.debian.org/new/dkms_2.0.21.0-1.html
[07:15] <AnAnt> superm1: although I dunno how to get the diff.gz !
[07:15] <superm1> AnAnt, i can already tell there is some delta there
[07:15] <AnAnt> superm1: it's not on debian mentors
[07:15] <superm1> i'll try to get ahold of the pieces and examine tomorrow
[07:17] <AnAnt> btw, someone is making a package for cnetworkmanager (controlling NetworkManager under console)
[08:07] <Toadstool> good morning!
[08:08] <Hobbsee> morning Toadstool!
[08:08] <Toadstool> hey Hobbsee!
[08:49] <maxb> BYHAND is an unusual process where a package build submits arbitrary files as part of the upload for manual attention of the Debian ftp-masters, e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405925
[09:31] <savvas> should we remove bmpx package as well?
[09:31] <savvas> "The bmpx package has been removed from Debian so we are closing the bugs that were still opened against it."
[09:39] <savvas> pochu: here? should I file a bug report for bmpx removal? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517588
[09:39] <savvas> eh?
[09:40] <savvas> "RM: bmpx -- RoM; unmaintained upstream, uses outdated libraries"
[09:40] <savvas> :P
[09:40] <pochu> savvas: I guess so, unless somebody objects
[09:40] <savvas> ok :)
[10:08] <eMerzh> Hi all, if a motu want to review my package at http://revu.ubuntuwire.com/p/sqliteman i'll be glad to correct if there is errors :)
[10:09] <savvas> https://bugs.edge.launchpad.net/ubuntu/+source/bmpx/+bug/337659
[10:40] <_ruben> any hints on how to prevent stuff like this from happening: dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if "debian/open-vm-tools/usr/lib/open-vm-tools/plugins/vmusr/libresolutionSet.so" were not uselessly linked against it (they use none of its symbols).
[10:40] <_ruben> im guessing its the fault of the software itself which does unnecesary linking?
[11:01] <directhex> _ruben, it typically means the app is using "pkg-config --libs foo" and that's pulling in things it doesn't strictly needf
[11:02] <directhex> e.g. "pkg-config --libs libavcodec" will link against libvorbisenc, even if not needed by the app
[11:03] <_ruben> directhex: ic .. im guessing it might have something to do that the package has both cli and gui parts (seperate packages), and that the deps might be set too "global" ..
[11:03] <_ruben> checking for gtk+-2.0 >= 2.4.0 (via pkg-config)... yes
[11:04] <_ruben> gonna be a bitch to hunt this down (im merging an upstream release of open-vm-tools, for personal use)
[11:35]  * _ruben kicks pkg-config around a bit
[12:14] <_ruben> i give up .. pkg-config seems to pull stuff out of its ass (or perhaps something else all together)
[12:18] <pochu> _ruben: I think that's because some library is using Libs: when it wants Libs.private:
[12:19] <_ruben> pochu: which would be something that's far beyond my current packaging skills :)
[12:20] <pochu> _ruben: well, that's an upstream issue, although upstreams usually don't care about that
[12:20] <pochu> _ruben: you can ignore the warning if you want
[12:20] <_ruben> pochu: upstream of the affected libs?
[12:21] <siretart> pochu: pkg-config is clearly underdocumented, so many upstreams write broken or at least suboptimal .pc files
[12:21] <_ruben> pochu: well, unless im seeing things wrong, it results in unneeded dependencies
[12:21] <siretart> the best we can do is to send fixes for broken .pc files upstream
[12:23] <pochu> siretart: agreed
[12:23] <pochu> siretart: there are some bugs/patches for pkg-config to document *.private
[12:23] <pochu> but not merged yet though
[13:14] <goshawk> RainCT: setting up pbulder-intrepid as you said..
[13:15] <AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
[13:20] <goshawk> is it possible to install a package in a pbuilder environment for testing purposes? if yes, how?
[13:21] <RainCT> goshawk: Yes, pbuilder --login
 but my package is outside the chroot
 i can't see it from there
 i mean inside the chroot
[13:22] <RainCT> goshawk: you can use --bindmounts to share a directory between the host and the chroot, but be warned that this will delete everything inside the directory that you tell it (at least cowbuilder does)
[13:22] <directhex> or
[13:22] <directhex> or or or
[13:22] <directhex> cp foopkg /var/cache/pbuilder/build/*/tmp/
[13:23] <directhex> ^_^
[13:23] <geser> after pbuilder login
[13:23] <goshawk> so i inject the package into the chroot environment
[13:23] <RainCT> goshawk: so you can do something like:  mkdir /tmp/test; pbuilder --login --bindmounts /tmp/test; cp <files> /tmp/test
[13:23] <RainCT> directhex: uhm, right :)
[13:23] <goshawk> i used your wrapper scripts pbuilder-intrepid for it, does it accept --login? it seems no Error: «--login» is not a recognized argument.
[13:23] <directhex> goshawk, or use OTHERMIRROR and a PPA
[13:23]  * RainCT remembers that
[13:24] <RainCT> goshawk: then just   pbuilder-intrepid login
[13:25] <goshawk> i copied the package into the chroot like directhex said :)
[13:25] <goshawk> thx
[13:27] <goshawk> no auto completition for pbuilder-dist login, isn't it?
[13:28] <RainCT> nope
[13:28] <RainCT> it's a minimal environment, so it hasn't much :)
[13:28] <goshawk> i had to install the package with dpkg -i and then apt-get install -f for depends
[13:29] <RainCT> (you can install additional stuff doing   pbuilder-jaunty login --safe-after-login   installing it, and logging out, but don't put much place into it or it may interfere with builds)
[13:30] <RainCT> goshawk: That's right. You can also use "gdebi <file>.deb", which installs dependencies, but I'm not sure if that in the chroot
[13:32] <slytherin> quadrispro: geser: Thanks for working on the libdvdread transitions. :-)
[13:32] <goshawk> phone
[13:36] <elmargol> I have 2 git branches... and i like to import some changed lines... is there an easy way to do it?
[13:59] <rgreening> morning ScottK
[13:59] <rgreening> I seem to have balder2d python fixed
[13:59] <rgreening> just need to file proper bug
[14:00] <ScottK> OK.  Let me know and I'll take a look.
[14:00] <ScottK> rgreening: Or just pastebin me the debdiff
[14:01] <rgreening> sure
[14:01] <rgreening> 1 sec
[14:03] <rgreening> ScottK: try this http://paste.ubuntu.com/126280/
[14:04]  * ScottK looks
[14:05] <ScottK> rgreening: Did you test it works with 2.6?
[14:05] <rgreening> yeah. got it insalled here. ran and played the game. tried a bunch of options. went to fullscreen
[14:05] <rgreening> all seemed fine to me.
[14:05] <rgreening> got killed a lot
[14:06] <rgreening> :)
[14:06] <ScottK> OK.
[14:06] <ScottK> Why did you use just patch and not dpatch (dpatch is a lot less effort to integrate)?
[14:08] <rgreening> never played with dpatch
[14:08] <ScottK> rgreening: ^^^
[14:08] <rgreening> ^^
[14:08] <rgreening> :)
[14:09] <rgreening> patch was copy/paste from the cookbook.
[14:09] <ScottK> OK.  Interesting.  I've never actually seen someone do it that way before.
[14:09] <rgreening> I had tried quilt, but got some errors. I went to lowest common denominator...
[14:10] <rgreening> hehe
[14:10] <ScottK> There is some argument in a case like this for just inline the changes and let MoM handle it.
[14:10] <rgreening> old school from a new guy
[14:10] <ScottK> ;-)
[14:10] <ScottK> Also since it's not a K* program I wouldn't have put kubuntu in the patch name.
[14:12] <rgreening> doh
[14:12] <geser> ScottK: as you touched bmpx in the last days: any reason to keep it in Ubuntu? there is a removal request for it (bug #337659) I tend to confirm it
[14:12] <rgreening> ScottK: force of habit
[14:12] <rgreening> which I am trying to break by coming here :)
[14:12] <ScottK> geser: I just touched it for transition reasons.  I know of no reason not to remove it.
[14:13] <ScottK> rgreening: Fair enough.
[14:13] <directhex> i'm sleepy. falling asleep at my desk! zzzzzzzzzz
[14:13] <rgreening> well, I remembered the maintainer field ScottK heh
[14:13] <ScottK> rgreening: Also we don't put the maintainer change in debian/changelog.  It's actually Ubuntu Policy done to all packages, so no need to mention it.
[14:14] <ScottK> Yes, excessively.
[14:14] <directhex> update-maintainer!
[14:14] <rgreening> oh... new command for me
[14:14] <directhex> there we go, my sole reason for contributing to debian & syncing is becaise i suck at running update-maintainer so this way causes less admonishment from sponsors
[14:15]  * Laney fluffles directhex 
[14:15] <Laney> lots of lib syncs I see
[14:15] <ScottK> rgreening: Also ~ppa1 in the revision ...
[14:15] <rgreening> of course, I was testing it local.
[14:15] <directhex> Laney, yes, slomo went nuts this morning, and meebey did a few last night
[14:15] <Laney> \o/
[14:15] <rgreening> was going to change in the bug
[14:15] <directhex> Laney, one or two more i can file once the mirror push is done
[14:16] <rgreening> too quick sending debdiff
[14:16] <rgreening> ScottK: let me redo the deb dif...
[14:16] <ScottK> rgreening: No need.  I've been editing as I go along and all this stuff is minor.
[14:16] <rgreening> patch is missing something
[14:17] <rgreening> 1 sec
[14:17] <rgreening> maybe...
[14:17] <rgreening> nm.
[14:17] <rgreening> Im still asleep
[14:18] <rgreening> its all good
[14:21] <rgreening> ScottK: i'm still sending a proper diff... to ensure I got it corrected. Call it lerning by doing it over.
[14:21] <ScottK> rgreening: OK.  I'll look at it, but I'm already test building.
[14:22] <rgreening> ScottK: http://paste.ubuntu.com/126284/
[14:22] <rgreening> think I got it all this time
[14:24] <ScottK> I think so.
[14:24] <ScottK> rgreening: Next question: Does this go back to Debian?
[14:24] <rgreening> I think it's fairly innocous
[14:24] <rgreening> so it surely can
[14:26] <ScottK> Does Debian have Python 2.6 yet?
[14:26] <rgreening> that, I do not know.
[14:26] <ScottK> rgreening: Uploaded:  Thank you for your contribution to Ubuntu.
[14:26] <rgreening> yw.
[14:26] <rgreening> one less python package to worry about
[14:27] <ScottK> rgreening: rmadison -u debian python2.6 is an easy way to find out.
[14:27] <goshawk> RainCT: done
[14:27] <rgreening> I'll try another one in a bit. I assume there are sill some available to work on.
[14:27] <rgreening> ok
[14:27] <rgreening> ty ScottK
[14:28] <rgreening> hmm... rmadison doesn't appear to be reporting anything here ScottK. silently returns nothing.
[14:28] <goshawk> RainCT: and gdebi is not good in pbuilder, it carries on a lot of libgtk stuff and can make the pbuilder image dirty...
[14:28] <ScottK> rgreening: Great.  What I'd do with this is file it as a wishlist bug in Debian BTS and caveat the bug as ... when you get 2.6.....
[14:29] <rgreening> ok
[14:29] <ScottK> rgreening: I'd just send the patch, not the patch system stuff.
[14:29] <rgreening> good enough
[14:29] <rgreening> rmadison doesnt seem to work
[14:29] <rgreening> 4 me
[14:29] <ScottK> It looks like they Debian maintainer is also upstream, so I expect they'll just do a new release or something
[14:29] <ScottK> rmadison for Ubuntu is extremely slow.
[14:29] <rgreening> it just returns immediately with nothing
[14:31] <ScottK> In the case of Debian for python2.6 that's correct as they don't have it.
[14:31] <ScottK> Try it with 2.5
[14:31] <maxb> Why is Ubuntu's rmadison so slow? Is it just that people.ubuntu.com is overloaded?
[14:31] <rgreening> ScottK: ah
[14:31] <ScottK> maxb: Because it integrates with Launchpad I believe.
[14:31] <maxb> hmm
[14:32] <rgreening> ScottK: that works better
[14:32] <jpds> ScottK: It uses a mirror of the archive at people.u.c
[14:32] <ScottK> jpds: OK.  Then maybe maxb is right.
[14:32] <ScottK> It is painful, so if someone could figure a faster way ....
[14:32]  * maxb wonders how easy it would be to set up an external rmadison driven off the Packages/Sources files
[14:32] <jpds> http://people.ubuntu.com/~ubuntu-archive/madison.cgi
[14:34] <POX_> ScottK: FYI: python2.6 has the same maintainer in Ubuntu and Debian
[14:35] <ScottK> POX_: Yes, I'm aware.  I'm guessing he's just waiting for some transition to clear or something for Debian.
[14:36]  * POX_ wonders why the python2.6 transition is not made by Debian guys as clearly they have more manpower
[14:37]  * ScottK doesn't wonder.  
[14:37]  * ScottK just fixes ....
[14:37] <geser> POX_: more manpower doesn't imply that Debian moves faster than Ubuntu
[14:37] <POX_> isn't syncing easier?
[14:38] <POX_> geser: yeah, python2.5 transition was made faster than in Ubuntu (no, packages with broken memory allocation doesn't count :P)
[14:38] <geser> POX_: usually syncing is easier, but due to FF we might need to patch them anyway
[14:47] <bddebian> Heya gang
[14:47] <sistpoty|work> hi bddebian
[14:47] <bddebian> Hi sistpoty|work
[14:51] <mok0> POX_: Debian guys are busy fighting over python-central
[14:55] <POX_> mok0: no, we're not. python-support will be used, I'll make sure of it
[14:56] <POX_> read debian-python logs, nobody else wants python-central, even doko isn't complaining
[14:56] <geser> Hi bddebian
[14:56] <doko> POX_: ?
[14:56] <mok0> POX_: kk
[14:56] <mok0> POX_: ah :-)
[14:56] <POX_> doko: you didn't reply on debian-python@l.d.o
[14:57] <doko> POX_: be assured, I will. to your posting as well
[14:57] <POX_> it's too late :-(
[14:58] <ScottK> Depends on for what.  If he's got more good issues, then either you need to make Joss fix them or go back and reconsider.
[14:59] <POX_> it's always ok to report bugs, of course
[15:02] <bddebian> Heya geser
[15:19] <quadrispro> fabrice_sp__: i'm working on the tellico merge
[15:21] <quadrispro> fabrice_sp__: I think it couldn't be a good idea drop khelpcenter from Recommends field, I would prefer replace it with khelpcenter4
[15:21] <quadrispro> what do you think about this?
[15:39] <quadrispro> fabrice_sp__: package builds fine, let me know what you think about the point above, going away for some minutes
[15:44] <rgreening> Scottk: submitted bug to debian for balder2d
[15:44] <ScottK> Great.
[16:00] <cristi> hey again! so, i registered in launchpad, i read the packaging guide and tried the hello example. what should i do next in order to be able to contribute to ubuntu with packages?
[16:05] <savvas> er... I think the translations /usr/share/locale are missing from gdebi-core
[16:05] <DktrKranz> ScottK, sistpoty|work, nhandler: MC asked for motu-release charter to be published. Preliminary draft was here https://wiki.ubuntu.com/MOTU/MotuReleaseCharter, could we arrange to make a final version soon?
[16:05] <ScottK> Without actually admitting that MC has such authority to demand it, I don't see why not.
[16:06] <ara> cristi: you could have a look to the bugs listed as bitesize (https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize). These are sometime easy to fix
[16:06] <savvas> cristi: try providing debdiff patches to bitesize (easy) bugs: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[16:06] <savvas> darn :P
[16:06] <sistpoty|work> DktrKranz: looks good to me
[16:07] <cristi> ara, savvas thank you, i'll give it a look
[16:15] <savvas> Is the default locale dir /usr/share/locale or /usr/share/locale-langpack ?
[16:17] <savvas> ScottK: do you happen to know? ^
[16:19] <huats> geser: hey
[16:19] <huats> I am taking care finally of the python-webkit update
[16:19] <huats> and thus I will deal with the 2.6 transition needed
[16:20] <ScottK> savvas: No.
[16:21] <savvas> ok, thanks
[16:22] <savvas> I guess I should figure out a way to provide it for both in the program
[16:23] <savvas> probably /usr/share/locale is for the application and /usr/share/locale-langpack for the language packs
[16:34] <jdong> groan why do USB optical mice need to go into power saving mode and dim the optical circuitry?
[16:34] <jdong> it's not like that 5V/100mA LED is an atrocious waste of power and worthy of mouse lag on idle...
[16:35] <cristi> ﻿uhm, is this ok in the packaging guide? cp hello-2.1.1.tar.gz hello_2.1.1.orig.tar.gz  there is no ﻿hello-2.1.1.tar.gz, but only the .orig
[16:35] <cristi> ﻿what should i do copy the .orig ? is this what was meant?
[16:36] <jdong> if you already have the orig then you are okay
[16:36] <jdong> all that step says is that your orig should be named like hello_2.1.1.orig.tar.gz
[16:36] <jdong> the underscore before the version, .orig. before the tar.gz
[16:36] <cristi> jdong ah ok, thanks
[16:52] <cristi> how deep should my c++ knowledge be in order to fix bugs or make packages?
[16:53] <ScottK> cristi: None is sufficient.
[16:53] <ScottK> From a programming perspective if you have a bit of shell, that's enough.
[16:53] <ScottK> It's often useful if you do have more, but there's plenty to do if you don't.
[16:54] <cristi> ScottK can you give an example of such a bug that doesn't require cpp ?
[16:55] <ScottK> Currently we're going through a Python transition.  So we need to update a bunch of packages.
[16:55] <ScottK> Virtually none of those (and it's a lot of packages) need any programming.
[16:56] <ScottK> I did 4 today that just needed a recompile test and a no-change upload to build in the new environment.
[16:56] <cristi> ScottK i see
[16:56] <ScottK> Some of them need changes in their debian/rules or in postinsts scripts.
[17:27] <RainCT> niiice, geany now has highlighting for debian/rules :)
[17:38] <mok0> RainCT: emacs has highlighting for debian/control :-P
[17:39]  * RainCT will write a patch for that :P
[17:45] <hggdh> could a MOTU please tell me what is wrong on http://revu.ubuntuwire.org/p/libpst (lintian warning)?
[17:46] <mok0> hggdh: it doesn't look like anything's wrong
[17:46] <hggdh> mok0, why the warning, then?
[17:46] <mok0> hggdh: what warning?
[17:46] <mok0> hggdh: pastebin it
[17:47] <hggdh> mok0, http://revu.ubuntuwire.com/revu1-incoming/libpst-0902260309/lintian
[17:49] <mok0> hggdh: that's ok, original-maintainer is an ubuntu-specific field that lintian doesn't know about
[17:49] <hggdh> mok0, thanks
[17:50] <geser> but the version is wrong
[17:50] <eMerzh> if some motu want to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman
[17:50] <hggdh> geser, ?
[17:51] <geser> hggdh: it should be 0.6.27-0ubuntu1 instead of only -1 (that's reserved for Debian)
[17:52] <hggdh> geser, thanks, will correct
[17:54] <hggdh> ah, if I add an Ubuntu extension to the version, lintian does not complain anymore about original-maintainer in .dsc
[18:03] <RainCT> Is someone around who hasn't debootstrap intalled?
[18:05] <maxb> I'm sitting at a usb-creator intrepid installation upgraded to jaunty, if that helps
[18:06] <RainCT> maxb: Does dpkg -l | grep debootstrap return something?
[18:07] <maxb> uhm, I'm quite likely to have installed it manually
[18:09] <geser> RainCT: checked in a jaunty chroot: no output and the return value is 1
[18:10] <RainCT> geser: OK. Can you please check if directory /usr/share/debootstrap/scripts/ exists?
[18:10] <RainCT> I guess no, but just to be sure :)
[18:11] <geser> RainCT: ls: cannot access /usr/share/debootstrap/scripts/: No such file or directory
[18:11] <RainCT> geser: great, thanks
[18:13] <RainCT> ok, bug #334848 is fixed now :)
[18:33] <Brucevdk> Question, I'm trying to upload a package to a PPA. I've already sent the orig.tar.gz and now it's complaining that I'm trying to send a new orig.tar.gz that is different from the one already uploaded (which was associated with a failed build). That's the point though, I don't actually want to change the version number or anything. Is it possible to delete the orig.tar.gz or work around this?
[18:34] <Brucevdk> Maybe this belongs in #launchpad
[18:35] <RainCT> Brucevdk: delete the package, wait some days and try uploading it again
[18:35] <Brucevdk> RainCT: days :'(
[18:36] <RainCT> Brucevdk: not sure if you have to wait that much or it'll work right away
[18:36] <Brucevdk> RainCT: well, I'll do this, but if there are any other options I wouldn't mind hearing about them ;-)
[18:51] <Laibsch> RainCT: Thanks a lot!
[18:52] <RainCT> Laibsch: no problem :)
[18:54] <Laibsch> ScottK: Do you know of a simple way to find packages still depending on python < 2.6?
[18:54] <Laibsch> I'm sure, there is some dpkg or apt magic to get such a list
[18:55] <james_w> Laibsch: take a look at grep-dctrl
[18:55] <ScottK> It's not simple, but grep-dctrl is the tool you want to weild.
[18:55] <james_w> dctrl-tools is the package
[18:55] <Laibsch> alright, I think I used it once or twice in the past
[18:56] <Laibsch> I'll see about that python-4suite-xml package first
[18:56] <james_w> "grep-dctrl -FDepends -sPackage "python (<< 2.6" < /var/lib/apt/lists/*source*" might do it
[18:56] <Laibsch> It's the last one that is actually still bothering me
[18:56] <Laibsch> personally
[18:56] <ScottK> python-xml needs doing.
[19:05] <Laibsch> The package I'm trying to fix calls setup.py twice in debian/rules
[19:05] <Laibsch> Once for config
[19:05] <Laibsch> Once for build
[19:06] <Laibsch> Do I need to add "--install-layout=deb" to both calls?
[19:06] <Laibsch> I assume it should be sufficient for "build" only
[19:08] <Laibsch> Actually, setup.py is called much more often, when do I need to add the install-layout thing?
[19:09] <ScottK> install
[19:10] <Laibsch> ScottK: I assume, I should add it for install_html, too, though, right?
[19:10] <ScottK> Probably not.   You just want it when it's installing the python bits, but I'd build it and then check the resutls.
[19:16] <Laibsch> yes
[19:17] <Laibsch> the only problem is, the package took three hours to fail the build yesterday ;-)
[19:18] <Brucevdk> I feel for you, Estimated build start: in 3 hours :'(
[19:19] <Laibsch> oh
[19:19] <Laibsch> that would be the results in only after 6 hours!
[19:20] <Laibsch> actually, it says the build is only estimated to start in 4 hours here!
[19:32] <quadrispro> fabrice_sp: I'm sponsoring your application, keep up the good work ;)
[19:32] <bobbo> is there a list of packages that still need to be fixed for the Python 2.6 transition?
[19:32] <quadrispro> bobbo: hi!
[19:33] <bobbo> hey quadrispro :)
[19:34] <quadrispro> bobbo: I remember you was coming in Italy some week ago
[19:35] <Laibsch> bobbo: python-xml was mentioned here
[19:35] <Laibsch> I'm also working to get such a list from dpkg-ctrl
[19:35] <superm1> Laibsch, i'm looking at it right now
[19:35] <Laibsch> I failed so far
[19:35] <superm1> Laibsch, i think i might have it under control
[19:35] <Laibsch> superm1: cool, thanks
[19:38] <superm1> Laibsch, actually it looks like i was beat
[19:38] <superm1> RainCT, got it
[19:38] <superm1> thanks RainCT :)
[19:39] <ScottK> That should unblock quite a number of things.
[19:40] <superm1> ScottK, not fully - only in terms of apt letting them through.  see my mail to ubuntu-devel ML.  all packages using python-xml are still going to be broke.
[19:40] <ScottK> Right.  Forgot about that.
[19:41] <ScottK> superm1: I suspect doko would advise switching to a different/not deprecated XML library.
[19:42] <superm1> ScottK, well can't force upstreams to do that necessarily
[19:42] <Laibsch> if anybody with a bit of RAM in their build machine feels like trying to build https://launchpad.net/%7Er0lf/+archive/ppa/+files/python-4suite_1.0.2-7ubuntu1.dsc I'd appreciate it
[19:42] <ScottK> True, but in many cases we can patch our way around it.
[19:42] <Laibsch> the PPA will take another couple of hours to start
[19:43] <superm1> ScottK, is there anything that's close to API compatible with PyXML in the first place?
[19:44] <ScottK> superm1: It depends on what part of pyxml you're using.  Some bits are in Python itself, others can be found in other packages, some bits are unique to pyxml
[19:44] <ScottK> We tried, and failed once to push it all the way out of the archive.
[19:44] <fabrice_sp> quadrispro, thanks ;-)
[19:44] <superm1> ScottK, looks like xml.dom, xpath, htmllib
[19:45] <ScottK> It was a while ago I looked at these, so I don't recall....
[19:45] <superm1> and there's some comments that "The Python SGML based HTML parser is unusable (it finds tag starts/ends in the worst way possible" in the code, so not too reassuring
[19:59] <Zarel> Hi, everyone. The warzone2100 package in the intrepid repositories is very out of date - it's 2.1.0-beta4, and 2.1.1 has already been released. Since this is beta -> stable, nearly all the changes have been [important] bugfixes, so is there any chance someone could go and update it?
[19:59] <Zarel> -> http://packages.ubuntu.com/intrepid/warzone2100
[20:11] <fabrice_sp> Zarel, before being able to have it in Intrepid, we need to have it in Jaunty. Actual version for Jaunty is 2.1.0-1...
[20:12] <Zarel> fabrice_sp: Can we at least get 2.1.0-1 into Intrepid, then?
[20:13] <fabrice_sp> we are in Feature Freeze, so we need a good reason to upgrade it :-)
[20:13] <Zarel> fabrice_sp: It's a bugfix release, no new features?
[20:13] <Zarel> Is that a good enough reason?
[20:13] <Zarel> Also, it's stable rather than beta.
[20:14] <fabrice_sp> Zarel, yeah, but in this case, you have to compare the version that we will have in Jaunty and the latest one, so its stable with stable
[20:14] <fabrice_sp> I also have to check if no new features are there
[20:15] <Zarel> What do you mean by "compare the version"?
[20:15] <fabrice_sp> it seems to be a fix only release, you're right
[20:16] <fabrice_sp> so I'll try to compile the version in Debian, and if it works, I'll fill a sync request
[20:16] <Zarel> Thanks.
[20:17] <fabrice_sp> Zarel, do you volunteer to test it?
[20:17] <fabrice_sp> :-D
[20:17] <Zarel> Define "test"
[20:18] <fabrice_sp> install the version I will put in my ppa, and check it's working fine
[20:19]  * fabrice_sp builds warzone2100 2.1.1-1
[20:19] <Zarel> I only have three installs of Ubuntu - one of them I don't have package installation permissions, and the other two are VMs which aren't fast enough to run Warzone. Sorry. :/
[20:20] <Zarel> I can verify that sound apparently doesn't work on a default install of Warzone in Ubuntu. We've gotten lots of bug reports about that. :P
[20:21] <fabrice_sp> You're upstream?
[20:21] <Zarel> Depends on your definition of "upstream". For most definitions, I'd say yes.
[20:22] <fabrice_sp> k. Nice game by the way!
[20:22] <Zarel> Thanks.
[20:24] <fabrice_sp> it builds fine. I'll fill the sync request
[20:25] <directhex> isn't warzone an old strategy game from the 90s? or am i misremembering
[20:25] <Zarel> directhex: 1999, to be exact.
[20:25] <Zarel> It was open-sourced in 2004.
[20:26] <directhex> oh, neato
[20:30] <fabrice_sp> directhex, if you're interested in sponsoring the sync, I'll give you the bug number as soon as it appears ;-)
[20:30] <directhex> fabrice_sp, i'm not a motu
[20:32] <fabrice_sp> just in case some MOTU or U-C-D is interested in warzone2100: bug #337915
[20:35] <Zarel> Eheh, 2.1.1 isn't that big of a deal - it only had one bugfix from 2.1.0, and that was only for Macs.
[20:36] <fabrice_sp> Zarel, yes. It seems to be quite stable ;-)
[20:36]  * fabrice_sp installing version 2.1.1
[20:41] <fabrice_sp> working fine, even with sounds ;-)
[20:42] <Zarel> :D
[20:42] <Zarel> Good sign.
[20:42] <fabrice_sp> yep :-)
[20:45] <_16aR_> Hello
[20:45] <fabrice_sp> hello _16aR_
[20:45] <_16aR_> When we compile for amd64, does the CFLAGS enables old i686 function like MMX, etc ?
[20:45] <_16aR_> or we must enable them into the debian/rules ?
[20:46] <RainCT> fabrice_sp: sync request ack'd
[20:46] <_16aR_> by the way, how can we help for package stabilisation in jaunty ?
[20:46] <fabrice_sp> thanks RainCT ;-)
[20:47] <RainCT> No problem. I'm off now, see you tomorrow :)
[20:47] <fabrice_sp> CU! bye
[20:47] <fabrice_sp> _16aR_, you can check http://qa.ubuntuwire.com/
[20:48] <fabrice_sp> and check rcbugs, for example
[20:49] <_16aR_> ok fabrice_sp, thanks
[20:50] <fabrice_sp> you're welcome ;-)
[21:25] <quentusrex> Hello
[21:25] <quentusrex> Anyone here use kvm?
[21:26] <quentusrex> or libvirt?
[21:30] <directhex> a little
[21:44] <jpds> quentusrex: Might want to try #ubuntu-virt too. :)
[21:44] <quentusrex> jpds: I'm in there too :)
[21:45] <quentusrex> directhex: would you be interested in helping to backport libvirt 6.1 to intrepid?
[21:45] <quentusrex> or even to hardy?
[21:45] <directhex> quentusrex, i can test on intrepid, but not hardy. and i have too much on my plate to help do it
[21:46] <quentusrex> yeah, I can test on intrepid as well
[21:46] <quentusrex> I'm not too skilled on how to package for ubuntu yet...
[21:47] <Amaranth> cody-somerville: how does one get to talk in #xfce-dev?
[22:04] <khashayar> Hey folks, does anyone here have a couple of minutes to review pencil (http://revu.ubuntuwire.com/details.py?package=pencil)? We really need it for ubuntu studio (we're going to file exceptions).
[22:09] <cody-somerville> Amaranth, like that
[22:20] <TheMuso> c
[22:45] <ripps> Is it possible to modify functions in a debian/rules file that's been inherited from a include?
[22:46] <ripps> I'm trying to add dpatch support, but the file is practically only includes from cdbs.
[22:46] <ScottK> There's a cdbs rule for dpatch you can use.
[22:47] <ScottK> Don't try and add it by hand.
[22:47] <ripps> okay, thanks
[23:08] <POX_> doko: make sure you don't have "/local" somewhere in distutils.cfg (another user complained about it)
[23:08] <orci> hi all, sorry again if wrong place but wiki.ubuntu.com is having problems
[23:13] <ScottK> POX_: I had that once and it just needed the layout-deb magic added.
[23:13] <ScottK> orci: This is the wrong place.  I suspect #canonical-sysadmin.
[23:13] <POX_> /usr/local or /local?
[23:14] <ScottK> Oh.
[23:14] <ScottK> Nevermind.
[23:14] <ScottK> /usr/local
[23:14] <POX_> maybe I misunderstood him, though
[23:14]  * POX_ goes to bed
[23:14] <orci> ScottK-desktop, OK thanks
[23:47] <mrooney> hello motu friends, what are we doing with bugs resulting from the python 2.6 upgrade such as bug #338004, where python < 2.6 is required
[23:52] <james_w> mrooney: ah, that's where we just haven't got to it yet
[23:52] <james_w> there are people tracking those down and fixing them
[23:52] <james_w> I thought you were referring to a bug about a package now working when run under python2.6
[23:53] <mrooney> james_w: ah so a package which explicitly requires << python 2.6 will be noticed, ones that don't declare that are the ones to announce?
[23:54] <james_w> mrooney: yeah, in general
[23:54] <james_w> we can search for the former
[23:54] <james_w> the latter might be very subtle
[23:54] <mrooney> james_w: right you couldn't automatically detect that except by running some tool to find common upgrade issues on all the python packages
[23:56] <ajmitch> especially when the failures end up being in things like wxpython
[23:56] <mrooney> ajmitch: oh, has that happened
[23:56] <mrooney> I have a wxPython app in Jaunty
[23:57] <ajmitch> things like that have happened, wxpython was just an example of a complicated steaming mess :)