[01:01] <bluesabre> evening all
[01:01] <Unit193> Howdy.
[01:01] <bluesabre> hi Unit193  :)
[06:57] <Unit193> flocculant: So you'd say once thunar is ported to GTK3, we should hold off a while before pushing it to the real archives, keep it in PPA for testing?
[07:00] <flocculant> I'd imagine so - depends when it's ported I guess
[07:00] <flocculant> if it was early in cycle then maybe just go for it :)
[07:06] <flocculant> on the other hand maybe in the ppa for a bit
[08:39] <akxwi-dave> flocculant: notes added to pad
[11:10] <flocculant> akxwi-dave: ta
[12:04] <akxwi-dave> flocculant: your welcome
[20:55] <Unit193> https://git.xfce.org/xfce/xfce4-session/commit/?id=ac387875a5e0d4239848fa3560757fb7ef0c2338 could sync our whisker with Debian, though that's going to take a while...
[21:11] <Spass_> firefox really likes to freeze lately :/
[21:12] <flocculant> Spass_: not seen it since yesterday
[21:14] <flocculant> Spass_: also top marks for being first to mark the doodle poll :)
[21:14] <Spass_> yeah, I was hoping to not see that bug again after uprgrading to v53
[21:14] <Spass_> flocculant: ;)
[21:17] <Spass_> what's interesting about the freeze I have now is that htop froze with firefox
[21:17] <Spass_> and I cannot kill it
[21:20] <Spass_> 'top' works but it doesn't show firefox and htop processes, but I can see htop hanging in GUI system manager
[21:20] <Spass_> craziness
[21:20] <flocculant> Spass_: this is what I got http://i.imgur.com/0jkZRiW.png
[21:21] <Spass_> I would love to be able to open that link, but "Firefox is already running, but is not responding (...)"
[21:22] <Spass_> something new, cpu usage dropped significantly, but everything seems hanging still
[21:23] <Unit193> Use xombrero.
[21:23] <flocculant> well that screenshot showed load average at 58,31,13
[21:23] <flocculant> Unit193: :)
[21:24] <Spass_> xombrero, noted for later
[21:25] <Unit193> flocculant: You want xfce4-dict-0.7.99 up too?  It's a development snapshot.
[21:25] <flocculant> Unit193: no idea - I guess so
[21:25] <Spass_> ok, I was going to sleep nonetheless, good night all
[21:26] <flocculant> Spass_: night
[21:26] <Spass_> and this time I was able to send ubuntu-bug, maybe that was useful
[21:27] <flocculant> Spass_: bug number?
[21:27] <Spass_> ehrm... when it was showed?
[21:27] <Spass_> idk
[21:28] <flocculant> mmm - wonder what it sent
[21:28] <flocculant> tomorrow :)
[21:29] <Spass_> I didn't saw any bug number but I didn't looking for it, I may do it again before I go once again, it still hanging happily
[21:31] <flocculant> it is maybe sending a crash report - which is automatic
[21:32] <flocculant> and not the same as a bug report - that would necessarily mean using browser - check in /var/crash, should be there
[21:32] <Spass_> I saw a window with my system information, I looked through it briefly and I clicked 'send'
[21:33] <Spass_> nope, nothing related to firefox or htop in /var/crash :(
[21:33] <flocculant> maybe crash report then
[21:34] <Unit193> Spass_: What's your LPIP?
[21:35] <Spass_> Unit193: I'll try to guess - something related with Launch Pad? :)
[21:35] <Unit193> Launchpad IP.
[21:36] <Spass_> don't know if that's IP, but I'm 'mkubanski' there
[21:37] <Unit193> https://bugs.launchpad.net/~mkubanski
[21:37] <Unit193> There you go then.
[21:38] <Spass_> brb, reboot
[21:41] <Unit193> E: libgarcon-2-0: symbols-file-contains-current-version-with-debian-revision on symbol garcon_menu_item_action_get_command@Base and 16 others
[21:41] <Unit193> W: libgarcon-2-0: symbols-declares-dependency-on-other-package libgarcon-1-0 #MINVER#
[21:41] <Unit193> Nope.jpg
[21:46] <Spass> omg, that reboot took forever!
[21:47] <Spass> even xfce4-session-logout didn't operate properly
[21:47] <Unit193> Nope,of course not.   I'm very helpful
[21:57] <Spass> ok, I'm going now, last thing, probably won't be useful at all, but this took some time - https://drive.google.com/open?id=0B8qh4-wxxEZ7WlVVZnQ2Ti1yQ1E
[22:00] <Unit193> bluesabre: Can I pleeeeeease nuke https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xfce-4.12 now?
[22:10] <bluesabre> Unit193: I see no issue with doing so at this point.
[22:11] <Unit193> Sweeeeeet!


[13:07] <smoser> Odd_Bloke, do you think my returning "......" is silly ?
[13:07] <smoser> for dmi data.
[13:11] <Odd_Bloke> smoser: In what case?
[13:12] <smoser> recent commit to trunk, i made it return ..... (what dmi decode would return) when /sys is full of \xff
[13:12] <smoser> but i relally think "" seems better, as otherwise the user has to specifically know about this "..."
[13:13] <smoser> (and worse, i return the length of the value in sys, basically .replace('\xff', ".")
[13:14] <smatzek> smoser:  I've been seeing the recent activity around here on dev of new cloud-init function around networking, which is where the majority of my interest lies.  What dev is going on?  Is this on a 0.7.x branch?  It seems the v2.0 work died off.
[13:14] <smoser> 0.7.x
[13:14] <smoser> my 'net1' branch is where i'm working on it, and i want to get at least part of that into ubuntu today.
[13:15] <smatzek> and then you'll merge that back to master?
[13:15] <smoser> oh. well, yes. it will all land in trunk
[13:15] <smoser> before ubuntu
[13:15] <smatzek> thanks
[13:18] <Odd_Bloke> smoser: Yeah, I definitely think returning '' or None would be better.
[13:18] <smoser> '' seems better than None to me.
[13:18] <smoser> in order to differenciate between "NO VALUE THERE" and "value not set"
[13:19] <Odd_Bloke> smoser: Oh, sorry, this is for all Fs, not all 0s?
[13:19] <Odd_Bloke> Then, yeah, agreed on empty-string.
[13:20] <Odd_Bloke> Of course, the question then is if we modify dmidecode's output in that case? :p
[13:20] <smoser> Odd_Bloke, i'm modifying dmidecode's output
[13:23] <smoser> Odd_Bloke, review?
[13:23] <smoser> https://code.launchpad.net/~smoser/cloud-init/trunk.dmidecode-null/+merge/288925
[13:28] <Odd_Bloke> smoser: I'm heading in to a (hopefully) half-hour meeting; will review after. :)
[13:28] <smoser> meh. you can review while you wait for everyone else to show up
[13:28] <smoser> really quick
[13:29] <smoser> but your suggestion is also ok
[13:29] <Odd_Bloke> smoser: Cool; +1'd.


[07:12] <NoSee> I <3 Ubuntu Touch
[07:12] <NoSee> It is best
[11:30] <BluesKaj> Hiyas all
[20:44] <Bashing-om> meanwhile 2 hours later, we find that the OP is still trying to boot a liveUSB . nothing to do yet with the install .. pulling teeth !
[20:45] <OerHeks> you mean bray<number> ?
[20:55] <Bashing-om> OerHeks: Uh Huh .. bray be the one I referring to , patience Bashing-om is a virtue .


[01:47] <doko> slangasek, copied everything to 39, still building. will look at the ftbfs tomorrow. 16 should be obsolete
[09:15] <sil2100> Hello release team! We need an archive admin to preNEW review a new package before publishing it through the train
[09:32] <doko> sil2100, what is this? sounds scary before we copy the gcc5 silo
[09:33] <michi> doko: It’s code that is in thumbnailer at the moment. We are unbundling it so it becomes reusable.
[09:34] <michi> Nothing depends on it right now.
[09:34] <sil2100> https://code.launchpad.net/~unity-api-team/persistent-cache-cpp/devel <- here is the whole packaging + code
[09:35] <michi> sil2100: It’s been reviewed and passed already.
[09:35] <michi> Check the comments in the “Passed” column for silo 51 here: https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[09:35] <doko> michi: but you don't plan to update thumbnauler now?
[09:35] <michi> doko: Correct.
[09:35] <doko> looking
[09:36] <michi> We are leaving thumbnailer alone until the dust settles
[09:36] <michi> sil2100: You need to click on the silly speech bubble to see the comments.
[09:36] <doko> hmm, it's not in the NEW queue ... https://launchpad.net/ubuntu/wily/+queue?queue_state=0
[09:37] <sil2100> It's not NEWed yet, we're required to get a preNEW review before pushing it
[09:37] <sil2100> I can publish that to the NEW queue tho if you prefer
[09:37] <doko> ahh, sorry, can't help with this
[09:43] <michi> sil2100: It’s not important for this to go in doko’s PPA. I just want to get the package accept so we (and others) can eventually start using it.
[12:47] <doko> jibel, did slangasek talk to you yesterday?
[12:52] <jibel> doko, he didn't
[12:54] <doko> jibel, he proposed that you could be able to do an image build using the landing39 ppa. not sure how fast you could do that
[12:55] <doko> does this make sense?
[12:56] <doko> otoh, it may fail, because we didn't yet rebuild anything for the renamed libraries
[13:23] <jibel> doko, what would be the difference between an image built from wily + ppa 39 and an image built from proposed on ppa 39 is copied?
[13:24] <jibel> once*
[13:27] <doko> jibel, wily + ppa39 definitely won't work at this point. I think he meant proposed + ppa39
[13:35] <jibel> doko, if everything is installable building from the PPA can be an option
[13:36] <doko> jibel, sure, that would be good to know
[13:39] <doko> jibel, assuming you would work on this, when could such a test be finished?
[13:42] <jibel> doko, for today it's a bit late notice. Time to build an image I won't have any tester left
[13:44] <doko> ok, then let's do it without it
[13:44] <doko> the copy
[16:53] <slangasek> doko, jibel: I did not propose doing an image build using the landing-039 ppa; I was only asking how long we expected it to take for all the packages to build.  The plan for getting a test image is to build against -proposed once the phone stack is coherent there, which is a daunting prospect in itself
[16:56] <jibel> slangasek, makes sense. That was my understanding of your discussion with doko yesterday.
[17:46] <jderose> infinity: totem is launching fine and dandy in today's 14.04.3 daily... thanks! :D
[17:48] <infinity> jderose: Good deal.
[17:49] <infinity> jderose: I'm not happy with my "fix", but it was the same hack we used for .2, and no one complained there either. :P
[17:49] <infinity> (Well, similar, not identical, or I would have noticed the bug)
[17:50] <jderose> infinity: guess adding one line to debian/control for the appropriate mesa package is too hard :P
[17:50] <jderose> for someone, not you, of course :)
[18:05] <infinity> jderose: Well, one first needs to figure out where "appropriate" is, then the investigation of WTF that's needed at all (it probably should be a conditional load, and it's a bit broken), then a full SRU verification to get it in.  And the guy responsible is on vacation. :P
[18:06] <infinity> jderose: So, a hack works for now.  If a later SRU fixes it better, no one will notice. :P
[18:47] <jderose> infinity: gotcha... and i'm just being a little ornery anyway :P
[20:06] <slangasek> so, if ofono-qt and maliit-framework have made their way into wily, does that mean they didn't actually need g++ rebuilds, or is something broken...
[20:11] <infinity>  Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libqt5core5a (>= 5.2.0), libqt5dbus5 (>= 5.0.2), libstdc++6 (>= 4.1.1)
[20:11] <infinity> So, unless something has broken shlibs or a broken symbols file, I'd say no rebuild was needed.
[20:14] <infinity> Given that qt5core didn't have a package name change, that would imply its rdeps don't need a rebuild...
[20:15] <infinity> Ditto for qt5dbus.
[20:15] <infinity> No idea if my inference is actually correct, mind you, but people seemed to be taking the rename thing seriously, so...
[20:18] <infinity> Of course, given that libstdc++6 deps seem to be (correctly) generated from symbol availability, rather than a hardcoded shlib, that also means the tracker "good" string was a bogus lie.
[20:18] <infinity> Since anything that didn't actually need a transition will be listed as "bad" no matter how many times you rebuild it.
[20:25] <infinity> slangasek: Any objections about me fasttracking that apt/trusty SRU (and releasing on a Friday, oh noes!) once I've re-run all my testcases against the archive build and confirmed it's not broken?
[20:25] <infinity> slangasek: It's the only SRU blocking me turning off -proposed in the trusty dailies, which I'd like to do to (a) unblock the kernel team, and (b) have the images over the weekend be a better representation of the final 14.04.3 builds.
[20:25] <slangasek> infinity: I'm afraid my brain misses context for the apt SRU
[20:26] <infinity> https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.9
[20:27] <slangasek> and 1429041 was the preivous SRU?
[20:27] <infinity> Yeah.
[20:27] <slangasek> (and is the test case from there part of the build-time testsuite?)
[20:27] <infinity> It's not.  I need to learn the apt testsuite and submit two tests upstream, for both these regressions.
[20:28] <infinity> But, for now, I have manual tests to confirm both.
[20:29] <infinity> Manual tests all passed on my test binary built at home, just need to re-run them on the archive build.
[20:29] <infinity> THough, if the results differ, we have much bigger problems. :P
[20:32] <slangasek> infinity: ok, looked at the patch and it's clearly limited to things that are Never-MarkAuto-Sections (which seems like a good thing to say in the Regression Potential bit?) so if you've tested that it does what you need for the point release I'm ok with fast-tracking
[20:33] <infinity> slangasek: Right, re-running tests now.  Well, reruning the 1429041 tests.  The actual bug I was fixing is v-done based on the kylin livefs not being completely busted anymore.
[20:33] <infinity> (They remove ubuntu-desktop as part of their build, which is what exposed the regression)
[21:00] <infinity> slangasek: Alright.  Bug spammed with much testing output.  It all looks good to me.    My test removed the wrong package on the second pass.
[21:02]  * infinity redoes that bit.
[21:05] <infinity> slangasek: Okay.  Now all good.  :P
[21:07] <infinity> slangasek: Oh.  You seem to be away, according to your IRC client.  I'll trust my own testing on this one. :P


