[12:43] <Riddell> test what?
[12:43] <Riddell> there's too many things to test automatically
[12:45] <mhb> Riddell: you're probably right (as usual), but still, does C. use any tools for some CD testing tasks? Like testing whether it boots on a generic machine, or such.
[12:45] <Riddell> nope
[12:46] <Riddell> on the whole if it doesn't boot we'll know about it
[12:47] <mhb> Riddell: right, but I get the feeling using humans to test whether it boots is a waste of valuable resources
[12:47] <mhb> of course, hardware-specific tests have to be made, but generic tests should be conducted before that
[12:48] <Riddell> writing something like that might be interesting
[12:48] <Riddell> but testing CDs is about a lot more than just booting
[12:50] <mhb> Riddell: true
[12:56] <mhb> testing frameworks are neat nonetheless... I am looking forward to the day when apport will be able to collect necessary information for my system switching to console from usplash
[01:18] <nixternal> thanks for the heads up on the --list-missing...so far kdelibs has none missing :)
[01:18] <nixternal> Riddell: ^^
[01:19] <Riddell> groovy
[01:19] <Riddell> nixternal: did you grab the other tabs?
[01:19] <nixternal> you lost me with "tabs"
[01:19] <nixternal> yes
[01:19] <nixternal> derrr
[01:20] <nixternal> pimlibs and base, and I will grab more as I go on
[01:21] <Riddell> tars
[01:21] <nixternal> ya...I kind of took tabs as a shrunken version of tarballs :)
[01:39] <Riddell> "we will start working on a Kubuntu LiveCD with KDE 4 once it starts to stable out a little more" mostly I'm waiting for the CD creation script to be released
[01:40] <nixternal> ya, but I wasn't 100% sure what we were waiting for, so I made that up a little
[01:40] <nixternal> try to prevent the bashing ahead of time
[01:42] <nixternal> ya, I don't look at digg much, but someone mentioned it to me so I went to do a "fire prevention" type post there
[01:42] <nixternal> at least all of the comments there are positive...which I never expect from digg
[01:43] <Riddell> :)
[01:44] <nixternal> I love how fast kdelibs builds
[02:41] <mhb> hmm, I've got a young grasshopper question for a wise python-qt coder out here: is there a significant performance loss when doing "from qt import *" compared to "from qt import JustWhatYouNeed" ?
[02:43] <mhb> pylint is complaining about it, and I've read other papers that were against it, but it is quite hard to work in PyQt without it.
[02:47] <nosrednaekim> It takes longer to import, uses more memory, and its not as safe.
[02:48] <nosrednaekim> un-safe as in there are more functions imported into your base namespace.
[02:48] <mhb> nosrednaekim: yeah, that's what they tell you :o)
[02:49] <nosrednaekim> :)
[02:49] <mhb> nosrednaekim: what I'd like to know is the numbers ... whether removing the "*" for pyqt and pykde makes your apps run like ferraris
[02:50] <mhb> or it's just a 0.01 sec that you won't miss in a configuration tool you launch once a millenium
[02:51] <nosrednaekim> well, I have just heard about the speed thing. I did notice the cut down in namespace though... I was dumb enough to name one of MY functions the same as a fuction that I imported with a *
[02:54] <mhb> nosrednaekim: right, it should speed your apps up, that's why pylint and others warn you.
[02:54] <mhb> nosrednaekim: I just wanted to know the size of the speedup.
[02:54] <nosrednaekim> hmm I don't know. let me test something :)
[02:57] <nosrednaekim> lol... just importing what I wanted made the start-up time about 5 times SLOWER
[02:57] <nosrednaekim> :)
[02:58] <mhb> nosrednaekim: you sure?
[02:58] <mhb> nosrednaekim: didn't you have a .pyc for one and not for the other?
[02:58] <mhb> just guessing
[02:58] <nosrednaekim> I did a whole bunch of imports from system moduels
[02:58] <nosrednaekim> *modules
[02:59] <mhb> moduels, that's a nice typo :o)
[03:01] <nosrednaekim> when I "import *" the time is "real    0m0.044s"
[03:02] <nosrednaekim> when I "import <module name>" its "real    0m0.190s"
[03:02] <nosrednaekim> or so.
[03:05] <mhb> I guessed that
[03:05] <mhb> thanks for testing
[03:08] <milian> kmail crashes everytime I try to paste somthing into the composer
[03:09] <milian> since it's still v3.5.7 I think it's some kubuntu changes?
[03:09] <milian> feisty was very stable
[03:09] <mhb> milian: thanks for reporting, nixternal told us the same thing
[03:09] <nixternal> there is a bug report for it, I haven't looked at it yet
[03:09] <mhb> milian: yes, it's either us or the new "enterprise" branch of kdepim
[03:10] <milian> mhb: good
[03:10] <milian> nixternal: better :)
[03:13] <milian> damnit, it's kinda hart to not paste anything in a mail :D
[03:13] <milian> even if you know it doesnt work and you'll lose all your content...
[03:14] <mhb> milian: yeah, bugs like this are the reason why we don't recommend gutsy for production
[03:14] <milian> ++
[03:14] <milian> I'm bleeding for the bleeding edge ;-)
[03:14] <milian> and someone has to use it to find some bugs
[03:14] <mhb> milian: but I'm quite sure it gets fixed soon, because the devs also write emails sometimes
[03:16] <nixternal> mhb: I think all of the devs use Mutt :)
[03:17] <nosrednaekim> I Pine for those old days of Mutt.
[03:18] <milian> I'm off to bed
[03:18] <milian> have a good night (or day)
[03:18] <mhb> nixternal: oh do they? That means I'm not a dev :o)
[03:19] <mhb> nixternal: time to change my appearance then ... fr0m n0w 0n 1'M a scr1pt k1dd13 :o)
[03:19] <nixternal> mhb: hahaha
[03:22] <nosrednaekim> :)
[03:43] <mhb> nosrednaekim: by the way, do you happen to know about an "krazy"-like code checker for python-qt/kde ?
[03:44] <mhb> nosrednaekim: pylint or pychecker are cool, but they aren't "krazy" enough :o)
[03:44] <nixternal> Riddell: up to kdebase, and I just realised they split it into -workspace as well...this one may be a little tricky for my current newbset
[03:46] <nosrednaekim> I don't check my python code... I just run it :)
[03:46] <nixternal> I just run mine too, and then it yells at me
[03:47] <mhb> heh, still it won't yell if you do some childish thing that will make your app 2x slower or so, but it'll work
[03:47] <mhb> and code checking for basic/common mistakes is what I'd like
[03:48] <mhb> (which is what krazy does)
[03:48] <mhb> hm, let's try #python
[03:56] <nosrednaekim> yes.. that would be the ideal location..
[04:02] <nosrednaekim> who maintains adept?
[04:03] <Jucato> apt-cache show adept says...
[04:03] <Jucato> Riddel
[04:03] <Jucato> original maintainer would be mornfall though
[04:04] <nosrednaekim> Riddell it is... I want a simple feature added. I guess I should file a wishe
[04:04] <Jucato> what feature would that be?
[04:04] <Jucato> a patch would be better than a wishie ehehe
[04:09] <nosrednaekim> patch for download script support
[04:09] <nosrednaekim> I don't know C++, but I coded up a little python script to do it.
[04:21] <nosrednaekim> I guess you can't call python from a C++ app.
[04:22] <mhb> nosrednaekim: no
[04:22] <mhb> nosrednaekim: well, hardly
[04:22] <nosrednaekim> I guess you COULD call a python script though.
[04:22] <nosrednaekim> as a os.sytem call
[04:22] <nosrednaekim> or whatever it is in C++
[04:22] <mhb> nosrednaekim: that you could, but it's usually easier to reimplement the original code
[04:23] <mhb> and faster and nicer and whatever :o)
[04:23] <nosrednaekim> yeah and seeing as how the original code is only 15 lines....:)
[04:23] <mhb> nosrednaekim: however, the future of Adept is unsure
[04:23] <Jucato> it is? O.o
[04:24] <nosrednaekim> uhh oh.
[04:24] <nosrednaekim> what are they going to replace it with?
[04:24] <mhb> nosrednaekim: there was some gossip about creating a Python app for that, with KDE and GNOME frontends
[04:24] <Jucato> (eeek!)
[04:25] <nosrednaekim> :)
[04:25] <nosrednaekim> sounds good.
[04:25] <mhb> Jucato: you're the upstream, so I guess you're screaming eeek! because you spent your whole day today in improving and porting adept to KDE4 :o)
[04:25] <nosrednaekim> lol
[04:26] <Jucato> hahah
[04:26] <Jucato> what's KDE4?
[04:26] <Jucato> lol
[04:27] <mhb> Jucato: from my point of view it's a complicated piece of software that should share its backend with the GNOME counterpart, but doesn't
[04:27] <mhb> Jucato: sharing backends is great. You know why? Because we can leave fixing bugs to the Ubuntu devs and our (KDE) app will be improving for free
[04:28] <mhb> and we can slack and write plasmoids or something
[04:28] <Jucato> yeah back/front ends are great
[04:28] <Jucato> no doubt about that
[04:29] <Jucato> and  I guess the easiest frontend to use would be python, eh?
[04:29] <nosrednaekim> python a frontend?
[04:29] <nosrednaekim> huh?
[04:29] <mhb> frontend language, I guess
[04:29] <Jucato> PyKDE
[04:29] <mhb> yes, because the bindings are binaries anyway, so it's not very slow anyway
[04:30] <mhb> too much anyways :o)
[04:30] <nosrednaekim> PyKDE4 hasn't been released yet... I'm waiting VERY impatiently for it.
[04:30] <mhb> nixternal: hmm, not much help from the great gurus in #python
[04:30] <mhb> nixternal: it seems that when you ask a simple question, they treat you like a simple programmer
[04:31] <nosrednaekim> not like the great and advanced mhb
[04:31] <nosrednaekim> savior of the kubuntu restricted-manager.
[04:31] <nosrednaekim> :)
[04:31] <mhb> nixternal: which is probably for the best, but I always prefer not to be told about "change algorithms if you want to speed up" :o)
[04:31] <nosrednaekim> lol
[04:32] <mhb> nosrednaekim: haha, I'm clueless when it comes to some subjects, but it's a bit boring when others assume you're totally clueless :o)
[04:32] <Jucato> oh well... don't mind me
[04:32] <mhb> Jucato: right
[04:32] <mhb> Jucato: actually
[04:32] <mhb> Jucato: dpkg is the backend
[04:33] <nosrednaekim> did you guys see the package kit thing?
[04:33] <mhb> Jucato: apt is a layer above it
[04:33] <nosrednaekim> that looks pretty nice
[04:33] <mhb> Jucato: then there's python-apt
[04:33] <Jucato> aaah the endless flow of backs and fronts
[04:33] <mhb> Jucato: then there could be a common core for the package managers
[04:33] <nosrednaekim> for which there is no DOCS
[04:33] <mhb> Jucato: then there's python-kde or pygtk :o)
[04:34] <Jucato> mhb: I just hope that this common package manager would be worked on "at the same time" from both Ubuntu and Kubuntu... and not Ubuntu first, then Kubuntu next release :(
[04:34] <nosrednaekim> to repeat my buried question. "did you see package-kit"?
[04:34] <Jucato> what package kit?
[04:34] <mhb> nosrednaekim: nope, what's that?
[04:35] <mhb> Jucato: well, if you volunteer to implement it for Kubuntu, it will be so
[04:35] <nosrednaekim> dbus frintnd to various packagemanagers
[04:35] <nosrednaekim> I can't type tonight.. sorry
[04:35] <Jucato> I mean the backend of course... anyway... don't mind me. just ranting hehe
[04:35] <Jucato> nosrednaekim: haven't seen it
[04:36] <nosrednaekim> currently I think there is a YUM and whatever-mandriva-uses interfaces to it. With an apt  interface in progress.
[04:36] <nosrednaekim> but no KDE frontend yet.
[04:36] <nosrednaekim> apt-get
[04:37] <nosrednaekim> python
[04:37] <nosrednaekim> python -kde
[04:37] <nosrednaekim> dpkg
[04:37] <Jucato> dbus eh...
[04:37] <nosrednaekim> haha
[04:37] <nosrednaekim> yeah... it looks interesting.
[04:37] <nosrednaekim> especially the use cases
[04:38] <mhb> nosrednaekim: you mean "He is allowed to install pre-approved software from the hogwart-corporate-build repo but not from any other repo."
[04:39] <nosrednaekim> lol... no the one with the open-office user automatically getting the clipart libraries.
[04:40] <mhb> the only problem I see in it ... is dbus
[04:40] <nosrednaekim> and whats wrong with that?
[04:40] <mhb> why using dbus for that? It doesn't make much sense.
[04:40] <nosrednaekim> why not?
[04:41] <nosrednaekim> there are d-bus bindings for every programming language.
[04:41] <Jucato> and dbus is becoming/has become a (fd.o) standard so...
[04:41] <mhb> nosrednaekim: I think it's like aiming a bazooka on a mosquito
[04:41] <Jucato> bah! I shouldn't get into technical discussions...
[04:42] <nosrednaekim> well... at least the mosquito is dead ;)
[04:43] <mhb> nosrednaekim: I guess so. I am just a fan of the old time backend-frontend relationship
[04:43] <Jucato> dbus could be considered backend or middle-end...
[04:43] <mhb> nosrednaekim: if the frontend is coded well enough, the backend could be changed without the frontend changing a line of code
[04:44] <mhb> but I may be totally wrong
[04:44] <mhb> I'm not a dbus guru
[04:44] <Jucato> aaah the advantages of separating interface from implementation...
[04:44] <Jucato> just like in classes...
[04:45] <nosrednaekim> :)
[04:45] <nosrednaekim> Ok, I have to go.
[04:45] <nosrednaekim> its getting late here
[04:45] <mhb> nosrednaekim: late? it's 4:45 a.m. here :o)
[04:46] <nosrednaekim> Jucato: thought you were staying out of tech discussions;)
[04:46] <nosrednaekim> mhb: thats not late.... thats early.
[04:46] <mhb> nosrednaekim: not if you haven't slept yet
[04:46] <mhb> then it's late
[04:46] <nosrednaekim> its almost 11pm here
[04:46] <nosrednaekim> lol
[04:46] <Jucato> nosrednaekim: yeah... that was ajust a simple C++ remark :P
[04:46] <nosrednaekim> :)
[04:46] <mhb> Jucato: separating interface from implementation can be done using templates
[04:46] <mhb> and classes
[04:47] <mhb> Jucato: no need to use dbus or jebus
[04:47] <Jucato> you took me too seriously :)
[04:47] <mhb> Jucato: and you still end up coding the library in either C/C++
[04:47] <nosrednaekim> mhb is old fashioned.
[04:47] <mhb> see you
[04:47] <nosrednaekim> yep
[04:51] <mhb> Jucato: http://en.wikipedia.org/wiki/Modern_C++_Design is what I'm reading
[04:52] <Jucato> hm.. ok thanks :)
[04:52] <Jucato> I'm still a beginner-level C++-er... so :)
[04:53] <mhb> Jucato: ah, yes, that's not for you.
[04:53] <Jucato> my book's exercises make me even feel more inadequate :/
[04:54] <mhb> Jucato: you should be also reading the new tutorials on KDE's techbase
[04:54] <mhb> Jucato: it will take me a lot of time to adapt to all those new APIs :o)
[04:54] <Jucato> yeah. but I'm not laying my hands on anything Qt or KDE yet... I tried to, but haven't gotten my head around most of the object-oriented stuff
[04:55] <Jucato> don't worry, I don't have Qt/KDE 3 to corrupt my head yet :P
[04:55] <Jucato> I'm gonna start with Qt4 and KDE4 directly
[04:56] <mhb> Jucato: slightly off-topic, I wanted to create a simple plasmoid for showing all mounted drivers today.
[04:56] <Jucato> (anything KDE-related isn't offtopic to me :P)
[04:57] <mhb> Jucato: solid worked well, but when trying to adapt a plasma tutorial to my liking, I ended up with a widget that renders its top down corner only
[04:58] <Jucato> wasn't there a plasmoid for solid in playground?
[04:58] <Jucato> btw, thanks for the pointer to where those plasmoids where
[04:58] <mhb> Jucato: that's the downside of using unstable APIs - you never know whether your code or their code that's broken
[04:58] <mhb> also, it could be the tutorial code, because I was following it
[04:59] <Jucato> mhb: the advantage of starting late is that a) Qt 4 is very much stable already and b) by the tieme I get to KDE stuff, 4.0 would have been already released :)
[05:00] <mhb> Jucato: yeah.
[05:00] <mhb> Jucato: but I guess the real experience should be expected from 4.1.
[05:01] <mhb> Jucato: I would like to see a central point for progress bar like those mockups at kde-look suggested, or a common theme for notifications
[05:01] <Jucato> yeah. but by that time, I should be helping making the real experience in 4.1  :)
[05:38] <nixternal> mhb: I noticed their attitude in there as well
[05:38] <jjesse> evening
[05:38] <nixternal> howdy jjesse
[05:38] <jjesse> howdy nixternal
[05:38] <nixternal> you and the wife enjoying the weekend?
[05:39] <jjesse> yeah we are, spent the afternoon at the aquariaum and the olympic park area before the storms hit
[05:39] <nixternal> good ol' olympic park
[05:39] <nixternal> you see the cnn building?
[05:40] <jjesse> yeah we did
[05:40] <nixternal> heh, my dad was there all week actually
[05:40] <jjesse> someone in the class i was teaching actually works for turner broadcasting
[05:40] <nixternal> eww
[05:40] <nixternal> I have been raised to dislike turner
[05:40] <jjesse> :)
[05:41] <nixternal> dad is a broadcast engineer..so I am not supposed to like abc, cbs, anything turner, and oprah :)
[05:41] <jjesse> he dislikes turner as well
[05:41] <jjesse> what are you supposed to like then?
[05:41] <jjesse> if you can't like cbs abc etc
[05:42] <nixternal> nothing I guess :)
[05:42] <jjesse> i can't wait to go get faster internet
[05:42] <jjesse> this hotel is so slow
[05:42] <nixternal> heh
[10:36] <LongPointyStick> or have some other help system
[11:06] <_StefanS_> Tonio_: found the segfault for paired devices; will prepare a patch for you.
[11:07] <_StefanS_> Tonio_: in kdebluetooth that is ;)
[11:25] <Riddell> nixternal: awake?
[11:59] <Riddell> nixternal: I'm moving kde4beta to kubuntu-members ppa
[12:08] <Riddell> Tonio_, allee:   File "/usr/bin/kblueplugd", line 13, in <module> import gobject
[12:08] <Riddell> ImportError: No module named gobject
[12:08] <Riddell> does it have to use gobject?  why not qt?
[12:46] <Tonio_> Riddell: hum, I didn't wrote that script, so maybe allee has its own reason for this
[12:46] <Tonio_> Riddell: strange that you get that error, I didn't notice this before, lemme look
[12:49] <Tonio_> Riddell: distutils.errors.DistutilsExecError: command 'kbluetooth' failed with exit status 255
[12:50] <Tonio_> Riddell: I now get this, but the process launches....
[12:50] <Tonio_> Riddell: I suspect that some changes in kbluetooth executable result that it doesn't launch correctly as a daemon
[12:50] <Tonio_> Riddell: I'll tru to get that fixed today
[12:50] <Tonio_> s/tru/try
[12:51] <Tonio_> Riddell: the point is that it'll not detect unplug now cause the script crashes.....
[12:51] <Tonio_> Riddell: and I'll try to figure out why that gobject thing
[12:54] <Tonio_> Riddell: well it's kbluetooth that seems to fail btw
[12:54] <Tonio_> Riddell: and yeah , the import gobject seems unused
[12:55] <Riddell> it's used
[12:55] <Tonio_> Riddell: hu ?
[12:55] <Tonio_> Riddell: by what ?
[12:55] <Riddell> loop = gobject.MainLoop()
[12:56] <Tonio_> Riddell: oups, still sleeping hehe :)
[12:56] <Tonio_> Riddell: how would that we done with import qt ?
[12:56] <Tonio_> qt.MainLoop() ? ;)
[12:58] <Tonio_> oki I had a kde problem in my /var/tmp, no kbluetooth issue now
[01:00] <Tonio_> Riddell: I'll look at my python book on that gobject thing ;)
[01:14] <Riddell> I doubt it'll say anything, it's a question of whether you can use the qt mainloop with dbus
[01:30] <Tonio_> Riddell: oki so I'll search the web :)
[02:36] <freeflying> ridicuous, my strigi can not index anything
[02:42] <mhb> hi folks
[02:42] <Jucato> hi mhb
[02:49] <nosrednaekim> hey mhb got enough sleep over the day?
[02:58] <mhb> nosrednaekim: sure
[02:59] <nosrednaekim> :)
[03:34] <gustavonarea> Hello, everyone. Is it me or Kmail is unusable in Tribe 5? I've already reported 3 bugs on kmail (133857, 135787 and 136368), but Bug #136368 is the worst of all. If it's all due to the Enterprise branch, then why was it included so late (in Tribe 5, instead of Tribe 1)?
[03:34] <ubotu> Bug 136368 on http://launchpad.net/bugs/136368 is private
[03:35] <mhb> gustavonarea: it's not you
[03:36] <mhb> gustavonarea: I can't really tell why it was included in Tribe 5, though
[03:38] <nixternal> Riddell: roger that
[03:38] <nixternal> mhb: do you ever sleep?
[03:39] <nosrednaekim> yeah.... but he sleeps during the day
[03:39] <mhb> during the morning, to be exact :o)
[03:39] <Jucato> vampire...
[03:40] <mhb> well, let's do some debugging
[03:50] <allee> Riddell: I have chosen gobject, because it was the only one found in the python dbus tutorial.  qt-dbus included no examples.  Can you point to example code of qt-dbus event handling.  kblueplugd need no x window.  So a window less loop would be best suited
[03:57] <nixternal> Riddell: do you want me to continue on with the rest of the beta packages, or are you doing them now?
[03:59] <allee> great.  Nothing depends on python-qt4-dbus already :(
[04:06] <Riddell> nixternal: hi
[04:06] <Riddell> nixternal: I've done kdebase and kdepim
[04:06] <Riddell> nixternal: just let me know if you start another one so we don't duplicate
[04:06] <Riddell> nixternal: and upload to kubuntu-members ppa
[04:07] <Riddell> allee: I don't know of any examples I'm afraid
[04:07] <gnomefreak> Riddell: is kde4 ready to run inplace of kde3
[04:08] <Riddell> although there must be something out there
[04:08] <Riddell> gnomefreak: no
[04:08] <gnomefreak> ok i know release is fairly soon was just wondering
[04:09] <Riddell> it's not until december
[04:10] <gnomefreak> oh i was thinking october
[04:10] <mhb> gnomefreak: it was delayed
[04:10] <gnomefreak> makes sense
[04:11] <gnomefreak> looking at release schedule see how many betas they plan on
[04:11] <Jucato> do we have a sort of plan on how to go about the installation of KDE 4 on an existing KDE 3.5.x system? do we overwrite the default? install in a different path like we do right now?
[04:12] <Jucato> gnomefreak: from 2, they added 2 more
[04:12] <Jucato> the first plan was only 2 betas
[04:12] <gnomefreak> they also pushed beta 1 where beta 2 should have been released it seems
[04:12] <nixternal> Riddell: thanks for the kdebase-workspace...that one threw me for a curve
[04:12] <Riddell> oh yes, that too
[04:13] <nixternal> I have just setup kubuntu-ppa in dput, so I am ready to go :)
[04:13] <gnomefreak> beta2 was aug. 29th but seems beta was just released
[04:13] <Jucato> although it should be noted that the schedule talks about "tagging", which is a bit different from "release"...
[04:13] <gnomefreak> nixternal: you play with ppa yet?
[04:13] <nixternal> oh ya
[04:14] <Riddell> gnomefreak: why?
[04:14] <gnomefreak> packages keep failing to upload (things that i should have checked for like licenses and crap
[04:15] <Jucato> silly Ctrl+Q...
[04:15] <nixternal> Riddell: kdepimlibs 4 or 5 :)
[04:16] <Riddell> the source package
[04:16] <gnomefreak> oh and you cant take back packages (once that is used than ill hate it less)
[04:16] <nixternal> gnomefreak: gotta do all of your checking before you upload first :p
[04:18] <Riddell> gnomefreak: you can retry builds
[04:18] <Riddell> ppa doesn't care about licences
[04:18] <gnomefreak> yeah but if it uploads than fails to build i have to change version
[04:18] <gnomefreak> Riddell: yes it does
[04:19] <gnomefreak> top left corner is the TOS
[04:19] <Riddell> but in general, using a ppa isn't a substitute for compiling it on your machine first to make sure it actually compiles and builds properly
[04:19] <gnomefreak> it has to be a free license
[04:19] <nixternal> Riddell: ya, ppa does worry about licenses :)
[04:19] <nixternal> don't know what the list of acceptable licenses are, but it will complain on non-free licenses
[04:20] <Riddell> complain in which way?
[04:20] <nixternal> I believe it will reject the upload, or maybe it allows the upload but will FTBS due to the license
[04:20] <gnomefreak> i was missing one they wouldnt let me upload
[04:20] <gnomefreak> it wont reject it it stops it before it trys
[04:20] <nixternal> ahh, OK
[04:20] <Riddell> I wonder how it knows
[04:20] <nixternal> I can't remember exactly what Matt Revell stated about it
[04:24] <Riddell> nixternal: I'm doing kde4edu
[04:24] <nixternal> annma would be proud :)
[04:28] <Riddell> gnomefreak: "This PPA does not contain any packages yet." so you uploaded and it automatically rejected?
[04:29] <gnomefreak> Riddell: if that is from my personal one i have gotten to that one yet
[04:29] <gnomefreak> Riddell: im building for mozillateam PPA
[04:29] <Riddell> ah
[04:29] <gnomefreak> but it takes a bit of time beofre its accepted sometimes and even longer to build
[04:30] <gnomefreak> https://launchpad.net/~mozillateam/+archive/
[04:30] <Riddell> yes, PPA will be low priority for the buildds
[04:55] <mhb> Riddell: I've got some updates on the evil kpart bug 117731
[04:55] <ubotu> Launchpad bug 117731 in python-kde3 "Python crashes after attaching pty to a konsole kpart" [High,Triaged]  https://launchpad.net/bugs/117731
[04:56] <mhb> Riddell: the interesting thing is, when you use edgy (so the apps work), there is an extra output line
[04:56] <mhb> Riddell: that isn't shown on an unaffected Gutsy machine
[04:57] <mhb> KWrited - Listening on Device /dev/ttyp0
[04:58] <Riddell> have you tried recompiling the edgy kdelibs and base on gutsy and seeing if the problem occurs?
[04:59] <mhb> no, partly because recompiling anything on an affected machine (which is usually an older one) takes forever
[04:59] <mhb> also I've no idea if KDE 3.5.5 will compile
[04:59] <mhb> but I'll try it later today
[05:00] <mhb> on a different i386 machine
[05:32] <allee> Uhm, kmail and konqueror, 'refuse' to download anything.  With feisty it was enough to stop knetworkmanager.  Not working with gusty anymore :(
[05:33] <Riddell> even if you quit knetworkmanager?
[05:58] <allee> Riddell: yes :(
[05:59] <Riddell> allee: if you stop network manager daemon?
[06:01] <allee> Riddell: Argl, found it.  Played with networkstatustestservice at work and it was restored at home.  I killed it and now konqueror
[06:26] <allee> QT dbus problem:  import dbus.mainloop.qt  => ImportError: No module named qt   See file:///usr/share/doc/python-qt4-doc/html/pyqt4ref.html#the-dbus-support-module   There's only dbus/mainloop.so in python-qt4-dbus,  not .py.  apt-file search dbus/mainloop/qt finds no .py too.  Can a python class be defined without any .py file?
[06:27] <ScottK> Yes.
[06:28] <ScottK> What happens if just open a Python shell and "import qt"
[06:29] <allee> ScottK: Nothing import qt is the line before import dbus.mainloop.qt ;) I've checked in python interacively and import qt is okay
[06:29] <ScottK> OK
[06:31] <ScottK> To answer your question though, I believe that you can import a C extension just fine if it's properly built, etc.
[06:34] <mhb> hmm
[06:34] <mhb> no subdirs in /usr/share/python-support/python-dbus/dbus/mainloopp
[06:34] <mhb> it's just __init__.py and glib.py
[06:37] <mhb> and python-qt4 sources have a dbus/ directory with what I dare presume is the binding
[06:38] <mhb> but looking at /var/lib/dpkg/info/python-qt4.list I don't see any dbus files installed
[06:39] <mhb> allee: I guess you have tried building your own python-qt4, haven't you?
[06:40] <allee> mhb: no.
[06:40] <mhb> allee: judging by the information I posted above, I think it might be worth a shot
[06:41] <allee> hmm, with 64 kbit link?  no fun ;)
[06:41] <mhb> allee: okay, I'll do it for ya :o)
[06:43] <mhb> The dbus support module will be installed in
[06:43] <mhb> /var/lib/python-support/python2.5/dbus/mainloop.
[06:44] <mhb> that seems okay, I wonder if it will build it correctly as well
[06:55] <mhb> allee: bingo!
[06:56] <mhb> allee: in order to get that module to load, you have to a) fetch the python-qt4 sources and have build-deps
[06:56] <mhb> b) python configure.py
[06:56] <mhb> c) cd dbus/; make; sudo make install
[06:57] <mhb> allee: also, the Ubuntu package should provide that by default, someone should be notified about it
[06:59] <mhb> allee: hmm... or, of course, install python-qt4-dbus
[06:59] <mhb> :D
[06:59] <mhb> silly me for not checking it first
[07:00] <mhb> I was looking for a workaround so hard I forgot to check the debian/ dir :o)
[07:02] <mhb> allee: so, there you go
[07:55] <allee> mhb: thx.  In c): what does make install  install that is not in the pkgs?
[07:57] <mhb> allee: nothing, see my later comments - it's in the python-qt4-dbus
[07:57] <mhb> allee: I didn't know it's separated like that
[07:58] <allee> mhb: I'm confused I've python-qt4-dbus installed.  that's the pkgs with only the dbus/mainloop/qt.so file
[07:59] <allee> oh, python-qt4 source + build dep are 4,3 hours to go :(
[08:00] <duccio> Hi all...I'm new! How can I contribute to kubuntu development?
[08:00] <Riddell> duccio: please do
[08:00] <Riddell> but you need to tell us a bit about your skills
[08:01] <_Sime> mhb: I'm not sure if PyQt4 supports DBus.
[08:01] <Riddell> documentation, packaging, bug triage, bug fixing, programming, testing are all areas of help
[08:01] <_Sime> mhb: you can use the normal DBus bindings though.
[08:01] <duccio> ok
[08:02] <duccio> I'm Italian...so my English is not perfect
[08:02] <Riddell> ciao
[08:02] <duccio> I am an Informatic Engineer
[08:02] <duccio> University of Siena
[08:02] <allee> _Sime: according to file:///usr/share/doc/python-qt4-doc/html/pyqt4ref.html#the-dbus-support-module it does.  And there a dbus/mainloop/qt.so in python-qt4-dbus
[08:02] <duccio> i've finished my study one year ago
[08:03] <_Sime> allee: mmm... I reserve the right to be wrong. ;) I know that the normal DBus bindings work with Qt and teh glib event loop.
[08:03] <allee> _Sime: problem is I for import qt then import dbus.mainloop.qt  -> ImportError: No module named qt
[08:04] <duccio> i don't know much about ubuntu way of development
[08:05] <allee> _Sime: kblueplugd works with glib eventloop already.  But Riddel (and me) would like to have it g* free ;)
[08:05] <duccio> but i'm interested on helping develop
[08:06] <duccio> so...what should i do?
[08:06] <Riddell> duccio: documentation, packaging, bug triage, bug fixing, programming, testing are all areas of help
[08:07] <Riddell> duccio: any of those sound interesting?
[08:07] <_Sime> allee: the dbus module is probably built on the C dbus implementation which in turn uses glib.
[08:07] <_Sime> allee: I'm not sure if you can avoid glib.
[08:07] <duccio> i think that bug fixing and programming sounds good
[08:08] <duccio> but i don't know how much time I can assure
[08:10] <duccio> Should I read some documentation?
[08:10] <allee> _Sime: well would be nice to not use import gobject and import dbus.mainloop.glib.   But on the other hand and a bit more important.  import dbus.mainloop.qt fails.  And that's a bug that need to be fixed ;)  But as this happens during the 2nd iteration of my first python script im pretty glueless what goes wrong
[08:14] <duccio> Riddell: next step I should do?
[08:17] <mhb> allee: it won't fail if you've python-qt4-dbus install
[08:17] <mhb> allee: at least it won't fail for me anymore
[08:17] <Riddell> duccio: I have a small programming task that needs doing
[08:18] <_Sime> is this all on gutsy?
[08:18] <duccio> ok
[08:18] <Riddell> duccio: our splash screen create a cache of the image, which means when we get a new wallpaper the splash still shows the old image
[08:18] <allee> mhb: ii  python-qt4-dbus               4.3-2ubuntu4                  DBus Support for PyQt4
[08:18] <duccio> i understand
[08:18] <allee> mhb: 'always' was installed
[08:18] <Riddell> duccio: if you know shell, this could probably be fixed in startkde from kdebase
[08:19] <mhb> allee: was it? Well, I didn't have it installed
[08:19] <allee> mhb: and import qt ; import dbus.mainloop.qt works now for you without error?
[08:19] <Riddell> duccio: apt-get source kdebase and edit startkde to check if /usr/share/wallpapers/kubuntu-wallpaper.png is newer than $KDEHOME/share/apps/ksplash/cache/Moodin/
[08:19] <mhb> allee: right...
[08:20] <mhb> allee: hmm, but it may be because of that first compile-it-yourself
[08:20] <duccio> yes...i think so, but i've never work on this
[08:20] <allee> mhb: maybe.
[08:21] <mhb> allee: but I have only qt.so in there, so that is the correct state
[08:21] <duccio> ok..
[08:22] <duccio> ...
[08:22] <duccio> (download the source code)
[08:23] <ScottK> Riddell: Do you think it would be possible to arrange it so that kubuntu-members PPA didn't send FTBFS messages to everyone in kubuntu-members?
[08:23] <mhb> allee: I think I see the culprit
[08:24] <mhb> allee: are you there?
[08:25] <Riddell> ScottK: hmm, possibly we should start yet another team for this
[08:25] <mhb> sudo ln -s /usr/lib/python2.5/dbus/mainloop/qt.so /var/lib/python-support/python2.5/dbus/mainloop/qt.so
[08:25] <mhb> allee: ^^ do this and tell me what happens
[08:26] <duccio> ...i'm editing startkde...
[08:26] <duccio> ok
[08:27] <ScottK> Riddell: I'm not an expert in how to deal with it, but I think that the FTBFS messages out to somehow just go to whoever did the upload.
[08:35] <duccio> Riddell: i'm very slow because i don't know this language..
[08:39] <allee> mhb: you're my hero! Works.   I wanted to check this, but didn't found yet how to get the MODULE path python search ;)
[08:40] <_StefanS_> Tonio_: I found the problem in kdebluetooth, its hasBonding() that crashes the Paired/Trusted Devices.
[08:40] <_StefanS_> Tonio_: im not quite sure how to fix it though :(
[08:40] <mhb> allee: so it WAS a package problem.
[08:40] <allee> ^^ IS ;)
[08:40] <mhb> allee: true, but I'll try to change that soon-ish. :o)
[08:41] <nosrednaekim> is this the Kmail problem?
[08:41] <ScottK> allee: To add it to your Python path, import sys and then insert the path to your module in sys.path
[08:42] <allee> mbh: hmm, why in /var/lib/python.   Sounds somehow wrong place (and dpkg -S var/lib/python2.5  find's nothing)
[08:42] <ScottK> mhb: ^^
[08:43] <allee> ScottK: thx!!!! :)
[08:43] <mhb> allee: no
[08:43] <duccio> Riddell: What documentation should I read to understand the syntax of startkde?
[08:44] <mhb> allee: /var/lib/python-support is used by many packages
[08:44] <mhb> allee: the error lies elsewhere - the Python interpreter find dbus.mainloop
[08:44] <mhb> allee: finds it in /var/lib/python-support/...
[08:45] <allee> bedtime for the kids.  bbl
[08:45] <mhb> allee: but the qt.so is elsewhere, thus it cannot be found
[08:53] <duccio> Riddell: if [/usr/share/wallpapers/kubuntu-wallpaper.png -nt $KDEHOME/share/apps/ksplash/cache/Moodin] ; then echo "newer" else echo "older"
[08:58] <duccio> Riddell: I read some about shell and I came back next days...it's ok?
[09:00] <duccio> bye all
[09:51] <mhb> there is something rotten in the state of python-qt4
[09:52] <manchicken__> Does xgl screw with keymappings?
[09:52] <manchicken__> mhb: Is there?  Are you talking about the "C/C++ Object Deleted" error?
[09:53] <manchicken__> I was getting that the other day.  I'm trying to learn Python and scratch an itch with a little Python app to manage my resolv.conf and routes.
[09:54] <Riddell> mhb: not that I know of, why?
[09:54] <mhb> manchicken__: not actually, I am starting with compilation
[09:54] <mhb> Riddell: well, if you have read the conversation with allee today, there is a bug that prevents dbus to work with Qt4
[09:55] <mhb> Riddell: I am trying to fix it, and while debuilding pyqt4 the whole compilation of it is running twice
[09:55] <Riddell> hmm, I thought doko had changed that
[09:55] <Riddell> one build is for debug version
[09:55] <mhb> Riddell: ah, that makes sense
[09:58] <mhb> Riddell: well, in current version of the source the qt.so file is moved from /var/lib/python-support to /usr/lib/python2.5/, which breaks it
[09:58] <mhb> Riddell: because all the other python-dbus files are in /var/lib/...
[10:04] <Riddell> has doko done an upload if it recently?
[10:04] <mhb> 24th
[10:05] <mhb> and yes, there is a fix dbus install location changelog entry
[10:05] <mhb> Riddell: in what way was it fixed then? Was moving to /usr/lib/python2.5/ the fix? If so, why?
[10:06] <mhb> I have the most recent version of python-dbus, which resides in /var/lib/python-support
[10:07] <mhb> lets ask him
[10:08] <manchicken__> Okay, so /usr/bin/X is now a dead link...
[10:08] <manchicken__> I'm guessing that it's supposed to point to /usr/bin/Xorg?
[10:08] <mhb> manchicken__: works here
[10:08] <crimsun> x11-common should provide /usr/bin/X
[10:09] <Riddell> I don't know what was changed
[10:09] <manchicken__> Should reconfiguring x11-common fix that?
[10:09] <nixternal> Riddell: I need some feedback from as many KDE devs as possible...would posting to kde-core-devel be my best bet, or is there a better route?
[10:11] <mhb> nixternal: sounds right to me, if you ask me (but you do not :o)
[10:11] <nixternal> muhah
[10:11] <manchicken__> Ahh, I figured out why Xgl is running all the time now.
[10:12] <nixternal> yeehaw!
[10:12] <allee> mhb: when you fix python, check why qeventloop.html  talks about exec_(...).  It's not exec_(...) it's exec_loop(...).   Hah, and loop.exec_loop() gives a SEGV.  Great :(
[10:13] <allee> mhb: err, python-qt that is
[10:13] <Riddell> nixternal: it depends what the question is
[10:13] <nixternal> Riddell: trying to get a list of apps that are ready for people to start doing doc work on...my blog post got about 10 new people interested in helping out KDE with docs
[10:14] <mhb> allee: hmm, interesting. Perhaps _Sime was right that dbus in pyqt4 being broken
[10:15] <mhb> allee: I fixed the packages, but I need to know why doko changed it in the first place... perhaps I lack knowledge of the greater scheme
[10:17] <mhb> allee: could you pastebin your crashing code for my easier testing experience? :o)
[10:17] <allee> mhb: okay.    Let's see what he thinks about it.
[10:17] <allee> mhb: wait ..
[10:18] <Riddell> nixternal: kde-core-devel is for libraries mostly, not apps
[10:18] <allee> http://paste.debian.net/35995
[10:18] <allee> ^^ mhb
[10:19] <Riddell> allee: does that work?
[10:20] <allee> Riddell: no, it SEGV at the end when entering the eventloop  loop.exec_loop() :(
[10:22] <mhb> allee: that segvs? Not here, I'm afraid
[10:23] <mhb> allee: unable to execute kbluetooth: No such file or directory
[10:23] <mhb> allee: ^^ is that a block to the segfault?
[10:24] <tmske_> I'm trying to connect to the internet with knetworkmanager, but at 57% I get an connection error, but it looks like I can connect for some programs, konversation for example :-) but some can not connect, like konqueror
[10:24] <tmske_> but those programs can only connect if I use dhclient manually
[10:24] <allee> mhb: eh?  you have no /usr/bin/kbluetooth ?
[10:24] <allee> mhb: here output is like: ...
[10:24] <allee> waiting for bt device (un)plug events ...
[10:24] <allee> Segmentation fault (core dumped)
[10:24] <allee> mhb: so it's he loop.exec_loop()
[10:26] <allee> mhb: interesting is I changed it to loop.exec_loop(QEventLoop.AllEvents), which according to the exec_() the default.  But: too many arguments to QEventLoop.exec_loop(), 0 at most expected
[10:26] <allee> mhb: better missing docs than wrong one ;)
[10:27] <mhb> allee: what package is it in?
[10:28] <tmske_> it's really strange; in kopete jabber works, but msn doesn't work
[10:28] <mhb> allee: kdebluetooth I guess
[10:29] <allee> mhb: yes
[10:30] <mhb> allee: oh my, I've tried to update it and now dpkg return an error code because of a overwriting library
[10:31] <allee> mhb: did you removed he sym link you've created?
[10:32] <mhb> allee: ah, fixed. Right, it segfaults.
[10:35] <mhb> allee: by the way, why are you using Qt3 and the Qt Dbus bindings?
[10:35] <mhb> allee: it's not really nice
[10:36] <allee> mhb: hmm, man QEventLoop says exec()  without args.
[10:36] <mhb> AFAIK, the dbus bindings are only for Qt4
[10:36] <allee> mhb: I asssume qt4.   mhmm, what does import qt do?
[10:36] <mhb> imports Qt3
[10:37] <allee> mhb: oh sh*t
[10:37] <mhb> allee: http://www.rkblog.rk.edu.pl/w/p/introduction-pyqt4/
[10:38] <mhb> short version: from PyQt4 import QtCore, QtGui
[10:38] <mhb> allee: although I am usually using the uglier:
[10:38] <mhb> from PyQt4.QtGui import *
[10:38] <mhb> from PyQt4.QtCore import *
[10:38] <manchicken> Naughty naughty :)
[10:39] <allee> mhb: yeah qt.qVersion -> 3.3.7
[10:42] <mhb> allee: Qt4's QEventLoop seems to be fine
[10:42] <mhb> exec_ like the API says
[10:43] <allee> mhb: you don't get: QEventLoop: Cannot be used without QApplication
[10:43] <mhb> allee: you need a QApp alright, is there a reason not to create one?
[10:47] <allee> mhb: hmm, I assume it's okay.
[10:48] <mhb> allee: it seems not to crash
[10:48] <mhb> allee: but I have no bluetooth devices at home to prove it
[10:49] <allee> mhb: I'll test here.
[10:57] <allee> mhb: seem not to work :(  Nothing printed on addition/removal.  Uh, and ignoes ctrl-c too :(
[10:58] <mhb> allee: uh oh. Well, let me take a look at the code. I should learn the new APIs of KDE4 anyway.
[10:59] <Riddell> nixternal: rest of kde4beta uploaded (except bindings)
[10:59] <Riddell> nixternal: if you are wanting to do more, it needs uploaded to feisty in the ppa
[11:03] <allee> mhb: me too :)  Here's my current version: http://paste.debian.net/36000
[11:11] <nixternal> Riddell: I will work on it here in a few...that will give me something to do tonight
[11:20] <mhb> allee: http://www.riverbankcomputing.com/pipermail/pyqt/2007-January/015193.html
[11:20] <mhb> allee: read that?
[11:21] <mhb> and tried that?
[11:22] <allee> mhb: I'll do...
[11:26] <allee> mhb: heh, works: http://paste.debian.net/index.php
[11:27] <allee> mhb: ^^ I tested with plug/unplug a second bt device.  (Before I stoped kblueoothd by hand)
[11:27] <allee> mhb: can you upload to main?
[11:28] <mhb> allee: nope
[11:28] <allee> mhb: k
[11:29] <allee> mhb: only strange thing is. kblueplugd ignores ctrl-c,   killall lblueplugd or the other hand works
[11:31] <nosrednaekim> its a daemon.... daemons aren't killed with ctrl+c'
[11:32] <allee> nosrednaekim: it's not a daemon.  I did detach from tty and don't fork into background.  It's a little qt app and those can be usually killed by ctrl-c
[11:33] <mhb> allee: you *did* detach from tty?
[11:33] <allee> mhb: eh, sorry I didn't.
[11:34] <allee> http://paste.debian.net/36001
[11:37] <allee> well, as it's normally autostarted in background during login.  Not reacting to Ctrl-C is not a real problem.  Still anoying for test, and more anoying that I don't understand yet why the signal get's blocked
[11:38] <allee> Riddell: ^^  so if you don't care: http://paste.debian.net/36001  uses qt + dbus
[11:39] <allee> time for bed.  Nite
[11:40] <mhb> good work allee
[11:40] <mhb> goodnight
[12:17] <Riddell> nixternal: you can probably upload with feisty-backports in the ppa and it should pick up qt 4.3
[12:18] <Riddell> mhb: do you have a fix for python-qt4-dbus then?
[12:19] <mhb> Riddell: a debdiff? Almost, but I'd like to ask doko first. He must have had a reason for it to break.
[12:20] <Riddell> mhb: what do I need to move around?  just to test allee's script
[12:20] <mhb> Riddell: scroll up a bit and find my message about a "sudo ln -s"
[12:21] <Riddell> groovy, that seems to work
[12:24] <Riddell> Tonio_: you forgot the -0ubuntu1 part on the kdebluetooth version number
[12:25] <Riddell> I've uploaded it with allee's new qt happy script
[12:25] <Riddell> mhb: send doko an e-mail is probably the best way to ask
[12:33] <mhb> Riddell: okay
[12:37] <Tonio_> Riddell: thanks a lot :)
[12:38] <Tonio_> Riddell: yeah, I forgot that dch uses 1 by default instead of 0ubuntu1.... sorry