[00:16] fta: glitch-free enabled or disabled? [00:16] dtchen, how do i know? [00:17] hheheh [00:17] dtchen: that's the common question [00:19] anyone wanna take a stab at my problem ^^^^ [00:19] fta: grep tsched= {/etc/pulse/default.pa,~/.pulse/default.pa} [00:20] (eh, not the most efficient set, but whatever) [00:21] /etc/pulse/default.pa:load-module module-hal-detect tsched=0 [00:21] grep: /home/bugabundo/.pulse/default.pa: No such file or directory [00:22] /etc/pulse/default.pa:load-module module-hal-detect tsched=0 [00:22] grep: /home/fta/.pulse/default.pa: No such file or directory [00:23] fta: ok, so i presume pkill pulseaudio works around that? [00:23] nope [00:24] 1st thing i tried [00:25] ok, what if you disable autospawn, pkill pulseaudio, and just use alsa directly? [00:26] fta: is the volume at 100%? [00:26] mine tends to get muted or low [00:26] or at 0% [00:26] nearly all HDA controllers have this gpio screwery that i haven't figured out how to work around [00:27] it manifests itself as crackling when the Master/PCM/Front widgets are powered down [00:27] aka "muted" === rickspencer3-afk is now known as rickspencer3 [00:28] or change from analog to digital [00:28] or alsamixer gets out of sync [00:28] lol [00:28] just so many bugs.... poor dtchen [00:29] asac: ping. are you around! want to clear a bug/feature on NM and 3G [00:29] how do I disable autospawn? [00:30] fta: change /etc/pulse/client.conf's "autospawn = yes" to "autospawn = no", or do so in ~/.pulse/client.conf [00:30] (anything in /etc/pulse will be overridden by ~/.pulse) [00:32] yep, better [00:32] ok, so the plot thickens [00:32] there are a few things to consider, and i'm working with the speex developer on the resampling [00:32] the resampler is one culprit [00:32] another culprit is the use of shm [00:33] you can try disabling shm in daemon.conf [00:33] but it was almost fine in jaunty [00:33] you can also adjust default-fragments and default-fragment-size-msec [00:33] jaunty and karmic have _very_ different audio stacks [00:33] how come? [00:33] in fact, the audio stack has changed significantly between each of gusty, hardy, intrepid, jaunty, and karmic [00:34] it's like having five separate stacks, really [00:34] hm [00:34] well, for starters, every release brings a newer section of the stack (alsa-kernel shipped in linux-image-$(uname -r) - and alsa-lib) [00:35] not to mention the glue layer shipped in alsa-plugins changes [00:35] not to mention pulseaudio itself changes [00:35] ehehe [00:35] not to mention the compilation options have changed [00:37] well, i trust you on this ;) [00:37] no need to trust me [00:39] :) [00:40] default-fragments = 8 [00:40] default-fragment-size-msec = 10 [00:40] what do you recommend? [00:41] it's extremely controller specific [00:41] fta: I went up to 128 [00:41] above 16 didn't notice any diference [00:41] there is no "one size fits all" [00:42] BUGabundo: then you're just spinning the cpu more than you need to [00:42] eheh [00:42] I'm back on 8 [00:43] mplayer randomly pauses itself [00:45] tried 8/10, 16/10, 32/10, 8/20, 8/40(=unusable) [00:45] nada [00:46] I just changed frag.... not size msec [00:48] fta: they're frame-aligned on powers-of-two [00:48] 8, 16, 32... [00:49] ok [00:49] let me work on the git snapshots of pulse and get back to you [00:50] i would, in the meantime, reset those values to 8 and 10, respectively, and try changing the resampler [00:50] (i'm currently using ffmpeg, but some people use trivial) [00:51] dtchen: how can we do that? [00:52] hhmmm;, excellent [00:52] with ffmpeg [00:52] BUGabundo: daemon.conf [00:53] "resample-method = ffmpeg" [00:53] you'd think it would be straightforward to adjust these parameters, but the permutations of HDA controllers really make things horrifically complicated [00:54] if i pause in mplayer for more than a few secs, when i unpause, it plays just 3 secs and stops [00:54] using either -ao alsa or -ao pulse, correct? [00:55] yes [00:55] it's ao=alsa now [00:55] grr, that's more complicated (need to look at both linux and pulseaudio) [00:56] if you're brave, can you reproduce the symptom using http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc5/ ? [00:56] need to know where to start the git-bisect :/ [00:58] it's 2am, will try tomorrow [00:58] mainline? [00:58] yeah, im wit fta [00:58] to late for me [00:58] vanilla [00:59] dtchen, will those kernels work with my nvidia blob? [01:00] Would someone here be willing to review a FF extension I tried packaging following the guide on the wiki? [01:01] fta: the nvidia blobs are DKMSised; you just need to ensure that you also install the linux-headers* mainline debs, too [01:07] LP Bug #375753 if anyone gets a chance. The bzr branch is linked to the bug report. [01:07] Launchpad bug 375753 in ubuntu "[needs-packaging] NoScript (Firefox extension)" [Wishlist,In progress] https://launchpad.net/bugs/375753 [01:11] nhandler: I've asked debian maintainer of mozilla-noscript about update and he said that he'll try to do it soon (He had a child some time ago and it took his whole free time :) ). [01:14] kklimonda: Ah ok. I missed that we had mozilla-noscript. Shouldn't it be listed on https://edge.launchpad.net/~mozilla-extensions-dev ? [01:16] nhandler: it isn't maintained by Mozilla Extensions Team so I guess they don't list it on their page. [01:19] What has been bothering me is the fact that there is no standard in naming extension packages.. we have mozilla-noscrtipt, adblock-plus, firefox-greasemonkey, iceweasel-imperator.. it's easy to miss something. [01:20] iceweasel-vimperator* === micahg1 is now known as micah1 [01:30] kklimonda: I think we discussed a while ago (few months ago or so) and decided to not use mozilla, firefox and similar in packages' names. The reason would be not to get an impression that the software is produced by Mozilla, and also because we ship debranded version of Firefox (abrowser). [01:30] kklimonda: IIRC, mozilla-noscript and firefox-greasemonkey were packaged way before that discussion was held. [01:31] kklimonda: though, I'm not sure if we should rename those specific few packages now. You should check that with asac. [01:33] Jazzva: I've already seen one or two packages that had both "branded" dummy package (used for transition) and clean one.. I think we could at least rename iceweasel-vimperator to vimperator as we don't ship iceweasel at all [01:34] I'll ask asac about it. asac? :) [01:34] Jazzva: I know that we won't be using my packaging, but if you get a chance, could you please look at my version of noscript to let me know if it looks ok (so I know for next time)? [01:34] also, mozilla-noscript is in the wiki list... I'll update ~mozilla-extensions-dev page to link to that list. I suppose most of the extensions need to be updated... I'll give my best to help (after I finish another school project, which is going to be on Saturday) [01:35] nhandler: sure, I'll take a look now :) [01:35] Jazzva: I think it was added by nhandler [01:35] kklimonda: mozilla-noscript was already there. I added (and removed) noscript [01:35] ah, i see [01:36] kklimonda: it was also unknown if that's the NoScript as distributed on addons.mozilla.org, IIRC [01:39] nhandler: "firefox | firefox-3.0 | ..." should be "firefox | ...". seems like I should also rework extensions' packaging page... [01:40] nhandler: that's from the period when "firefox" was FF2, and firefox-3.0 was FF3 [01:40] Jazzva: Then should XPI.TEMPLATE be updated to reflect that? [01:41] nhandler: also, we don't ship iceweasel and icedove [01:41] nhandler: I'll update it. I didn't know it wasn't updated. [01:42] Yeah, those Dependencies are from XPI.TEMPLATE [01:42] nhandler: sorry for the mess :) [01:42] No problem [01:43] nhandler: other than that, looks good [01:43] nhandler: it builds and installs correctly, right? [01:44] Yeah, it built fine. It looks like it is installing the files properly, but I did not test that yet (I am not ready to restart firefox and close mibbit) [01:44] nhandler: Ok, I'll give it a testdrive then :). Does it work with Thunderbird too? [01:45] Jazzva: The website did not list it as working with Thunderbird [01:46] nhandler: You missed to point Vcs-Bzr field in debian/control to the right branch. Also, one little typo, you wrote "mozilla" in the description. I think it would be better to write "Mozilla" [01:48] nhandler: the idea is to provide template, and then to remove, or add dependencies as needed (and also to reflect that in MOZ_XPI_MOZILLA_DIRS in debian/rules), so you should probably remove thunderbird (and I'll remove icedove and iceweasel from the template :)) [01:49] Jazzva: I thought about adding the Vcs-Bzr, but the wiki guide didn't mention it. I also didn't think having it linked to my personal bzr branch would be very beneficial (it would be better to have it point to a team maintained branch). As for the description, you are right, it should be mozilla. [01:50] Jazzva: As for the dependencies, wouldn't it make more sense to not have it depend on Thunderbird by default since MOZ_XPI_MOZILLA_DIRS does not include Thunderbird by default [01:52] nhandler: I'll check with asac for tbird dependency. For now, I'll add a comment in debian/rules to reflect changes made to MOZ_XPI_MOZILLA_DIRS in dependency line. [01:52] nhandler: As for the Vcs-Bzr, it should link to https://code.launchpad.net/~ubuntu-dev/firefox-extensions/.ubuntu [01:53] nhandler: since your branch will be merged into that branch. I'll add that to the packaging page on wiki [02:08] asac: do you know why gnomefreak added iceweasel and icedove to XPI.TEMPLATE branch? [02:10] nhandler: looks like noscript is installed correctly [02:11] Awesome! Now I just need to find a package another package that is actually properly licensed and is not already in debian/ubuntu [02:12] nhandler: if you want, you can also update some of already packaged extensions... [02:13] nhandler: if in doubt if the maintainer mentioned on the wiki page will complain, then feel free to take some of mine :) [02:14] Jazzva: That isn't a bad idea. Also, do we track which of our extensions are in Debian, and which are not? [02:16] nhandler: we have different (and IMO easier) packaging. Feel free to take some of the extensions mentioned in the first list, I'm 99% sure that they're all packaged using mozilla-devscripts (that's the thing in which we differ for now) === rickspencer3 is now known as rickspencer3-afk [02:22] Jazzva: Unless you have any objections, i'll try and update GreaseMonkey [02:22] nhandler: no problem. Thanks :) [02:26] Jazzva: Do we not have $EXTENSIONNAME.upstream branches? [02:28] nhandler: If you think on .upstream branches in ~ubuntu-dev's bzr, no, we don't have them [02:28] nhandler: here's mine https://code.edge.launchpad.net/~jazzva/firefox-extensions/firefox-greasemonkey.upstream [02:29] Jazzva: Why don't we keep the .upstream branches with the .ubuntu branches? [02:30] nhandler: we actually moved nspluginwrapper (and maybe some other packages) to use the same branch for upstream and ubuntu branches. I'm not sure if that's the way we decided to maintain extensions. You're probably right. asac will know more than me. [02:41] Jazzva: For firefox-greasemonkey, it Depends on: firefox | abrowser | firefox-3.0 | firefox-2, should the firefox-3.0 and firefox-2 be removed? [02:42] nhandler: yes [02:42] nhandler: have you checked the current packaging in ~ubuntu-dev branch? [02:45] Jazzva: Yes. That is the one I am working with. Did you have any other changes in your person branch that I should merge in? [02:45] nhandler: no. [02:45] ;) [02:47] ok, sleep time over here. good luck with packaging :) [02:51] Thanks a lot for your help Jazzva. I should have an upgrade ready by the end of the night ;) [02:51] Good night [02:52] nhandler: no problem. good night :) [03:07] Hiya gang [03:07] Yall do cover the Thunderbird as well? [03:08] Yes supernix [03:09] I was having an issue with getting Thunderbird to connect to a server to smtp email [03:10] I had to switch to Evolution to get it done [03:10] Funniest thing never had that issue before [03:11] I tried switching to SSL and no authentication and even TLS all would not connect === nhandler_ is now known as nhandler === micahg1 is now known as micahg === Nafallo_ is now known as Nafallo [09:50] Jazzva: no i dont know ;) [09:51] i think i told him not to ;) [10:05] hi [10:06] hi fta [10:06] grr ... gwibber is unreliable [10:06] how so? [10:06] i posted that i was at metallica concert and its not there ;) [10:09] indeed, annoying [10:09] ooo is still uninstallable for me [10:11] http://paste.ubuntu.com/171393/ [10:16] at least the rest is now good ;) [10:17] fta: aptitude dist-upgrade will tell you more why its a problem [10:17] it's related to the lang packs [10:23] asac, http://paste.ubuntu.com/171398/ [10:25] hmm ... quite a lot of removal [10:26] hopefully, it's fixed in https://edge.launchpad.net/builders/vernadsky === fta_ is now known as fta [10:30] asac, [Tue 12 23:16] http://paste.ubuntu.com/170976/ [10:30] asac, [Tue 12 23:22] ok, got it, it was javascript.options.jit.chrome=true [10:35] reproducible? [10:36] 100% [10:36] file a bug ;) [10:36] just enable jit chrome? [10:37] i asked on #developers yesterday if it was a known bug, someone said yes but failed to give me a bug # === dpm_ is now known as dpm [10:51] mozillla bug 492028 [10:51] Error: Launchpad bug 492028 could not be found [10:51] mozilla bug 492028 [10:51] Mozilla bug 492028 in JavaScript Engine "TM: Crash [@ nsEventReceiverSH::AddEventListenerHelper]" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=492028 [10:52] fta: ^^ [11:04] does anyone care to add latest patch to tbird3 for the reply all actions? I have no issue building it with patch but i wouldnt have daily [11:06] gnomefreak: is that an upstream patch? [11:07] asac: yes that is where i would grab it from. I will see if i can find upstream bug for you in a few [11:08] gnomefreak: once it lands upstream we will get it in dailies [11:08] mozilla 45715 [11:08] Mozilla bug 45715 in Composition ""Reply to List" [button/(context) menu item]" [Enhancement,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=45715 [11:09] so you mean if i wantede it now i would have to build it and just not upgrade the daily builds until it is released [11:11] gnomefreak: i think that patch will take a while. doesnt the extension just work? [11:12] asac: dont know i know it did not work when this problem sufaced. I might have miss the commant about the extension if it in that bug report [11:13] gnomefreak: story is that at some point nothing worked ... then we added a patch that supports reply to list in the backend ... from there on the extension works [11:13] now it seems they want to do the UI on their own [11:13] imo there is nothing to do here for us [11:13] just wait until this gets committedd [11:14] desending == in order of newest part of bug is first than the re: is after that. but tbird dorsnt understand that at all [11:14] confirming that the extension still works would be good i guess and maybe contacting the extension author if it doesnt work anymore [11:15] gnomefreak: what is your "descending === ..." line about? is that a new bug yo [11:15] ? [11:15] asac: the problem that started this bug IIRC was that using replt all would reply to the commenter and the bug, they/we are looking more for a way to reply to newgroups/mailing list posts without using the commenter as a reply [11:16] the "NEW" bug line is after the responces bug comments [11:16] yes, thats the nature of "reply to list" [11:16] gnomefreak: the NEW bugline thing is something different [11:17] i submitted a patch for that at some point ... seems it got not accepted [11:17] asac: than no extension doesnt work and either did our attempts to fix it to work that way [11:17] asac: i know its not the same [11:22] asac: here is what i mean: http://www.flickr.com/photos/26378196@N05/3528186214/ [11:22] and yes that is decending order [11:23] gnomefreak: why dont you use a threaded view? [11:25] threaded doesnt put them in groups AFAIK (what i mean is group bugs together [11:26] oh maybe it does [11:26] threaded groups ;) [11:26] thats the idea of threaded [11:26] ah i just changed it to that it looks helpful ;) thanks [11:28] hehe [11:28] welcome [11:31] shit i have to go im later already :( [11:53] fta: chromium daily doesnt work here [11:54] ? [11:54] i always get "Aw, there is something wrong with displaying this site" [11:54] ?? [11:55] regression? [11:56] fta: http://people.ubuntu.com/~asac/tmp/chromium1.png [11:56] i think its a regressoin [11:56] i definitly was able to use it [11:56] this is 32bit [11:56] havent tested here for 2 weeks or so [11:56] on amd64 i tested a more recent and it worked [11:56] e.g. the build after fixing gconf i think is what i tested [11:57] works for me on 32b [11:57] the tabs are a problem with compiz afaik [11:57] nope, the tab corruption is known. it's about transparency. it's been fixed yesterday [11:58] hmm ... but it worked on my ati card ... [11:58] are you up-to-date? [11:58] fta: i just updated to latest of today [11:58] jaunty? [11:58] so yesterdays nightly i guee [11:58] yes [11:58] ii chromium-browser 2.0.181.0~svn20090512r15864-0 Chromium browser [11:58] i changed one thing: i dropped sse2 from the build flags [12:00] fta: todays i386 build failed in karmic ;) [12:00] i know [12:00] ah ... yeah. so you dont have latests ;) [12:00] i do [12:00] lets see if i get that with older build too [12:00] i have both jaunty and karmic ppas for ucd [12:01] what do you see in the console? [12:01] ok trying apr 29 now [12:01] http://paste.ubuntu.com/171482/ [12:03] so apr 29 the tabs look good ;) [12:03] but rendering aint working either [12:03] http://code.google.com/p/chromium/issues/detail?id=11679 [12:04] http://people.ubuntu.com/~asac/tmp/chromium2.png [12:04] kk [12:05] do you have msttcorefonts ? [12:06] did you drop the depends? [12:06] nope [12:07] then how can i not have it? [12:07] and yes, i dont have it [12:07] pleeeaase add the Sans patch ;) [12:07] its a bit odd ... not sure what they use, but Arial maps to a font here using fontconfig [12:08] so it would be really interesting if the patch you showed me helped [12:08] fta: do you have the url for that patch again? [12:08] hhm [12:08] fc-match Arial [12:08] DroidSans.ttf: "Droid Sans" "Regular" [12:08] i have those nice great droid fonts ;) [12:08] actually are google fonts [12:10] ii chromium-browser 2.0.178.0~svn20090429r14851-0 Chromium browser [12:10] pn msttcorefonts (no description available) [12:11] nhandler: Jazzva: yes, we prefer to use .bzr-builddeb/*.conf so we can just have .ubuntu branch as baseline [12:11] asac: ok. [12:12] asac, http://code.google.com/p/chromium/issues/detail?id=9100 ? [12:12] asac: just wanted to ask you that to... and are we gonna rename packages as firefox-greasemonkey and mozilla-noscript to greasemonkey and noscript (though, the second exists in debian under that name, maybe the first too) [12:13] s/that to/that too/ [12:13] fta: so our chromium-browser is the test_shell =? [12:13] http://code.google.com/p/chromium/issues/detail?id=10665 [12:13] nope, not anymore [12:13] we have both [12:14] test_shell is in -testsuite [12:14] fta: do they have codebrowse or something so i dont need to ge tthe full orig? [12:14] i want to check what they do in getCachedFontPlatformData [12:14] in general Arial should resolve properly ... unless they reinvented the wheel... which as it seems they did [12:14] no public mxr :( [12:15] but a svn web [12:15] http://src.chromium.org/svn/trunk/src/ [12:15] Jazzva: yeah. removing those prefixes is good. we should check though that we dont end up having a different source package name as debian [12:15] otherwise they will get synched here and we will have it twice [12:15] ok, so there's iceweasel-greasemonkey, I suppose we could remove firefox- then [12:15] so source package should stay the same [12:15] binary package should be renamed [12:15] asac: ok [12:15] and a bug filed against debian asking politely to consider to rename [12:16] fta: thanks. thats not that helpful for my case ;) ... i guess i have to branch whole stuff [12:17] fta: ok back to eliminating third_party stuff ... i think we have to accept that we wont have system webkit for some time [12:17] or grab the orig if you want it faster [12:17] what i want is to get rid of everything else [12:18] fta: do you know which subdir all that code is in? [12:18] i introduced a SYSTEM_LIBS feature a while ago, it's in. [12:18] so looking at http://src.chromium.org/svn/trunk/src/third_party/ [12:18] what works with our system libs? [12:18] src/third_party/WebKit/WebCore/platform/graphics/chromium/FontCacheLinux.cpp ? [12:19] hmm [12:19] didnt they say they sync without patches from trunk? [12:19] so thats an issue in webkit? [12:19] odd [12:19] ok thanks [12:19] i will check that [12:20] err webkit isnt in third_party [12:21] so they also use skia ... i think we should package that [12:21] its also needed by gears [12:22] not sure where my SYSTEM_LIBS is since they migrated to gyp :P [12:23] lost in the battle? [12:25] gyp? [12:26] no scons anymore? [12:26] http://code.google.com/p/gyp/ [12:26] yes, scons, but scons rules are auto updated by gyp [12:27] sort of [12:27] is that innovation or just over-engineering? [12:27] both [12:28] it's yet another layer but it helps [12:29] http://code.google.com/p/gyp/wiki/GypUserDocumentation [12:29] http://code.google.com/p/gyp/wiki/GypLanguageSpecification [13:06] ok lost my changes ... synching chromium from svn [13:07] use my local branch feature [13:08] it will create and keep up to date for you the full svn tree [13:09] local branch? [13:09] better tell me now as the sync is already running ;) [13:09] shall i abort that? [13:09] LOCAL_BRANCH [13:10] my get-orig-source supports a LOCAL_BRANCH variable [13:10] yeah [13:10] i want to work on upstream sources for now though [13:10] LOCAL_BRANCH=../upstream/chromium-browser.svn [13:10] yep [13:10] i guess you dont have the .svn packed uploaded somewhere ;)? [13:10] no [13:11] want them? [13:11] i can do that easily [13:11] not today ... i think providing baselines would be nice ... but should be done upstream imo [13:11] didnt they put a "get started svn thing" somewhere? [13:12] http://dev.chromium.org/developers/how-tos/get-the-code [13:22] asac, i have a tar, want it? [13:22] what size? [13:23] is that with .svn files - like i want? [13:24] yes, my full upstream branch [13:29] not sure ... this checkout is running for quite some time already [13:29] cant be that much longer ;) [13:29] fta@cube:/data/bot/upstream/chromium-browser.svn $ du -sm . [13:30] 3119 . [13:31] ok i am at 3.1G [13:31] so it should really be ending soon ;) [13:31] 3.1G . [13:31] asac@tinya:/tmp/chromium-browser-2.0.178.0~svn20090429r14851$ [13:33] hmm. odd that you had 31119 [13:33] err 3119 [13:33] good ... it finished ;) [13:35] fta: https://wiki.ubuntu.com/Chromium/Build doesnt even say how to build the upstream way ;) [13:36] hm, right :) [13:37] http://code.google.com/p/chromium/wiki/LinuxBuildInstructions [13:38] yeah [13:41] fta: ok updated https://wiki.ubuntu.com/Chromium/Build [13:42] fta: so do you know how i can use a different directory for producing all the .o files and so on? [13:42] i dont really like to clutter the source tree with those things [13:42] similar to MOZ_OBJDIR=... [13:42] it's already in a subtree [13:43] ah yeh [13:43] se OBJ_DIR=$TOPSRCDIR/obj [13:43] sconsbuild [13:44] by default, all files end up in $(SRC_DIR)/sconsbuild/ [13:44] hmm [13:45] wow [13:45] so this uses some magic to figure the CHROME dir? [13:45] i mean i checked out in /tmp [13:45] and moved to some other place [13:45] now it complains that it cannot find the /tmp page [13:45] path [13:46] sort of, it's ..(/..)* [13:46] huh? [13:46] fta: so where is that directory written? [13:47] $(SRC_DIR)/sconsbuild/ [13:47] DEB_TAR_SRCDIR := src [13:47] SRC_DIR := $(CURDIR)/build-tree/$(DEB_TAR_SRCDIR) [13:47] base/base.scons: '/tmp/chromium-browser-2.0.178.0~svn20090429r14851/src/base', [13:47] base/base.scons: '/tmp/chromium-browser-2.0.178.0~svn20090429r14851/src/base', [13:47] grr [13:47] ? [13:47] seems depot_tools sync does that [13:48] ok seems its generated from .gyp [13:48]