Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread OmPrakash Muppirala 
On Tue, Nov 14, 2017 at 7:50 PM, Par Niclas Hedhman 
wrote:

>
> Alex,
> it is called "Open SOURCE" and not "Binary with link to Source" for a
> reason. Apache Software Foundation official only promise SOURCE releases.
> Any convenience binaries are not required/expected. It is not kosher to so
> called release (or make available) any binaries that are not built from an
> official source releases and place them in /dist. That goes against policy
> and infrastructure is likely going to have a strong opinion on the matter,
> i.e. pull the artifacts if found out.
>
> Very simple workflow;
>   1. Get your Source Release in order.
>   2. Check it and vote
>   3. Release it to /dist
>   4. Worry about anything else...
>
> Point 4 includes things like "Build binary convenience artifacts from the
> Source release".
>

Niclas,

Apologies if I have missed some context.

Piotr is the release manager here, I am not sure why your email is directed
towards Alex?

Quoting Alex:  "But given they don't look right in US Windows systems, unless
there is an easy workaround, it might be a good idea to fix this issue in
another RC."

As you can see in this thread, we are trying to figure out where the source
package gets messed up and we are trying to fix it.  While your input is
appreciated, I think your tone is a bit confrontational.

Thanks,
Om


>
> HTH
> Niclas
>
> On 2017-11-14 14:43, Alex Harui  wrote:
> > I think I just verified that the binary artifacts are ok regarding the
> > non-ascii characters.  I think that's because they are correct in the
> > repo, and were compiled into bundles from that repo source.  I'm not sure
> > when the files get screwed up.  I think it is when Ant copies the files
> to
> > the temp folder to be packaged.  Also, I'm not clear what code page they
> > are actually in.  I tried using "iconv" on my Mac to convert the files,
> > but I couldn't find the right source page.
> >
> > I also ran installer.xml in the binary artifact and found that the
> scripts
> > aren't executable.  I looked in the build.xml and installer.xml and do
> not
> > see any calls to chmod that would fix that, like there is in the FlexJS
> > versions of those files.  There are some indications from the archives
> > that this also has been a problem for as far back as 4.12.
> >
> > So, my assessment is:
> > 1) the binary artifacts are ok.  No new problems.
> > 2) the source artifacts are not ok.  There might be a workaround if we
> can
> > figure out how to convert the code page on those files.
> > 3) Would be nice to fix the executable bit on the scripts, but not a new
> > problem either.
> >
> > So, the vast majority of our users may not hit this problem since they
> > consume the binary artifacts and not the source artifacts.  I'll leave it
> > up to Piotr as to whether he wants to roll another RC that picks up
> > changes.  To fix the executable bits, I would recommend looking at how
> > chmod was used in the FlexJS build.xml and installer.xml.
> >
> > My 2 cents,
> > -Alex
> >
> > On 11/13/17, 10:19 PM, "Piotr Zarzycki" 
> wrote:
> >
> > >Hi Justin,
> > >
> > >Could you please post screenshot what is wrong cause I don't
> understand. -
> > >I wanted to compare results of tests between those two RCs.
> > >I will cut another RC, but not because of the issue above, but because I
> > >couldn't run sh script either on my Mac which is not good itself. I
> would
> > >like to let you know that I build Moonshine IDE sources with the
> binaries
> > >and it's working perfectly fine.
> > >
> > >Thanks, Piotr
> > >
> > >
> > >2017-11-14 1:17 GMT+01:00 Justin Mclean :
> > >
> > >> Hi,
> > >>
> > >> > Which would effect the locale files i.e. the Chinese and Japanese
> and
> > >> probably French and other european language locales would be broken.
> > >>
> > >> Confirmed it’s an issue and I would also vote -1 binding because of
> > >>that.
> > >>
> > >> To reproduce just view a DateChooser and you’ll see it has some ? in
> > >>it’s
> > >> display when using the Chinese and Japanese locales where other
> > >>characters
> > >> should be.
> > >>
> > >> Thanks,
> > >> Justin
> > >
> > >
> > >
> > >
> > >--
> > >
> > >Piotr Zarzycki
> > >
> > >Patreon:
> > >*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> > >eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27
> bb9f
> > >%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636462372052361116=Dc%
> > >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0
> > > https%3A%2F%2Fwww.patr
> > >eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27
> bb9f
> > >%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636462372052361116=Dc%
> > >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0>*
> >
> >
>

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Justin Mclean 
Hi,

