[00:17] Riddell: I'm having huge issues here with Karmic and USB support (randomly does not detect devices, including keyboard). have you heard of any similar issues before? [00:17] just trying to make sure if hardware or software is to blame [00:18] markey: no I've not I'm afraid, but have you checked lshal to see what level it happens at? [00:19] Riddell: will check, thanks === dendrobates is now known as dendro-afk [01:50] If somebody could sponsor http://jmthomas.toniox.org/phonon-backends_4.3.80-0ubuntu1.dsc and qt4-x11 and kdebase-runtime from bzr, that'd be great [01:59] JontheEchidna: I'm looking at Qt [01:59] thanks [01:59] JontheEchidna: This is the one that already built in the Ninja PPA, right? [02:00] yeah, all 3 of the packages are in ninjas [02:00] K. Thanks. [02:19] has anyone had problems with quassel crashing? [02:23] Only very rarely. [02:23] Much more rarely than in Jaunty [02:23] Note to everyone: Please don't make random whitespace changes in previous debian/changelog entries. [02:28] I think some text editors can automatically remove trailing whitespaces [02:32] Which would be fine if it were Debian doing it, but if we do it, then it can be merge hell. [02:35] is there a ppa with kde 4.4 packages newer than beta1? [02:36] No [02:38] desktop effects don't work for me in beta 1, and I read that it won't be fixed until beta 2 [02:42] Beta 2 is not out yet [02:53] OK, didn't notice UNRELEASED in debian/changelog. Doing it again .... [03:14] JontheEchidna: in kdebase-runtime, debian/control I see that: kcm-phonon-xine replaces kdebase-runtime-data (<< 4:4.3.80-0ubuntu89) [03:14] 0ubuntu89 [03:14] eek [03:16] all fixed [03:16] ok [03:17] thanks [03:18] no problem, good night :) [03:20] packaging issue, overwrite files in another package http://pastebin.ca/1716603 [03:23] Let's see how many libboost1.38-dev -> libboost1.40-dev transitions I can do while the source package for Qt builds. [03:35] Qt is uploaded. [03:39] ok just updated to the beta that is on the PPA and everything seems to be so much faster response time wise [03:49] hey [03:49] I'm on lucid and konversation uses 99% of cpu [03:49] jjesse: nothing broken? should I go ahead and upgrade? [03:49] any on has a similar experience? [03:49] anyone* [03:50] patcito: yeah, known Qt bug. Some workarounds include messing with font size or using a monospace font or messing with font subpixel rendering [03:51] http://bugreports.qt.nokia.com/browse/QTBUG-6281 [03:52] oh well, here we go...try out beta 1 on karmic === dendro-afk is now known as dendrobates [03:57] ok, thanks JontheEchidna [03:58] JontheEchidna: would deja sans mono work? [03:59] Possibly. The whole workarounds thing is a "your mileage may vary" sort of thing :( [04:02] thanks that fixed it :) [04:04] JontheEchidna: Selecting previously deselected package konq-plugins-l10n. [04:04] Unpacking konq-plugins-l10n (from .../konq-plugins-l10n_4%3a4.3.0-1ubuntu2_all.deb) ... [04:04] dpkg: error processing [04:04] /var/cache/apt/archives/konq-plugins-l10n_4%3a4.3.0-1ubuntu2_all.deb (--unpack): [04:04] trying to overwrite '/usr/share/doc/kde/HTML/en/konq-plugins/index.cache.bz2', [04:04] which is also in package konq-plugins 4:4.3.0-1ubuntu2 [04:04] Riddell said something about fixing that tonight [04:04] for once a konq-plugins update that I wasn't involved in ;-) [04:04] patcito: great :) [04:05] patcito: In the future, support for lucid should go to #ubuntu+1, but I'm glad that fixed your issue. [04:06] k [04:12] nixternal: You said something about virtuoso earlier ? [04:15] not that I know [04:15] Hmm might have been dreaming it [04:16] * daskreech impatiently goes trolling through PPAs for a virtuoso 5 build [04:20] Lex79: great job on beta packages for karmic...Just had to remove an extra bar on the bottom....jeesh, side-by-side notifications are scary :) [04:20] speaking of notification...the kglobalaccel one is annoying as all hell [04:22] Why doesn't krunner's command options work? [04:22] it's been 6 months :( [04:25] I'm unusally miserable tonight [04:42] nixternal, jjesse cli, development, netbook just pushed to lp:... [04:47] nixternal: please look at development edits. I took out a couple of duplicate entries that may have been there intentionally [04:49] kanibalv_: which ones were they? [04:49] I did have duplicates, ie. the tools [04:50] kanibalv_: sorry... [04:50] damnit [05:54] FREENODE SUCKS! QUIT SPLITTING ALREADY [05:54] damn, and entire day of shit around here [06:03] stupid stupid irc! [06:03] * nixternal wishes Ubuntu and KDE were on OFTC [06:03] they have SSL! [06:03] I am talking to nothing but air and netsplits, and it is fun [06:13] * daskreech tapes all of this [07:38] nixternal: the protocol is the problem, not the implementation [07:38] can't really do much about it [07:40] oh man [07:40] [07:34] [Notice] -Yettie to #freenode- YOUR SERVER'S UNDER ATTACK, PACK UP YOUR SHIT AND MOVE TO IRC.RIZON.NET, QUICKLY, I HAVED OPENED COMMUNICATION LINES AND WE'RE READY FOR YOU ALL! [07:40] they are really trying to blow it up [07:40] could be anyone [07:41] from one angry fat nerd, to microsoft, to apachelogger... who could tell [07:46] Sounds like Verizon [08:26] ehlo humans and wannabe humans [08:26] :) [08:31] that damned router, won't accept my configuration :/ [08:31] * Quintasan is out to school [08:50] Riddell: many thanks again for the tip with "lshal" you gave me last night [08:50] I did that, and the output is interesting [08:50] apparently the OS does see my devices [08:50] but then doesn't [08:50] I've copied the output on my server [08:50] Riddell: http://mark.kollide.net/lshal_markey.txt [08:50] (maybe you can make sense of it) [08:54] markey: the lost HIDs that is? [08:54] I guess [08:54] ah yes [08:54] lost USB devices [08:54] is what I mean [08:54] hrrr, that's fun [08:55] right now it doesn't see my printer, and a HDD [08:55] and can't get it to see them [08:55] (tried all ports) [08:56] if you search for "print" in the file, it shows a printer [08:56] but somehow KDE doesn't see it [09:20] markey: apachelogger is not saying much since them attacks started, I suspect that he is at the very least involved in all this [09:22] hehe [09:22] but then... with that Mafia boss avatar... [09:22] this made me suspect you [09:24] * apachelogger switches off all gps devices so that he shall not be located [09:32] hmmm update went ok thx to tsimpson heh i needed the overwrite for klipper too [09:32] but i noticed some bugs going to file some reports today [09:32] o.o [09:36] Ksuduko crashes on startup for me [09:37] how buggy is it really? [09:37] hmm no tried but i cant get rid of my national country flag even if i tell it to go away [09:37] :D [09:37] * apachelogger does not feel like booting his only kubuntu installation :P [09:37] since my netbook got equiped with moblin [09:38] that said, I find the UI paradigm a bit of the weird kind [09:41] ryanakca: any guesses about http://validator.w3.org/check?uri=http%3A%2F%2Fwww.kubuntu.org%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 [09:41] when I looked the other day I only found &? [09:41] maybe drupal/php does replace that for some reason? [09:43] ryanakca: also, can we somehow get gzip compression for the css and js files? [09:43] * apachelogger thinks that this in combo with proper http cache settings should proof quite a speedup [10:13] hiya [10:13] could any of you imagine giving a session about something K-related at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep ? :) [10:14] developer week time again? [10:14] yeeeeeeehaw [10:15] end of January [10:20] so who of the friends of the K is up for giving a session? [10:21] we're all thinking hard about what sessions to give, we'll get back to you :) [10:21] :-) [10:21] thanks muchly! [10:58] apachelogger: gzipping css would slow down the page [10:59] ghostcube: how so? [10:59] cause the page always needs css to be present [10:59] so? [10:59] it doesnt speed up to gzip it for the webserver [10:59] cause its always touched [10:59] why for the webserver? [10:59] on-the-fly compression [11:00] client http requests -> server [11:00] i know :| [11:00] server -> compress gzip -> chttp rely [11:00] but it wont help [11:00] reply even [11:00] ghostcube: yeah why [11:00] what need do you have to gzip an css file ? [11:00] makes sense if you gzip the on the fly cache for the php files [11:01] this is fastening up [11:01] but css o.O [11:01] gzip cache? [11:01] wtf [11:01] css is plaintext no good bandwith waster [11:01] so first we nuke off the constant transfer by issuing a proper http cache value [11:01] and then we gzip that thing [11:02] so once every month or so the visitor gets a new gziped css, that gets decompressed once a month, after that it is in the browser cache anyway [11:02] not being updated for another month due to http cache value [11:03] hmmmm [11:03] ok this would make sense [11:03] it even would make sense without the http cache value [11:03] make a response test [11:03] say you have a css that is like 50kb, gzipped it is like 10kb or so [11:03] i say it wont to [11:03] for 56k users it makes a lot of difference if that thing is 50 or 10 [11:04] hahahaha ok now we at the point [11:04] for dsl users it doesnt [11:04] if you look this way your aboslutely right [11:04] is that so? [11:04] most browser implement a hard barrier for http connections [11:04] no for which dsl users does the response time be an fact to not use the side or to claim about o,oo1 ms [11:04] so your browser will only open like 4 channels per server [11:05] yeah but this is stupid from the beginning [11:05] the more you can squeeze through those 4 channels the faster the site will render [11:05] thats true [11:05] the larger the site the more you need to get through at large [11:05] you cant reinvent the wheel [11:05] hence you want to have everything through as quickly as possible [11:05] :D [11:06] ghostcube: you should not be thinking in parts here [11:06] but sites [11:06] you can improve the user experience by adding Expires headers to the stylesheets and scripts [11:06] 1 site .. n parts [11:06] each part alone might be small [11:06] you can improve the server resource usage by adding gzip compression to that [11:06] but in the end you might end up transfering 500k of which 300k are completely pointless [11:07] apachelogger: ok thats correct [11:08] al: depends on what improve the server resource usage means [11:10] you'll get a slightly higher memory usage, neglectable rise in cpu usage, everything else improves === steveire_ is now known as steveire [11:11] * apachelogger notes that cpu usage is never neglectable [11:11] a server that does gzips everything is a lot easier to bring down than one that does not [11:12] just the additional lookups in memory will make a considerable overhead for large sites [11:12] dunno, nobody brought mine down so far [11:12] just saying [11:12] there's no overhead [11:13] ok now we come to an load balancer maybe :p [11:13] or psad [11:13] or snort [11:13] would move up cpu and mem would reduce any attacks [11:13] as long as you have high cache hit rates it's even faster to pull the compressed object from cache than the uncompressed [11:13] simplified for new requests the server goes: do I have file in mem? oh good, stream to NIC. .... with gzip do I have file? oh I should gzip file. do I have gzipped file? oh good, stream to NIC. [11:14] exactly [11:14] gzipping will always require more cpu cycles [11:14] not true, as pointed out above [11:14] depends on the server architecture or ? [11:14] of course [11:14] not all except apache can handle this in other ways [11:15] al: and how does the server know what to get? [11:15] the client asks nicely? [11:15] al: the client asks the server to hand him mem 0x13045uf+10? [11:17] if you have a http server software that does apply gzip everytime and everywhere then you can indeed assume there is no overhead for cache hits [11:18] for those that are nogzip by default (which is generally a good idea unless the site is never-changing anyway) then cache hits on gzip content will still introduce overhead by having the http server software realize that this is content that needs to be gzipped before it can access the memory [11:24] i don't see your point [11:25] 1) client requests, 2) server determines resource to serve, 3) based on 1+2 server looks for either compressed or uncompressed object in cache [11:26] on if 3) does not lead to a cache hit you get worse performance [11:26] 2) is crudely simplified if we are talking about resources really [11:27] and yes, not hitting cache is reducing performance [11:27] s/on/only/ [11:27] though we have at least 5 kinds of cache :P [11:28] not hitting either of them will reduce performance [11:28] where obviously not hitting an on-disk cache will be most awful [11:29] in that secnario you have to read a file from disk, wait for the read to finish and then process the file in whatever way [11:30] if you hit the on-disk cache you can just grab that and stream it off to the NIC [11:30] if you hit the cache in RAM you can stream off there [11:30] etc. [11:31] in most cases you will probably end up with hitting RAM cache (well, on a linux system at least) [11:35] well, exactly [11:35] whether you're serving compressed or uncompressed objects makes no difference if you hit the cache, besides compressed objects being smaller [11:40] al: I am quite sure that your CPU will disagree [11:45] i have empirical evidence of the opposite :> [11:49] * amichair uses gzip (on text/html content only) and Expires headers (on static content) too... [11:50] I'd have to agree that there is not impact on performance. unless you have a site with huge amounts of content such that every access will requires hitting the disk... in which case apachelogger is right [11:50] but that is pretty rare... [11:51] haha, empirical data :D [11:52] amichair: my point is that no matter what, gzip compression will introduce overhead unless the server software applies an-always-gzip paradigm [11:52] apachelogger: say I have 100MB of content. how much cpu does it take to gzip all of it? spread over the uptime of the server? that's pretty neglible... [11:52] not the compression [11:53] the lookup [11:53] speaking in apache httpd terms, enabling gzip compression is no more than adding an outputfilter for certain content types [11:53] calling that overhead is a huge exaggeration [11:53] the lookup is identical. at worst, pretend that you have twice as many resources to fetch. no change in hashmap access (or whatever similar technique the cache/server uses). [11:55] apachelogger: unless you're going for the theoretical 'even 1 cycle is overhead' logic. in that case you're right. but in practice... neglible. [11:56] * apachelogger notes that his original claim was that gzipped enabled servers would be easier to bring down [11:57] oh, that's a whole different discussion :-) [11:57] how so? [11:57] I might add ... form a calculation overhead ... in praticse probably the NIC or some bus from the NIC will be a bottleneck [11:58] I guess what matters is where your bottle neck is - that's the first thing to go down [11:58] if it's bandwidth (like in my case), gzip can only help. [11:58] if it's in cpu, it will do worse [11:59] as just said it will not be the cpu :P [11:59] if it's RAM, turning off caching will do the trick (regardless of compression) [12:00] for that to happen you need to be able to transfer data at higher speed than it happens internal via the fastest bus [12:01] depends on the hardware, of course... [12:01] some weak home routers can reach cpu bottlenecks before the bandwidth is saturated... [12:02] well, specifically for the web server case [12:02] hey, some ppl run web servers on shivaplugs too... [12:02] :-P [12:03] yet they will not hit a cpu bottleneck :P [12:03] there's no general 'right answer' - it depends on the particular use case and hardware [12:03] what cpus do those have nowadays anyway? [12:03] * amichair goes off to do some research :-) [12:04] wow, they're stronger than I thought, 1.0-1.2 ARMs [12:05] my router has ~200MHz [12:05] and there are weaker ones... [12:05] amichair: at the point the cpu might end being fludded with cache requests (which is most likely what will happen) the NIC will have gone down from either too much incomming traffic or it will be ever busy asking for resends of packets [12:06] amichair: ARM is going up actually, resulting the ARM based netbooks next year [12:06] so I've heard [12:06] well, we both know the discussion is pointless without specifics [12:06] * apachelogger imagines a bit of a fight there, intel moving towards embedded and arm towards desktop [12:06] but it's always fun to talk about performance and optimizations :-) [12:07] amichair: well, I think we can conclude that if no other bottlenecks apply the one or two cycles more will make the cpu go down faster than without gzip :P [12:07] ok, what's the IP? let's take it down :-P [12:09] * amichair flashabcks to his days of actual assembly cycle-counting optimizations... [12:09] my ip storage app is only equippied with char[16], but the IP was v6 ;) [12:32] hey apachelogger [12:37] hoi Xand3r [12:37] maybe you wanna say me wich ppa i need for the dualview support in systemsettings [12:39] pling ... [12:39] dualscrren support [12:39] o.O [12:39] woha this gzip discussion ... i have to read back lol [12:40] ghostcube: u can read the compressed version! [12:41] would be ... gzip isnt useful ? [12:41] :D [12:42] woha tomtom sux [12:42] :| [12:42] off to talk to the hotline [12:43] grml [13:37] hi Riddell, I'm looking at the Kubuntu translations in the imports queue and I see these POT files [13:37] debian/patches/common/kde.pot in kdelibs [13:37] debian/tmp/usr/include/kde/kde.pot in kdelibs [13:37] debian/kdelibs4-dev/usr/include/kde/kde.pot [13:37] I assume they should not be imported and can be blocked safely? [14:09] someone want a nice little get it into ubuntu job from me? this: http://atdot.ch/scr/index.html (the package already works well, but be nice to have in the repos) :D [14:15] dpm: right kde.pot doesn't get imported [14:15] it gets merged into kdelibs4 I think [14:18] Riddell, ok, thanks. Would it be possible to modify the package so kde.pot is not generated in patches/, tmp/ and kdelibs4-dev/ and therefore the intermediate .pot files don't get imported into LP? [14:18] meeting in 4 hours, yhes? [14:19] seele: a little under, but yes. [14:54] Riddell, and another question, I see kscreensaver/kxsconfig/hacks.pot in kdeartwork, is this a template that should be imported? Or is it an intermediate artifact or something? [15:18] Riddell: btw, how to reapply kubuntu membership? :) [15:18] at the meetign today :) [15:18] i need gto do so as well [15:18] if i remember :) [15:19] jjesse: yours expired as well? :) [15:20] freeflying: you should be able to just extend it yourself? [15:21] Riddell: seems can't [15:21] freeflying: yes i missed it when it exprired [15:22] i need to reapply i guess [15:23] I can just renew them then [15:24] Riddell: can we generate a localized version kubuntu for lucid? [15:26] How does this membership work? If someone becomes a Kubuntu member, will he/she also an Ubuntu member, or only a Kubuntu member? [15:26] hmmm no glovbal notices today for all the netsplits o.O [15:27] now that it's more busy in here........ [15:27] could any of you imagine giving a session about something K-related at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep ? :) [15:27] :-D [15:28] * Quintasan thinks [15:29] oh how nice, phonon died [15:30] Quintasan: what do you mean died? [15:30] Lex79: what's with kdebase-runtime? when I try to upgrade it to latest version (ninja ppa) it has literally over 9000 problems with depends [15:30] phonhon died after 1 year ? [15:30] freeflying: not working, not at all, even the control panel [15:30] oh the the daemon thought the whole system lol [15:31] lól [15:32] boah guys ok i have a short joke, i bought an tomtom one added it to my mac usb worked [15:32] added it to 5 different xp sp3 pc's no way [15:32] it doenst work [15:32] tomtom srvice [15:32] have u tried to change the usb cable [15:32] wth guys i told you on my mac it works [15:32] hmm ok we will have a look [15:32] o.O [15:32] Lex79: nvm, that's the runtime for lucid and I have karmic packages :P [15:33] anyone living near tomtom center in netherlands can go there kill them [15:33] :D [15:33] Quintasan: What? 9000? That can't possibly be correct! :P [15:34] LoL [15:34] JontheEchidna: you bet it is, proposed solutions were counted for 30 seconds :P [15:34] or should I call you Vegeta :P [15:34] * Quintasan notes he shouldn't mix Lucid and Karmic repos and expect everything to work [15:34] well, phonon kcm died for me [15:34] heh [15:34] heh [15:34] actually WHOLE phonon died for me [15:34] hehe [15:35] use jackd [15:35] :P === ghostcube_ is now known as ghostcube [15:39] Argh, I want to fire some of my evul tools at that faggot attacking freenode [15:42] JontheEchidna: are you working on libattica 0.1.1 ? [15:42] Lex79: nope, it's all yours [15:42] "thanks" :P [15:42] hehe [15:42] :) [15:44] JontheEchidna: Is it possible to copy new kdebase-runtime and phonon-backends? I'm pretty sure we don't want to break Phonon [15:44] or it's Qt's fault? [15:45] copy to where? [15:45] to this beta PPA [15:45] karmic copy to be exact :P [15:45] gaaah [15:45] oh, whew, thought that was a split [15:46] JontheEchidna: oh wait, nvm [15:46] Quintasan: I don't think the Qt + phonon trunk has been backported to karmic ppa yet. It probably should though === dendrobates is now known as dendro-afk [15:46] Don't do it [15:46] broken [15:46] really? [15:46] if properly backported I don't think it would be [15:47] Qt from ninjas and -> http://imagebin.ca/view/Znmhj-DQ.html [15:47] as long as you backport Qt, kdebase-runtime and phonon-backends all at once [15:47] hurr Qt from ninjas and 4.4 from beta PPA [15:50] bla [15:50] [10:47:18] hurr Qt from ninjas and 4.4 from beta PPA [15:50] [10:47:38] yeah, kdebase-runtime in beta ppa is built without phonon support [15:50] [10:47:56] since Qt in beta ppa doesn't have phonon from trunk yet [15:50] i mentioned i hate netsplits ? === jtechidna is now known as JontheEchidna [15:50] good i dont use phonon [15:51] :D === ghostcube_ is now known as ghostcube [15:53] argh, I hate netsplit. [15:54] today its very unhandy [15:54] 3 servers now [15:55] yesterday it was worst:/ [15:56] 2 hour left to the meeting:P [15:56] yeah still ddos christel says in #freenode [15:57] what does someone have against them? [15:58] I read the global notice, but today wasn't any notice [15:58] or is it just for gits and shiggles? [16:00] seems for account steeling [16:00] o.O [16:00] but dont ask me what this should be === nixternal is now known as Guest25223 [16:05] JontheEchidna: do you have the powers for upload libattica? [16:05] no :( === zorael is now known as Zorael [16:08] Is the meeting in an hour? [16:09] uff :( [16:09] ScottK or Riddell: http://dl.dropbox.com/u/394059/libattica_0.1.1.orig.tar.gz [16:09] http://dl.dropbox.com/u/394059/libattica_0.1.1-0ubuntu1.dsc [16:09] http://dl.dropbox.com/u/394059/libattica_0.1.1-0ubuntu1.diff.gz [16:09] 18:00 UTC, in about 2 hours [16:10] Lex79: Please merge from Debian and rename the source attica [16:12] ah.. I looked at the wrong time :) === skreech_ is now known as Daskreech === txwikinger2 is now known as txwikinger === Daskreech is now known as DaskreeCH [16:16] Can Kubuntuone do that? === dendro-afk is now known as dendrobates [16:20] I think the meeting should go to irc.oftc.net again, like yesterday:/ [16:33] aww man, I might miss the meeting [16:34] maybe I can pre-ack both applications? :P [16:34] JontheEchidna: people have done that in the past... (on other councils) [16:37] I'd rather they were post-acked [16:38] but we have a large council deliberately so we can get quorum easily [16:38] ok, I'll do that then. but I think we'll have quorom anyways without me [16:42] hmm, Lex79: are you working on Qt? [16:42] Quintasan: for what? [16:43] Lex79: well phonon kcm or phonon itself isn't working [16:43]