[UPDATE] Re: Update on ports on 10.0

[Ion-Mihai Tetcu]

On Mon, 17 Oct 2011 23:52:54 +0000
"Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net> wrote:

> On 17. Oct 2011, at 20:51 , Stanislav Sedov wrote:
> 
> Hi,
> 
> I shrinked that Cc: list dramatically.

Thanks; I Cc'ed all maintainers of those high-profile ports.

As a new update, we're now running an other -exp with jpeg fixed.

> > On Mon, 17 Oct 2011 15:35:51 +0300
> > Ion-Mihai Tetcu <itetcu at FreeBSD.org> mentioned:
> > 
> >> 
> >> Here's a little status update:
> >> We iterated through a few -exp runs (basically for ports/161404 --
> >> committed and ports/161431 -- skv@ any problem with it?). With
> >> those two we can build around 7k packages. The majority of the
> >> rest can't be built because of a few high profile ports that don't
> >> package: expat (6581), curl (975), jpeg(5057), lcms(1080),
> >> libiconv(11180), libltdl(1187), libogg(1947), pcre(5737),
> >> python27(5935).
> >> 
> >> http://pointyhat.freebsd.org/errorlogs/i386-10-latest/
> >> 
> >> What we'd like to do next is see how many ports we can package
> >> after individually fixing those above. This will require a few
> >> other -exps since undoubtedly we'll find other highly-depended-on
> >> ports broken that weren't tried because of the blockers above.
> >> 
> > 
> > It doesn't require an exp-run to understand that you won't move
> > much further with just fixinng these ports.
> 
> Well, there was a significant update from ~2800 to ~7000 ports by
> just fixing 2 or 3?  I think understanding these and handling them in
> a well defined manner is a good idea.

And we need to know which are broken and which aren't.

> > patching similar to the patch Ed, Doug and other people proposed.
> > Actually, that sed one-liner fixed like 99% of the ports in tree,

Did you do a full run with the patch? Can you provide the list of ports
that aren't fixed by the patch and the exact patch you used? Thanks.

> > excluding some complex ones (like GCC).  So why not commit that
> > patch as a KNOB to bsd.port.mk like it was initially proposed and
> > let people use it in individual ports makefiles to fix them (and
> > portmgr@ can commit the initial bunch of these knobs)? This is the
> > easiest thing you can do now, and you will be able to abandon it
> > when the better solution is available (which is unlikely).
> 
> I think that's what he was saying as a possible next step.  If they
> have the cycles currently while waiting for RC1 to happen let them do
> it; we are talking in having things within a month not in spring next
> year already.
> 
> I would assume that the aforementioned patch might go into the
> framework, would only be applied if a) OSVERSION>=10... and b) the
> port has a knob that says "I need this to run".

Yes.

> > WRT your "submit upstream" comment, personanlly, I'd argue against
> > this:
> 
> We damn need it;  they need to regen the stuff; it's going to take
> months if not years to get 80% to that point and a couple of projects
> might be dead and we might want to use a local patch then but the
> sed-KNOB is a bandaid that must die again.
> 
> I would argue that no port must add the KNOB (once it would exist,
> should it) without having notified upstream.  And you might know a
> lot better than I do but ideally there would be a new official
> libtool release before that and ideally the libtool people would have
> by now fixed all the !FreeBSD similar cases...

Hopefully so.


-- 
IOnut - Un^d^dregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"
FreeBSD committer -> itetcu at FreeBSD.org, PGP Key ID 057E9F8B493A297B