Thanks. The good news: We can now connect the slave without having to set the file.encoding.
The bad news: Our jobs don't produce any console output any more. Neither a simple "set" command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi <[email protected]> wrote: > No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ > > > 2013/6/13 Dirk Haun <[email protected]> > >> Kohsuke, >> >> thanks for trying to fix it. But I'm afraid there's no difference - it >> still can only connect when we set the file.encoding to ISO8859. >> >> I took the remoting-1.42-SNAPSHOT.jar from here: >> https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ >> >> Was that even the correct file? But I didn't see any other version >> anywhere. >> >> >> >> >> On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi <[email protected]>wrote: >> >>> I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes >>> that. Any chance you can try a new remoting jar to see if you can connect >>> via JNLP without overriding the encoding? >>> >>> There's a corresponding change in the server for a proper fix, but you >>> wouldn't need that since your master runs in an ASCII-compatible encoding. >>> >>> >>> 2013/6/12 Kohsuke Kawaguchi <[email protected]> >>> >>>> XML without prolog is parsed as UTF-8, so I think that part is OK. >>>> >>>> I'm spotting a few places in JNLP handshaking that relies on >>>> ASCII-compatible encoding, so I wonder if that's causing it. In any case, I >>>> think we need more detailed error messages. >>>> >>>> Another thing I spotted is the BASIC auth header. How is the username >>>> and password supposed to be encoded? >>>> >>>> >>>> 2013/6/12 James Nord (jnord) <[email protected]> >>>> >>>> Looks like jenkins serves up its JNLP pages without an XML prolog >>>>> (the <?xml version="1.0" encoding="UTF-8"?> bit)…**** >>>>> >>>>> ** ** >>>>> >>>>> If you save the file and add an XML prolog for UTF-8 and run from that >>>>> without setting the encoding – does that work?**** >>>>> >>>>> ** ** >>>>> >>>>> /James**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* [email protected] [mailto: >>>>> [email protected]] *On Behalf Of *Dirk Haun >>>>> *Sent:* 12 June 2013 15:03 >>>>> *To:* jenkinsci-users >>>>> *Subject:* Re: Jenkins vs. EBCDIC**** >>>>> >>>>> ** ** >>>>> >>>>> Ah, the default encoding. It seems we *have* to set it to something >>>>> other than EBCDIC so we can even get a connection to our master.**** >>>>> >>>>> The slave is connected via Java Web Start and started like so: >>>>> >>>>> java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl >>>>> http://<ip-of-master>/computer/sva-zpdt-emul/slave-agent.jnlp -auth >>>>> <username>:<password>**** >>>>> >>>>> Without the -Dfile.encoding (or setting it to EBCDIC), the slave can >>>>> not get a connection to the master.**** >>>>> >>>>> ** ** >>>>> >>>>> Connecting via ssh is not an option, as it's not available on the >>>>> emulator.**** >>>>> >>>>> Any suggestions?**** >>>>> >>>>> ** ** >>>>> >>>>> On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi <[email protected]> >>>>> wrote:**** >>>>> >>>>> This should work out of the box, because we take the encoding of the >>>>> slave into account for obvious reasons.**** >>>>> >>>>> ** ** >>>>> >>>>> the "Execute Shell" feature uses the CommandInterpreter class, which >>>>> uses the FilePath.createTextTempFile method to create a shell script. This >>>>> file takes contents as String, then uses the encoding of the slave when it >>>>> does "new FileWriter(f)". So it should write the shell script in EBCDIC. >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> Does your slave JVM have a proper default encoding configured?**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> 2013/6/12 Dirk Haun <[email protected]>**** >>>>> >>>>> We're trying to use Jenkins to build our software on OS/390 (using the >>>>> Hercules emulator, not real hardware, but still). This OS uses EBCDIC as >>>>> its native character set, not ASCII. We've successfully managed to check >>>>> out from our SVN repository (yay!), but now we would need to run commands >>>>> to build the software. And this is where we run into problems ...**** >>>>> >>>>> The problem is that commands that we type into the text field of the >>>>> "Execute shell" build step need to be translated from ASCII to EBCDIC when >>>>> run on the OS/390 side. We confirmed that this is the problem by manually >>>>> translating a simple command to EBCDIC and typing those characters into >>>>> the >>>>> text input field - the command was then executed.**** >>>>> >>>>> However, a lot of EBCDIC characters have non-printable ASCII >>>>> equivalents, so this is not an option in practice (besides it being a pain >>>>> in the back to maintain).**** >>>>> >>>>> Is there any any plugin that can handle this situation?**** >>>>> >>>>> Alternatively, is there a plugin that would simply let us run a script >>>>> that's already on the OS/390 side? Please note that again, there's the >>>>> problem of character set translation - this time with the file name; but >>>>> since the SVN plugin does work as expected, maybe some part of Jenkins is >>>>> already doing the right thing.**** >>>>> >>>>> We're stuck at this point, so any help is appreciated. Thank you.**** >>>>> >>>>> bye, Dirk**** >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> **** >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> -- >>>>> Kohsuke Kawaguchi **** >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> **** >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Kohsuke Kawaguchi >>>> >>> >>> >>> >>> -- >>> Kohsuke Kawaguchi >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Kohsuke Kawaguchi > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
