I don't see how doing anything other than calling a Bugzilla function is the right thing to do.
I won't apply this patch. On Mon, 2011-03-14 at 01:06 +0200, Yavor Nikolov wrote: > Hello guys, > > Here is a patch for this issue: > 1) I'm just resetting stdout & stderr encodings to utf8 after Bugzilla > module has been loaded. > 2) I'm explicitly setting usage mode to ..CMDLINE just in case. (Th > other modes which are currently available seem to be less > appropriate). > * 3) As I've already suggested - setting SERVER_SOFTWARE doesn't seem > a good idea: it triggers cgi-specific responses (like http 301 > Redirect and who knows what). > > Regards, > Yavor > > On Mon, Mar 7, 2011 at 09:41, Yavor Nikolov <[email protected]> > wrote: > A few more observations (basically I'm calling > Bugzilla::User->check( 'invaliduser' )): > > Scenario 1: (SERVER_SOFTWARE=1; usage_mode uninitialized): > results in cgi BROWSER mode. Errors are formatted as html; > possible interactive questions to user. > > Scenario 2: (SERVER_SOFTWARE=1; usage_mode = ...XMLRPC): > results in complications when error needs to be reported: > Can't locate object method "faultcode" via package > "SOAP::Fault" (perhaps you forgot to load "SOAP::Fault"?) > > Scenario 3: (SERVER_SOFTWARE=1; usage_mode = ...CMDLINE): this > seems to work OK in my test. However: > - Results in Bugzilla internal function i_am_cgi() returning > true and maybe some other cgi-specific stuff. Maybe that won't > cause serious problems but I don't like it very much. E.g. > following is executed in such case: > # This makes sure we're in a CGI. > if ($ENV{SERVER_SOFTWARE} && !$ENV{MOD_PERL}) { > require CGI::Carp; > CGI::Carp->import('fatalsToBrowser'); > } > > - Console initialization (init_console call) is never > performed. Which is maybe good. binmode STDERR is never > touched in this scenario (just binmode STDOUT, ':utf8') > > *** > So the current options are: > (1) Use Scenario 3. > (2) "Hack" Bugzilla code. (Could be result of Bugzilla team > fixing a bug if this is considered a Bugzilla bug). > (3) Switch to non-windows environment (and SERVER_SOFTWARE > unset; usage_mode=...CMDLINE). Actually this would result in > locale-based encoding. I don't know if that's good or bad. > > Regards, > Yavor > > > > On Mon, Mar 7, 2011 at 08:45, Yavor Nikolov > <[email protected]> wrote: > Hi, > > I managed to setup a test environment on Win32 (using > strawberry perl - latest version). > > Seems the problem is reproducible for me too. > Simplified test looks like that: > use Bugzilla; > $pid = fork(); > print "something [$pid]"; > > And this fails (print is never reached). > Trying to call Bugzilla->usage_mode( USAGE_MODE_*** ); > doesn't have desired effect since module needs to be > initialized before that call. > > Only setting SERVER_SOFTWARE seems to prevent the > problem from what I've tested so far. Or changing > Bugzilla code. > > *** > Root cause of the problem is changing stdout/stderr > encodings in > Bugzilla::Install::Util->set_output_encodings(). > > The deadly combination is something like that: > # code page of console is somehow detected (used to be > utf8 before) > binmode STDOUT, ":encoding(cp866)"; > defined ( $pid = fork() ) or die( "Can't fork: $! > \n" ); > # this is enough to crash perl when forking > > In scmbug point of view I don't think we want to > change encoding to something like that at all. (I'm > not sure what's best - maybe utf8 as it used to be) > > *** > I think it would be best if we ask Bugzilla team for > their opinion too: > 1) Report the described behavior (Bugzilla is crashing > fork unless SERVER_SOFTWARE is set) > 2) Module initialization takes place before before > usage_mode(...) so how to switch usage_mode then? > 3) Which mode would be best for us to use /maybe new > one/ > > > Regards, > Yavor > > 2011/3/6 Kristis Makris <[email protected]> > > On Thu, 2011-03-03 at 12:48 +0100, Thorsten > Schöning wrote: > > script? If this works, Kristis may have to > options: Issue a call to > > Bugzilla::usage_mode with USAGE_MODE_BROWSER > before doing anything > > else with Bugzilla or defining the env > variable before using Bugzilla. > > > Could someone test this before I release > something that breaks Bugzilla > 4.0 for everyone? > > In particular, test NOT setting > SERVER_SOFTWARE=1 in ENV. This sounds > like poking under the Bugzilla covers. Using > Bugzilla::usage_mode sounds > more proper. > > > _______________________________________________ > scmbug-users mailing list > [email protected] > > http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users > > > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