> Niclas,  Where did I say it was "Binary with link to Source?”

I would assume from your email here:

> So, my assessment is:
> 1) the binary artifacts are ok.  No new problems.
> 2) the source artifacts are not ok.  There might be a workaround if we can
> figure out how to convert the code page on those files.
> 3) Would be nice to fix the executable bit on the scripts, but not a new
> problem either.
> So, the vast majority of our users may not hit this problem since they
> consume the binary artifacts and not the source artifacts.  I'll leave it
> up to Piotr as to whether he wants to roll another RC that picks up
> changes.

i.e. That you were good to release the working binary and broken source 
artefacts together.

I did also raise this as a issue , although perhaps in a less direct way.

> Either way it's the source that’s the offical release and it seems unusual to 
> release a broken source release even if the binary did work.


Given there’s going to be another RC perhaps it would be better to not waste 
energy arguing about this?

Thanks,
Justin

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Alex Harui 
Niclas,  Where did I say it was "Binary with link to Source?"  Do you
truly understand the issues here or are you just falsely accusing me of
something?  This is the kind of behavior we are supposed to model?  How
about modeling constructive criticism instead.

-Alex

On 11/14/17, 7:50 PM, "Par Niclas Hedhman"  wrote:

>
>Alex,
>it is called "Open SOURCE" and not "Binary with link to Source" for a
>reason. Apache Software Foundation official only promise SOURCE releases.
>Any convenience binaries are not required/expected. It is not kosher to
>so called release (or make available) any binaries that are not built
>from an official source releases and place them in /dist. That goes
>against policy and infrastructure is likely going to have a strong
>opinion on the matter, i.e. pull the artifacts if found out.
>
>Very simple workflow;
>  1. Get your Source Release in order.
>  2. Check it and vote
>  3. Release it to /dist
>  4. Worry about anything else...
>
>Point 4 includes things like "Build binary convenience artifacts from the
>Source release".
>
>HTH
>Niclas
>
>On 2017-11-14 14:43, Alex Harui  wrote:
>> I think I just verified that the binary artifacts are ok regarding the
>> non-ascii characters.  I think that's because they are correct in the
>> repo, and were compiled into bundles from that repo source.  I'm not
>>sure
>> when the files get screwed up.  I think it is when Ant copies the files
>>to
>> the temp folder to be packaged.  Also, I'm not clear what code page they
>> are actually in.  I tried using "iconv" on my Mac to convert the files,
>> but I couldn't find the right source page.
>> 
>> I also ran installer.xml in the binary artifact and found that the
>>scripts
>> aren't executable.  I looked in the build.xml and installer.xml and do
>>not
>> see any calls to chmod that would fix that, like there is in the FlexJS
>> versions of those files.  There are some indications from the archives
>> that this also has been a problem for as far back as 4.12.
>> 
>> So, my assessment is:
>> 1) the binary artifacts are ok.  No new problems.
>> 2) the source artifacts are not ok.  There might be a workaround if we
>>can
>> figure out how to convert the code page on those files.
>> 3) Would be nice to fix the executable bit on the scripts, but not a new
>> problem either.
>> 
>> So, the vast majority of our users may not hit this problem since they
>> consume the binary artifacts and not the source artifacts.  I'll leave
>>it
>> up to Piotr as to whether he wants to roll another RC that picks up
>> changes.  To fix the executable bits, I would recommend looking at how
>> chmod was used in the FlexJS build.xml and installer.xml.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 11/13/17, 10:19 PM, "Piotr Zarzycki" 
>>wrote:
>> 
>> >Hi Justin,
>> >
>> >Could you please post screenshot what is wrong cause I don't
>>understand. -
>> >I wanted to compare results of tests between those two RCs.
>> >I will cut another RC, but not because of the issue above, but because
>>I
>> >couldn't run sh script either on my Mac which is not good itself. I
>>would
>> >like to let you know that I build Moonshine IDE sources with the
>>binaries
>> >and it's working perfectly fine.
>> >
>> >Thanks, Piotr
>> >
>> >
>> >2017-11-14 1:17 GMT+01:00 Justin Mclean :
>> >
>> >> Hi,
>> >>
>> >> > Which would effect the locale files i.e. the Chinese and Japanese
>>and
>> >> probably French and other european language locales would be broken.
>> >>
>> >> Confirmed it’s an issue and I would also vote -1 binding because of
>> >>that.
>> >>
>> >> To reproduce just view a DateChooser and you’ll see it has some ?
>>in
>> >>it’s
>> >> display when using the Chinese and Japanese locales where other
>> >>characters
>> >> should be.
>> >>
>> >> Thanks,
>> >> Justin
>> >
>> >
>> >
>> >
>> >-- 
>> >
>> >Piotr Zarzycki
>> >
>> >Patreon: 
>> 
>>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa
>>>tr
>> 
>>>eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27bb
>>>9f
>> 
>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636462372052361116=D
>>>c%
>> >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0
>> 
>>>>>tr
>> 
>>>eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27bb
>>>9f
>> 
>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636462372052361116=D
>>>c%
>> >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0>*
>> 
>>

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Par Niclas Hedhman 

