Date: Mon, 17 Sep 2018 20:11:13 +0200 From: "Tobias C. Berner" <tcberner@freebsd.org> To: Matthias Andree <mandree@freebsd.org> Cc: amdmi3@freebsd.org, danilo@freebsd.org, gnome@freebsd.org, grog@freebsd.org, h2+fbsdports@fsfe.org, jamesb-bsd@excamera.com, "kde@FreeBSD.org" <kde@freebsd.org>, multimedia@freebsd.org, rm@freebsd.org, Thierry Thomas <thierry@freebsd.org>, Ben Woods <woodsb02@freebsd.org>, Yuri Victorovich <yuri@freebsd.org>, portmgr <portmgr@freebsd.org>, Alexey Dokuchaev <danfe@freebsd.org>, olivier@freebsd.org, ehaupt@freebsd.org, dumbbell@freebsd.org, FreeBSD@shaneware.biz Subject: Re: HEADS UP: [msg #2] graphics/ilmbase and graphics/OpenEXR update planned includes openexr rename - feedback required until Sept 23/portmgr Sept 21 Message-ID: <CAOshKteROyxXnRVnM0YM7%2B7ZKxYJRi37f7YZq86ye7ihqB65uw@mail.gmail.com> In-Reply-To: <33ae9410-0161-84d0-f742-6d75989bb283@FreeBSD.org> References: <8745aabb-b6d8-b8b6-2745-78818c6d5594@FreeBSD.org> <92cd8d96-d129-5612-7246-7753800143e5@FreeBSD.org> <CAOshKtckvKgr-VafjBr0fx2rhHkW7bDQCncYjfZ4bbV55keskQ@mail.gmail.com> <33ae9410-0161-84d0-f742-6d75989bb283@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Looks good for me with the kde@ hat on -- I think an exp-run wouldn't hurt. But feel free to touch the required kde@ ports ad done in the diff. mfg Tobias On Mon, 17 Sep 2018 at 19:30, Matthias Andree <mandree@freebsd.org> wrote: > Am 17.09.18 um 18:39 schrieb Tobias C. Berner: > > Moin moin > > > > Do you have a list of the kde@ ports broken by the update? Or is this a > > compile everything, then fix it call? > > Moin Tobias, > > Thanks for picking up the thread for kde@. > > This list you are asking about is empty, but you never know what happens > with sweeping changes in the field after the fact, that's why I am > pushing forward. We don't want a high-profile port diverging between > quarterly and head, and we don't want to duplicate fix efforts right > after the branch. > > I have compile-tested all ports in poudriere 11.2-RELEASE amd64 that > have a direct dependency on ilmbase or OpenEXR listed that is either > mandatory, or an option that defaults to "ON". > > The only casualty is the unmaintained (upstream and ports) > graphics/ampasCTL (see below why) and none of the *kde* or *qt* ports > have broken or killed ports that require them. I may take one or two > more stabs at ampasCTL to see if it turns out to be low-hanging fruit. > > > My call is "check if you have any concerns about my proposed update to > ilmbase/OpenEXR and the OpenEXR -> openexr rename". > The proposed update is the one I provide as patch, not the earlier shar > file. > > If you are keeping an outside private KDE repository, you may have to > merge my patch into your private kde@ repository once I commit, and test > your own ports that depend on ilmbase/openexr before you commit your > tree back to the FreeBSD ports repository. > > > NOTE: I think I do not formally need to ask approval about PORTREVISION > bumps and bumps to requisite library changes, we do not normally do that. > > I do want to coordinate nonetheless, and I'll happily receive approvals. > > I just can't afford to spend hours on end to chase down everybody behind > mail exploders. I believe I've done a thorough job of testing the > builds and direct dependents, and if someone wants to do a full -exp > run, use the patch from my previous message, URIs repeated below for > convenience: > > - https://people.freebsd.org/~mandree/openexr-v2.patch > - https://people.freebsd.org/~mandree/openexr-v2.patch.asc (GnuPG sign.) > > > Note that OpenEXR is not formally advertised as incompatible, what I > found out so far is: > > * "Iex::BaseExc no longer derived from std::string." is what appears to > have broken ampasCTL > <https://github.com/openexr/openexr/releases/tag/v2.3.0>; because it > can't seem to std::cout << ... those data types any more and I get a > truckload of excuses why none of the candidates is viable for automatic > type conversion. Haven't yet dug deeper, but I don't consider an > unmaintained (upstream & downstream) leaf port as sitting in the > critical path anyways, we can fix it after the fact (and the fix could > also be MFHd from head to quarterly without ado since it's unbreaking a > broken port, hence pre-approved). > > Cheers, > Matthias >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOshKteROyxXnRVnM0YM7%2B7ZKxYJRi37f7YZq86ye7ihqB65uw>