> Date: Sat, 11 Jan 2014 16:07:23 +0000 (GMT) > From: Richard <r_j_humphr...@yahoo.co.uk> > To: BLFS Support List <blfs-support@linuxfromscratch.org> > Subject: Re: [blfs-support] WebKitGTK-1/Flash > > > ----- Original Message ----- > > From: akhiezer <lf...@cruziero.com> > ... > > - meant to add, that if it's just no-pasa with flash+uzbl, then if possible > > as a fallback-test, build seamonkey/firefox as part of your blfs build > > (you'll likely have much of the 'Required' infrastructure already, > > in passing), > > and per blfs instructions, and verify that flash works ok for you with > > one/both > > of those. (Yes, I realise/guess that you perh/prob want uzbl as a bypass of > > the > > likes of ff/sm). Or, as an alternate test, can you add flash successfully > > to a > > distro that doesn't ship with it per se - e.g. slackware-14.1 . > > I may try that as an overnight build tonight. Forgive my stupidity - but how > is building a gecko-based browser going to assist with diagnosing why webkit > cannot use the plugin? >
That was a same-day reply to your initial post; at which time was still allowing for the possibility that you might just want to get the proverbial 'flash running in a browser' (your "how do you guys get flash working?" was interpreted by more than one, it seems, as a general question), rather than via a more-specific (webkit) route; I think it's fair to say that the more-apparent goal & 'allowed' routes, emerged in stages over the first few days of posts of the thread. For the apparent goal/routes that you want, I'd think that the likes of Fernando &c's posts in the main branch of this thread, that more-directly concern webkit &c, are of course the way to go. Am interested in how it's resolved. At the same time, although yes it can be interesting to get to the root of a problem - as well as or instead of 'just' sidestepping or working around it: but if "flash remains a necessity", per one of your early follow-up posts, then you might want to consider the ff/sm route; it's how I 'get flash working'; it's straightforward, and have never managed to get it not working - outwith test/dbg. Some general points to bear in mind, if not already: ---- * don't just rely on one 'test flash' site; use at least a few different ones. * you often will need javascript enabled (Fernando (&c?) has noted this). * some flash files may play ok while others not, due to e.g. different video encodings, etc. * curl: istr the conversation was re gnash; but keep it in mind for flash. * some ... types of debugging ... can lead to a situation where 'it works', but not sure what was the clinching factor. If you then try to find the decisive point by trying to 'break' the setup by undoing steps, you might get false-positives/negatives due to caching mechanisms. Such caching certainly applies to flash-in-browser IME. * post commands used, & stdout/stderr, if possible. * webkitgtk builds: looking around some slack-related sites (e.g. via 'http://www.slackware.org.uk/slackbuilds.org/', 'http://www.slackware.org.uk/slacky/'), webkitgtk seems to get built with some extra explicit './configure' options, such as '--enable-plugin-process=no' ["build plugin process for WebKit2 [default=yes]"] (I know that you mentioned it earlier), along with the other stuff that switches-off gtk3/webkit2. ---- rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
