Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Apr 2019 12:28:44 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
To:        Balanga Bar <balanga.bar@gmail.com>
Cc:        "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Mark Linimon <linimon@lonesome.com>, freebsd-arm@freebsd.org, Ian Lepore <ian@freebsd.org>
Subject:   Re: Marvell Kirkwood - anyone?
Message-ID:  <201904231928.x3NJSi7D039312@gndrsh.dnsmgr.net>
In-Reply-To: <CADocevA8ZfS2RGd=dkoqA2Bo32dQ2XP1ZDD3G3vSNE_%2BBv8MHQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> Many thanks. Is this what I should use?
> 
> ftp://ftp.fi.freebsd.org/pub/FreeBSD/releases/amd64/11.0-RELEASE/ports.txz

If your trying to get 11.0 release ports/packages working on that platform
that would be a good place to start.  Your going to run into some issues
with out of date tar balls, but since you got 11.0 running the amount of
this should be greatly reduced.

> 
> Not really sure how this differs from portsnap fetch, but it seems to be
> what I'm looking for...

portsnap fetch well get you the latest ^head ports, and they may or may
not build on 11.0, I believe it does build on 11.2.  I am not a consumer
of portsnap fetch so take anything I say about it with very light value.

I was more trying to give you some starting points if you
did need to go down the 8.X path, given your light years
ahead of that by being able to run 11.0 much of what I
said is less importand and more of that mcl said applies.

Another aside of having 11.0 running is you can probably host
cross build on a AMD64 11.0 system and speed up your build
cycles.  I do not think that worked so well back in the 8.x era.

> On Tue, Apr 23, 2019 at 7:01 PM Rodney W. Grimes <
> freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> 
> > > On Tue, Apr 23, 2019 at 03:19:15PM +0100, Balanga Bar wrote:
> > > > Is it possible to get a version of portsnap from that point?
> > >
> > > I don't know enough to answer that question.  I think it would be fair
> > > to assume "no".
> >
> > You would not want ot use portsnap I do believe,
> > but what you may want to start with is the ports.txz file
> > that should of shipped on the i386/amd64 disc1 .iso
> >
> > That would of been the copy of the ports tree at the time
> > the system was released.  Your going to have probably significant
> > paints in finding tar balls that match, but it is not impossible.
> >
> > The shorter your list of needed ports the better.
> >
> > Your are then going to have to check for CVE's against
> > all that code and either fix or mitigate the issue, if
> > it is a non connected low access device CVE's may not
> > matter at all.
> >
> > For OS sources I think I would either grab from svn the version
> > at releng/8.x that matches what you decided on, or a point
> > on stable/8 slightly after this.  My reasoning here is that you
> > would be able to pull in specific changes from later in the
> > life of stable/8 that you may need fairly easily, ie svn merge.
> >
> >
> > > IIUC you seem to be looking for an _easy_ way to get Kirkwood back up
> > > and working.  I'm going to be honest and say there isn't one.
> >
> > I Concur.
> >
> > > Here are the approaches I think you can take:
> > All very reasonable too.
> >
> > >
> > >  - stay on 8.x; bring individual port updates to it from ports-head and
> > >    build your own ports.  Difficulty: hard.
> > >
> > >  - figure out what src changes after 8.x regressed Kirkwood; check
> > >    out src 12-STABLE, build your own src, and use FreeBSD.org packages.
> > >    Difficulty: expert.
> > >
> > >  - stay on 8.x; attempt to bring a modern ports tree to it and build
> > >    your own ports.  Difficulty: challenging.
> > >
> > > The difficulty level of the first approach depends on which ports you
> > > are going to try to use.  shells/bash?  Probably not too hard.  Anything
> > > GUI-related?  Very hard.
> > >
> > > None of these approaches are achievable within hours; they will take
> > > days, or, in the case of the third approach, weeks.
> > >
> > > fwiw, the second approach is the only one where your fixes could be
> > > merged back into FreeBSD.  If I were personally determined to run
> > > Kirkwoord, that's the approach I would take.  (I gave my GuruPlug
> > > away some time ago.)
> > >
> > > I'm sorry that I can't be more encouraging.
> > >
> > > mcl
> >
> > --
> > Rod Grimes
> > rgrimes@freebsd.org
> >

-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904231928.x3NJSi7D039312>