[00:00] <bdrung> yes.
[00:00] <bdrung> but why should we support someone, who wants to shoot into his foot? ;)
[00:00] <asac> right. so thats why i would suggest to always add a empty (maybe with commented example/intro) file on top of the existing extensions files
[00:01] <asac> you never know until you find out
[00:01] <asac> and at that point the damage is already done
[00:01] <asac> user goes away happy. you go away screaming
[00:01] <asac> happened a lot of times with the old approach to ship all .js files in the /etc/firefox directory used by debian
[00:01] <asac> (not sure if they still do it ... i think not because of syspref)
[00:02] <asac> and we the deverloper only get a bit of suport headache. in forums they go mad at these ;)
[00:02] <asac> starting to spread stuff like: "deleting all /etc helps" and such
[00:02] <asac> so we need to be sensitive and prevent that from happening to any desktop user ;)
[00:03] <asac> (my 2 cents)
[00:03] <asac> ok will see if can write something tomorrow
[00:03] <asac> not sure if i get to it
[00:03] <asac> have two jobs atm ;)
[00:04] <asac> while the previous one was three jobs ;)
[00:06] <bdrung> two jobs?
[00:09] <bdrung> asac: do you think it would be useful to put the xpi-recommends-stamp target into a script (so probably all xpath calls will end up in this script)? this would make the xpi.mk file better readable and simpler.
[00:10] <bdrung> ok, i am going to sleep now. bye
[03:28] <dogatemycomputer> Greetings!   I am new to Triaging bugs.   My mentor referred me to this channel regarding bug #491181.  Could someone tell me if this bug contains enough information to mark it as "confirmed"?   The reporter says openjdk-6 crashes after a password prompt but the application is internal which makes reproducing it impossible for me.
[03:28] <micahg> hi dogatemycomputer
[03:29] <dogatemycomputer> hehehe.. hey micahg!   Long time.. no talk.   :-)
[03:29] <dogatemycomputer> micahg:  I keep swatting but this bug won't go away.
[03:29] <micahg> dogatemycomputer: I think the backtrace is good, but reproduce steps is nice
[03:29] <dogatemycomputer> micahg: :-)
[03:31] <dogatemycomputer> micahg:  well.. he can't turn over the app..  and if it happens with IE 100% of the time but Firefox seems more forgiving then I am assuming this application could be the problem.  Would hate to bother the developers if he can't reproduce it anywhere else.
[03:31] <dogatemycomputer> "I haven't ruled out poor coding within the Java App itself, unfortunately it is on an Management System Server so it may be hard to get a copy of the App."
[03:32] <micahg> dogatemycomputer: I think I'll try searching upstream a little later for a similar bug
[03:33] <dogatemycomputer> micahg: I am happy to do the legwork if you'd like.   I just need to know where to start?
[03:33] <micahg> dogatemycomputer: do you understand backtraces?
[03:34] <dogatemycomputer> micahg:  No.  Well.. rephrase..  they are not greek but they are not english.
[03:36] <micahg> dogatemycomputer: here's the upstream bugtracker if you want to search: http://icedtea.classpath.org/bugzilla/
[03:36] <dogatemycomputer> micahg: let me take a crack at it.   If I am unsuccessful then I will let you know.
[03:36] <dogatemycomputer> micahg: thanks again for the help!
[03:36] <micahg> dogatemycomputer: ok, if you find something, I'm happy to take a look at it
[04:29] <dtchen> asac: do your speakers pop on shutdown/reboot?
[04:57] <dogatemycomputer> micahg: I'm sorry but I cannot find a duplicate bug upstream for bug #491181 .  I looked through the backtrace and based on my limited knowledge it appears there is a segmentation fault when calling IcedTeaPluginFactory::HandleMessage.   Of course the actual message information is missing from the backtrace so who knows if it was null, malformed or I am way off base.
[05:17] <dogatemycomputer> micahg: I asked the reporter to get us the plugin debug logs too.   Hopefully that will help.
[10:08] <asac> dtchen: yes
[10:09] <asac> dtchen: why?
[14:33] <dtchen> asac: it affects the linux patch I'm working on
[14:33] <dtchen> asac: touching the dtor/free path (aka reboot) is a bit more complicated
[14:36] <asac> ok
[14:36] <asac> i am still wrestling a bit with alsa plugin using my usb headset thing
[14:37] <asac> dtchen: you said you were fixing bugs in that direction? what symptoms do those bugs have?
[14:37] <dtchen> asac: your usb headset thing is related to PA; alsa-plugins is only secondary
[14:37] <dtchen> asac: alsa-plugins is the latency and stream screwups for ALSA apps routed through pulse
[14:37] <asac> its odd. previously i couldnt speak ... now i cannot hear (one time after reboot it works though)
[14:38] <asac> and the output thing just doesnt appear in the "applications" tab
[14:38] <asac> at all
[14:38] <asac> anyway. i somehow feel its app related still ... so dont really bother until i figure that
[14:39] <asac> dtchen: would "stream screw ups" have such symptoms?
[14:40] <dtchen> well, some apps do incorrectly "restore" their volume states in their pulse backend code
[14:40] <asac> like "output stream disappearing"?
[14:40] <asac> the apps have no pulse backend
[14:40] <asac> just alsa
[14:41] <dtchen> asac: yes, the symptom would be rapid corking and rewinding due to ptr desyncing, which means the app's connection to PA through the pulse pcm plugin dies, rapidly reconnects with audible distortion, etc.
[14:41] <asac> hmm ok
[14:42] <asac> is there some ppa that might influence that so i can see if its really an issue with the plugins?
[14:42] <dtchen> asac: if you could confirm on Lucid, that would help
[14:43] <asac> hmm. i can use latest .32 kernel from ppa ... will be able to upgrade to lucid till next week
[14:43] <dtchen> as for ppa, there's a newer version of PA in the ubuntu-audio-dev one, but it's unlikely to help
[14:43] <asac> the problem i am having is that i cannot even see if its a bug in alsa/pulse or application
[14:44] <asac> or maybe even network setup ;) ... i guess i should just leave you alone with that until i know something :(
[14:44] <dtchen> well, it should trivially pinned to alsa-plugins <-> PA, because if you remove PA completely (disable autospawn, kill it) so that the app uses native ALSA, the issue should not be reproducible
[14:45] <dtchen> echo autospawn = no|tee -a ~/.pulse/client.conf && killall pulseaudio
[14:45] <dtchen> (to revert, just rm ~/.pulse/client.conf)
[14:46] <dtchen> you may need to then configure the app's alsa preferences to use a virtual device other than 'default'
[14:47] <dtchen> say, plughw:foo, where foo is the name in brackets from /proc/asound/cards
[14:47] <dtchen> or you can use the index, e.g., plughw:0
[14:47] <dtchen> anyhow, off for some hours (work)
[15:02] <asac> ok will check after lunch
[15:02] <asac> thx
[18:03] <asac> bug 432205
[18:49] <fta> micahg, 3.7 needs a rebase
[18:54] <micahg> fta: yeah, I saw, I guess the green couldn't go on forever :)