Alex,
it is called "Open SOURCE" and not "Binary with link to Source" for a reason. 
Apache Software Foundation official only promise SOURCE releases. Any 
convenience binaries are not required/expected. It is not kosher to so called 
release (or make available) any binaries that are not built from an official 
source releases and place them in /dist. That goes against policy and 
infrastructure is likely going to have a strong opinion on the matter, i.e. 
pull the artifacts if found out.

Very simple workflow;
  1. Get your Source Release in order.
  2. Check it and vote
  3. Release it to /dist
  4. Worry about anything else...

Point 4 includes things like "Build binary convenience artifacts from the 
Source release".

HTH
Niclas

On 2017-11-14 14:43, Alex Harui  wrote: 
> I think I just verified that the binary artifacts are ok regarding the
> non-ascii characters.  I think that's because they are correct in the
> repo, and were compiled into bundles from that repo source.  I'm not sure
> when the files get screwed up.  I think it is when Ant copies the files to
> the temp folder to be packaged.  Also, I'm not clear what code page they
> are actually in.  I tried using "iconv" on my Mac to convert the files,
> but I couldn't find the right source page.
> 
> I also ran installer.xml in the binary artifact and found that the scripts
> aren't executable.  I looked in the build.xml and installer.xml and do not
> see any calls to chmod that would fix that, like there is in the FlexJS
> versions of those files.  There are some indications from the archives
> that this also has been a problem for as far back as 4.12.
> 
> So, my assessment is:
> 1) the binary artifacts are ok.  No new problems.
> 2) the source artifacts are not ok.  There might be a workaround if we can
> figure out how to convert the code page on those files.
> 3) Would be nice to fix the executable bit on the scripts, but not a new
> problem either.
> 
> So, the vast majority of our users may not hit this problem since they
> consume the binary artifacts and not the source artifacts.  I'll leave it
> up to Piotr as to whether he wants to roll another RC that picks up
> changes.  To fix the executable bits, I would recommend looking at how
> chmod was used in the FlexJS build.xml and installer.xml.
> 
> My 2 cents,
> -Alex
> 
> On 11/13/17, 10:19 PM, "Piotr Zarzycki"  wrote:
> 
> >Hi Justin,
> >
> >Could you please post screenshot what is wrong cause I don't understand. -
> >I wanted to compare results of tests between those two RCs.
> >I will cut another RC, but not because of the issue above, but because I
> >couldn't run sh script either on my Mac which is not good itself. I would
> >like to let you know that I build Moonshine IDE sources with the binaries
> >and it's working perfectly fine.
> >
> >Thanks, Piotr
> >
> >
> >2017-11-14 1:17 GMT+01:00 Justin Mclean :
> >
> >> Hi,
> >>
> >> > Which would effect the locale files i.e. the Chinese and Japanese and
> >> probably French and other european language locales would be broken.
> >>
> >> Confirmed it’s an issue and I would also vote -1 binding because of
> >>that.
> >>
> >> To reproduce just view a DateChooser and you’ll see it has some ? in
> >>it’s
> >> display when using the Chinese and Japanese locales where other
> >>characters
> >> should be.
> >>
> >> Thanks,
> >> Justin
> >
> >
> >
> >
> >-- 
> >
> >Piotr Zarzycki
> >
> >Patreon: 
> >*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27bb9f
> >%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636462372052361116=Dc%
> >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0
> > >eon.com%2Fpiotrzarzycki=02%7C01%7C%7Cfcef139cb31d4bfc2bf008d52b27bb9f
> >%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636462372052361116=Dc%
> >2B05mo72Kfp6REB3IniQTA1%2BkLnXl%2F9gKP%2ByWD8mkE%3D=0>*
> 
>

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Alex Harui 
I couldn't see the screenshot, but I assume it didn't match.  The goal is to 
get it to match.  I still think the issue is the Ant Copy task.  Have you tried 
using the JAVA_TOOL_OPTIONS environment variable?  I know the CI server is 
using it.


