[00:01] PROGRESS [00:01] :D [00:01] argh, why the hell there is a SEGV in there? [00:02] doesnt like you [00:03] apachelogger: that's not a reason to spew SEGV's at me :S [00:03] apachelogger: http://dl.dropbox.com/u/69524/troll.tar.gz [00:03] :P [00:03] * Quintasan is going to regret this [00:04] hm [00:04] valgrind talks about memleaks in X and fontconfig \o/ [00:04] with a qt hello world app [00:05] also still getting loads of possible losses regarding eventdispatcherglib [00:05] apachelogger: btw. I've asked this, if I'm doing (inside a constructor) QPushButton *problemButton = new QPushButton(somecraphere, [wtf to put as a parent?] [00:06] this? [00:06] jefferai: http://people.ubuntu.com/~apachelogger/tmp/valgrind.log should you ever get example files, maybe this helps too :) [00:06] it's from a hello world example [00:06] http://doc.trolltech.com/4.3/tutorial-t1.html [00:06] apachelogger: tell thiago this [00:06] :-) [00:06] or tzander [00:06] apachelogger: 60mb of memory? [00:07] Quintasan: yup [00:07] but don't tell them I told you [00:07] wth [00:07] heh [00:07] hey don't tell me that my TrollFace app steals even more @_@ [00:07] hm [00:07] jefferai: you shouldn't have said that [00:07] heh [00:07] where do you see 60mb? [00:08] megabytes :P [00:08] possibly lost: 59,018 bytes in 970 blocks [00:08] that's 5.9 kb [00:09] no [00:09] 0.45 megabyte [00:09] that's 59 kb [00:09] yeah, woops [00:09] :O [00:09] not MB though [00:09] nobody can do math [00:10] okay, everything is fine, apart from the whole app throwing SEGV's all around [00:12] omfg, it's not the image's fault that the app i crashing [00:12] is* [00:17] Quintasan: did I just break it or is the resource file empty? [00:17] ... [00:18] it's empy here too [00:18] wtf [00:18] well [00:19] need I say more [00:19] hah [00:19] apachelogger: even if you add the trollface it still fails to display it [00:19] dunno why :S [00:20] apachelogger: fixed tarball -> http://dl.dropbox.com/u/69524/App1.tar.gz [00:20] though it still spews crap at me :( [00:23] well [00:24] Quintasan: I would use QPixmap to begin with [00:24] "The QPicture class is a paint device that records and replays QPainter commands." [00:24] that does not sound like you want that :P === dendrobates is now known as dendro-afk [00:25] * Quintasan hugs apachelogger [00:25] works [00:25] :DDD [00:26] argh [00:27] apachelogger: one more thing [00:27] apachelogger: void TrollFace::Troll() [00:27] apachelogger: when I put there trollImage->show(); and then click on the button the whole app segfaults [00:27] :S === dendro-afk is now known as dendrobates [00:31] ohm === wgrant_ is now known as wgrant [00:35] ah [00:35] uh [00:35] lol [00:35] rofl [00:35] hahahha [00:35] * apachelogger needs to check something [00:36] ^^ [00:36] well then [00:36] how do I put this [00:36] Quintasan: what would "QLabel *trollImage = new QLabel(this);" do? [00:37] outside the context of your app [00:37] in general [00:37] what would that line do [00:37] create a pointer to QLabel object with... [00:37] omfg [00:37] ah ^^ [00:37] what scope does that object have :P [00:38] class scope? [00:38] :S [00:38] so what should I put as a parent in that constructor? [00:38] also mind the live time [00:38] see [00:38] trollImage = new QLabel(this); [00:38] != [00:38] QLabel *trollImage = new QLabel(this); [00:39] with the former you asign the member pointer trollImage a QLabel object on the heap [00:39] with the latter you create an entirely new pointer of local scope and life time [00:39] the member however stays untouched [00:39] argh [00:39] and that is why you get a segfault, because obviously the member will point to some random junk [00:40] that said it would be much more sensible to initialize member pointers to 0 IMHO :P [00:40] apachelogger: I see it now :S [00:40] also makes tracking of the issue easier [00:40] if you init to 0 [00:40] and then you get a segfault because you are trying to access 0 [00:40] apachelogger: still, what I [00:40] well, then obivously the assignment went wrong [00:41] btw [00:41] trollImage->setPixmap(QPixmap(":/img/troll.png")); [00:41] that is how I would load the pixmap ;) [00:41] + problemButton and trollImage need ot be parented [00:42] + IMHO you need to revise your member var names ;) [00:42] 4th time I ask this [00:42] + you will have to update the widget size once the image is shown [00:42] hngh [00:42] those are minor thng [00:42] crap [00:42] I'm having problems with typing :S [00:43] also, IMHO you should only create the qlable and load the pixmap in Troll() [00:43] otherwise it sits in mem for no good reason [00:43] apachelogger: Sput told me to parentize my widgets because I will not remember to delete them later, what should I use as the PARENT when I'm declaring things in CONSTRUCTOR? [00:44] trollImage = new QLabel(this); [00:44] as per documentation there is this constructor that expects at first arg a pointer to a qwidget [00:45] since TrollFace's base class is QWidget, and since this is a builtin pointer you just use this [00:45] same for the qpushbutton [00:45] problemButton = new QPushButton(tr("problemButton", "Problem, officer?"), [00:45] this); [00:45] oh, actuall [00:45] Quintasan: inside a qobject you can use tr() ;) [00:45] another intersting thing to remember [00:46] awesome [00:46] Quintasan: and finally ... you dont necessarily need to parent the members, but if you dont you need to create an appropriate dtor [00:46] dtor? [00:46] so usually you want to parent them ;) [00:46] Quintasan: destructor [00:46] oh [00:46] ctor = constructor; dtor = destructor [00:47] I still don't entirely get the "Trollface::Trollface(QWidget *parent) : QWidget(parent)" line [00:47] especially the : QWidget(parent) [00:47] you initialize a QWidget using the parent pointer you got [00:48] I understood like this [00:49] Trollface::Trollface(QWidget *parent) needs a pointer to QWidget, right? So we create a QWidget and pass it to Trollface :P [00:49] maybe that's why I don't get it somehow [00:52] apachelogger: http://www.cprogramming.com/tutorial/initialization-lists-c++.html is that what I'm looking for? [00:52] ehm [00:52] how do I put that [00:53] well [00:53] Quintasan: TrollFace _is a_ QWidget [00:53] right? [00:53] it is a special kind of QWidget, but still a QWidget [00:53] yeah [00:54] the idea of polymorphism is that you can address it as QWidget even though it is a specific QWidget [00:54] i.e. the QWidget is the base class of TrollFace [00:54] Polymorphism makes my head hurt. [00:55] now the thing is, in order to work with TrollFace as if it were a QWidget (i.e. access it members and all) it needs its very own instance of QWidget [00:55] hm [00:55] imagine it like a matrjoschka [00:56] outside you have TrollFace, and inside is a QWidget [00:56] and IIRC inside the QWidget is a QObject [00:56] so you create a TrollFace and the TrollFace creates a QWidget and the QWidget creates a QObject [00:56] ! [00:56] but [00:57] say you dont define no constructor [00:57] then the compiler will make a rather crappy one for you [00:57] called default ctor [00:57] dont define no :) [00:57] that thingy takes absolutely no arguments is the biggest crap evar [00:58] additionally that thingy will call the default ctor of QWidget [00:58] and so on [00:58] until everything is one way or another constructed [00:58] apachelogger: so and default constructor for TrollFace would be TrollFace() which calls QWidget() which calls QObject() and each and everyone is empty? [00:59] if you define a ctor but do not explictly initialize an instance of the base class as you do with : QWidget(parent) the compiler will still be fancy and automatically use the default ctor of QWidget [00:59] we do not want that [00:59] we want to allow ourselfs (or maybe a user of our class) to define a parent [01:00] i.e. maybe is trollface a child of another QWidget because TrollFace gest embedd in Amarok or something [01:00] so you implement a default constructor that can (but doesnt need to) access one argument [01:00] of the type QWidget* [01:01] now, earlier I said that a default ctor is one that does not accept nor arguments (<= imbrandon :P) [01:01] and this is archived by making 0 a default for that QWidget* [01:02] so if I want a TrollFace I can do TrollFace() or TrollFace(randomQWidget*) [01:02] both will use the same ctor [01:02] * Quintasan saves that for later [01:03] and in order to pass the latter on to the base of TrollFace (i.e. QWidget) we init QWidget ourselfs [01:04] finally please note that, would you not do that, the compiler would call QWidget() and you affectively would end up without parent, because the parent magic is implemented somewhere beyond QWidget, so since the compiler calls QWidget(), your base will not know anything about the parent... [01:04] if that makes any sense ^^ [01:04] * apachelogger should have gone to bed 2 hours ago [01:04] o/ [01:04] nini [01:04] nini [01:04] * Quintasan goes to bed too [01:05] Quintasan: oh, btw, the dtor will thanks to the same magic call the default dtor of the base class, so any memory the base class uses is freed again ;) [01:05] unless you use glib :P [01:08] apachelogger: I don't get anything you say to me but it's because lack of sleep :P [01:33] Tm_T: In ~75 minutes there will be new clamav packages in lucid-proposed. Could you install them and verify clamav-daemon works (doesn't segfault on start)? [01:33] It's a powerpc specific fix. [01:38] * genii slides Tm_T a super-caffeinated coffee [01:44] Not a great rush in any case since it has to properly age in -proposed before it can move to -updates. [02:55] nixternal: Done with powerpc for a while so you can turn it off again if you didn't already. [03:41] hum ok so i want to use a gst pipe in pyqt directly instead of phonon, anyone played with that ? [03:48] http://www.gtmf.us/ [03:49] http://tinyurl.com/2fj6lzv [03:50] heh [03:51] nixternal: bleh [03:51] I have always wanted to do that to someone [03:51] This is a personal favorite of mine: http://imagemacros.files.wordpress.com/2010/01/rtfm_noob.jpg [03:51] finally, and go figure, it is the hillbilly that I get it with :) [03:51] haha, nice [03:52] LOL [03:53] wish my cycling clothes would hurry up and finish washing...i need sleep! [04:11] and they are done...good night all!!! [04:13] nixternal: You should probably 'dent your laundry status before you go to sleep. [04:15] lol [04:48] whoa, these are seriously neat: http://leogg.wordpress.com/2010/05/05/ubuntu-ids-2/ [05:53] JontheEchidna: ooh shiny [07:11] ScottK: will try [07:12] apachelogger: no I didn't have that dependency issue, I'm on 386 [07:20] ScottK: starts just fine [08:38] apachelogger: ping [08:47] ScottK: and runs and stops fine [08:50] Riddell: http://www.kubuntu.org/news/kde-sc-4.4.3 gives 403 [08:50] although it's mentioned in http://kde.org/info/4.4.3.php [09:50] Tm_T: published now [09:54] \o [09:55] Riddell: thanks (: [09:59] hm, I still have 8 kdebase and plasma packages not updating, do you have a ETOA for those packages? [09:59] Mamarok: amd64? [10:00] since those are kdebase, workspace and plasma-worksapce packages it seems rather essential... [10:00] yes, 64bit [10:00] but I have an Intel 64bit, why do you guys insist on calling it amd? [10:01] Mamarok: it's the architecture name [10:01] Mamarok: I think it's done under one hour now, https://edge.launchpad.net/~kubuntu-ppa/+archive/ppa/+build/1717912 [10:02] finally :) [10:02] I don't know why the buildds are so busy :( [10:04] i386 14 builders 1153 jobs (14 hours) [10:04] everybody updating their ppas to lucid era? [10:05] yeah, the week after release is usually heavy load [10:06] but why does that affect the building process? [10:06] and project PPAs should defnitely have higher priority over individual ones [10:10] should, yes [10:18] Mamarok: some 5 minutes now is my uneducated guess [10:18] as it's building docs now, almost done [10:20] ...if that log can be trusted [10:47] o/ [10:52] ghostcube: hi there [10:52] * Quintasan is installing lucid on KVM to close some bugs [10:53] hi Quintasan :) [11:11] hey [11:11] WTF [11:11] Why slideshows on CD are not in Polish? I'm sure I have translated all of them. [11:13] Quintasan, did you finish the translations before the non-language-pack deadline -> https://wiki.ubuntu.com/LucidReleaseSchedule? As far as I know, all translations were exported from Launchpad and integrated into the package correctly [11:15] dpm: I'm pretty sure that I've done it before the deadline. Maybe I missed it because of timezones :P [11:16] dpm: well, it's not someone is going to cry but having the main title in Polish and then the rest in English looks sill [11:16] silly* [11:17] I'm still missing the words @_@ [11:19] Quintasan, I fully agree, but the best thing now would be to investigate why that happened, so that it is not repeated. I'd suggest opening a bug against the Ubuntu Slideshow being as much detailed as possible (i.e. which particular strings are missing translations, if you did the translation before deadline, screenshots, etc.) -> https://bugs.launchpad.net/ubiquity-slideshow-ubuntu/+filebug [11:31] dpm: seems it's my fault [11:31] dpm: some translations were not accepted somehow in Launchpad [11:38] KPK is really useless [11:46] Quintasan, no worries. You might want to contact the Ubiquity Slideshow developers to ask them if they could be added perhaps in 10.04.1 once they are accepted. Btw, don't you have a translation mailing list to coordinate Polish translations and avoid these misunderstandings? [11:47] dpm: we have but most of the dudes do Ubuntu things and Kubuntu is left partly untranslated. [11:47] oh, I see :( [11:47] dpm: I can accept translations myself but I must've missed them or something went wrong [11:48] Quintasan, bummer. But yeah, get in touch with the Ubiquity Slideshow guys, as I say, perhaps they can be put in Kubuntu 10.04.1, since unfortunately those translations cannot be updated in language packs [11:51] agateau: pong [11:51] Tm_T: oh, k ^^ [11:51] apachelogger: what did I do now? [11:52] apachelogger: oh, yeah, all is fine now both 386 and 64bit [11:52] or atleast should be [11:57] apachelogger: what's the status of the KDE client for U1? === dendrobates is now known as dendro-afk [11:57] apachelogger: (oh, and hi!) [11:57] agateau: in planing stage [11:58] apachelogger: ok, thanks === michaelk is now known as Guest56007 === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [13:30] Riddell: any news about the website? [13:30] ofirk: no, sigh, I guess the sysadmins are at the UDS location already doing stuff there :( [13:31] so I'll need to hassle them in person next week [13:33] I am wondring, what is our relation with canonical? it seems that they don't care about kubuntu public relations [13:34] to be fair, www.ubuntu.com hasn't changed either === effie_jayx_ is now known as keffie_jayx [13:36] yeah, but that is because they weren't ready for the change [13:37] we are ready === dendrobates is now known as dendro-afk [13:45] Tm_T: Would you please comment in Bug #574906 on clamav working on powerpc. [13:45] Launchpad bug 574906 in clamav "Clamav 0.96.0 clamd fails to start on powerpc" [High,In progress] https://launchpad.net/bugs/574906 [13:47] apachelogger: Would you please give us the benefit of your expertise in Bug #571286. [13:47] Launchpad bug 571286 in couchdb-glib "Data loss of postal addresses between Evolution and Ubuntu One's Funambol exchange/web UI" [High,In progress] https://launchpad.net/bugs/571286 [13:47] Good $TIMEOFDAY everyone. [13:47] * apachelogger falls over [13:47] Good 13:47 to you too ScottK [13:47] I should go get something to eat :P [13:48] Riddell: How goes the battle against tryranny and foreign opression? [13:49] the polling booths are open I hear, I'm due at the counting centre later tonight to make sure there's no corruption going on [13:49] oh my [13:49] 7 people want something from me [13:50] apachelogger: Yes, but I pinged last, so by definition it's the most urgent. [13:51] interesting defintion [13:51] hm [13:52] It's correct because it's the one that works best for me. ;-) [13:52] ScottK: akonadi does use free-form addresses IIRC [13:52] and it worked, ScottK! [13:52] apachelogger: Would you please check and say "It's good, bad, don't care" in the bug as applicable. [13:52] well [13:53] * apachelogger dislikes the idea of making fdo follow crap someone else invented for no good reason [13:53] gotta look into it a bit more though [13:53] If that SRU goes in we'll be pretty much stuck with it. [13:53] Thanks. [13:54] * ScottK was tempted to write "Web service bought a proprietary thing that's incompatible with FOSS is not on the list of allowed reasons for SRU", but refrained. [13:55] * apachelogger finds that sensible though :P [13:55] anyhow [13:55] just so I get this right [13:55] evolution uses free-form street field [13:55] so does the fdo spec [13:55] so does akonadi [13:56] so does legacy KDE stuff, which probably follows what vcd supports [13:56] ah yeah. good old U1 :> [13:56] * ScottK thought people would find it's absence in Kubuntu a feature and was a bit suprised to be found wrong. [13:56] and they are seriously proposing that we change all of that because they feel that using some prop crap is a viable option for a company that is supposed to make money using floss? [13:57] fwiw, afaik Akonadi's SyncML support use(d|s) Funambol as well [13:58] at least last year's GSoC project for SyncML support required libfunambol [13:58] apachelogger: I don't mind if they use proprietary stuff in their server. I do mind if they create a permanent diff between (K)(U)buntu and the rest of the world over it. [13:58] no idea if/hpw that relates :) [13:59] Sput: well, looking at akonadi alone it is no problem eitherway [14:00] apachelogger: yeah, but if the real reason for this behavior is phone syncing support... [14:00] apachelogger: Will kmail consume the data either way? [14:00] because especialy in context of the couchdb resource definition @ fdo, the resource needs to map akonadi data to match the spec [14:00] ScottK: akonadi abstracts that pretty nicely, yes [14:00] * ScottK hopes this is going into the bug. [14:00] ScottK: will do [14:01] Tm_T: Thanks. [14:01] Sput: that is reason to disobey an established standard? [14:01] kmail should provide an option for not using akonadi as backend [14:01] maybe we should make ooo default to MS office doc format after all [14:01] maybe more reasonable [14:01] seeing as it improves interoperability [14:02] oh oh oh [14:02] apachelogger: from reading the bug, the established standard has already been adapted :) [14:02] ScottK: I see trouble emerging eitherway [14:02] ScottK: is my comment sufficient? [14:02] Sput: It's not clear if that's an adopted change or a proposed one. [14:02] so [14:02] ah. tenses. [14:02] we have address1 [14:02] and address2 [14:03] and the user creates an entry using both on a phone [14:03] Tm_T: Fine. Thanks. [14:03] so that gets synced into U1 [14:03] from U1 we sync into akonadi [14:03] and now!!! [14:03] akonadi/kaddressbook uses free-form address data [14:03] so, either akonadi/kaddressbook is changing its behaviour [14:04] I was just wondering about how it'll work once Akonadi speaks with phones directly, disregarding U1 (and it'll probably use Funambol as well), in which case maybe adapting the standard to match reality wouldn't be that bad [14:04] OR the akonadi-couchdb resource needs to dump address2 (more like not add it to the akonadi entry) [14:04] Seems to me more sensible for their web app thingy to be smart enough to convert free form address data to the format needed by funabol instead of imposing that on the user. [14:05] ... or that, if it can be done sensibly :) [14:06] well [14:06] IMHO the only solution here is [14:06] a) serverside abstracation, to somehow squeeze the client form-free address into funabol [14:06] or [14:07] b) get a revised version of vcard spec and implement that across floss to come up with a non-form-free addresss field === dendro-afk is now known as dendrobates [14:07] making every u1 client implementation follow funabol, just because they are too stupid and ugly to follow a freaking standard is just not sensible [14:08] as long as the standard isn't adapted to what appears to be reality (or not?), it's not [14:09] Sput: that funnyball is not reality [14:09] * apachelogger thinks vcard is much more established :P [14:10] * Sput wonders what SyncML does natively [14:11] "Any client that supports SyncML contact sync, MUST use vCard 2.1 to convey contact information." [14:11] that looks quite clear :) [14:11] that's from an Apple spec though :> [14:12] apple only knows the word MUST anyway :P [14:12] in any case, looks like SyncML uses vCard and vCal to exchange data, which is also the only sane thing to do [14:12] most notably is doesn't have address1 and address2 [14:14] * apachelogger finds the couchdb-glib stuff increidbly confusing -.- [14:15] so yeah, I take back what I've speculated before and agree that the only sane thing to do is honoring existing well-established standards [14:16] hm [14:17] aha [14:17] http://library.gnome.org/devel/libebook/stable/EContact.html [14:17] apparently evolution does not use free-form streets [14:17] but also uses that street + ext stuff [14:18] that's what the guy said in the bug [14:18] oh, must have overread that [14:18] hm [14:19] interesting is that EContact dervies from EVCard [14:20] * apachelogger fires up evo [14:22] ehm [14:22] I dont get it [14:23] * apachelogger also finds that documentation rather useless [14:23] but in evo I have a free-form text field for the address [14:23] no clue where it gets ext from [14:24] wth [14:24] I'm getting disconnected all the time :S [14:28] sebas: Reading kde-devel it seems it's time to have the "What version of Qt will KDE support with KDE SC 4.5" discussion. I suspect we'll be going to 4.7 and most distros will too, so it'd be nice to have a discussion about it and get everyone in agreement. I seriously never want to have to deal with the Qt 4.5/KDE 4.2 mismatch we had in Jaunty again. [14:33] ScottK: agreed [14:38] theres plenty of Qt 4.7 dependencies in trunk already [14:38] Sput: http://paste.ubuntu.com/428952/ anything youd add? === mcas_quassel is now known as mcas [14:40] apachelogger: b) is weirdly put, also misses a verb [14:41] b) as far as we (that is me and a KDE gentoo developer) can see, akonadi will support phone sync via syncml (an established standard), and syncml enforces exchange of contact data via vCard (an established standard). (that said I wonder why the fdo spec cant implement vcard to begin with) [14:41] maybe? [14:41] bought [14:42] or "an even more established standard" :) [14:42] that sounds like fun ^^ [14:44] also, all mail clients I know of support exchanging contact data via vCard, so do the groupware servers I know [14:44] even phones [14:45] ScottK: good point, let me think about that [14:45] sebas: Thanks. [14:45] Tm_T: and phones. === dendrobates is now known as dendro-afk [14:48] now that I think about it, forcing the street information to be 1-2 fields makes no sense - there's address schemes that require more fields [14:49] as I understand it address1 is still free-form [14:49] just that ext is somehow supposed to enhance it [14:49] no clue how or for what === dendro-afk is now known as dendrobates [14:49] O_o [14:49] MAH BRAINZ!1! [14:50] kubotu: order brain for Sput [14:50] * kubotu shouts: OMG!!!!! RED ALERT! We lost a brain. Get me a medic, NOW! [14:50] !!! [14:50] omg [14:50] * apachelogger posts comment and starts reviewing some C code [14:50] apachelogger: Thanks. [14:51] also I find it concerning how quickly they are on changing the spec [14:51] ...what if a company internally implemented that couchdb stuff using the spec... [14:52] Right, well now's your chance to speak up. [14:52] * apachelogger adds that comment too [14:52] Just be glad I decided to review that unaccepted queue yesterday for potential SRUs. [14:52] *nod* [14:53] kubotu: order cookie for ScottK [14:53] * kubotu slides one of world's finest cookies down the bar to ScottK. [14:53] Thanks. [14:55] order steak for ScottK [14:55] kubotu: order steak for ScottK [14:55] * kubotu slides steak down the bar to ScottK [14:55] hmmmm. Steak for breakfast. Wonderful. [14:55] * Quintasan hands ScottK a glass of water [14:55] You'll need it. :P [14:56]