[00:02] <LLStarks> hey asac
[00:03] <LLStarks> or is it asac_
[00:03] <LLStarks> ?
[00:10] <asac> fta: http://paste.ubuntu.com/236209/
[00:10] <asac> LLStarks: its me
[00:11] <asac> but i have to throw myself in the bed soon ;)
[00:11] <LLStarks> asac, is autocomplete acting up for you?
[00:11] <LLStarks> https://bugzilla.mozilla.org/show_bug.cgi?id=507269
[00:11] <LLStarks> also, when will firefox-3.6 be distro package on launchpad?
[00:12] <asac> LLStarks: can you give detailed instructions? e.g. how you trigger autocomplete etc.
[00:12] <fta> asac, l35=l97
[00:12] <LLStarks> i have no idea how i trigger it
[00:12] <asac> fta: oh yeah. the team section at bottom is removed ;)
[00:12] <asac> thx
[00:13] <asac> i thought it was better to start with simple stuff like team and toools ;)
[00:13] <asac> good thing its more or less an open end session ;)
[00:14] <asac> so if you wake up and feel like jumping in at 9 or 9:30 i might still be acting ;)
[00:14] <asac> ok with team at bottom removed: http://paste.ubuntu.com/236213/
[00:15] <fta> i'm at work at that time
[00:15] <asac> that makes sense ;)
[00:16]  * asac is curious who will show up that early ... australians? asians? early-birds?
[00:16] <fta> no one?
[00:16] <asac> i just can hope that whatever set it is,its at least with me ;)
[00:17] <asac> i would hope not :)
[00:20] <asac> LLStarks: usuually we push things in repo on late alphas or early betas
[00:20] <asac> for first time
[00:24] <fta> lzma is good for the size, but the build time jumped to almost 3h
[00:24] <asac> i dont think thats worth it now
[00:24] <asac> chromium is alredy heavy enough
[00:24] <asac> it for now ;)
[00:26] <fta> heavy? you mean slow to build or heavy debs?
[00:28] <asac> slow to build
[00:28] <asac> currenlty PPA cycles seem to be more precious than space ;)
[00:28] <asac> at least we seem to be ok with the current quota (also not much room of course)
[00:29] <asac> damn. i uploaded nss jaunty to intrepid in ppa :(
[00:29] <asac> now the ppa is lost
[00:30] <fta> lol, with 40GB of quota, that's enough..  even if every few days, i reach 38GB
[00:30] <asac> still it works for the current approach :)
[00:33] <asac> have you seen this notify-osd patch from above?
[00:34] <LLStarks> mark better demand delta debs for lucky liger.
[00:34] <asac> i cant parse that to be honest ;)
[00:34] <asac> but its late
[00:34] <LLStarks> or courgette
[00:35] <asac> i think the mozillateam is the wrong group to fix debs to use courgette ;)
[00:37] <fta> asac, http://paste.ubuntu.com/236226/
[00:38] <fta> asac, so your patch could be much simpler
[00:39] <asac> fta: you mean because it unrefs?
[00:40] <BUGabundo> hey guys
[00:41] <asac> fta: not sure what you mean. the patch definitly could make things much simpler, but i dont think the patch can be made much simpler. i do the check for the reference counting of surfaces because of the data thing that the client has to take care on its own
[00:41] <fta> asac, no, your if (ptr != NULL) destroy(ptr);
[00:41] <asac> ok
[00:41] <fta> just call destroy
[00:41] <asac> yeah that could be
[00:41] <asac> it was not specified in api doc
[00:41] <fta> that's why i fetched the sources
[00:42] <asac> yeah. but i am not sure one should rely on undocumented api behaviour
[00:42] <asac> thats why i usually dont look at sources ;)
[00:42] <asac> but i will think about it... maybe there is some general sectio nthat says that all destroys in cairo are NULL safe
[00:42] <fta> cairo does ref counting, so that should be pretty robust
[00:43] <fta> otherwise, we'll see a lot of crashes everwhere in gnome
[00:44] <asac> fta: you say alot of things in gnome call _destroy with NULL ?
[00:44] <asac> not sure why refcounting means that something is NULL safe ;)
[00:45] <asac> anyway. there ar emore memory issues left. at least i am down from 100 Megabyte in 20 minutes using special testcase to 1.4 m ;)
[00:45] <fta> that's the basis of refcounting, don't crash ;)
[00:45] <asac> well. not on NULL
[00:45] <asac> the idea of refconuting is that you can unref it ... but not that you can unref something that doesnt exist
[00:46] <asac> of course its there to prevent doublt free situations... but you rarely call something with NULL and ge ta double free
[00:46] <asac> rarely == never ;)
[00:46] <asac> either its graceful or it crashes
[00:47] <asac> good. nss bits are in the ppa ... so i can sleep  ;) cu 'morrow
[00:47] <fta> 'night
[00:49] <BUGabundo> night
[00:49] <BUGabundo> I'm going to
[00:50] <BUGabundo> still need to make chromium work on debian
[00:50] <BUGabundo> darn lib32-gtk
[00:50] <fta> rebuild it
[00:50] <fta> oh, lol, more ia32 issues
[00:51] <fta> BUGabundo, i will soon experiment with native x64
[00:51] <fta> it's getting closer
[00:51] <BUGabundo> YAY
[01:08] <fta> asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/3fbd367ac70f6232
[01:38] <micahg> asac: I would normally show up for that time period as it's 1AM for me :)
[01:38] <micahg> I won't be there tonight though...
[01:38] <micahg> I'll check the logs over the weekend though
[01:38] <micahg> I wish I could make it
[08:21] <asac> fta_: annoying form thing ... posted two messags. they dont show up
[08:21] <asac> fta_: if you could point them to my issue, that would be great: http://code.google.com/p/v8/issues/detail?id=411
[08:21] <asac> http://groups.google.com/group/chromium-dev/browse_thread/thread/3fbd367ac70f6232
[08:26] <asac> pinged evmar directly
[09:00] <asac> anyone with hardy/intrepid/jaunty here ;)?
[09:05] <e-jat> :)
[10:29] <asac> so i will probably not so another training session at 6 UTC)
[10:30] <e-jat> :( i miss the training ..
[11:40] <andv> asac, which training session?
[12:06] <gnomefreak> asac: did devicekit-power replace devicekit?
[12:09] <gnomefreak> !sound
[12:13] <asac> gnomefreak: dont know. but sounds reasonable
[12:13] <asac> at least devicekit is dead
[12:18] <gnomefreak> ah
[12:18] <gnomefreak> asac: thanks
[13:25] <gnomefreak> asac: my feelings aside im getting the hint that multisearch shyould be removed. 2 more bugs reported today on it.
[13:27] <gnomefreak> - Drop devicekit dependency.
[13:27] <gnomefreak>     - Add Conflicts to devicekit.
[13:27] <gnomefreak> that explains that
[13:27] <gnomefreak> ill be back in a few
[13:33] <asac> gnomefreak: we will remove multisearch for alpha4
[13:33] <asac> that was communicated, wasnt it?
[13:33] <asac> i will check if we can remove it in a week or so. i guess we have want we wanted by then
[13:34] <asac> gnomefreak: please use "multisearch" tag for those bugs. thanks!
[13:48] <gnomefreak> asac: they were duplicates of the 2 main bugs we have
[13:48] <gnomefreak> asac: i will check to make sure they are tagged
[13:49] <gnomefreak> asac: yep both are tagged already
[13:49] <gnomefreak> my Lp script isnt working :(
[13:52] <gnomefreak> bdmurray: as i recall you are the author of the LP greasemonkey script (from PPA) if so it seems i lost the reply choices
[13:53] <gnomefreak> firefox-lp-improvements is the name of it
[14:01] <gnomefreak> asac: it doesnt seem you commented about removing it on either bug. Can you please comment about it either on your blog or on the 2 bugs bug 403246 bug 402767. if on blog let me know i will comment ont he bugs linking them to your blog. blog im talking about is at: http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:28] <mac_v> guys...In karmic, why is the right-click google search always searching in the Ubuntu start page?
[14:28] <mac_v> I removed ubufox but still it is stuck with the start page :(
[14:31] <mac_v> searching from the searchbox searches in the google.com/firefox , but the right click select always uses ubuntu start page [both in 3.0 &3.5]
[14:32] <mac_v> fta_: asac gnomefreak : is this a known issue or should i open a separate bug^ ?
[14:33] <gnomefreak> mac_v: yes for now disable ubufox should help it
[14:33] <mac_v> gnomefreak: nope , doesnt do it :( , i removed ubufox , but still only start page
[14:34] <gnomefreak> start page == your home page or ubuntu search page
[14:34] <mac_v> ubuntu start page
[14:34] <gnomefreak> mac_v: link?
[14:35] <asac> gnomefreak: ubufox has nothing to do with it
[14:35] <asac> multisearch ;)
[14:35] <asac> is it
[14:35] <mac_v> gnomefreak: what link? i'm confused
[14:35] <gnomefreak> asac: removing ubufox helps some of them. but yes i know multisearch is the problem
[14:35] <mac_v> http://www.google.com/cse?q=
[14:35] <asac> gnomefreak: please dont tell anyone to disable ubufox
[14:36] <mac_v> lol
[14:36] <asac> gnomefreak: for the search issue. thats a wrong thing and spreads around and everyone drops ubufox ;)
[14:36] <gnomefreak> asac: you started that not me
[14:36] <asac> i started it?
[14:36] <asac> i said: disable multsearch ;)
[14:36] <asac> not ubufox
[14:36] <mac_v> guys... gus...
[14:36] <mac_v> guys... how do i solve this? ;p
[14:36] <gnomefreak> asac: ah. thats it :(
[14:37] <asac> mac_v: what is right click google search ... i dont know that
[14:37] <gnomefreak> mac_v: try disabling multisearch :)
[14:37] <asac> ack ;)
[14:37] <gnomefreak> http://www.google.com/cse?q=fun&ie=utf-8&cx=partner-pub-2070091971271392:hsw1kx-3zxg&sa=Search
[14:37] <gnomefreak> you can also check the button that says web search
[14:37] <mac_v> asac: select text and right-click , you have the search option ... i was mentioning that
[14:38] <gnomefreak> at the top of that page but not sure if that is once or once for each search
[14:38] <mac_v> gnomefreak: i tried checking the websearch button , no go for me
[14:38] <gnomefreak> mac_v: disable multisearch extension
[14:38] <gnomefreak> asac: there are 4 or 5 arm patches?
[14:39] <asac> mac_v: yeah disable multisearch then
[14:39] <gnomefreak> there is 18_arm 38_arm bz339782_cvs and bzr 322806_
[14:39] <gnomefreak> i had 3 of them already
[14:40] <gnomefreak> so i feel im missing one
[14:40] <mac_v> hehe... so long i was wondering what was multi-search extension.... just now checked ... that bugger has sneaked in ;p
[14:40] <asac> mac_v: also file a bug about "right click search going to custome search" ... and tag it multisearch please
[14:40] <asac> thx
[14:40] <mac_v> yeah disabling it solves the problem
[14:41] <mac_v> asac: ok... but how did that extension get added?
[14:43] <gnomefreak> hmm that seems those are the only ones. at least the 2 bzr were added
[14:44] <asac> !multisearch
[14:44] <asac> !multisearch is http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:44] <asac> 15:44 [freenode] [ubottu(n=supybot@ubuntu/bot/ubottu)] Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[14:44] <asac> sigh ... too bad that they dumped me from the ops list
[14:44] <gnomefreak> i got it
[14:44] <gnomefreak> !multisearch is <reply> http://www.asoftsite.org/s9y/archives/162-What-is-this-Multisearch-thing-in-my-Firefox-about.html
[14:44] <gnomefreak> :)
[14:45] <asac> sure. but i am 100% sure it worked for me a while ago ;)
[14:45] <mac_v> lol
[14:45] <gnomefreak> asac: you have to be loggede in to bot to add
[14:45] <gnomefreak> @login
[14:45] <gnomefreak> asac: try that
[14:46] <asac> @login
[14:46] <asac> @me
[14:46] <asac> @whoami
[14:46] <asac> !whoami
[14:46] <asac> you dont rock ubottu
[14:47] <asac> gnomefreak: we already had that a few days ago. i am not in the list anymore i am sure
[14:47] <gnomefreak> asac: i am working on it
[14:47] <asac> dont bother to add me again ;) ... just curious when i got removed
[14:47] <gnomefreak> me too
[14:47] <gnomefreak> !snack
[14:47] <gnomefreak> !treat
[14:47] <gnomefreak> damnit
[14:47] <gnomefreak> !good
[14:47] <asac> !snack is <reply> not something to drink
[14:47] <gnomefreak> :(
[14:47] <asac> hehe
[14:48] <gnomefreak> no there is one already
[14:51] <gnomefreak> gedit is crashing damnit
[14:51] <gnomefreak> gedit patches/series
[14:51] <gnomefreak> Segmentation fault (core dumped)
[14:51] <mac_v> asac: done ... Bug #406893
[15:00] <asac> thx
[15:10] <bdrung_> asac: you wanted a correct version comparison. here you have it: http://paste.ubuntu.com/236641/
[15:10] <gnomefreak> ok arm patches are added :)
[15:10] <bdrung_> asac: the only problem is, that you need all packages installed (e.g. firefox-3.0, firefox-3.5, thunderbird, prism, ...)
[15:10] <asac> bdrung_: please a diff ;)
[15:11] <asac> bdrung_: yeah. but you need those installed then ... i am not sure if we really want it
[15:12] <bdrung_> asac: http://paste.ubuntu.com/236644/
[15:12] <bdrung_> asac: or would it be enough if you strip the upstream version out of the debian package version?
[15:13] <asac> bdrung_: we could say that apps should add a custom header to the binary packages control file
[15:14] <asac> like: Xb-Moz-App-Version: ${xulapp:version}
[15:14] <asac> however, i am currently not sure if we can have access to that on the builders
[15:15] <bdrung_> asac: how do access those information in the terminal?
[15:16] <asac> bdrung_: check apt-cache show mozilla-plugin-gnash | grep Npp-
[15:16] <asac> those are custom headers that are in control like: Xb-Npp-....
[15:24] <bdrung_> asac: i read your classroom session and stumbled upon the xulrunner dependency checks. e.g. "shell pkg-config --exists 'cairo >= 1.5.8'; a=$$?; if test $$a != 1; then echo 1; fi"
[15:25] <bdrung_> asac: you can simplify this or do you really want to check _exactly_ the result version != 1?
[15:27] <gnomefreak> now it no longer crashes
[15:28] <bdrung_> asac: "shell pkg-config --exists 'cairo >= 1.5.8' && echo 1" should do the same. the second command is only run, if the first exits with 0.
[15:39] <asac> bdrung_: yeah i know.
[15:39] <asac> bdrung_: i am not sure when we did it ;)
[15:39] <asac> i usually dont care for working code :)
[15:39] <asac> feel free to suggest improvements
[15:40] <asac> at best by suggesting merges ... lol...
[15:40] <asac> yeah this training session was a bit odd. noone really replied so i think they expected something completely different and ran away
[15:41] <bdrung_> asac: oh, i wanted to only create a patch file :) (so i don't have to write a changelog entry)
[15:41] <bdrung_> asac: or they had to go to university to write an exam.
[15:41] <asac> bdrung_: whatever you prefer. but i assure you that you will love bzr if you actually give it a chance ;)
[15:41] <asac> bdrung_: yeah. actually the time was more for eastern europe/asian/australian folks
[15:42] <bdrung_> asac: i like bzr, but not love it. :)
[15:42] <asac> but afaik free software isnt that popular
[15:42] <asac> bdrung_: that whould be good enough to use it :)
[15:42] <asac> should
[15:42] <asac> TomJaeger: hi
[15:42] <TomJaeger> hi
[15:42] <asac> TomJaeger: so seems xserver 1.7 is at risk
[15:43] <bdrung_> asac: my preference would be a combinition of git and bzr
[15:43] <TomJaeger> asac, yup
[15:43] <asac> bdrung_: for our purposed bzr is pretty perfect
[15:43] <bdrung_> but slow
[15:43] <asac> bdrung_: nowadays?
[15:44] <bdrung_> asac: yes
[15:44] <asac> bdrung_: for me it feels pretty snappy nowadays ;)
[15:44] <asac> at least similar to hg
[15:44] <bdrung_> asac: git feels faster.
[15:44] <asac> and the difference really isnt significant to git for everything but the biggest source tres
[15:44] <asac> bdrung_: i think your current perception is still biased from past experiences ;)
[15:45] <bdrung_> asac: gitweb is better.
[15:45] <asac> thats a fair point
[15:45] <asac> and i kick folks everytime i see it
[15:45] <asac> see them
[15:45] <bdrung_> but the big problem of git is, that is complex and some command are really weird
[15:45] <asac> but imo git web doesnt outweight the brain-pain that git comes with
[15:45] <asac> right. i dont think its worth for packaging. really
[15:46] <asac> its completely over engineered for that purpose
[15:46] <asac> its for a huge development project with centralize main tree ;)
[15:47] <bdrung_> :)
[15:47] <bdrung_> asac: and for ugly packages like eclipse
[15:48] <asac> packages that need git do something wrong i am sure ;)
[15:48] <bdrung_> asac: for the speed: bzr pull in mozilla-devscripts need 4 secs (with no changes)
[15:48] <asac> oh wait. eclipse package is dead
[15:48] <asac> bdrung_: because you go through ssh?
[15:49] <gnomefreak> kernel uses git IIRC
[15:49] <asac> try how quick the http: thing is
[15:49] <asac> bdrung_: if you use lp:~.... it tries ssh first i think
[15:49] <bdrung_> asac: bzr+ssh
[15:49] <asac> yes
[15:49] <bdrung_> asac: but with http i cannot push, right?
[15:50] <asac> bdrung_: you can have http for pull and ssh for push
[15:50] <gnomefreak> bdrung_: https you can
[15:50] <gnomefreak> its slower by a little bit
[15:50] <bdrung_> gnomefreak: that's what asac was referring to (its for a huge development project with centralize main tree)
[15:50] <asac> gnomefreak: no you cannot push
[15:51] <gnomefreak> asac: i thought i did
[15:51] <asac> bdrung_: for me pull taking 4 seconds is completely acceptable. you dont run pull like twenty times in a row ;)
[15:51] <asac> anyway ;)
[15:51] <bdrung_> asac: i have a script which updates all my repos
[15:51] <gnomefreak> apport isnt working in Kamric
[15:52] <asac> bdrung_: yeaah. then pull through https ... just tried takes about 1-2 seconds
[15:52] <gnomefreak> any idea on how to report a crash using apport?
[15:52] <asac> bdrung_: bzr pull --remember https://code.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts
[15:52] <gnomefreak> asac: example i used bzr push sftp://bazaar.launchpad.net/~gnomefreak/firefox/firefox.dev
[15:52] <asac> gnomefreak: you shouldnt use sftp
[15:53] <asac> thats rally old and slow
[15:53] <gnomefreak> asac: shouldnt but had to with firefox
[15:53] <asac> gnomefreak: use lp:~gnomefreak ...
[15:53] <gnomefreak> asac: i couldnt it would stall out every time push or pull using lp~*
[15:53] <bdrung_> asac: http needs 1.1 secs
[15:54] <bdrung_> and https 1.1 secs, too.
[15:55] <bdrung_> thats nearly 4 times faster.
[15:56] <asac> bdrung_: yeah. thats what i mean
[15:56] <asac> the other thing is bzr+ssh
[15:56] <asac> so its all ssh handshake ;)
[15:57] <asac> so do a bzr pull --remember with https://code.launchpad on all branches and bzr push --remember lp:~... then its fine
[15:57] <bdrung_> 3 secs for ssh. i currently tested my ssh connection to the university. they need 3 secs, too.
[15:58] <bdrung_> asac: so i blamed the wrong one. ;)
[15:59] <asac> ack ;)
[16:08] <bdrung_> asac: back to xpi.mk: if all apps would provide a custom header Upstream-Version, then this patch should work: http://paste.ubuntu.com/236723/
[16:09] <asac> bdrung_: yeah. unfortrunately i found out that we have no access to any apt db during build
[16:09] <asac> :(
[16:09] <bdrung_> asac: why not?
[16:10] <bdrung_> asac: isn't it possible to depend on apt?
[16:11] <asac> bdrung_: apt yes, problem is you dont have athe apt db locally ... nor do you have access to network on buildd's
[16:12] <bdrung_> asac: so we need the first approach, that we have the binary packages installed. any other suggestions?
[16:15] <asac> good question.
[16:17] <asac> i will think a bit about it
[16:17] <Willex> hi
[16:18] <asac> we could have two modes: a) accurate versioning (requires build depends) or b) no versioned depends
[16:18] <asac> hi Willex
[16:18] <Willex> is it possible some update has screwed up my firefox as it struggles to start?
[16:18] <bdrung_> asac: can you explain b) more?
[16:19] <bdrung_> hi Willex
[16:20] <Willex> it worked fine in the morning but this evening when I rebooted nothing appears until like 5 min lag...
[16:20] <Willex> I tried reinstalling but still no change
[16:21] <bdrung_> Willex: did you tried to start ff without plugins?
[16:21] <Willex> no
[16:21] <asac> bdrung_: basically extension package maintainers could decide. either they opt-into accurate versions ... which would require them to build depend on all applications he wants to have in Depends/Recommends
[16:22] <asac> or he says: just add packages for the given targetapplication ids ... wihtout considering versions
[16:22] <bdrung_> Willex: you can try to start ff with "firefox -safe-mode"
[16:22] <Willex> well I already disabled all the addons and it now starts fluidly
[16:23] <Willex> so is it some broken extension update that's screwing it up?
[16:23] <bdrung_> Willex: so you can enalbe them step by step and you will catch the problematic one
[16:23] <Willex> I don't remember updating them recently...
[16:24] <bdrung_> or it is a ff problem in combinition with an extension
[16:25] <Willex> well I've had the same ones for quite some time...
[16:26] <Willex> hmm, seems to be Kallout that's the trouble maker here
[16:26] <Willex> waiting... tralalalaaa
[16:28] <bdrung_> asac: updating the changelog and doing the change in the same commit or in different ones?
[16:30] <asac> bdrung_: what change?
[16:31] <asac> the accurate vs. proactive
[16:31] <asac> err sloppy
[16:32] <bdrung_> asac: e.g. the one regarding xulrunner (simplifying the shell command)
[16:32] <asac> bdrung_: rule is: if current changelog is UNRELEASED -> extend the changelog
[16:32] <asac> if its karmic or so it means that last commit was a release update
[16:33] <asac> then open new changelog entry with UNRELEASED
[16:33] <asac> makes sense?
[16:33] <bdrung_> asac: yes, that was clear
[16:33] <asac> bdrung_: oh. do it on xulrunner-1.9.2.head branch ... thats where we usually land improvements first
[16:33] <bdrung_> asac: my question was: a) doing changes, commit, update changelog, commit or b) doing changes, update changelog, commit
[16:33] <asac> as its trunk
[16:33] <asac> bdrung_: ah ok.
[16:34] <asac> bdrung_: doing change, update changelog and use debcommit
[16:34] <asac> so the changelog entry is used for bzr commit of the change
[16:34] <bdrung_> ok
[16:42] <bdrung_> asac: here you are: https://code.launchpad.net/~bdrung/xulrunner/simplify-shell-command/+merge/9469
[16:49] <bdrung_> asac: you can find UNRELEASED twice in the xulrunner changelog. something went wrong there...
[16:56] <asac> let me check
[16:56] <asac> bdrung_: yeah. thats the 1.9.1 changelog still ;)
[16:59] <bdrung_> asac: how to proceed with xpi.mk?
[17:04] <asac> bdrung_: a bit of a difficult question.
[17:04] <asac> bdrung_: not from xpi.mk side, but from what we require applications to do
[17:04] <asac> xpi.mk should get a switch like ..._XPI_AUTO_VERSION
[17:05] <asac> and if its there use whatever mechanism we define for targetapplication packages to expose their version
[17:05] <asac> also we could consider to define a version mapping for packages so we could guess the right lower/upper version bounds for depends
[17:06] <asac> for package versions
[17:06] <asac> let me think a bit ;)
[17:06] <bdrung_> it's now late enough to think clearly ;)
[17:07] <bdrung_> asac: my goal is it to simplify the plugin packages. so simplifying depends, but the having to b-d on the ff, tb, etc. would destroy the win
[17:21] <asac> bdrung_: yes. so if we could invent a mozversion -> deb package mapping, we could generate proper version bounds without having them installed
[17:22] <asac> so we might have impossible combinations like thunderbird (>= 3.0~a1)
[17:22] <asac> but we could maintain a list of special EOL and SOL versions for certain packages
[17:22] <asac> ;)
[17:22] <asac> like thunderbird_sol = 0.1a1pre
[17:22] <asac> thunderbird_eol = 2.0.0.*
[17:23] <bdrung_> what do you mean with eol and sol?
[17:23] <asac> thunderbird-3.0_sol = 3.0a1pre
[17:23] <asac> bdrung_: eol = end of life ;)
[17:23] <bdrung_> aha
[17:23] <asac> sol the opposite ;)  ... version of birth like ;)
[17:25] <bdrung_> not birth date, but fecundation date ;)
[17:26] <bdrung_> asac: you said that in the building we cannot run apt-cache. how should the mozversion -> deb package mapping work?
[17:31] <bdrung_> asac: now i understand it.
[17:41] <bdrung_> asac: here's the implementation of your idea: http://paste.ubuntu.com/236918/
[17:42] <bdrung_> afk
[17:46] <eagles0513875> morning asac
[18:03] <bdrung_> re
[18:04] <bdrung_> asac: we could set the *_sol to the current upstream version of the packages in unstable/karmic, couldn't we?
[18:58] <bdrung_> asac: wow, NEW contains nearly 300 packages.
[19:39] <bdrung_> asac: packages should b-d on xulrunner-dev instead of libxul-dev, right?
[19:51] <bdrung_> asac: do you know how to sru a new upstream version? https://bugs.launchpad.net/ubuntu/+source/adblock-plus/+bug/320762
[20:24] <asac> bdrung_: yes xulrunner-dev is the right one
[20:24] <asac> bdrung_: thtas a backport request. not an SRU?
[20:25] <asac> bdrung_: ok. it basically needs a bug that is severe enough to justify a backport
[20:25] <bdrung_> asac: the backport team said, that sru fits better than backporting
[20:25] <bdrung_> asac: maybe we should adjust the severity
[20:32] <asac> bdrung_: we should make a bug out of it ... like: "adblock-plus filters broken"
[20:32] <asac> what exactly is broken?
[20:33] <bdrung_> asac: some filter expressions do not work, because only the newer version supports the syntax. so less spam is filtered.
[20:33] <bdrung_> asac: so it is not totally broken, but partly.
[20:34] <asac> bdrung_: i remember that there are different filterlist providers
[20:35] <asac> are the new filter expressions used by new providers? or by the old ones?
[20:35] <bdrung_> asac: and depending on how aggressively they use the new syntax...
[20:35] <bdrung_> asac: by the old ones.
[20:35] <bdrung_> asac: they are used by (nearly) all providers listet on adblock website
[20:38] <asac> bdrung_: what i mean is: users that have the old adblock extension ... do they already pull data that they dont properly understand?
[20:39] <bdrung_> asac: yes. the lists are automatically updated (weakly)
[20:47] <pace_t_zulu> fta_: i reckon this command works for formatting the commit date like you suggested GIT_DATE = $(shell cd $(TMP_DIR)/src && git rev-list --max-count=1 --date=rfc --format=%ad HEAD | tail -1 | xargs -i date +%Y%m%dt%H%M -d'{}')
[20:48] <pace_t_zulu> fta_: if you have a better/more compact command... please share
[20:49] <asac> bdrung_: ok make a bug out of it. change severity and subscribe motu-sru
[20:50] <bdrung_> asac: other topic: should we set the *_sol to the current upstream version of the packages in unstable/karmic?
[20:50] <asac> bdrung_: but i think we cannot use the same packaging. so we need to branch off the current jaunty version and maintain a stable branch for jaunty and before
[20:51] <asac> bdrung_: no. i think _sol is basically first upstream version that matches the branch associated with the name
[20:51] <pace_t_zulu> fta_: so now the version looks like this... 0.0.3+git20090717t2107x65f7bc7
[20:51] <pace_t_zulu> i stuck the hash on the end for good measure
[20:51] <asac> bdrung_: example: thunderbird-3.0 -> 3.0a1pre
[20:51] <bdrung_> pace_t_zulu: very long version string
[20:52] <pace_t_zulu> bdrung_: indeed... that's just for the ppa... for unreleased commits
[20:52] <asac> bdrung_: firefox-3.5 -> 3.5a1pre ...
[20:52] <bdrung_> pace_t_zulu: then it's ok. it would be more readable if the date is seperated from the rest
[20:53] <pace_t_zulu> bdrung_: how do you suggest i do it dfferently
[20:54] <bdrung_> pace_t_zulu: for git checkouts i used only the date, e.g. 0.0.3+git20090717 and if you need more than one build per day, add the time 0.0.3+git20090717-1704
[20:54] <asac> bdrung_: alternatively we could say that it should be the first version that entered the archive
[20:55] <asac> have to think a bit about it ... but i currently lean to the first upstream version
[20:55] <bdrung_> asac: and why not the current version in the archive?
[20:55] <pace_t_zulu> bdrung_: you wouldn't include the hash?
[20:56] <bdrung_> pace_t_zulu: no, you could mention the hash in the changelog.
[20:57] <asac> bdrung_: because that would be overly strict imo
[20:57] <bdrung_> s/you could/i would/
[20:57] <bdrung_> asac: but it fits for the normal user.
[20:57] <asac> bdrung_: think about packages. you wouldnt bump lower version if there is no incompatibility
[20:58] <asac> bdrung_: why do you think its better to use current version as sol?
[20:59] <bdrung_> asac: example: we have thunderbird 2.0 in the repo, but the _sol is 0.1a1pre.
[20:59] <asac> yes
[20:59] <bdrung_> asac: we have an extension which works with tb till 1.0.
[20:59] <asac> because what we use _sol for is to figure if it makes sense to have thunderbird as a dependency
[21:00] <bdrung_> asac: so it would not work with tb and so tb should not be listed as possible dependency.
[21:00] <asac> bdrung_: no. it should be listed, but with proper bounds
[21:00] <asac> thunderbird >=0.5 <= 1.0.*
[21:01] <bdrung_> asac: ok, with bound it would be ok.
[21:02] <asac> so if we use current ones we would get overly strict depends
[21:02] <bdrung_> asac: then the xpi.mk need finetuning
[21:02] <asac> if we use upstream sol /eol we would end up with overly lax depends until we do the next and final step and get perfect bounds
[21:03] <asac> imo overly lax is better because it does not prevent you install for targets that work
[21:03] <asac> also its the right way for the final solution imo
[21:03] <andv> asac, are you available for an upload later?
[21:04] <asac> not today
[21:04] <andv> asac, I've decided to take back libagg coz someone wanted to NMU it
[21:04] <asac> tomorrow might work
[21:04] <andv> asac, my other packages are all ok so I can have one more package to work on
[21:04] <andv> asac, I gonna leave for the sea at like 2-3 pm
[21:04] <asac> bdrung_: the final solution would require a version scheme for packages .. e.g. policy
[21:05] <andv> asac, can you make it for the morning?
[21:05] <asac> no
[21:05] <asac> i cants say when
[21:05] <andv> damn : /
[21:05] <asac> i have a haystack of work ;)
[21:05] <bdrung_> asac: how would the version scheme look like?
[21:06] <asac> bdrung_: i think its pretty simple (not sure about *) ... 2.0a1pre -> 2.0~a.1~pre
[21:07] <asac> maybe + instead of .
[21:07] <bdrung_> ?
[21:07] <asac> 2.0~a+1~pre
[21:07] <asac> i am not sure if there can be a perfect mapping ;)
[21:07] <bdrung_> asac: i would prefer 2.0~a1~pre
[21:08] <asac> bdrung_: does it always work if we dont split letter to number transitions?
[21:09] <bdrung_> asac: yes. we only have to split number to letter
[21:09] <asac> bdrung_: maybe it really works
[21:09] <bdrung_> asac: because their interpretation is that an empty string is lower than everything else
[21:09] <asac> dpkg --compare-versions a1 eq a01 && echo asdsa
[21:10] <asac> a1 is equal to a01 ... so dpkg seems to split those transitions somehow
[21:11]  * asac  didnt know that a01 == a1 ;)
[21:11] <bdrung_> even a1 > a-2 works
[21:11] <asac> bdrung_: is it equal in mozilla land too ;)?
[21:11] <bdrung_> asac: yes, they allow negative numbers
[21:11] <asac> bdrung_: no i mean is a01 == a1 ;)
[21:11] <asac> let me test with our script ;)
[21:11] <bdrung_> asac: yes, it was one of the examples
[21:12] <asac> works ;)
[21:12] <asac> ok so lets try to standardize that with debian moilla and debian moz extension maintainers
[21:12] <asac> i will talk to extension guy ... and ask him to ask instead of me ;)
[21:13] <bdrung_> asac: mozilla mailing lists i should subscribe?
[21:14] <asac> bdrung_: no .. debian mozillateam
[21:14] <asac> mozilla has no stake in deb versions ;)
[21:14] <bdrung_> asac: link?
[21:14] <asac> let me get it
[21:15] <asac> http://lists.alioth.debian.org/mailman/listinfo/pkg-mozilla-maintainers + http://lists.alioth.debian.org/mailman/listinfo/pkg-mozext-maintainers
[21:15] <asac> bdrung_: ^
[21:15] <bdrung_> asac: and ubuntu lists?
[21:16] <asac> bdrung_: we only have our mailing list (/topic)
[21:16] <asac> hmm ... there is no url ;)
[21:16] <asac> https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam
[21:17] <asac> bdrung_: ^
[21:18] <bdrung_> asac: done. :) the ubuntu list was the fastest (although i subscribes as last)
[21:23] <andv> asac, k
[21:23] <andv> asac, gonna prepare everything for you for tomorrow
[21:23] <andv> asac, it's just a bug fix anyway on amd64
[21:25] <bdrung_> asac: pkg-mozilla-maintainers needs a spam filter
[21:26] <asac> yeah
[21:26] <asac> debian doesnt want spam filter ;)
[21:26] <bdrung_> why?
[21:28] <asac> bdrung_: i wasnt accurate. debian has tradition to not require a subscription
[21:28] <asac> and since alioth has no spam filtering (compared to debian-devel) its a mess
[21:28] <asac> but even debian-devel gets loads of spam through afaik
[21:28] <asac> but they have pretty good mailadmins that tweak spamfilter quite well
[21:30] <bdrung_> asac: where to report the spam filter request for alioth?
[21:33] <asac> let me check if i can enable spam filtefring for that list
[21:34] <asac> hmm ... i am not admin i think
[21:34] <asac> of the list
[21:34] <asac> just the project
[21:35] <asac> i dont know where to file something. sorry.
[21:39] <bdrung_> asac: what was the conclusion of the _sol version? using the version of the first package release?
[21:44] <BUGabundo> hey . gonna get my self a Android G2 tonight!
[21:47] <andv> asac, does it matter if I gonna provide you orig diff e dsc files instead of branches?
[21:56] <bdrung_> pace_t_zulu: for getting the latest git commit date, i used: "git log --pretty=format:%h -1"
[21:56] <pace_t_zulu> bdrung_: i will test that now
[21:57] <bdrung_> pace_t_zulu: your command looked much more complex
[21:57] <pace_t_zulu> bdrung_: indeed...
[21:58] <bdrung_> pace_t_zulu: ups
[21:58] <bdrung_> pace_t_zulu: that command was only for the hash. for the date i used the current one (date +%Y%m%d)
[21:59] <pace_t_zulu> ?
[21:59] <bdrung_> pace_t_zulu: and i used "${VERSION}+git$(date +%Y%m%d).${GIT_HASH}" as version string. so i did include the hash
[21:59] <fta> hi
[21:59] <asac> bdrung_: i think so. yes.
[21:59] <fta> (booo, localtime, baad)
[22:00] <fta> asac, so, how was your session?
[22:00] <pace_t_zulu> bdrung_: that date command will only get the current date... not the commit date
[22:00] <andv> asac, does it matter if I gonna provide you orig diff e dsc files instead of branches?
[22:00] <bdrung_> pace_t_zulu: yes, i know. i thought i improved that.
[22:01] <pace_t_zulu> bdrung_: the current date isn't as useful as the commit date
[22:01] <asac> andv: i think only you can answer that
[22:01] <andv> asac, lol
[22:01] <andv> asac, nvm then :S
[22:01] <andv> * :D
[22:01] <asac> a) i have no clue what package you are talking about ... b) i have no idea if there were any branches used before/in future
[22:02] <asac> etc.
[22:02] <andv> asac, libagg, there are no branches yet
[22:02] <andv> asac, there will be some branches in the future, but I gonna setup them after the package is uploaded (fixes a grave bug)
[22:03] <andv> asac, so on monday when I get back, I'll make some working branches
[22:03] <asac> k
[22:03] <andv> asac, gonna provide you a dgettable url
[22:03] <andv> asac, don't worry
[22:05] <bdrung_> andv: all ubuntu packages are now in bzr branches. so you could easily branch the karmic version.
[22:06] <andv> bdrung_, are you talking about my package?
[22:06] <andv> (libagg?)
[22:06] <bdrung_> andv: https://code.launchpad.net/ubuntu/+source/agg
[22:06] <bdrung_> andv: yes.
[22:07] <asac> yeah. should be easy to downstream maintain packages in debian from ubuntu
[22:07] <andv> bdrung_, have to upload a package as soon as possible, so I won't have time to do all revisions in bzr
[22:07] <andv> bdrung_, on monday I'll set them up
[22:08] <andv> bdrung_, for now I gonna work with orig diff dsc file
[22:08] <bdrung_> andv: it's only a hint for the future work.
[22:08] <andv> bdrung_, appreciated ty
[22:08] <andv> bdrung_, I'll have to merge the package anyway
[22:08] <andv> I see two ubuntu patches there
[22:08] <andv> for fixing something in jaunty
[22:09] <bdrung_> andv: you're welcome
[22:09] <andv> didnt know all packages are branched now
[22:10] <bdrung_> it's for a short time now
[22:10] <andv> bdrung_, how does it work?
[22:10] <andv> bdrung_, they get synced on bzr automatically?
[22:11] <bdrung_> andv: yes. every time a new package is uploaded a new commit is generated.
[22:11] <andv> cool
[22:12] <bdrung_> andv: i don't know how fast it is. it's probably a cron job which runs every hour or every day or something in between
[22:12] <andv> yeah
[22:12] <andv> looks like a good idea
[22:14] <fta> asac, http://dev.chromium.org/user-experience/omnibox may give you idea for the addon ;)
[22:14] <fta> +s
[22:23] <asac> fta: idea for which addon?
[22:24] <asac> multisearch?
[22:26] <fta> yep
[22:26] <fta> roh, i'm kidding
[22:28] <asac> does chromium not have a search field by default?
[22:31] <fta> no, it's omnibox
[22:33] <asac> k
[22:34] <asac> fta: we have to decide what to do with dailies
[22:34] <asac> err .head for xul + ffox
[22:34] <asac> i will transition stuff like yesterday ;)
[22:34] <asac> at firs tadding xulrunner-dev to 1.9.1
[22:35] <asac> then transitioning rdepends and then moving firefox to 3.5, enablling branding and asking profile migration question
[22:37] <asac> so i see two questions ew have to answer with yes to just continue:
[22:37] <asac> a) is it ok to migrate daily users to xulrunner-dev 1.9.1 by default
[22:37] <asac> b) is it ok to migrate daily users to firefox 3.5 by default
[22:37] <asac> i dont think its a big issue ... and i think thats aktually what most probably want, but still it hsould be an explicit decision that you also agree with ;)
[22:37] <asac> fta: ?
[22:38] <asac> rather than me injecting that in .head and then it happens everywhere
[22:40] <fta> i guess it's fine
[22:40] <asac> yeah only thing i am a bit unsure about is xulrunner-dev
[22:40] <asac> maybe they want to respin a hardy package and then it breaks
[22:40] <asac> but lets assume that those that need this can use pinning
[22:41] <asac> and the rest doesnt care most likely
[22:43] <fta> they should respin in chroot / pbuilder, not on their own box
[22:47] <andv> asac, a linux magazie in italy posted the link to chromium daily ppa
[22:48] <andv> asac, on this month
[22:48] <andv> * magazine
[22:49] <andv> bdrung_, do ppa builds for sid too?
[22:50] <asac> no
[22:50] <bdrung_> andv: no
[22:50] <andv> k ty
[22:50] <bdrung_> andv: and only x86 and amd64
[22:50] <asac> lpia
[22:50] <andv> I gonna change the changelog to karmic then
[22:50] <bdrung_> (due to virtualisation)
[22:51] <bdrung_> asac: lpia counts as x86 for me
[22:51] <asac> still they build separtely
[22:51] <asac> andv: remember to keep version in ppa lower than the actual upload
[22:51] <asac> ~andv1
[22:51] <andv> ok
[22:52] <fta> i wonder if it's possible to hack apport to send crash reports to upstream somehow
[22:53] <fta> google would like that
[22:54] <asac> fta: can google deal with our crash files?
[22:54] <asac> the blocker usually is that they need our symbols
[22:54] <fta> no, they use breakpad
[22:54] <asac> right so its the same thing as with mozilla
[22:54] <fta> yep
[22:54] <fta> breakpad is actually google, not mozilla ;)
[22:54] <asac> fta: the blocker is not really the sending of the crash report
[22:54] <asac> i knew
[22:55] <asac> its the "how to get the symbols uploaded and keep them versioned in their db so they can find the right ones etc."
[22:55] <asac> i would be happy if we solve this with google directly ;)
[22:56] <fta> i often resolve my crash files locally
[22:56] <asac> you do. but most dont have the huge -dbg packages availabl
[22:56] <asac> and it shouldnt be required
[22:58] <fta> that's something lp should do
[23:00] <asac> fta: what should launchpad do?
[23:00] <asac> fta: google has to be ready to accept uploads of symbols from distros
[23:00] <fta> lp has all the debs, fresh and not so fresh, it should be able to resolve all the crashes that are interesting to have and feed the results to a tracker specified in the package
[23:00] <asac> and later be able to assocaited those symbols
[23:00] <asac> fta: you say forward the bugs. ok
[23:01] <asac> thats a different thing
[23:01] <fta> no
[23:01] <asac> than uploading the crashes to breakpad
[23:01] <fta> just an apport service
[23:02] <asac> we discussed forwarding retraced crashes to their db
[23:02] <asac> but there were problems too
[23:02] <fta> i would like to add some apport hooks to my packages to teach apport what it should do with resolved crashes, instead of posting them in a lp bug, or reject it because "it's not a genuine ubuntu package"
[23:03] <asac> fta: unlikely that apport will get a feature to run code etc on the retracers machine
[23:03] <asac> fta: i understand. but where should it post the results to?
[23:03] <asac> fta: you said know if i asked if those should be auto fild upstream
[23:03] <fta> a remote bug tracker
[23:03] <asac> err you said no ;)
[23:04] <fta> not to lp, then forwarded, but directly upstream
[23:04] <asac> ah ok
[23:04] <asac> but still in launchpad ?
[23:04] <asac> nm
[23:05] <fta> apport will run on the ubuntu side, as all the debs are there
[23:06] <asac> so that would involve: a)
[23:07] <asac> make an apport webservice that is the primary upload service, rather than launchpad bugs
[23:07] <fta> yes
[23:07] <fta> something like that
[23:07] <asac> specify a contract that upload plugins can implement
[23:07] <asac> and use that after retracing to do the upload
[23:08] <asac> main problem is really that the retracers machine are deep in a datacenter ... not sure if someone would wnat to give them net access
[23:08] <asac> but one has to find out
[23:08] <asac> something we should suggest to pitti
[23:08] <fta> could be proxified, like pushed in a queue and processed by another machine
[23:09] <asac> yeah. the other thing is that we are talking about privacy related data
[23:09] <asac> so if users upload to ubuntu ... they dont expect google to get the private data
[23:10] <asac> not sure if that is relevant
[23:10] <asac> but users even complained that we violate privacy law in many states by putting multisearch in
[23:10] <asac> even though we just get the amount of clicks done where ;)
[23:11] <asac> and all the requests still go to google
[23:12] <fta> well, it's no different that going through breakpad
[23:12] <asac> fta: its different
[23:12] <asac> well of course it applies to the idea of us uploading to breakpad
[23:12] <asac> as well
[23:12] <fta> maybe i should just find a way to bypass apport and use breakpad then
[23:12] <asac> i meant its different if users directly upload to breakpad
[23:12] <asac> and we provide te symbols
[23:13] <asac> fta: as i told you thats the best way. but the problem is somewhere else
[23:13] <asac> its to get the symbols uploaded ... and afaik breakpad is not ready out of the box to do that
[23:13] <asac> if we can solve that i would jump up and down for 10 minutes ;)
[23:21] <fta> not enough ;)
[23:21] <asac> https://code.edge.launchpad.net/~mozillateam/
[23:22] <asac> fta: ok one time a week 10 minutes additional push ups for a month;)
[23:22] <asac> with each month it takes till this happens i remove 1 minute ;)
[23:22] <fta> bug? they all have the same graph
[23:22] <asac> !date
[23:23] <asac> fta: yeah
[23:23] <asac> thats what i wanted to say ;) and forgot to write it after the link
[23:23] <asac> not sure yet which one they take
[23:23] <asac> i had a different one before i reloaded
[23:32] <fta> anyone using chromium and having crashes on shutdown?
[23:33] <fta> http://code.google.com/p/chromium/issues/detail?id=18112
[23:35] <asac> fta: no
[23:35] <asac> works
[23:35] <asac> since when does ithappen?
[23:35] <fta> with --enable-plugins?
[23:35] <fta> i noticed a few days ago
[23:35] <asac> fta: i use the dailies
[23:35] <asac> i am upgrading to latest now
[23:35] <asac> but i think i upgraded yesterday
[23:36] <fta> try with  --enable-plugins
[23:36] <fta> on the cmd line or in /etc/chromium-browser/default
[23:37] <fta> upstream noticed some crashes when totem plugin is installed, but that's supposedly fixed now
[23:37] <asac> fta: do i need to use something that trigers plugins?
[23:37] <asac> or jus topen and cloe?
[23:37] <fta> no
[23:37] <asac> argh
[23:37] <asac> typing spastics
[23:37] <asac> --enable-plugins works too
[23:37] <asac> i am on 32bit
[23:38] <asac> hmmm ... even works with nspluginwrapper ;)?
[23:38] <asac> nice ;)
[23:39] <asac> hmm. seems they dont resolve links
[23:39] <asac> so i have multiple entries now
[23:44] <andv> asac, sent to build on ppa
[23:45] <andv> asac, if it builds fine on amd64, problem is fixed
[23:48] <fta> asac, it crashed if i have acid3 in a tab
[23:49] <fta> -d+s
[23:54] <asac_> no need to report every progress. just the big steps :)
[23:54] <andv> asac_, k


