=== vorian is now known as vorian_afk [00:54] i hate house problems :( [00:54] aw? what happened? [00:54] and good evening jjesse [00:54] good morning Jucato [00:54] we have a tree in the front yard and those tree roots have cracked the pipe that leads from the house to the sewer [00:55] so whenever water is run it backs up into the house from the drain [00:55] so we now have to get a new pipe run (which means paying somoene to dig up our front yard) [00:58] oh... :/ [00:59] yeah booo [01:02] i love it when you ask a question from a company about something on one of their web pages and they refer you back to that same web page [01:02] that doesn't have the answer you need [01:03] quality customer support :) === vorian is now known as vorian_afk [04:30] wow.. kde4 iso only finished downloading now?! :( [04:32] * stdin starts downloading... [04:33] my body clock is severely messed up.... [04:33] mine's totally screwed [04:33] I woke up at ~2am (it's 04:34) [04:34] and I slept for ~12 hours [04:34] even with several alarms going off... [04:34] let's see... I usually get to sleep at around 3am... or sometimes 4am... wake up at around 8am... sleep again around 10am... up to 12noon... that was yesterday.. [04:35] saturday to sunday I only slept a total of 6 hours... including naps [04:35] bad Jucato. you're taking after me, i see. [04:36] :) [04:36] hmm, "[22:49] stdin: how much is a default kernel loaded in the ram" < why do these people ask ME these things... [04:37] because you know everything duh! [04:37] but, why not ask the channel? [04:38] and I don't really know the answer, I'd guess all of it tho [05:49] * nixternal loves valgrind! [05:49] * Jucato loves nixternal [05:49] in a fraternal way :) [05:49] hahaha [05:49] nice try [05:50] what? O.o [05:50] not to shabby....only took me a few hours to complete a class implementation...and I had one hang up that was blatent, but I couldn't see it [05:50] private: [05:50] int maxIndex; [05:50] and then later in a member function I had [05:50] int max = maxIndex; [05:50] :) that won't work [05:51] no, it wont :P [05:51] * Jucato scratches his head... [05:51] if it was java it would of worked :) [05:51] Jucato: maxIndex wasn't implemented [05:51] if I had 'int maxIndex = 0;' then it would have worked [05:51] oh... I thought it would have been initialized through the constructor :) [05:51] not implemented, instantiated [05:51] default constructor [05:51] ah ok :) [05:52] in that case :) [05:52] I could still instantiate that way [05:52] nixternal: oh, i was assuming you were trying to use a private variable, out of scope. [05:52] * Jucato headdesks until bled dry [05:52] lol! different views :) [05:52] Hobbsee: if my findMaxIndex() was public, then you would be correct [05:52] findMaxIndex() was private as well [05:52] oh right [05:52] * Hobbsee wonders why [05:52] * nixternal too [05:53] but that is the way the class was designed [05:53] erm, if findMaxIndex() was part of teh class, you could use the private variable. [05:53] with it public [05:53] if I used an accessor/mutator, then yes [05:53] but this class has none [05:54] err, ya, dunno what I was just thinkin'...it was a lonely little butterfly of an int [05:54] nonetheless, totally forgot to instantiate the lil bugger [05:54] valgrind came to the rescue...because it would still build fine, but it would seg fault [05:55] seg fault due to maxIndex being null [06:00] * Jucato thinks his c++-foo doesn't even come close to average if he couldn't grok this... [06:02] * Hobbsee thinks it would be more helpful with the code [06:02] you can still change private variables from the public function - you just cant change the private varialbe directly [06:03] * Jucato thinks he's pretty dense today... [06:48] kde4 live is quicker than I'd have thought :) [06:48] even if I did have to get a wired connection and edit the sources.list to enabel restricted then install l-r-m [06:49] * Jucato would love to have tested it on a real CD... [06:49] alas no blanks... [06:50] I used a DVD [06:50] no blank CDs [06:50] (my mother stole them all) [06:51] no blanks. period. [06:51] not even blank bullets... :/ [06:51] virtualbox/vmware/qemu ? [06:52] vbox [06:52] took a while to load for me in vbox [06:52] *a long while [06:52] long while [06:52] yeah. I fell asleep [06:52] j/k [06:53] it looks different too... [06:53] uploading screenshot [06:56] http://jucato.org/stuff/kde4/kde4live.png [06:57] Jucato: what's with the windeco glitchiness? [06:57] vbox :) [06:58] although I doubt vbox had anything to do with the Task Manager plasmoid's location :) [07:01] wow so many KDE4 apps installed :) [07:05] bg [07:05] kwin --replace [07:06] * Jucato just closed it... :P [07:06] damn [07:06] :p [07:06] but so far so good. the ISO works :) [07:07] well, I got kwin composite going :) [07:07] something I can't do in vbox :) [07:14] morning, all [07:19] wow, only 3 crashes so far :) kwin: 1, kontify4: 2 [07:19] yeah knotify [07:20] those were the 2 things i expected to crash [07:20] kwin after I enabled composite anywat [07:20] *anyway [07:20] although I haven't experienced kwin crashing yet on my lappy (from svn) [07:21] mine crashed just as it enabled composite, that why you saw my try to restart it before [07:26] time to reboot back in to kde3 === \sh_away is now known as \sh [08:46] good morning folks [09:21] hi sebastian^ [09:40] :) === Shely is now known as MJ086 === Hobbsee_ is now known as Hobbsee [12:19] what is the approbiate status for this bug ? invalid ? [12:19] https://bugs.launchpad.net/ubuntu/+source/kde-style-qtcurve/+bug/135847 [12:19] Launchpad bug 135847 in kde-style-qtcurve "kde style qtcurve doesnt apply changes" [Undecided,Confirmed] [12:21] mikkael: yeah, i would [12:21] * Jucato waves [12:21] is i right, that his ".config" folder should be owned by user ? [12:21] yes [12:22] if it is in your home, yes === meduxa is now known as toscalix [12:22] ah good [12:22] and it sounds like an invalid bug which relates to an alpha, judging by your comment [12:23] for me it was a valid bug until 10 minutes ago :D [12:25] what's the package that contains the trash icon on kicker ? [12:30] right-click on the panel -> Add Applet to Panel -> Trash? [12:31] i mean whats the package to report a bug [12:32] kicker (or kdebase) [12:33] if i want to open the trash folder via this icon i get "malformed url: trash:/" error if dolphin is my file-manager [12:37] on a default gutsy install, with dolphin as filemanager..is the trash opened with konqueror or dolphin ? [12:37] * Jucato fires up vbox [12:39] mikkael: dolphin [12:39] uh oh, then again something wrong on my install :( [12:40] mikkael: seems to work here [12:42] well google shows a lot of results if i search for that error-message..ill try to fix this [12:42] thanks, you saved lp from another invalid bug ;) [12:43] I remember it not working during the pre-releases of gutsy, but that got fixed afaik [12:44] my install is from august.. [12:45] my install is from about september [12:46] mine is last month. beat that! :P [12:46] fine! i'll reinstall now :p [12:49] stdin: how about adding amarok2 to you ppa ? [12:49] mikkael: it won't build [12:49] oh ok [12:49] that's the only problem :p [12:50] I tried getting a more recent snapshot, but that failed miserably too [12:50] ok, gotta go, have a nice day guys and girls [13:16] hello [13:21] * Hobbsee waves [13:22] * Jucato waves too [13:25] now, why isn't poppler backported? [13:26] ....................... [13:26] @lart stdin [13:26] well I needed to backport it to build... something? but it's not in -backports [13:26] stdin: um...um...what do you need it for? [13:27] and it makes my "revert to -backports" script go "BOOM" [13:27] *with out it backported [13:27] backporting poppler will tend to make it go boom, too [13:27] assuming it's an api change, which it almost always is, iirc [13:27] I think I needed it for kdebase-kde4 [13:28] oh, do you just need libpoppler-qt4-2 ? [13:29] not sure, i needed it for something (fuzzy memory) when building kde4 in my ppa [13:30] either kdebase-kde4 or kde4libs [13:30] sarah@LongPointyStick:~% rdepends libpoppler2 | wc -l 12:29AM [13:30] 19 [13:30] doesn't count build-deps does it.. [13:30] it's fancy grep time [13:31] no, that's why i searched for the binary lib, not the -dev package - and made the assumption that all the packages involved did shlibs correctly. [13:31] sarah@LongPointyStick:~% rbuildepend libpoppler-qt4-dev | wc -l 12:31AM [13:31] 8 [13:31] i'd say ti's that that you need [13:32] sarah@LongPointyStick:~% rbuildepend libpoppler-dev | wc -l 12:31AM [13:32] 18 [13:32] sarah@Lo [13:32] I think it's kdegraphics-kde4 and/or koffice actually [13:32] grep -C5 "poppler" /var/lib/apt/lists/ppa.launchpad.net_tsimpson_ubuntu_dists_gutsy_main_source_Sources |grep "Package:" [13:32] sarah@LongPointyStick:~% rbuildepend libpoppler-qt4-dev 12:31AM [13:32] kde4graphics [13:32] kdegraphics-kde4 [13:32] koffice2 [13:32] okular [13:32] kde4graphics [13:33] kdegraphics-kde4 [13:33] koffice2 [13:33] okular [13:33] you have a strange way of doing things :) [13:33] * stdin is tempted to do "!paste | Hobbsee", but fear the stick too much [13:34] howzat? [13:34] that'll do :) [13:35] yeah, kdegraphics-kde4 build-deps libpoppler-qt-dev (>= 0.6.1-1) [13:35] and 0.6-0ubuntu2.1 is in -updates [13:35] then i think you'll need to backport everything that depends on it. [13:36] or build depends [13:36] and test it [13:36] either way, it's a mighty big backport [13:36] it'll be needed if you want kdegraphics-kde4 in gutsy-backports/universe [13:37] one thing is certain ... ast is a good speaker - makes one really unhappy about the state of bloat in current software [13:37] I've had the new poppler installed for a while and haven't noticed any breakage anyway (doesn't mean there isn't any, just that I haven't seen any) [13:37] jdong might have smoked enough crack to take it...but.... [13:39] <_buz> stdin: i've found it to be much faster [13:39] <_buz> now pages render near instantly in kpdf [13:40] <_buz> whatever you did to it, its appreciated :P [13:40] just got the package from hardy and built it against gutsy :) [13:40] stdin: then again, this is backports. [13:40] but, it's also ubuntu's reputation [13:40] tough call. [13:41] Hobbsee: I know my ppa isn't any comparison to the ubuntu archive [13:42] also everyone who has kde4 from my ppa has the new poppler anyway [13:42] stdin: it's not the kde stuff that i'm worried about [13:42] it's the fact that who knows about gnome, etc, stuff, which people who are testing your ppa likely arent using [13:42] yeah, true [13:43] if evince breaks with the new poppler, your KDE 4 people are extremely unlikely to test it :) [13:43] yet, oh crap, you've just broken it for anyone running backports running gnome. "whoops" [13:44] I doubt "whoops" will be the exact response :p [13:44] well, true :{P [13:48] No, the exact response is something like "Backports aren't enabled by default for a reason." [13:49] *snort* [13:49] well... [13:50] they do say "unsupported updates", but not "enable this and have to reinstall" [13:50] coz that would be "stdin's PPA"... [13:50] * Jucato runs and hides [13:50] Hobbsee: you snorted again? O.o [13:50] kind of makes you look sceptically on all those new ultra-complex projects. [13:51] hi mhb [13:51] hi Jucato [13:51] Jucato: nah, my ppa has "enable this and get a svn version of konversation, a broken smplayer and a shiny new QtCurve" :p [13:51] KDE4 was just a bonus :) [13:51] * ScottK once worked on a project where we spent almost 2 years simplifying the design to the simplest, minimal solution we could come up with. [13:51] "and break your system" :D [13:52] only if you don't remove kde4base-data [13:52] ScottK: and the result? [13:52] Worked better than anyone expected when fielded. [13:52] We also got some "You spent two years in design and all you changed was ..." [13:52] :o) [13:53] My response was along the lines of, "Yeah, it was really hard to figure out how to change so little." [13:54] Of course I've also been caught figuring out how to do things that get 80% of the benifit at 5% the costs too. [13:56] ScottK: that is what I thought [13:56] we really should be trying to do things simple [13:56] It's hard though. [13:57] people said that Adept was too complex, and we will soon be replacing it with something twice (or more) as complex, with DBus dependencies and more [13:57] A good exercise is to try to add a feature to a program at a net zero SLOC count change. [13:58] * ScottK has personally already replaced Adept with Apt. [13:58] me too [13:58] actually, I was wondering whether we need a package manager [13:59] We do, but it should be far lighter than Adept, I'd say. [13:59] we should use an automatix-equivalent [14:00] you could have a nice web app doing all the searching and other stuff [14:00] if you have no internet, you use gdebi then, I guess [14:00] * ScottK boggles at nice being right next to web app. [14:00] :o) [14:01] But of course, I'm old and cranky, so I like my programs and my data on my actual computer. [14:01] me too [14:02] but I like googling, too [14:02] googling a package, clicking on it, see it install... [14:03] and when you are old and cranky, you would use apt-get which you have on your machine nonetheless [14:04] * ScottK shudders at actually installing code found via Google without looking at it. [14:04] I still think adept manager lacks a target group [14:04] ScottK: installation could be done via apt like it still is [14:05] ScottK: you just find the package via the internet, the installation will be done by a nicer version of adept batch [14:05] Right. It's the install random code found somewhere out there I shudder at. [14:06] ScottK: which will not happen in this scenario [14:06] OK. I guess I misunderstood "[09:02] googling a package, clicking on it, see it install..." [14:07] * Jucato thought Tonio_ was working on kio-apt for that? [14:07] he already did it [14:08] the framework is all in place, basically [14:08] all we would need is just do a nice official search engine for packages and then dump graphical package management once and for all [14:09] * Jucato would disagree w/ the last part though.. but since he doesn't code, doesn't have a right to say [14:09] Jucato: what do you mean? [14:10] if by "dump graphical package management'" you mean dropping a standalone package manager app. [14:11] Jucato: yes, by dump graphical package management I mean dropping everything except gdebi and adept_batch [14:11] Jucato: please tell me who and why would need it [14:11] Jucato: my idea surely can be flawed [14:12] it's just me. don't worry about it :) [14:12] don't have stats or user feedback to back it up. [14:13] Jucato: just give me an example [14:13] Jucato: basic users would browse the web, it is perhaps even easier for them than the current way [14:13] Jucato: and I guess more intuitive [14:13] Jucato: advanced users like me stick to apt-get [14:14] I don't know... that really sounds easy for installing (and browsing) packages. but besides installing? [14:16] it would probably really be more intuitive though for users coming from Windows-land, where they'd use a web browser to look for packages and then download those and install them [14:16] hmm, I wonder how often basic users remove packages [14:16] I mean surely they remove apps [14:16] and they perhaps fancy autoremoving [14:17] but besides this? [14:17] libraries? [14:18] mhb: This may be a good spec for Hardy +1. Not to soon to start thinking it through. [14:19] just not sure.. despite the unlove for Adept, there are still quite a number of users who prefer to use a GUI package manager. and in the absence of a good KDE/Qt alternative, resort to Synaptic [14:19] So make one that's lighter and faster. [14:20] indeed [14:20] but there are no plans of such a manager [14:20] only more complicated ones are on the horizon [14:20] mhb: So make some. [14:21] qt frontend to packagekit in the making? [14:21] * ScottK thinks not. [14:21] I mean, there's one in the making... not sure about it's status though [14:22] There is? [14:22] yeah [14:22] * ScottK thought it was just a Gnome thing. Not sure how it'd help anywhere else? [14:22] ScottK: why? [14:22] ScottK: I mean - my solution will be very light [14:22] packagekit is supposed to be a cross-desktop/distro package management system [14:22] ScottK: why should I make more? [14:23] http://liquidat.wordpress.com/2007/11/13/qt-frontend-for-packagekit/ [14:23] Jucato: For Gnome. [14:23] er? [14:23] Jucato: packagekit will be complex by design [14:23] That's what someone told me. At which point I quit caring. [14:23] it doesn't have a GUI frontend [14:23] afaik [14:23] hm. ok... [14:23] mhb: I agree with much of what you're saying, but not the web app bit. [14:23] I might be wrong. so anyway [14:24] ScottK: server (web) apps are designed for indexing stuff... [14:24] ScottK: so search will take less time than it would take normally [14:25] ScottK: on my machine, on grammas machine, everywhere [14:25] I can see creating a functional split where figuring out what package you want to install is a web thingy, but everything after that is a local app. [14:25] you will not download anything via web itself, you just find the package, everything else will be as secure as it is today [14:26] ScottK: of course [14:26] OK. Sounds like we agree. [14:27] ScottK: the web app would be the equivalent of the user googling "sudo apt-get install package" [14:28] +site:kubuntu,org [14:28] ScottK: adept_batch would handle the installation itself [14:29] advanced users would still prefer apt-get cmd line because it is the superior way of adminning stuff IMHO. [14:29] <_buz> how would go about alternative repos with webapp [14:30] _buz: Hopefully only after lots of warning. [14:30] Really not our problem. [14:30] _buz: yeah, that is the only technological part that is not ready today... something like apt://repository/package could be done, but with warnings [14:31] <_buz> sounds too much like linspire to me [14:32] _buz: What sounds like Linspire? [14:32] <_buz> webapp for packages [14:32] <_buz> isnt that what linspire does [14:33] You mean Click and Run? [14:33] <_buz> yes [14:33] it may be similar, I am not saying that the idea is original [14:33] It's main point is to get you proprietary software, so the intent we're discussing is completely different. [14:33] we already have the technology, opensuse has it, too [14:34] it is just the bold step with dropping the Add/Remove software and Adept Manager that is new [14:34] totally radical change [14:34] we have seen that administering those apps was a PITA [14:34] nobody really cared for them [14:34] (devs, I mean) [14:34] and users were not really happy about them [14:35] but doesn't that apply only to Adept? [14:35] (unfortunately) [14:35] Jucato: hmm, other package managers are more polished, I am certain [14:35] mhb: I'd say slap something together and get it in Universe for Hardy. If users like it, maybe the tide can be turned. [14:36] ScottK: heh, how many people out of this channel would care if there was a new package in universe? :o) [14:37] I guess what I'm just saying that to drop the prospect of having any GUI package manager completely, just because of Adept, is a bit of a jump... oh well [14:37] time to work. [14:37] ScottK: I can sit on my behind doing nothin, because the technology is there already [14:37] mhb: If every time someone whined about Adept, people could reply "Here, try this instead..." then maybe it'd get momentum. [14:37] mhb: What do I install to make it work then? [14:38] ScottK: kio-apt from Tonios repos, I think [14:38] ScottK: review the thing in -motu please [14:38] I dont know whether he pushed it somewhere [14:38] Hobbsee: There is no thing yet. [14:38] <_buz> whatever happened to kpackage anyway [14:38] ScottK: at :32? [14:39] Right. We're discussing the idea of a light weight alternative to Adept. [14:39] ScottK: there is also another aspect, which I sometimes take too seriously, but it is definitely important, and that is publicity [14:39] ScottK: lightweight would be an understatement I think :) [14:39] mhb: True, but IME if you have a better mousetrap, people would notice. [14:40] ScottK: we already have the technology and we can have it working by Alpha 2 [14:41] Great. When you have something that needs reviewed for upload, ping me on -motu and I'll take a break from my reviewing strike to look at it. [14:41] I guess for Hardy, having both around, but pushing the new one could be the goal [14:41] because it is LTS, after all [14:41] Yes. No radical change for Hardy is the best way. [14:41] we can see if it catches on, and we will have Adept as failsafe ready [14:42] Exactly. === apachelogger__ is now known as apachelogger === \sh is now known as \sh_away === rdieter is now known as rdieter_away === apachelogger_ is now known as apachelogger === rdieter_away is now known as rdieter [19:12] Riddell: what is going on with kdepim packages in hardy? === \sh_away is now known as \sh [20:23] here's the fun i'm having today: http://www.flickr.com/photos/j0217995/sets/72157603315165637/ [20:25] Yum [20:25] yeah.... no water for 3 days :( === buz_ is now known as buz [21:02] evening [21:04] mhb: Good evening. === _czessi is now known as Czessi === \sh is now known as \sh_away [21:23] ScottK: the biggest flaw in my plan ATM is the way that the website "knows" whether the package is installed or not [21:24] That'd definitely be tough. [21:26] yeah, I wonder how to do that as simply as possible [21:28] easy, use an active-x control [21:28] SCNR [21:29] buz: sure :o) [21:30] mhb: what are you making? [21:31] mhb: from skimming the conversation yesterday, i thought the idea was something along the lines of kio-apt? [21:31] (which i haven't tried) [21:31] yuriy: right, my idea was to create a package search web application which would be tied to kio-apt [21:32] mhb: what do you mean by a web application though? would it be running locally? [21:32] mhb: how would it be different from kio-apt? [21:33] yuriy: think adept manager, but as a web app, with links to kio-apt [21:34] yuriy: well, not exactly kio-apt, more like the Firefox package installation system [21:35] yuriy: apt://thunderbird/ installs Thunderbird ... [21:35] oh... cool. [21:35] nosrednaekim: one - searching done remotely, faster searching on all computers [21:37] nosrednaekim: two - web content is really flexible, you cannot add icons, screenshots to the current Debian labeling system easily, you could do that on web pages [21:37] oh thats nice.... screenshots of the app :D [21:37] nosrednaekim: three - it is more multiplatform than whatever the PackageKit people come up with [21:38] haha.... figures thats what is behind it all :D [21:38] nosrednaekim: we already have most of the technology, OpenSUSE has it too and I am sure more distributions will have it in the future [21:39] Actually getdeb (for all I think they aren't great packagers) have a decent web site for this kind of thing. [21:39] ScottK: good to know, I will check that [21:41] nosrednaekim: my aim would be to finally solve package management in Kubuntu for basic users [21:41] nosrednaekim: by "solve" I mean replace with something that is usable, simple, fast and maintainable [21:41] yeah. [21:42] I think klikit was trying to do something like this.. [21:42] nosrednaekim: what we need is simple package installation for the common users [21:42] nosrednaekim: powerusers should always stick to the command line, there is no point in providing graphical tools for them [21:42] (by default, that is) [21:43] I love synaptic, and I think I'm pretty much power-user defined. [21:43] Though in general I agree with you [21:43] adept is too complicated [21:43] And slow [21:44] I wish we could just go with synaptic themes all qt-ish XD [21:44] nosrednaekim: sure, use what you like best, that is the open-source way. [21:45] yup.... but I will be interested in seeing what you turn out..your stuff is pretty good.. [21:45] mhb: Make it simple, useable, and fast, and it'll be what people pick. [21:46] nosrednaekim: adept is too complex to my liking, and too complex usually means too slow. Although I try to be as unbiased to PackageKit as possible, you cannot really label it "simple". [21:48] ScottK: hmm, the getdeb.net engine is not open-source [21:48] i think adept primarily is as slow because its python [21:48] buz: wrong, adept is pure C++ [21:48] it is? [21:48] well in any case, the ui sure is weir [21:48] d [21:49] wish people would get it out of their heads that python is slow too <_< [21:49] mhb: No. I was just refering to how it looked. I'd not recommend actually using any of their code even if it was available. [21:49] nosrednaekim: depends on what youre doing [21:49] if you start crunching data in pure python, it's not gonna be fast [21:50] true [21:50] but if youre sane enough to use the lib properly, it can be quite fast [21:50] and the code is a dream to read [21:50] unfortunately Python is one of the languages where your math computations take so much longer that you manage to write the C equivalent, compile it and finish it while the Python code runs [21:51] Develop first and then opimize later anyway. [21:51] usually i would agree [21:51] mhb: True, but do the thing in Python and there optimize where needed. [21:51]