-Dfile.encoding=UTF8

Another option you have is to update the build.xml and set the 
outputencoding="utf-8" on all file tasks.  You will know you have it right when 
you can unpack the source package and the characters match up.  Until then, it 
isn't really worth putting out another RC.

Good luck,
-Alex

From: Piotr Zarzycki 
>
Reply-To: "dev@flex.apache.org" 
>
Date: Tuesday, November 14, 2017 at 10:06 AM
To: "dev@flex.apache.org" 
>
Subject: Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

Hi Alex,

I'm running out of time for today, but I just look into the: 
frameworks/tests/basicTests/spark/views/SortTests.mxml in my local repository 
on Windows I see exactly same as you pasted here:

"海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "川 (U+5DDD)"]);

But when I unpack on my Windows RC2 sources from zip I see in that file this 
one:

[Obraz w treści 1]

Can you see screenshot above ?

Thanks, Piotr


2017-11-14 8:47 GMT+01:00 Alex Harui 
>:
Piotr,

If you look at your repo's copy of
frameworks/tests/basicTests/spark/views/SortTests.mxml, around line 43 you
should see:

  "海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "川 (U+5DDD)"]);

Note the character before "(U+5DDD)".  It should look like 1 curved line
followed by 2 straight lines.


In the RC1 source package, it looked like this (on Mac):

  "海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "?? (U+5DDD)"]);

Note the "??" before "(U+5DDD)".  And it also wasn't right on Windows
(en_US).


I'm wondering, what do you see on your system?  And what do you see in
RC2?  I haven't looked yet, and I'm pretty much out of time for tonight.
It could be that on your Windows system, even for RC1 you will see the 1
curved line followed by 2 straight lines.  But I'm pretty sure your Mac
should have the "??" for RC1.  If RC2 has the 1 curved line followed by
two 2 straight lines, then you probably got it right, but I'm more
suspicious of the Ant file manipulation than I am of Git's manipulation of
the files.

If you don't touch line endings when you pull from Git, you still should
ensure that the Windows .bat files have DOS line endings otherwise they
become hard to read on Windows systems.  I'm not sure the build script is
set up to do that.  It might assume that if you are on Windows, you don't
need to touch the .bat files.

HTH,
-Alex

On 11/13/17, 11:22 PM, "Piotr Zarzycki" 
> wrote:

>Alex,
>
>I understand what is all about with chmod as it was in FlexJS (not sure
>which file should be converted), but I would like to leave it as is now.
>Unfortunately I don't understand your last sentence:
>
>"I was hoping the source files would be valid on Windows, but I just
>checked and even there they are not.  I'm guessing that Piotr's default
>character encoding for Windows where he lives is different than US
>Windows.  I'm not sure there is a workaround to convert those files back
>to UTF8 or not.  But given they don't look right in US Windows systems,
>unless there is an easy workaround, it might be a good idea to fix this
>issue in another RC."
>
>I just pushed RC2, where I have checkouted once again whole repository
>having all files unchanged in case of line endings. Now sh scripts are
>runnable on Mac. I just run also installer.xml and it's working. I will
>wait for Justin's look into the pushed RC2 before I officially cut it.
>
>Thanks, Piotr
>
>
>2017-11-14 7:56 GMT+01:00 Alex Harui 
>>:
>
>>
>>
>> On 11/13/17, 6:27 PM, "Justin Mclean" 
>> > wrote:
>>
>> >Hi,
>> >
>> >> Is the DateChooser problem from your local build of the sources or
>>from
>> >> the RC binary artifacts?
>> >
>> >A local built from the compiled source bundled I've not tested the
>>binary
>> >yet but given it was made from the source release I would expect it to
>> >show the same issues. Or are you saying that the binary artefact was
>>not
>> >made from the code in the source release?
>>
>> The binaries are not created by first creating the source package,
>> unpacking it and compiling it.  You were a Flex SDK RM at least once,
>>did
>> you not understand what you were signing?  The build builds the sources
>>it
>> got from the repo and assumes that the copy to the temp folder to create
>> the source package will not modify the files, but it looks like at least
>> on Windows, Ant will change the character encoding in the copy

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Piotr Zarzycki 
Hi Alex,

I'm running out of time for today, but I just look into the:
frameworks/tests/basicTests/spark/views/SortTests.mxml in my local
repository on Windows I see exactly same as you pasted here:

"海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "川 (U+5DDD)"]);

But when I unpack on my Windows RC2 sources from zip I see in that file
this one:

[image: Obraz w treści 1]

Can you see screenshot above ?

Thanks, Piotr


2017-11-14 8:47 GMT+01:00 Alex Harui :

> Piotr,
>
> If you look at your repo's copy of
> frameworks/tests/basicTests/spark/views/SortTests.mxml, around line 43 you
> should see:
>
>   "海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "川 (U+5DDD)"]);
>
> Note the character before "(U+5DDD)".  It should look like 1 curved line
> followed by 2 straight lines.
>
>
> In the RC1 source package, it looked like this (on Mac):
>
>   "海 (U+6D77)", "雨 (U+96E8)", "水 (U+6C34)", "?? (U+5DDD)"]);
>
> Note the "??" before "(U+5DDD)".  And it also wasn't right on Windows
> (en_US).
>
>
> I'm wondering, what do you see on your system?  And what do you see in
> RC2?  I haven't looked yet, and I'm pretty much out of time for tonight.
> It could be that on your Windows system, even for RC1 you will see the 1
> curved line followed by 2 straight lines.  But I'm pretty sure your Mac
> should have the "??" for RC1.  If RC2 has the 1 curved line followed by
> two 2 straight lines, then you probably got it right, but I'm more
> suspicious of the Ant file manipulation than I am of Git's manipulation of
> the files.
>
> If you don't touch line endings when you pull from Git, you still should
> ensure that the Windows .bat files have DOS line endings otherwise they
> become hard to read on Windows systems.  I'm not sure the build script is
> set up to do that.  It might assume that if you are on Windows, you don't
> need to touch the .bat files.
>
> HTH,
> -Alex
>
> On 11/13/17, 11:22 PM, "Piotr Zarzycki"  wrote:
>
> >Alex,
> >
> >I understand what is all about with chmod as it was in FlexJS (not sure
> >which file should be converted), but I would like to leave it as is now.
> >Unfortunately I don't understand your last sentence:
> >
> >"I was hoping the source files would be valid on Windows, but I just
> >checked and even there they are not.  I'm guessing that Piotr's default
> >character encoding for Windows where he lives is different than US
> >Windows.  I'm not sure there is a workaround to convert those files back
> >to UTF8 or not.  But given they don't look right in US Windows systems,
> >unless there is an easy workaround, it might be a good idea to fix this
> >issue in another RC."
> >
> >I just pushed RC2, where I have checkouted once again whole repository
> >having all files unchanged in case of line endings. Now sh scripts are
> >runnable on Mac. I just run also installer.xml and it's working. I will
> >wait for Justin's look into the pushed RC2 before I officially cut it.
> >
> >Thanks, Piotr
> >
> >
> >2017-11-14 7:56 GMT+01:00 Alex Harui :
> >
> >>
> >>
> >> On 11/13/17, 6:27 PM, "Justin Mclean"  wrote:
> >>
> >> >Hi,
> >> >
> >> >> Is the DateChooser problem from your local build of the sources or
> >>from
> >> >> the RC binary artifacts?
> >> >
> >> >A local built from the compiled source bundled I've not tested the
> >>binary
> >> >yet but given it was made from the source release I would expect it to
> >> >show the same issues. Or are you saying that the binary artefact was
> >>not
> >> >made from the code in the source release?
> >>
> >> The binaries are not created by first creating the source package,
> >> unpacking it and compiling it.  You were a Flex SDK RM at least once,
> >>did
> >> you not understand what you were signing?  The build builds the sources
> >>it
> >> got from the repo and assumes that the copy to the temp folder to create
> >> the source package will not modify the files, but it looks like at least
> >> on Windows, Ant will change the character encoding in the copy unless
> >>you
> >> use JAVA_TOOL_OPTIONS.  That is something we should figure out how to
> >> prevent in the future, either by documenting how to prevent character
> >> encoding changes or by changing the build script.  And in my tests, the
> >> binary artifact did work correctly.
> >> >
> >> >Either way it's the source that’s the offical release and it seems
> >> >unusual to release a broken source release even if the binary did work.
> >>
> >> I was hoping the source files would be valid on Windows, but I just
> >> checked and even there they are not.  I'm guessing that Piotr's default
> >> character encoding for Windows where he lives is different than US
> >> Windows.  I'm not sure there is a workaround to convert those files back
> >> to UTF8 or not.  But given they don't look right in US Windows systems,
> >> unless there is an easy workaround, it might be a good idea to fix this
> >> issue in another RC.
> >>
>

