Dave, I haven't run RAT, but I did just run the custom license tool for TC and this is what it says:
Error Unknown-Text! traffic_monitor_golang/common/util/num.go Error Unknown-Text! traffic_monitor_golang/traffic_monitor/crconfig/data.go Error Unknown-Bourne-Again! traffic_ops/app/db/pg-migration/runwaiter.sh Error GPL/LGPL! traffic_stats/vendor/ gopkg.in/retry.v1/LICENSE Error GPL/LGPL~! traffic_stats/vendor/ gopkg.in/retry.v1/clock.go Error GPL/LGPL~! traffic_stats/vendor/ gopkg.in/retry.v1/exp.go Error GPL/LGPL! traffic_stats/vendor/ gopkg.in/retry.v1/regular.go Error GPL/LGPL! traffic_stats/vendor/ gopkg.in/retry.v1/retry.go Error GPL/LGPL~! traffic_stats/vendor/ gopkg.in/retry.v1/strategy.go There are problematic licenses. Looks like two go files and one shell file missing it's apache header, plus a problematic GPL component. On Wed, May 17, 2017 at 9:46 AM Eric Friedrich (efriedri) < [email protected]> wrote: > There is an issue that Jeff E will take care of later this week that is a > showstopper. > > Also Dan was going to look into seeing if we needed more post > install/postgres fixes back ported to 2.0.x so it could be useful. > > —Eric > > > > > On May 17, 2017, at 11:02 AM, Dave Neuman <[email protected]> wrote: > > > > Hey All, > > We had some great discussion about the 2.0 release at the summit, I was > > wondering if anyone had a summary of that discussion and a list of what's > > left to do that could be added to this thread? I think we discussed that > > we were going to take another look at 2.0 and see if it is a viable > release > > that we should move forward with, is that everyone else's understanding > as > > well? > > Does anyone know of any showstopper issues that still exist? > > > > Thanks, > > Dave > > > > On Mon, Apr 10, 2017 at 9:19 PM, Eric Friedrich (efriedri) < > > [email protected]> wrote: > > > >> Update: > >> - License issue has been fixed- Thanks Rob! > >> - Postinstall script is broken, Jeff and Dan are looking at it. > >> > >> Once post install is fixed, I will cut an RC > >> > >> —Eric > >> > >> > >> > >>> On Apr 6, 2017, at 2:35 PM, Dewayne Richardson <[email protected]> > >> wrote: > >>> > >>> +1 > >>> > >>> On Thu, Apr 6, 2017 at 9:43 AM, Robert Butts <[email protected] > > > >>> wrote: > >>> > >>>> +1 > >>>> I didn't realize it was new. > >>>> > >>>> On Thu, Apr 6, 2017 at 8:49 AM, Dan Kirkwood <[email protected]> > wrote: > >>>> > >>>>> +1 > >>>>> > >>>>> On Thu, Apr 6, 2017 at 7:43 AM, David Neuman < > [email protected] > >>> > >>>>> wrote: > >>>>>> Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet > >>>>>> released, why don't we just remove the `ResumeSession` method all > >>>>> together > >>>>>> and eliminate the dependency? Otherwise we are deprecating > something > >>>>> that > >>>>>> we never formally released. > >>>>>> > >>>>>> On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts < > >> [email protected] > >>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Regarding `TC-119: traffic_ops/client dependency license issue`: > >>>>>>> > >>>>>>> It looks like the persistent cookie jar is only needed by Traffic > Ops > >>>>>>> Client `ResumeSession(toURL string, insecure bool) (*Session, > >> error)`. > >>>>>>> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone > >>>>> else is > >>>>>>> using it. Because it returns an error, and persisted cookies have > >>>>>>> lifetimes, any current users already must handle errors from > >> persisted > >>>>>>> cookies being expired. Thus, we can change it to always return an > >>>> error > >>>>>>> with only degraded performance (and not much, login is cheap), > >> without > >>>>> loss > >>>>>>> of functionality. > >>>>>>> > >>>>>>> To fix TC-119, I propose we document `ResumeSession` as deprecated, > >>>> and > >>>>>>> change it to always return an error, which lets us remove the > >>>>> dependency, > >>>>>>> without the development cost of writing our own persistent cookie > >>>> store > >>>>>>> that no one is using. > >>>>>>> > >>>>>>> Any objections? > >>>>>>> > >>>>>>> > >>>>>>> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell < > >>>> [email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> These all got fixed and backported to 2.0: > >>>>>>>> > >>>>>>>> TC-203: Mojo doesn’t set cachable headers on public files” > >>>>>>>> TC-190: TTL type mismatch in CrConfig > >>>>>>>> TC-189: ssl_multicert.config too slow > >>>>>>>> > >>>>>>>> So Jan and Dave just need to close the issues. > >>>>>>>> > >>>>>>>> On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin < > >>>>> [email protected] > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi Eric, > >>>>>>>>> I was going to address the immediate Postinstall issues TC-185. I > >>>> am > >>>>>>> way > >>>>>>>>> late on this. I created a fork yesterday, need to run a couple of > >>>>> tests > >>>>>>>> and > >>>>>>>>> then I can push to this fork. > >>>>>>>>> Jeff Martin > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) < > >>>>>>>>> [email protected]> wrote: > >>>>>>>>> > >>>>>>>>>> We have some release blockers for 2.0. Specifically: > >>>>>>>>>> > >>>>>>>>>> TC-119: traffic_ops/client dependency license issue > >>>>>>>>>> We cannot ship with Category-X LGPL software, so I’m waiting > >>>>> for > >>>>>>>> this > >>>>>>>>>> to be resolved before cutting a release branch > >>>>>>>>>> "TC-185 post install doesn’t run due to missing perl module” > >>>>>>>>>> We shouldn’t ship a release in which the install process is > >>>>>>> broken > >>>>>>>> in > >>>>>>>>>> this way. > >>>>>>>>>> *There’s no assignee yet for this, any volunteers?* > >>>>>>>>>> > >>>>>>>>>> I think if we can get those two taken care of we can cut an RC0 > >>>>> later > >>>>>>>>> this > >>>>>>>>>> week. > >>>>>>>>>> > >>>>>>>>>> Major bugs we will ship with (unless someone objects): > >>>>>>>>>> TC-203: Mojo doesn’t set cachable headers on public files” > >>>>>>>>>> TC-190: TTL type mismatch in CrConfig > >>>>>>>>>> TC-189: ssl_multicert.config too slow > >>>>>>>>>> > >>>>>>>>>> —Eric > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Apr 4, 2017, at 1:13 PM, Dave Neuman <[email protected]> > >>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Good question. I would also like to see us try to get some > >>>>> release > >>>>>>>>>>> candidates out for 2.0. I am pretty sure the actual install > >>>> and > >>>>>>>>>>> postinstall need work. There are also a couple of issue that > >>>>> are > >>>>>>>> still > >>>>>>>>>>> assigned to 2.0 and unresolved: > >>>>>>>>>>> https://issues.apache.org/jira/browse/TC/fixforversion/ > >>>>>>>>>> 12338562/?selectedTab=com.atlassian.jira.jira-projects- > >>>>>>>>>> plugin:version-summary-panel > >>>>>>>>>>> . > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn < > >>>> [email protected] > >>>>>> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> When are we planning to release 2.0? We at Comcast are > >>>> running > >>>>>>> what > >>>>>>>> we > >>>>>>>>>>>> call 2.0…. So we are +1, I am pretty sure. > >>>>>>>>>>>> > >>>>>>>>>>>> Eric: are you waiting for something? Which cats need herding? > >>>>>>>>>>>> > >>>>>>>>>>>> Rgds, > >>>>>>>>>>>> JvD > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > >> > >
