[01:26] <porthose> directhex: 175 mib used when play a track, sorry it took so long, life got in the way
[01:35] <directhex> stupid life. try patching it!
[01:35] <directhex> porthose, that's a huge number! that's the "Writable Memory" column?
[01:36] <porthose> oops how about 22 mib
[01:36] <directhex> 32 bit cpu?
[01:37] <kklimonda> porthose: nice, my banshee uses almost 70 :/
[01:38] <kklimonda> seems like rhythmbox is still better when it comes to memory consumption :/
[01:38] <directhex> that's a remarkably low value for a library of that size, porthose
[01:38] <directhex> kklimonda, it's about 25% better with mono 2.4
[01:38] <kklimonda> directhex: is mono 2.4 going to get into 9.10?
[01:39] <directhex> kklimonda, yes
[01:39] <directhex> kklimonda, waiting for 2.4.2 bugfix release on monday
[01:39]  * porthose double checks
[01:44] <porthose> directhex: yea it's showing 28 to 29 mib writable memory
[01:44] <directhex> porthose, that was i386 or amd64?
[01:44] <porthose> i386
[01:44] <directhex> okay, makes sense
[01:45] <directhex> i get pretty much the same values from RB, with a much smaller library - but on amd64
[01:46] <directhex> now, i totally need to go to bed
[01:47] <porthose> directhex: night
[04:07] <ausimage> ajmitch: you track down how I presumably broke review?
[06:15] <dholbach> good morning
[06:15] <slytherin> dholbach: good morning
[06:15] <dholbach> hi slytherin
[06:28] <fabrice_sp>  good morning dholbach !
[06:28] <dholbach> heya fabrice_sp
[06:41] <mochaRHW> hello, anyone here I can ask a quick question about Atheros drivers?
[07:01] <mochaRHW> hello?
[07:03] <dholbach> mochaRHW: maybe #ubuntu-kernel? but just ask
[07:03] <dholbach> no need to ask to ask :)
[07:04] <mochaRHW> I was just wondering if anyone knows what version of madwifi was used to build the ath_pci.ko module in Jaunty?
[07:05] <mochaRHW> modinfo says "D3FD3BD11169A96DBCFF8DE"
[07:05] <dholbach> definitely #ubuntu-kernel
[07:05] <mochaRHW> ok, I'll try
[07:05] <dholbach> the -motu team does not maintain any parts of the kernel
[07:05] <dholbach> good luck
[07:05] <dholbach> the kernel people might wake up in a few hours
[07:07] <mochaRHW> yea, seems like everyone is asleep!
[07:07] <dholbach> :)
[07:07] <mochaRHW> no one in #madwifi either
[08:51] <geser> good morning
[09:00] <MooKow> buildd issues?
[09:00] <LordKow> .
[09:01] <geser> looks like it
[09:01] <gaspa> geser: you mean the one about mktemp package?
[09:02] <geser> yes
[09:02] <gaspa> what happened?
[09:02] <geser> don't know
[09:02] <gaspa> :)
[09:03] <wgrant> coreutils contains and now Conflicts with mktemp.
[09:03] <wgrant> apt doesn't like removing Essential packages, which mktemp is.
[09:03] <wgrant> A fixed coreutils has been uploaded (producing a transitional non-Essential mktemp binary), but it needs to be built manually.
[09:06] <geser> wgrant: btw: should we leave hppa in the FTBFS list (for now) or remove it as it's e-o-l?
[09:06] <wgrant> geser: I think I might just remove it, as I don't think a DAS can be removed from Soyuz...
[09:28] <AnAnt> can someone sponsor those:  LP #359436 , LP #359444 , LP #359446 ?
[09:30] <qiyong> hey, how the US and europe economics now?
[10:32] <hyperair> does anyone here use tcptrack?
[10:33] <hyperair> it's currently pretty useless in jaunty and karmic; no connections are shown at all
[10:38]  * kmdm peers at debuild -S checking build-deps rather than just spitting out a source package to be built with pbuilder...
[10:40] <hyperair> kmdm: -S -d
[10:40] <kmdm> hyperair: It's doing...  debuild -S dpkg-buildpackage -rfakeroot -d -us -uc -S
[10:41] <kmdm> (pretend there's a linefeed in there)
[10:41] <hyperair> heh
[10:41] <hyperair> strange.
[10:41] <hyperair> it should work
[10:41] <kmdm> yeah, quite - this always used to work...not my first package build by any stretch of the imagination
[10:42] <hyperair> hehe
[10:42] <hyperair> well try running dpkg-buildpackage then
[10:43] <kmdm> I guess I should examine debian/rules and see what it's doing there... but am I right in thinking in general building the source package doesn't need to check the build-deps since they get resolved by pbuilder when doing the binary package?
[10:44] <kmdm> hyperair: Bah, this package depends clean on configure, which then checks the build-deps... *sigh*
[10:44] <hyperair> ha. no wonder.
[10:45] <hyperair> ooh netsplit.
[10:45] <hyperair> kmdm: it's ./configure checking for builddeps then? and not dpkg-checkbuilddeps?
[10:45] <kmdm> well, it's calling dpkg-checkbuilddeps manually
[10:46] <jpds> hyperair: Yeah, tcptrack looks broken.
[10:46] <hyperair> jpds: =(
[10:46] <kmdm> it looks like the packager's assumed that everyone bulds in place since they're doing make clean style stuff too
[10:47] <hyperair> i'd fix it, but this looks beyond my capabilities.
[10:47] <hyperair> heh no wonder.
[10:47] <jpds> hyperair: Still, who needs it when we have tcpdump, tcpflow, iptraf, .....
[10:47] <hyperair> kmdm: you mean debian/rules calls dpkg-checkbuilddeps?
[10:47] <kmdm> hyperair: Aye, well... checkbuild: chmod u+x ./debian/dpkg-checkbuild ./debian/dpkg-checkbuild debian/control
[10:47] <hyperair> jpds: i liked tcptrack's interface. i use iptraf otherwise, but the thing is that tcptrack shows the rates of each connection in real time. iptraf only shows one at a time.
[10:47] <kmdm> (with linefeeds) :)
[10:47]  * hyperair facepalms
[10:48] <hyperair> kmdm: wipe it out and package it from scratch
[10:48] <hyperair> or salvage the bits that you can
[10:52] <directhex> kmdm, sometimes you can't run "make clean" without "./configure"
[10:52] <directhex> kmdm, which causes scenarios where you need build-deps in order to make a source package
[10:52] <kmdm> directhex: Aye, they were guarding a make clean/distclean in there
[10:53] <directhex> kmdm, that makes less sense
[10:54] <kmdm> If anyone's curious enough: https://launchpad.net/~kees/+archive/ppa/+files/heartbeat_2.1.4-2~hardy1.dsc (seems to be a direct backport from upstream to Hardy)
[10:54] <kmdm> I'm just trying to coax it onto dapper at the moment, could be a losing battle though. :)
[10:56] <savvas> well if you think it's going to be useful for the server, it's worth a try, you can also backport its dependencies if you think that's required :)
[10:57] <kmdm> Anyone know if dapper had some equivalent of python-central?
[12:04] <stani> pochu: What means 'declined for Karmic' at bug #370839?
[12:06] <pochu> hey stani! looking
[12:06] <pochu> stani: it means there's no need to open a karmic task, the "normal" task can be fixed in karmic as it's the development cycle
[12:07] <stani> pochu: I am a bit confused if this bug should be a SRU or not
[12:08] <stani> pochu: I am afraid there will come more duplicate bugs
[12:08] <stani> pochu: I mean for Jaunty
[12:08] <slytherin> stani: I don't think 'changing build depends' would be allowed in SRU.
[12:09] <stani> and it if it's a SRU for Jaunty, it should be fixed in Karmic first right?
[12:09] <stani> slytherin: it's not about 'build depends' but about 'depends'
[12:10] <pochu> slytherin: it's a new ORed dependency
[12:10] <pochu> stani: seems fine to me, will the kiki.py change still work with wx2.6?
[12:10] <stani> slytherin: and the dependencies causes bugs in Jaunty because in Jaunty wxpython 2.6 is the default, while before it was 2.8
[12:11] <pochu> it sounds fine as it won't change anything for people that already have it
[12:11] <stani> pochu: it will work even better, as now kiki uses a deprecated class of wxpython2.6
[12:11] <pochu> except for the code change, but if it still works with 2.6 it should be fine IMHO
[12:11] <pochu> stani: ok cool
[12:12] <pochu> stani: so it just needs to be uploaded to karmic, and then we could SRU it
[12:12] <pochu> with approval from the MOTU SRU folks, of course
[12:12] <stani> pochu: yes
[12:12] <stani> pochu: I am just doubting what would be the best reason for the SRU
[12:13] <pochu> stani: does it still break SPE, even after your SPE SRU?
[12:14] <slytherin> stani: my mistake, got confused.
[12:14] <stani> it might be the use of deprecated class, breaks with wxpython2.8, unnecessarily making a dependency of wx2.6
[12:14] <pochu> the unneeded dependency is probably not a good enough reason, I guess
[12:15] <pochu> so unless it still breaks something, we can leave it
[12:15] <pochu> i.e. if SPE works fine now after the SRU
[12:15] <stani> pochu: no my SPE sru fixes SPE of course, but now spe is dependent of 2.6 and 2.8, but it will break applications which are only compatible with 2.8
[12:15] <stani> so SPE is fixed, but there will be others which might break
[12:15] <pochu> hmm, you could say that as the reason for the SRU
[12:15] <stani> not every other application uses wxversion to force a wxpython version
[12:16] <stani> now wxpython applications assume 2.8, not 2.6
[12:16] <pochu> so if kiki uses 2.6 and your app doesn't care, will it pick up 2.6?
[12:16] <pochu> even if both 2.6 and 2.8 are installed?
[12:17] <stani> yes, this is another sru bug, for which I submitted a fix, which I guess mok0 is dealing with
[12:18] <pochu> stani: I mean, in general
[12:18] <pochu> not specifically with SPE
[12:18] <stani> pochu: yes all other applications which expect 2.8 are affected
[12:19] <pochu> stani: that's a good reason then IMHO
[12:19] <stani> for example if you have an application which depends on python-wxgtk2.8, it will use wxpython 2.6 when it just does an "import wx"
[12:19] <stani> and most likely this application will fail
[12:19] <pochu> oh
[12:20] <pochu> but that's the wxwidgets bug, right?
[12:20] <stani> no
[12:20] <stani> the application could use wxversion to select its versions, but most apps don't care
[12:20] <stani> they suppose you've installed the right wxpython version
[12:21] <pochu> okay
[12:21] <pochu> so let's just fix it
[12:22] <stani> pochu: it doesn't break directly, but it will provoque breaking
[12:22] <pochu> yeah, it's alright then
[12:23] <stani> pochu: if you read the original bug report, you see that the author complains that his applications don't work any more. probably he doesn't know he could fix it with wxversion, but there will be more people like this
[12:23] <stani> pochu: you want me to start the SRU process? (with the hope you will back me up)
[12:25] <pochu> stani: yes, but it needs to be uploaded to karmic first
[12:28] <stani> pochu: this is in the pipeline right? I could already prepare the SRU process as I did for bug #377044 (read first line)
[12:29] <stani> pochu: and it would be nice if you could give feedback on that bug (as the SPE sru fix is now waiting in -proposed)
[12:29] <pochu> stani: I only have Hardy here :(
[12:30] <stani> pochu: than you can beta test the new Phatch from my PPA ;-) (just joking, no obligations)
[12:34] <pochu> stani: yeah I can do that ;)
[12:35] <pochu> stani: the PPA is ~stani ?
[12:35] <stani> pochu: yes, more info here http://ubuntuforums.org/showthread.php?t=1178224
[12:41] <stani> pochu: do you know why Phatch fails to build by a "chroot problem", see https://launchpad.net/~stani/+archive/ppa/+build/1060898?
[12:42] <stani> pochu: that only happens on Karmic
[12:46] <pochu> stani: everything's failing to build
[12:46] <pochu> stani: see #ubuntu-devel's /topic
[12:48] <stani> pochu: ok, so it is just a matter of time
[12:48] <pochu> yup
[13:03] <cjwatson> wgrant: we're killing karmic/hppa now
[13:03] <cjwatson> wgrant: it will have the side-effect that builds for karmic/hppa will basically never have happened, but lamont says he's ok withthat
[13:03] <cjwatson> with that
[13:03] <wgrant> cjwatson: I didn't think that was possible without a bit of manual DELETE action.
[13:03] <wgrant> That explains it.
[13:03] <wgrant> That's a bit ew, though.
[13:04] <cjwatson> it is a bit. but the alternative is having karmic/hppa continue to show up as a sort of ghost town.
[13:04] <cjwatson> I'd honestly rather it just went away and I don't think anyone *really* cares enough ...
[13:04] <wgrant> Or convince Soyuz people to implement a DAS.disabled flag.
[13:04] <wgrant> Of course. But altering history is always a little iffy for me.
[13:32] <stani> pochu: I prepared the SRU request, so it can start once it is uploaded to Karmic https://bugs.launchpad.net/ubuntu/+source/spe/+bug/370839
[14:54] <mterry> I'm looking at a FTBFS that seems like it should BFS.  I might just be missing some details about buildds.  Does anyone have a sec to look at bug 383921?
[14:54] <mterry> It builds in my chroot, and the buildd tried to build it a full month after librcc was done building.  So it seems like the buildd should have been able to get librcc.
[14:55] <slytherin> mterry: what is BFS?
[14:55] <mterry> slytherin: Build From Source
[14:58] <slytherin> mterry: You can ask someone from core team to give back the package. Try #ubuntu-devel. Please mention that it builds fine in your karmic chroot.
[14:59] <mterry> slytherin: Hmm, OK.  Still curious why it failed.  Maybe they'd know
[15:19] <cjwatson> (for the record, the reason mterry couldn't reproduce the bug was that his chroot had universe enabled and the buildd's chroot didn't since it was building for main
[15:19] <cjwatson> )
[15:20] <mterry> cjwatson: :)  Thanks
[17:22] <savvas> now that the coreutils bug is fixed, the builds that had problems are set to be rebuilt right?
[17:23] <savvas> in cgal it says "Needs building", just checking, in case I have to do any requests: https://edge.launchpad.net/ubuntu/+source/cgal/3.4-4ubuntu1/ :)
[17:26] <cjwatson> savvas: yes, they are set
[17:26] <geser> I guess a mass-giveback will happen (if it did not already happen)
[17:26] <cjwatson> "needs building" is what you get *after* a mass give-back
[17:26] <cjwatson> and before it's actually built
[17:26] <savvas> cool, thanks :)
[17:34] <jdstrand> slangasek: hi! what is the process for a sync request from debian-multimedia? eg, bug #378124
[17:44] <pwnguin> hyperair: how stable is your unstable banshee ppa?
[17:44] <hyperair> pwnguin: as stable as banshee unstable is.
[17:45] <pwnguin> ie, there's a 1.5 release as of june 1st
[17:45] <pwnguin> it seems to have rhythmbox imports, which i'd like to try out
[17:46] <pwnguin> but im not sure i want to upgrade daily
[17:47] <pwnguin> ah, i see. they use an even/odd numbering
[17:48] <pwnguin> hyperair: so the unstable ppa tracks the official beta releases, and you have a seperate daily build?
[17:48] <hyperair> pwnguin: bingo.
[17:48] <pwnguin> ok, that makes more sense
[17:50] <hyperair> pwnguin: what confused you? perhaps i can amend the descriptions
[17:59] <pwnguin> hyperair: i wanst sure what the difference between unstable and daily was
[17:59] <hyperair> i see.
[18:00] <pwnguin> you might make a note that the unstable is from official upstream unstable releases
[18:00] <pwnguin> not all projects have unstable release series like that
[18:01] <slangasek> jdstrand: update-sources should grab from debian-multimedia; then you just need to pass a -D option to sync-source.py (or syncbugbot)
[18:02] <jdstrand> slangasek: that is what I figured, but wanted to be sure. thanks!
[18:04] <hyperair> well you can enable all three PPAs together
[18:07] <mterry> With regards to inclusion in 'main', is it by source package or by binary package?
[18:14] <superm1> mterry, the source package has to be in main for any of the binary packages to be in main. not all of the binary packages have to be in main though
[18:14] <superm1> see lirc for example, it's source is in main, and liblircclient0 is, but 'lirc' and 'lirc-x' aren't
[18:14] <mterry> superm1: Cool.  OK
[18:26] <nixternal> anyone have any idea as to why sun-java6-plugin deps on the following:
[18:26] <nixternal> firefox | firefox-2 | iceweasel | mozilla-firefox | iceape-browser | mozilla-browser | epiphany-gecko | epiphany-webkit | epiphany-browser | galeon | midbrowser | xulrunner
[18:26] <nixternal> no konqueror in there, arora, rekonq...discrimination I tell you!
[18:26] <nixternal> why not just x-www-browser?
[18:29] <sebner> nixternal: firefox2 is obsolete, what's arora rekonq? ^^
[18:29] <nixternal> 2 new KDE browsers
[18:29] <nixternal> plus Konqueror isn't even in the list there
[18:29] <vorian> arora?
[18:30] <nixternal> though I don't even know if arora or rekonq have java support yet, I was being a bit of an ass with those 2 :)
[18:30] <vorian> <3 arora
[18:30] <geser> does the plugin work with those and is installed in the right dir?
[18:30] <nixternal> arora is qt not kde
[18:30] <nixternal> geser: yup
[18:30] <nixternal> well it works with konqueror
[18:30] <nixternal> I don't know about the other 2
[18:31] <vorian> I have to use sun-java6-bin (i think) to get java properly working with arora
[19:48] <ausimage> ajmitch: how is the REVU issue comming along :S
[22:41] <nhandler> Is there a way to have dch act as if I am on Debian? When it creates a new changelog entry, it wants to append ubuntu1 instead of bumping the Debian revision
[22:54] <cody-somerville> dtchen, interestingly, no sound at all with new kernel
[22:54] <cody-somerville> dtchen, will try old kernel once I get back from walk with the dog.
[22:55] <nhandler> For those interested, it appears that I can use the --distributor option
[22:56] <cody-somerville> dtchen, hm.... killing pulseaudio fixed the problem
[22:59] <dtchen> cody-somerville: usually a mixer element (volume)/sink issue
[23:20] <bencrisford> I am getting a debuild error today :/
[23:20] <bencrisford> yesterday debuild -S worked fine
[23:20] <bencrisford> but on a package today it wont
[23:21] <bencrisford> http://paste.ubuntu.com/189282/
[23:22] <JontheEchidna> bencrisford: you need to build-depend on the gnome-pkg-tools package
[23:22] <JontheEchidna> and also install it on your system ;-)
[23:23] <directhex> nhandler, yes, there is a way
[23:23] <nhandler> directhex: I found it, see above
[23:24] <bencrisford> JontheEchidna: Oh, how do I do that =S?
[23:24] <bencrisford> just install the gnome-pkg...
[23:25] <bencrisford> and do apt-get install build dependencies?
[23:25] <JontheEchidna> then in debian/control, put gnome-pkg-tools in the build-depend sline
[23:25] <JontheEchidna> *line
[23:26] <bencrisford> JontheEchidna: Ohhh..  Ok, thanks :)
[23:26] <JontheEchidna> :)
[23:35] <cjwatson> nhandler: -U
[23:36] <cjwatson> (or yes, --distributor)