Re: [DISCUSS] Release Apache Flex SDK 4.16.1 - RC1*

2017-11-14 Thread Maxim Solodovnik 
I can confirm (using Ubuntu 16.04 latest)

LICENSE file has Windows line endings (which is OK if it was checked-out on
Windows)
both frameworks/locale/ja_JP/metadata.properties
and frameworks/tests/basicTests/spark/views/SortTests.mxml files has
invalid contents (encoding)

I would suggest to create .gitattributes (similar to .gitignore) in case
line endings might be an issue
not sure why UTF-8 files were damaged, there are OK after git clone

On Tue, Nov 14, 2017 at 2:50 PM, Alex Harui 
wrote:

>
>
> On 11/13/17, 11:34 PM, "Justin Mclean"  wrote:
>
> >Hi,
> >
> >> The binaries are not created by first creating the source package,
> >> unpacking it and compiling it.  You were a Flex SDK RM at least once,
> >>did
> >> you not understand what you were signing?
> >
> >Every time I made the release I made it from the source on my local
> >machine on a clean tagged branch. I understood 100% what I was signing
> >(for instance see [1][2]) and write most of  the scripts to do help make
> >builds [3][4] and contributed a lot to the wiki on the instructions on
> >how the build the SDK. [4] I was a Flex SDK RM 1/2 dozen times probably
> >more and more than a dozen releases in this project.  So I have no idea
> >why you would say “did you not understand what you were signing?” and IMO
> >that was uncalled for.
>
> Because it sounded like you didn't understand how the build scripts worked.
> >
> >>  I'm not sure there is a workaround to convert those files back
> >> to UTF8 or not.
> >
> >Even if you did find a way it would likely change the md5s and make the
> >signatures invalid as converting to UTF8 modifies the file by adding a
> >byte order mark at the front of the file.
>
> A workaround of converting the files back to UTF8 before compiling would
> have nothing to do with md5s and sigs.
>
> -Alex
>
>


-- 
WBR
Maxim aka solomax