[00:35] <DanaG> I'm waiting for that darn "panda" to become available.
[00:35] <DanaG> Though, if I were to have an ARM file server, I'd want one with native gigabit ethernet and SATA, not USB stuff.
[00:39] <persia> DanaG, There are always rumours of new cool stuff.  Currently, I believe you can get this retail for ARMv6, but not ARMv7.
[00:40] <DanaG> http://wiki.debian.org/ArmHardFloatPort/VfpComparison
[00:41] <DanaG> I know that "Panda" is something that actually exists, but is supposedly under NDA.
[01:04] <dcordes> GrueMaster: Yes makes perdect thanks. Thank you
[01:05] <dcordes> s/perdect/perfect/
[01:05] <dcordes> GrueMaster: Well thanks for the explanation.
[01:05] <dcordes> It seems like I need a break.
[08:48] <hrw> morning
[12:27]  * ogra glares at the kernel mailing list
[12:27] <ogra> This patchset enables full support for the 22-inch 3M touchscreen. The
[12:27] <ogra> controller handles up to 60 fingers, and this version can do at least
[12:27] <ogra> 20 fingers.
[12:28]  * ogra wonders if they also have a geneitc patch for humans to actually grow 60 fingers
[12:30] <amitk> ogra: I heard them mention something about a camping expedition to a nukular dump
[12:30] <ogra> lol
[12:34] <XorA|gone> there is an assumption there that there is only one user
[12:37] <ogra> well, how much of teh display will you be able to see on 22 inch having 6 persons putting all ten fingers in ?
[12:37] <XorA|gone> 22inch is big enough for RPG games to be played on
[12:50] <lag> Who has their ES2.0 to hand?
[12:52] <lag> ogra: rsalveti: GrueMaster:
[12:57] <ogra> i do but i'm busy beta testing today
[12:57] <ogra> i.e. i wont boot it today
[13:00] <ogra> lag, what info do you need for failing suspend (/me is about to write a bug but there is no trace of info in any logs it seems)
[13:04] <lag> Just tell me how I can re-create it
[13:05] <lag> My query was on the same lines
[13:05] <lag> Have you tried to shut it down - then reboot it again?
[13:05] <ogra> it wont shut down with the current kernel since it cant deconfgure the NIC
[13:06] <lag> So you'd expect this kind of thing on re-bootup would you? http://paste.ubuntu.com/486626/
[13:06] <ogra> lag, to recreate, just click on the shutdown icon in the panel and select susped ... you will only get a gnome-screensaver password prompt
[13:07] <lag> ogra: Can you use the prompt to re-login?
[13:07] <ogra> sure
[13:07] <lag> Okay
[13:07] <ogra> it just behaves like a locked screen
[13:07] <ogra> (pm-utils enforces gnome-screensaver --lock before telling the kernel to suspend)
[13:08] <lag> And when you check the logs, nothing new is in there?
[13:08] <ogra> nope
[13:09] <lag> k
[13:09] <lag> Did you check my paste?
[13:09] <ogra> i see a message abot the screensaver lock dialog having come up, but nothing between that and the last messages from booting
[13:09] <ogra> yes, looks bad
[13:10] <ogra> which kernel is that ?
[13:10] <zumbi_> i am playing with an IGEPv2 board, it does not suspend for me, do you have an idea if PM works fine on such target?
[13:10] <ogra> the one in the archive or a special build ?
[13:10] <lag> rsalveti's
[13:10] <ogra> zumbi_, sadly no, might be a kernel issue
[13:10] <lag> Oh wait
[13:10] <lag> You're Beta testing ES1.0?
[13:11] <ogra> lag, yep
[13:11] <lag> ogra: I can't help you with your suspend issue
[13:11] <ogra> lag, ??
[13:11] <ogra> lag, i suspect there is a config option missing in our kernel, normally you would at least see *some* message
[13:12] <lag> My Panda's are borked
[13:12] <lag> I can have a look
[13:12] <ogra> that would be nice
[13:12] <ogra> i'll try to tickle some more debug output out of pm-utils later
[13:13] <ogra> beyond that and an ubuntuone crash the omap4 image looks fine though :)
[13:14] <lag> do: pm-suspend PM_DEBUG=1
[13:15] <ogra> will do
[13:15] <ogra> persia, got any interest to work on bug 613612 ?
[13:15] <ubot2> Launchpad bug 613612 in ubuntu-netbook-efl-default-settings (Ubuntu Maverick) (and 1 other project) "Favorites missing from netbook-launcher-efl (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/613612
[13:19] <ogra> lag, filed bug 628029 for now
[13:19] <ubot2> Launchpad bug 628029 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "[maverick] panda ES1.0 does not suspend on beta image (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/628029
[13:20]  * ogra submits http://iso.qa.ubuntu.com/qatracker/result/4495/696 :)
[13:21] <ogra> lag, in your paste, the first issue it shows is sound related, i think there was some work going on to include ASoC fixes we are missing yet ( lrg might be able to tell you more )
[13:22] <ogra> could well be that the subsequent oopses are just fallout of thet
[13:22] <ogra> *that
[13:22] <lag> Could well be
[13:23] <lag> I'll touch base with lrg
[13:23] <lag> What time is he normally in?
[13:23] <ogra> he is in the UK, normally he is here during our workday
[13:24] <ogra> no idea why he isnt atm, XorA|gone might know ... but he seems to be gone :)
[13:24] <XorA|gone> lrg is UK timezone
[13:24] <XorA|gone> but he has ADSL problems at moment
[13:25]  * ogra takes a break
[13:27] <lag> ogra: It looks like our ti-omap4 branch has been upgraded to 2.6.35
[13:27] <XorA> if thats ASoC issues on panda lrg isnt looking at that board at the moment
[13:28] <XorA> buest bug prpplague and other board bringup dudes
[13:28] <lag> XorA: Thanks for the info
[13:29] <XorA> lrg is working on 4430sdp so if you can repeat it on that
[13:30] <lag> ogra: This answer your question: debian.ti-omap4/config/config.common.ubuntu:# CONFIG_PM is not set
[13:34] <ukleinek> ericm|ubuntu: would you care to look at http://thread.gmane.org/gmane.linux.kernel/1027380/focus=34838?  It affects pxa3xx_defconfig
[13:34] <ericm|ubuntu> ukleinek, ok
[13:36] <ericm|ubuntu> ukleinek, how's it going to affect pxa3xx_defconfig?
[13:36] <ukleinek> ericm|ubuntu: thanks
[13:36] <ukleinek> ericm|ubuntu: pxa3xx_defconfigs currently has NFS_V4 but not CRYPTO so it fails to build
[13:37] <ericm|ubuntu> ukleinek, would your patch finally include fix to that, I guess it would be better to include then?
[13:39] <ukleinek> ericm|ubuntu: -ENOPARSE
[13:40] <ericm|ubuntu> ukleinek, heh
[13:40] <ericm|ubuntu> ukleinek, guess a simple fix would to have CRYTO selected in pxa3xx_defconfig?
[13:40] <ericm|ubuntu> ukleinek, and I doubt only pxa3xx_defconfig has this issue
[13:41] <ukleinek> ericm|ubuntu: there are many symbols that select CRYPTO
[13:41] <ukleinek> ericm|ubuntu: see my mail, only mx1, pxa3xx, qil-a9260, usb-a9260 and usb-a9263 are affected
[13:42] <ericm|ubuntu> ukleinek, so will you include fix to these _defconfig(s)?
[13:42] <ukleinek> ericm|ubuntu: no need to
[13:43] <ukleinek> ericm|ubuntu: I really wonder about how many people understand these defconfig targets wrong
[13:43] <ukleinek> Trond Myklebust though the defconfigs need fixing, too
[13:44] <ukleinek> s/though/thought/
[13:45] <zumbi_> where can i find info on unity and anataya?
[13:45] <ericm|ubuntu> ukleinek, what is a proper fix?
[13:47] <ukleinek> ericm|ubuntu: my patch
[13:48] <ericm|ubuntu> ukleinek, ah I see
[13:49] <ericm|ubuntu> ukleinek, so it looks nothing needs to be done at pxa3xx_ side, no testing building/run even needed, the patch looks right to me
[13:50] <ukleinek> ericm|ubuntu: the only thing you can do is seeing that pxa3xx is broken
[13:50] <ukleinek> (http://armlinux.simtec.co.uk/kautobuild/2.6.36-rc3/pxa3xx_defconfig/zimage.log)
[13:50] <ukleinek> and see it fixed with my patch
[13:51] <ericm|ubuntu> ukleinek, cool
[13:52] <ericm|ubuntu> ukleinek, thanks
[14:53] <ogra> lag, yeah, it has been upgraded to .35 but not been uploaded (since it defaults to ES2 which we cant use in beta yet) ... mind reporting the missing option on bug 628029 ?
[14:53] <ubot2> Launchpad bug 628029 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "[maverick] panda ES1.0 does not suspend on beta image (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/628029
[14:55] <lag> Why have you made it incomplete?
[14:56] <ogra> because it needs info
[14:57] <ogra> (you asked for pm debug logs, remember ?)
[14:58] <lag> ogra: I didn't
 do: pm-suspend PM_DEBUG=1
[14:58] <lag> For your info
[14:58] <ogra> thus my second comment on the bug and the marking as incomplete
[14:58] <lag> Anyway, it's not a problem
[14:58] <lag> I've changed it
[14:59] <lag> I'll make a kernel for you to test
[14:59] <ogra> ah, nice
[14:59] <ogra> lag, slow down
[14:59] <ogra> lag, lets better revisit it with ES2
[14:59] <ogra> after beta
[15:00] <lag> So you don't need it for Beta?
[15:00] <lag> Fine
[15:00] <lag> I'll concentrate on ES2
[15:00] <ogra> right, its just a remonder that we check it again after beta on ES2
[15:00] <ogra> *reminder
[15:01] <ogra> it surely has to work but i dont want to put more work than necessary into ES1 now
[15:02] <lag> Fine by me
[15:02] <lag> I've assigned myself anyway
[15:02] <ogra> cool
[16:13] <lag> prpplague: Pounce!
[16:14] <lag> prpplague: http://paste.ubuntu.com/486626/
[16:14]  * prpplague looks
[16:15] <prpplague> lag: you need some updated pulse and alsa config files
[16:15] <lag> Are they in our builds currently?
[16:16] <prpplague> i do not know, let me forward them to you
[16:16] <lag> k
[16:16]  * prpplague checks to see if he has lag's email
[16:16] <ogra> prpplague, kernel configs ?
[16:16] <prpplague> ogra: no state files
[16:17] <lag> ogra's problem :)
[16:17] <ogra> lag, ??
[16:17] <lag> Sounds like userspace to me :)
[16:17]  * ogra doesnt get how pulse configs can prevent kernel oopses before pulse can even run
[16:19] <ogra> lag, oops on kernel init cant be userspace :)
[16:19] <lag> My teflon shoulders not working today!
[16:19] <lag> Fail
[16:20] <lag> prpplague: ?
[16:21] <prpplague> i thought the log showed that it was already booted
[16:21]  * prpplague checks the log again
[16:21] <ogra> prpplague, pulse only starts with the desktop on ubuntu, no way that can have any effect here
[16:23] <prpplague> ogra: yea, my bad, i saw there that the mmc section had detected the partitions, on first look i assumed that the root fs had booted
[16:24] <prpplague> lag: which kernel are you using?
[16:24] <prpplague> lag: that doesn't look like the L24.9 audio configuration for the panda
[16:24] <lag> It should be L24.9
[16:24] <ogra> lag, i think we're one version behind TI
[16:25] <lag> This is L24.9
[16:25]  * ogra saw some discussion about having to backport ASoC fixes from the TI branch to the ubuntu one last week
[16:25] <lag> prpplague: Give me a sha id to look up in the log to confirm
[16:26] <prpplague> lag: http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=summary
[16:26] <prpplague> lag:  you can check the tags/id's there
[16:27] <prpplague> lag: but anything about L24.9 should be functional
[16:29] <lag> prpplague: http://paste.ubuntu.com/486816/
[16:30] <lag> prpplague: http://paste.ubuntu.com/486817/
[16:30] <lag> prpplague: Looks fairly up-to-date to me
[16:31] <prpplague> one sec, let me check the git repo
[16:32] <lag> prpplague: This is the one I'm currently using: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-es2
[16:32] <GrueMaster> ogra: oem-config crashed on panda for me.  20100901 image.
[16:33] <ogra> GrueMaster, hmm, worked fine here
[16:33] <ogra> XM doesnt boot with MMC errors for me :/
[16:36] <prpplague> lag: checking the git repo now
[16:36] <prpplague> lag: give me a minute or two
[16:37] <lag> np
[16:39] <prpplague> lag: looks like in the merge/rebase something has gotten broken, the L24.9 works fine, but it looks like the ubuntu integration tree is broken
[16:39] <prpplague> lag: give me about 5 minutes to look it over
[16:39] <lag> np
[16:41] <ogra> lag, any reason you dont use the kernel team git repo ? afaik it should have everything for ES2 including all display patches
[16:41] <ogra> (the one the package will be built from)
[16:41] <lag> ogra: Yes, when I started using this tree our tree wasn't rebased
[16:42] <prpplague> lag: looks like you might be missing a couple of panda related patches
[16:42] <ogra> i'm not sure what additional patches ricardo has in his tree vs the packaging tree
[16:42] <lag> There are no differences
[16:42] <lag> Well
[16:42] <ogra> or is missing...
[16:42] <lag> No significant differences
[16:43] <lag> Only his LED patch and my edits (suspend and sound debug)
[16:44] <prpplague> lag: ok one sec
[16:45] <prpplague> lag: ok http://paste.ubuntu.com/486626/  , checkout line 237
[16:46] <prpplague> lag: I2C write to TSP61305 failed
[16:46] <prpplague> lag: notice it is spell TSP61305
[16:46] <prpplague> lag: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commitdiff;h=3136e1a1a34e1197c8ee363b77e5a2ce1c98c2a7
[16:46] <prpplague> lag: that patch fixes that spelling mistake
[16:47] <prpplague> lag: which leads me to believe you don't have the current source building
[16:49] <lag> prpplague: http://paste.ubuntu.com/486828/
[16:51] <prpplague> lag: can you paste the sound/soc/omap/4430sdp.c file?
[16:51] <prpplague> lag: look - Linux version 2.6.34-903-omap4 (buildd@hawthorn) (gcc version 4.4.5 20100728 (prerelease) (Ubuntu/Linaro 4.4.4-8ubuntu1) ) #7-U
[16:51] <prpplague> lag: this can not be the L24.9 kernel
[16:52] <lag> Odd
[16:52] <lag> Give me a mo
[16:52] <ogra> yeah, thats definitely the packaged kernel
[16:52] <prpplague> lag: the L24.9 kernel will report something similar to:  Linux version 2.6.35-00002-gfe2d3db-dirty (danders@ccd-dev) (gcc version 4.3.3 (GCC) ) #17 SMP PREEMPT Mon Aug 30 11:06:07 CDT 2010
[16:53] <ogra> well, it would be  2.6.35-90*-omap4 for us
[16:53] <ogra> likely 904
[16:53] <prpplague> ogra: right, just pointing out that it would 2.6.35 not 2.6.24
[16:53] <lag> prpplague: [    0.000000] Linux version 2.6.35-903-omap4 (root@tangerine) (gcc version 4.4.5 20100728 (prerelease) (Ubuntu/Linaro 4.4.4-8ub)
[16:53] <ogra> unless it gets reset to 900 because fo the version bump
[16:53] <lag> I was using it earlier
[16:54] <prpplague> lag: ok that doesn't match what you pasted
[16:54] <lag> Why on earth have my script just decided to grab another kernel
[16:54] <ogra> prpplague, correct
[16:54]  * lag investigates
[16:55] <ogra> well, good to know our packaged kernel wors so far on ES2 even though its not supposed to *g*
[16:55] <ogra> *works
[16:56] <lag> Can someone remind me why x-loader hangs?
[16:57] <ogra> wrong u-boot ?
[16:57] <lag> It worked earlier
[16:57] <ogra> before you did what ?
[16:58]  * lag shrugs
[16:58] <lag> That's what I'm trying to find out
[16:58] <ogra> heh
[16:58] <prpplague> lag: paste the log
[16:58] <lag> I'm using u-boot-with-ubuntu-patches.bin
[16:58] <lag> prpplague: Which log?
[16:58]  * ogra doesnt know what that is
[16:58] <prpplague> lag: of the x-load hang
[16:58] <lag> It's rsalveti's
[16:58] <ogra> ah
[16:58] <lag> There isn't a log
[16:58] <ogra> for ES2 i suppose
[16:59] <lag> U-Boot 1.1.4-gcebe815a-dirty (Aug 20 2010 - 02:44:51)
[16:59] <lag> ?
[16:59] <ogra> 1.1.4 ???
[16:59] <lag> It's what was given to me
[16:59] <lag> Again by rsalveti
[16:59] <ogra> we dont use 1.1.4 anymore
[16:59] <lag> Do you think he has it in for me?
[17:00] <lag> Let me download Linaro's one
[17:00] <ogra> i'm noit sure that has the ES2 patches yet
[17:00] <ogra> stuff we need to care for next week
[17:00] <lag> robclark:
[17:01] <lag> robclark: Do you have a u-boot.bin I can use?
[17:01] <robclark> hi lag
[17:01] <lag> Hello mate
[17:01] <robclark> yeah, I suppose so.. let's see here
[17:01] <lag> Email would be my preference :)
[17:01] <robclark> lag: es2?
[17:02] <lag> Yes please
[17:02] <robclark> k
[17:02] <lag> I'm going to pick this up tomorrow
[17:02] <lag> I have to get ready to take the long haired general out for dinner
[17:02] <ogra> i dont want to go to dinner with you !
[17:03] <robclark> lag: sent
[17:03] <lag> Not the long haired floor sweeper ;)
[17:03] <lag> The big-gun
[17:03] <ogra> heh
[17:03] <robclark> ouch
[17:03] <lag> The Mrs
[17:03] <lag> :D
[17:03] <lag> Thanks robclark
[17:03] <robclark> np
[17:04] <ogra> lag, enjoy ... and send long haired greetings
[17:04] <lag> Perhaps I should try this once, before you lot go to bed
[17:04] <lag> ogra: Will do
[17:04] <robclark> lag: probably a good idea
[17:07] <lag> Looks promising
[17:07] <lag> prpplague, ogra: I think my scripts failed to mount the MMC card after the dd, hence leaving the old kernel on the card
[17:08] <sebjan> prpplague: did you find anything with your latest x-loader? When it is fixed for all ES2.0, your tree could be used as reference to start on ES2.0 on coming days (+after adding the support for 1GB ;))?
[17:09] <ogra> sebjan, we'll switch the world over to ES2 starting on friday (after beta is out)
[17:10] <prpplague> sebjan: just started looking, i suspect that i missed something on the fref_clkout for the EHCI phy
[17:10] <GrueMaster> Is there a software difference between the two ES2 boards?
[17:10] <ogra> GrueMaster, i think ricardo said he had issues with the 8 layer
[17:10] <prpplague> sebjan: i've been so swamped doing board validation, code for production testing, and getting handoff repos maintained, that mistakes are starting to creap in
[17:10] <ogra> well, someone mentioned it and i think it was him
[17:11] <sebjan> prpplague: yes, I know that :). I can do some testing when you have something.
[17:12] <GrueMaster> hrm.  If not, I can use both for testing.  Otherwise one is useless (not even good as a paperweight).
[17:12] <prpplague> ogra: any idea what issues he reported?
[17:14] <sebjan> GrueMaster: there are some changes required in the x-laoder and kernel. Without those, you cannot use the USB/ethernet ports.
[17:14] <GrueMaster> rsalveti: What problems did you see between the two different ES2 boards?
[17:14] <ogra> prpplague, not really, he'll be back tomorrow from his conference and we can ask
[17:14] <rsalveti> lag: the u-boot binary I sent you is based on the es2 tree from gitorious
[17:14] <ogra> oh
[17:14] <ogra> he's here :)
[17:14] <rsalveti> GrueMaster: I still didn't test es2 8 layer
[17:14] <rsalveti> now yes :-)
[17:14] <GrueMaster> (helps if you use his id instead of his name).
[17:14] <rsalveti> yep :-)
[17:14] <GrueMaster> Ok
[17:15] <rsalveti> GrueMaster: I got the board at home, but I'm at linuxcon now
[17:15] <rsalveti> will test it tomorrow
[17:15] <prpplague> rsalveti: ahh ok
[17:15] <GrueMaster> Ok, no problem.
[17:15] <lag> rsalveti: I'm sure it worked at one point
[17:15] <rsalveti> ogra: lag: I didn't test the upstream u-boot, so that's why I built only the tested one
[17:15] <lag> rsalveti: It just stopped working
[17:15] <rsalveti> so we could test it
[17:15] <rsalveti> lag: the ubuntu-patches at u-boot is the one we had with the older package
[17:15] <ogra> rsalveti, ah, k, i guess we'll need to bug jcrigby on friday then
[17:16] <lag> rsalveti: robclark's one works, so I'll keep with that one
[17:16] <rsalveti> just setting default parameters and etc, nothing important
[17:16] <rsalveti> ogra: yep, but I first need to find time to test the upstream one
[17:16] <rsalveti> and first report it to sakoman
[17:16] <prpplague> rsalveti: the gitorious omap4_panda_L24.9 branches should work for both the 6 and 8  layer ES2.0 boards, sebjan reported an issue with the 6-layer not bringing up the usb EHCI, i'm looking into that now
[17:16] <rsalveti> they don't have es2 boards, I guess
[17:16] <rsalveti> prpplague: hm, ok, good to know, thanks
[17:16] <ogra> rsalveti, you mean linaro ?
[17:16] <robclark> fwiw, my MLO/u-boot.bin/uImage's are all for 6-layer boards..  I've not upgraded yet
[17:16] <rsalveti> lag: yep, for now it's the best one
[17:16] <ogra> they dont even have ES1
[17:17] <rsalveti> ogra: yep (linaro is basing on upstream from sakoman)
[17:17] <rsalveti> so first I need to try sakoman's tree
[17:17] <rsalveti> then linaro
[17:17] <rsalveti> will do that tomorrow
[17:17] <rsalveti> when I get home after my visa interview :-(
[17:18] <lag> rsalveti: Where to we email to tell them not to let you our of the country?
[17:18] <lag> ;)
[17:18] <lag> out*
[17:18] <rsalveti> for es2 8layer let's just wait prpplague to test it
[17:18] <rsalveti> and give us a valid tree
[17:18] <sebjan> rsalveti: for 8 layers, if you build a kernel, you'll also need a patch from prpplague tree (L24.9 branch)
[17:18] <rsalveti> lag: haha :-)
[17:18] <rsalveti> sebjan: yep, I saw that on gitorious
[17:19] <rsalveti> sebjan: prpplague: are we going to have just one kernel, u-boot and x-loader for both es2 6 and es2 8?
[17:19] <rsalveti> it'll make our life much much easier :-)
[17:19] <prpplague> rsalveti: yes
[17:19] <rsalveti> nice!
[17:19] <prpplague> rsalveti: the current handoff should work on both
[17:19] <sebjan> all: fyi, I am preparing a patch series to goes on top of Bryan pull request, and that integrates all patches from prpplague tree and new updates from our dev teams.
[17:19] <prpplague> sebjan: dandy
[17:19] <rsalveti> sebjan: awesome
[17:20] <rsalveti> sebjan: can you send an email or ping us at the irc when you're done?
[17:20] <rsalveti> so we can build it and try with our boards
[17:20] <rsalveti> then package them
[17:20] <sebjan> rsalveti: yep, sure!
[17:21] <rsalveti> sebjan: cool, thanks :-)
[17:21] <sebjan> rsalveti: np
[17:21]  * ogra wonders why we have 6 layer boards at all
[17:21] <rsalveti> ogra: well, probably because they didn't know they would get the 8 layer so fast
[17:21] <rsalveti> :-)
[17:21] <ogra> i think everyone who has the 6 layer has the 8 layer too now
[17:21] <robclark> ogra:  I don't :-(
[17:22] <rsalveti> or, we didn't get the 6 on time
[17:22] <prpplague> ogra: long story
[17:22] <rsalveti> robclark: but you're ti! ;-)
[17:22] <prpplague> ogra: basically they were a intermediate platform for testing the ES2.0 silicon before the 8-layer board were ready
[17:22] <ogra> ah
[17:23] <ogra> we should just ignore the 6 layer then i guess
[17:23] <ogra> and move right away to the real stuff :)
[17:23] <rsalveti> ogra: if we get just one binary for both boards, then we could use them for other purposes
[17:23] <rsalveti> send for other teams, builders, don't know
[17:24] <robclark> well, I assume there will be 6-layer boards floating around for a while..  best option is single binary if possible
[17:24] <ogra> rsalveti, send them to robclark :)
[17:24] <ogra> oh, wait you have a 6 layer ...
[17:24] <rsalveti> ogra: well, I can use them for my build cluster ;-)
[17:25] <rsalveti> with an external usb hd things gets quite fast
[17:25] <rsalveti> and I can easily build kernels and stuffs
[17:26]  * ogra is sad that they are not black though
[17:26]  * rsalveti still didn't see his own es2 8
[17:26] <rsalveti> black was nice
[17:26] <ogra> but its easier to tell them apart that way
[17:26] <hrw> you guys did not have other problems? I do not have any panda so no panda problems (yet)
[17:27] <rsalveti> ogra: another subject, how things are going with our image?
[17:27] <rsalveti> GrueMaster: ^
[17:27] <GrueMaster> hrw: that sounds like  a bigger issue.
[17:28] <GrueMaster> rsalveti: Looks good.  basic (fixable) bugs, but it boots through w/o issues.
[17:28] <ogra> wohoo, my XM just finished
[17:28]  * GrueMaster could have sworn he'd filed a bug about lack of dvi support.
[17:29] <rsalveti> GrueMaster: ogra: nice
[17:29] <ogra> hmm, i suspended it ...
[17:29] <ogra> how the heck to i wake it up
[17:32] <ogra> hmm, the reset button wakes it up ... kind of ...
[17:32] <ogra> not really the way i want it to :P
[17:33] <ogra> rsalveti, btw, i dont seem to have RAM issues on my XM rev A
[17:40] <sebjan> rsalveti: fyi, you can start looking here for updates on ubuntu kernel with latest patches from prpplague: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git, in branch for-ubuntu-2.6.35. I was able to boot on both panda 6 and 8 layers and blaze with this kernel image. This branch may still move a bit before I send it to Bryan.
[17:41] <rsalveti> ogra: random results :-)
[17:42] <ogra> sebjan, awesome, you rock !
[17:43] <rsalveti> sebjan: yeah, I'm always following this tree :-)
[17:43] <sebjan> ogra: thanks, but most of the work is from prpplague, robclark, ... thanks to them! :)
[17:43] <rsalveti> thanks you all then :-)
[17:44] <ogra> ++
[17:44] <rsalveti> ogra: we'll have problems with x-loader for xM
[17:44] <rsalveti> we need an extra patch for Numonyx memory
[17:44] <ogra> rsalveti, why ? works here with todays image
[17:44] <ogra> oh
[17:44] <ogra> ok
[17:44] <rsalveti> some xM will have this memory
[17:44] <ogra> well, x-loader is in our hands
[17:45] <rsalveti> ogra: just got that from beagle mailing list
[17:45] <rsalveti> ogra: sure, but no time for beta
[17:45] <ogra> oh, i think i got a mail too
[17:45] <rsalveti> ogra: will create a bug and push the update
[17:45] <ogra> who cares for beta :P
[17:45] <rsalveti> haha :-)
[17:45] <ogra> as long as the final image has it
[17:45] <rsalveti> sure, and the good part is that it should work by just changing a binary, at the first partition
[17:46] <rsalveti> so, easy to workaround by the users
[17:46] <ogra> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/x-loader/maverick/annotate/head:/board/omap3530beagle/omap3530beagle.c
[17:46] <rsalveti> just need to provide the correct binary around
[17:46] <rsalveti> and post that at blogs/etc
[17:46] <rsalveti> ogra: yep
[17:46] <ogra> needs http://gitorious.org/beagleboard-validation/x-load/commit/ead751e4a361ce19552ac94bbeba232f12849244
[17:47] <rsalveti> ogra: yep
[17:47] <ogra> robert sent that to me and lool today
[17:47] <rsalveti> ogra: saw that, it was because I said the beta was going to be supported for xM
[17:47] <rsalveti> then Jason pointed that out :-(
[17:48] <ogra> well, just say its supported for the XM's that have been out there two week ago ;)
[17:48] <ogra> *weeks
[17:48] <ogra> final product will have to use final images :P
[17:49] <rsalveti> ogra: :P
[17:49] <ogra> anyway, i need to vanish ...
[17:49] <rsalveti> see ya
[17:49]  * ogra submits all testing results to the isotracker and calls it a day
[17:55]  * prpplague wonders if people are using four letter words to talk about prpplague on the lists right about now
[18:07] <lag> prpplague: Only in the private channels
[18:07] <lag> ;)
[18:10] <prpplague> lag: hehe
[18:11] <lag> :)
[18:11] <prpplague> lag: well if they are, make sure they use really good four letter words
[18:12] <lag> prpplague: I'll be sure to tell you otherwise :)
[18:12] <prpplague> hehe
[18:20] <sakoman> ogra, rsalveti: I know that the x-load in my tree works with both the Numonyx and Micron versions of the xM
[18:21] <devilhorns> what is the typical --seed used to create the ubuntu-netbook-efl rootstock stuff ?
[18:21] <rsalveti> sakoman: but did you include the http://gitorious.org/beagleboard-validation/x-load/commit/ead751e4a361ce19552ac94bbeba232f12849244 patch?
[18:21] <rsalveti> or something simliar
[18:22] <devilhorns> should I just seed with ubuntu-netbook and then add the efl stuff ?
[18:23] <sakoman> rsalveti: yes: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=x-loader.git;a=summary
[18:23] <sakoman> fifth commit down
[18:24] <rsalveti> sakoman: cool, nice to know
[18:25] <rsalveti> didn't know you are also maintaining a x-loader tree
[18:25] <sakoman> rsalveti: heh, there is even a kernel tree :-)
[18:26] <rsalveti> haha, yep, you always start with just one tree, and at the end you have your own tree for everything :-)
[18:26] <sakoman> rsalveti: most of the xM support patches came from my x-load tree
[18:26] <rsalveti> sakoman: cool, didn't know
[18:27] <rsalveti> sakoman: do we have a kind of upstream x-loader?
[18:27] <rsalveti> or just basically trees all around, like beagle validation and yours
[18:27] <sakoman> rsalveti: as far as I know, there is no official "upstream" for x-load
[18:27] <sakoman> Personally I would like to see it die
[18:28] <sakoman> It is really horrid code
[18:28] <rsalveti> yeah, it'd be nice to kill it
[18:28] <rsalveti> and about the direct u-boot support for panda?
[18:29] <sakoman> that is waiting for me to get a new panda with a processor ES2 or later
[18:29] <sakoman> early processors have broken config header support
[18:30] <rsalveti> hm, ok
[18:59] <lool> sakoman: let's kill x-loader then
[19:00] <lool> sakoman: How much work would it be to merge it back into u-boot, with two build modes?
[19:00] <lool> like one config for x-loader mode, and one config for full mode
[19:00] <lool> sakoman: That sounds like a good Linaro topic, even if a bit biased towards OMAP  :-)
[19:17]  * rsalveti out again
[19:43] <prpplague> sebjan: ping
[19:49] <prpplague> sebjan: http://gitorious.org/pandaboard/x-loader/commit/a41abea82b5f02265cd9f7140f0f10be3a9c97e7
[19:57] <sakoman> lool: that is not a trivial task :-)
[20:17] <jcrigby> lool, I think the avenue to take would be  nand_spl like other arch's do
[20:18] <jcrigby> lool, I think the avenue to take would be  nand_spl like other arch's do
[20:18] <jcrigby> oops
[21:03] <devilhorns> hmm
[21:04] <devilhorns> running apt-get upgrade in my arm qemu image causes a segfault :(
[21:04] <devilhorns> anyone experience this before ?
[21:05] <orbarron> hey guys... where is the omap daily build releases? can some one send me a link plz
[21:05] <GrueMaster> orbarron: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/
[21:05] <orbarron> thanks
[21:15] <devilhorns> nvm, found that it appears to be a common problem :(
[22:13] <lool> jcrigby: nand_spl > interesting bit
[22:54] <tmzt> persia: is that the new zaurus? is it msm or something else?
[23:44] <rsavoye> how would I make Unity launch instead of gnome ? this is on an armel system
[23:46] <GrueMaster> You can select it at login from gdm.
[23:46] <rsavoye> ah, let me try again
[23:46] <GrueMaster> after selecting the user, but before entering password.  Bottom of the screen.
[23:50] <rsavoye> hum, I have no bottom of the screen unless I can figure out how to adjust my hdmi monitor horizontal setting
[23:50] <rsavoye> anyway to make it launch directry ?
[23:55] <rsavoye> is there a meta package to remove all of gnome ?
[23:56] <GrueMaster> you could run sudo /usr/lib/gdm/gdm-set-default-sesion une.
[23:56] <GrueMaster> That would launch unity, I believe.
[23:57] <GrueMaster> (after a restart).


[04:03] <Freen0deAdmin> !ops
[04:25] <Freen0deAdmin> !staff
[06:08] <Jef91> I hit some wacky hotkey, and now every time I click on a desktop in my pager it sends the windows from that desktop to my sixth virtual desktop. What on earth did I do and how do I undo it?
[07:26] <dani> hi
[07:27] <Guest36156> hi
[07:27] <Guest36156> im searching the program for screecasting - wich
[07:27] <Guest36156> :x
[07:28] <Guest36156> bechause i using kazam but its very bug
[07:28] <Guest36156> bechause i using kazam but its very bugs
[07:28] <Guest36156> bechause i using kazam but its very bugs
[07:29] <Guest36156> im searching the program for screecasting - wich
[07:31] <Guest36156> kdeits
[07:31] <Guest36156> buginhg
[07:38] <valorie> Guest36156: what exactly do you mean by screencasting?
[07:39] <Guest36156> yes
[07:39] <Guest36156> but kde its strange buging when i record
[07:39] <Guest36156> strangely
[07:39] <Guest36156> "x
[07:41] <valorie> http://www.linuxlinks.com/article/20090720142023520/Screencasting.html for more ideas
[07:41] <valorie> record my desktop is what I hear of people usually using
[07:41] <valorie> !screencast
[07:41] <valorie> ubottu knows more than I do
[07:42] <valorie> me either, ubottu
[07:42] <Graf_Westerholt> valorie :D
[07:58] <Guest36156> thank you
[07:58] <Guest36156> :D
[07:59] <Guest36156> bye from now
[08:09] <valorie> best of luck
[08:24] <Guest36156> ihave
[08:24] <Guest36156> a
[08:24] <Guest36156> gre
[08:24] <Guest36156> green screens
[08:25] <Guest36156> how to fix
[08:33] <MoonUnit`> don't like the new plasma5 theme much
[08:34] <MoonUnit`> changed to the other kickoff version and prefer that to the default one
[08:53] <Guest36156> stjuped green screeens
[08:53] <Guest36156> :X
[08:56] <valorie> Guest36156: can you say more about what you mean, or provide an image?
[08:57] <valorie> !paste
[08:57] <valorie> imgur link above for screenshots or photos
[09:03] <Guest36156> am
[09:03] <Guest36156> when i gust
[09:03] <Guest36156> waching videos
[09:03] <Guest36156> for little moment
[09:03] <Guest36156> green screen
[09:03] <Guest36156> whats dhtat
[09:05] <ismail_> HERKESE SLM.
[09:06] <ismail_> SKYSTAR  UYDU KARTINI ÇALIŞTIRACAK PROGRAM ARIYORUM!!!
[09:08] <ismail_> TÜRKÇE BİLEN VARMI???....)))))))))
[09:10] <Guest36156> english please
[09:25] <lordievader> Good morning.
[09:46] <Guest36156> good
[09:46] <Guest36156> morning
[09:46] <Guest36156> :d
[09:46] <Guest36156> i have a big bug
[09:46] <Guest36156> :X
[09:47] <Guest36156> with plasma5
[09:47] <Guest36156> i dont know hot to -purge
[09:47] <Guest36156> plasma
[09:47] <Guest36156> :x
[09:47] <Guest36156> lordievader: do you know
[09:47] <soee> Guest36156: please wrie in one line
[09:47] <soee> what bug do you have ?
[09:47] <Guest36156> green screen
[09:48] <lordievader> Guest36156: I have told you yesterday, don't use the enter key as a period or space key.
[09:48] <Guest36156> yes told me :X
[09:48] <Guest36156> sorry bro
[09:49] <lordievader> Guest36156: I'm not your 'bro', but do try to explain your problem again, as clear as possible.
[09:53] <Guest36156> am when i wachting videos and switching in full screen - gust  splashing a black screen
[09:53] <Guest36156> sorry the screen is green
[09:55] <soee> its liek some problem with drivers and video encoding
[09:55] <soee> do you have installed kubuntu-restricted-extras ?
[10:16] <Guest36156> yes
[10:16] <Guest36156> how to remove
[10:16] <Guest36156> :D
[10:16] <Guest36156> because thats - meybe problem
[10:16] <Guest36156> when i was without the secret-extars
[10:16] <Guest36156> i dont have a green screen
[10:50] <Walex> Guest36156: there is a thing called a "video surface" which is a way for the card to accelerate video display, and it is usually green, except wehn there is content on it.
[10:51] <Walex> Guest36156: video surfaces are handled a bit specially, so switching screens may not be a good idea while video display is on.
[11:28] <BluesKaj> Hiyas all
[13:16] <TJ-> Can you give me some package recommendations to install, for KDE-specific help/tutorial, suitable for a new user (no access to apt-get since it is a completely non-networked environment)
[14:59] <AciD``> my main computer screen does not want to wake up (and stays in standby mode) but I can still access it via ssh. How can I either force the screen to lightup, or close all my apps gracefuly (on kde) ?
[15:01] <lordievader> AciD``: What does xrandr say?
[15:04] <AciD``> lordievader > it seems to stall right now
[15:06] <AciD``> `xrandr` returns "Can't open display" of course, and `DISPLAY=:0 xrandr` just does not returns
[15:07] <lordievader> AciD``: Does it hang or does it return nothing?
[15:07] <Jef91> Anyone know why Google's branded Chrome browser doesn't start up again when I reboot like the rest of my applications do in KDE?
[15:08] <AciD``> it hangs
[15:09] <AciD``> I could kill -15 all my apps manually, but as it's not the first time that happens, I'd prefer to be sure I'm not missing an easy fix/workaround here
[15:10] <lordievader> Sounds like a mallfunctioning driver.
[15:11] <lordievader> AciD``: What videocard/driver are you rocking?
[15:11] <AciD``> I just tested that `DISPLAY=:0 kcalc` also does hang
[15:11] <AciD``> fglrx... :(
[15:11] <AciD``> and radeon HD 7950
[15:16] <AciD``> lordievader > ok so, connecting with `ssh -X computer`, I can launch kcalc and xrandr
[15:17] <AciD``> except xrandr does not picks up the host configuration then, but the client one it seems
[15:30] <lordievader> AciD``: What happens when you restart X? Note running applications will die.
[15:32] <AciD``> lordievader > I decided to go the old way, and killed -15 my apps and restarted
[15:32] <AciD``> upon restart, everything is fine
[15:32] <AciD``> (until next time)
[15:35] <lordievader> Next time try to restart X, perhaps that is all it needs ;)
[15:41] <AciD``> yes, but the result is same ; I lose my current work
[15:41] <AciD``> :(
[15:42] <lordievader> Err, yes. I'm afraid so.
[15:44] <AciD``> anyway, thanks for the help :)
[15:44] <lordievader> AciD``: No problem ;)
[15:45] <lordievader> AciD``: By the by, what version of fglrx do you use?
[15:46] <AciD``> lordievader > 2:14.301
[15:47] <AciD``> I updated to the latest catalyst driver few days ago
[15:47] <AciD``> which solved the huge glitches I had for weeks (when using a 2560x1440 res)
[15:47] <lordievader> !info fglrx-updates
[15:48] <lordievader> !info fglrx-updates utopic
[15:53] <AciD``> (quite old versions indeed)
[16:00] <lordievader> AciD``: Yeah, I get why you went to AMD directly ;)
[16:37] <indra> m
[18:09] <Walex> I get good frame rates with the free sw 'radeonsi' driver with the kernel and X server in 14.04LTS
[21:40] <Jef91> does KDE have a built in on screen keyboard or is there one that works well with it that is recommended?
[21:41] <soee> thers a keyboard widget
[21:41] <Jef91> soee: does that pop up/go away when text inputs are selected?
[21:42] <bprompt> Jef91:      run "kvkbd"    also available as a widget from the taksbr
[21:42] <bprompt> taskbar rather =)
[21:43] <soee> Jef91: no idea, never used it :)
[21:54] <AciD``> lordievader > you'll laugh, it's doing it again ; I went away and turned the screen off. coming back : no signals...
[23:54] <sysop2> hi guys, have a question,  can I use  qtvideosink to make a qml video wallpaper?  instead of doing animated gifs?