Re: Heads up: poppler won't build
On Feb 25, 2019, at 00:41, Mojca Miklavec wrote: > This message tells you what precisely to do to work around the issue: >sudo port -f dectivate poppler >sudo port install poppler > > We usually do something like deactivate hack >https://trac.macports.org/wiki/PortfileRecipes#deactivatehack > but I don't know why it wasn't done this way (maybe it doesn't work, > maybe there were other reasons ...). As explained on the wiki page, we typically use the deactivate hack when a port now provides files that one of its dependents previously provided. Not doing so would result in activation failure, and we want to prevent users from experiencing that. That's not what's happening with poppler. Poppler has a build conflict with another port (coincidentally: with older versions of itself). In those cases, we don't use the deactivate hack; instead we notify the user of the problem by using the conflicts_build portgroup. The user can then take charge of deactivating the conflicting port before the build and reactivating it afterward. Or the user might choose to postpone the upgrade, if they happen to know that they need the conflicting port to remain active for the time being. Maybe the conflicting port is (or is required by) a server process that they want to keep running, or a utility that the user is using in a script. One could argue that we should handle both situations the same way. But the reason we handle them differently might be as follows: The deactivate hack is used when two related ports have reorganized which one of them provides which files. For example, netpbm used to provide a bunch of libraries, but I moved them to a separate libnetpbm subport, therefore I had to use the deactivate hack in libnetpbm to deactivate any already installed older copy of netpbm. One could argue that doing so makes netpbm temporarily unavailable to the user. But the most likely way for the user to encounter this situation is for them to upgrade netpbm, and if the user has consented to that, then they already expect the netpbm programs to be unavailable for a short time. In contrast, build conflicts are typically declared between unrelated ports. A user upgrading a port would most likely not expect an unrelated port to be automatically deactivated, even temporarily.
Re: Heads up: poppler won't build
On Feb 24, 2019, at 17:55, Dave Horsfall wrote: > Hmmm... Proceed regardless: > >ozzie:~ dave$ sudo port -p upgrade outdated >Nothing to upgrade. > > (Yes, I'm in the habit of using "-p" to get past broken ports.) Please do not habitually (or ideally ever) use "-p" when installing or upgrading. It will cause problems. Suppose that you have installed a port PROG that depends on a library LIB. Suppose we upgrade LIB to a new version, and that this requires PROG to be rebuilt, so we also increase the revision of PROG. You've selfupdated and received these changes, and then you run "sudo port -p upgrade PROG", which causes LIB to be upgraded first, since it is a dependency. Suppose that for whatever reason, LIB fails to build on your system. Because you used the "-p" flag, MacPorts proceeds past this failure and rebuilds PROG anyway. If MacPorts is able to get a binary of PROG from our build server, that binary will be linked with the new version of LIB, which you don't have, so PROG will be broken. If you don't get a binary, it will build on your system, linking with the old version of LIB that you already had installed, despite the fact that the only reason for the rebuild was to link with the new version of LIB. So it will look to you as if PROG built successfully, but in fact what you built was not what we intended for you to get. Worse, when whatever problem prevented LIB from building on your system is fixed and you are able to upgrade it, you will have a broken PROG because it was linked with the old LIB. We should probably modify MacPorts base to prevent using the "-p" flag for the install or upgrade actions.
Re: Heads up: poppler won't build
On Feb 24, 2019, at 19:24, Bill Cole wrote: > On 24 Feb 2019, at 18:55, Dave Horsfall wrote: > >> Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. >> >> Doing my regular Monday "port upgrade outdated", and... >> >>---> Computing dependencies for poppler >>---> Configuring poppler >>Error: poppler cannot be built while another version of poppler is active. >>Error: Please forcibly deactivate the existing copy of poppler, e.g. by >> running: >>Error: >>Error: sudo port -f deactivate poppler >>Error: >>Error: Then try again. >>Error: Failed to configure poppler: poppler is active >> So, >> >>ozzie:~ dave$ sudo port -f deactivate poppler >>---> Unable to deactivate poppler @0.72.0_0, the following ports depend >> on it: >>---> gimp2 @2.10.8_3+python27 >>Warning: Deactivate forced. Proceeding despite dependencies. >>---> Deactivating poppler @0.72.0_0 >>---> Cleaning poppler >> >> Hmmm... Proceed regardless: >> >>ozzie:~ dave$ sudo port -p upgrade outdated >>Nothing to upgrade. > > Because after you deactivate a port, an "upgrade" isn't possible. That's not true, however a port is not considered outdated unless it is active. You can still upgrade it by explicitly naming it: sudo port upgrade poppler
Re: Heads up: poppler won't build
Mojca Miklavec writes:
> Dear Dave,
>
> On Mon, 25 Feb 2019 at 00:55, Dave Horsfall wrote:
>>
>> Sierra 10.12.6 + latest security updates, MacPorts 2.5.4.
>>
>> Doing my regular Monday "port upgrade outdated", and...
>>
>> ---> Computing dependencies for poppler
>> ---> Configuring poppler
>> Error: poppler cannot be built while another version of poppler is
>> active.
>> Error: Please forcibly deactivate the existing copy of poppler, e.g. by
>> running:
>> Error:
>> Error: sudo port -f deactivate poppler
>> Error:
>> Error: Then try again.
>> Error: Failed to configure poppler: poppler is active
>
> Yes, I would count it as a bug. Primarily as a bug in poppler build
> system, but as a consequence also a bug on our side. I don't know what
> precisely happened, but I assume that poppler picks its own installed
> headers from the previous version from $prefix and then fails to
> build.
There is an explicit test in the poppler Portfile. It seems this was necessary
for some older version.
if {${subport} ne ${name}} {
...
} else {
# generation of Poppler-0.18.gir fails if previous version of poppler is
active
# appropriate for main poppler port only
conflicts_build ${name}
}
--
Piet van Oostrum
WWW: http://piet.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
Re: Heads up: poppler won't build
Dear Dave, On Mon, 25 Feb 2019 at 00:55, Dave Horsfall wrote: > > Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. > > Doing my regular Monday "port upgrade outdated", and... > > ---> Computing dependencies for poppler > ---> Configuring poppler > Error: poppler cannot be built while another version of poppler is > active. > Error: Please forcibly deactivate the existing copy of poppler, e.g. by > running: > Error: > Error: sudo port -f deactivate poppler > Error: > Error: Then try again. > Error: Failed to configure poppler: poppler is active Yes, I would count it as a bug. Primarily as a bug in poppler build system, but as a consequence also a bug on our side. I don't know what precisely happened, but I assume that poppler picks its own installed headers from the previous version from $prefix and then fails to build. This message tells you what precisely to do to work around the issue: sudo port -f dectivate poppler sudo port install poppler We usually do something like deactivate hack https://trac.macports.org/wiki/PortfileRecipes#deactivatehack but I don't know why it wasn't done this way (maybe it doesn't work, maybe there were other reasons ...). By far the best way would be to fix the poppler build system. I believe that using the correct order of include flags should work to find the local version of header files first. > Note that I do not file bug reports unless I am 100% sure that it is > indeed a bug, and not my own silly fault; I've had this policy for 40+ > years. > > So, > > ozzie:~ dave$ sudo port -f deactivate poppler > ---> Unable to deactivate poppler @0.72.0_0, the following ports depend > on it: > ---> gimp2 @2.10.8_3+python27 > Warning: Deactivate forced. Proceeding despite dependencies. > ---> Deactivating poppler @0.72.0_0 > ---> Cleaning poppler This is expected. You probably wouldn't have poppler installed if it wasn't for another piece of software that pulled it in. The force deactivate was there precisely for that reason: you would temporarily leave some port broken until you reinstall that package. > Hmmm... Proceed regardless: > > ozzie:~ dave$ sudo port -p upgrade outdated > Nothing to upgrade. > > (Yes, I'm in the habit of using "-p" to get past broken ports.) > > Well, I don't (yet) use GIMP, and I have no idea what "poppler" is, so I > guess I can live with it. Just run "sudo port install poppler". (That's not a question for you, but doesn't gimp need to be rebuilt after poppler update?) Mojca
Re: Heads up: poppler won't build
On 24 Feb 2019, at 18:55, Dave Horsfall wrote: Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. Doing my regular Monday "port upgrade outdated", and... ---> Computing dependencies for poppler ---> Configuring poppler Error: poppler cannot be built while another version of poppler is active. Error: Please forcibly deactivate the existing copy of poppler, e.g. by running: Error: Error: sudo port -f deactivate poppler Error: Error: Then try again. Error: Failed to configure poppler: poppler is active That's a bug. It's a bug the port maintainer is apparently aware of and has chosen to not fix, but it is still a bug. Note that I do not file bug reports unless I am 100% sure that it is indeed a bug, and not my own silly fault; I've had this policy for 40+ years. So, ozzie:~ dave$ sudo port -f deactivate poppler ---> Unable to deactivate poppler @0.72.0_0, the following ports depend on it: ---> gimp2 @2.10.8_3+python27 Warning: Deactivate forced. Proceeding despite dependencies. ---> Deactivating poppler @0.72.0_0 ---> Cleaning poppler Hmmm... Proceed regardless: ozzie:~ dave$ sudo port -p upgrade outdated Nothing to upgrade. Because after you deactivate a port, an "upgrade" isn't possible. If you want it, you need to 'install' it. That's why this is a bug: it breaks a normal maintenance workflow. (Yes, I'm in the habit of using "-p" to get past broken ports.) Well, I don't (yet) use GIMP, and I have no idea what "poppler" is, so I guess I can live with it. This is a mystifying sentence. Why would you have installed GIMP if you weren't going to use it? (Also: poppler is a PDF rendering library.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Re: Heads up: poppler won't build
What does port rdependents poppler give you? > On Feb 24, 2019, at 6:55 PM, Dave Horsfall wrote: > > Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. > > Doing my regular Monday "port upgrade outdated", and... > >---> Computing dependencies for poppler >---> Configuring poppler >Error: poppler cannot be built while another version of poppler is active. >Error: Please forcibly deactivate the existing copy of poppler, e.g. by > running: >Error: >Error: sudo port -f deactivate poppler >Error: >Error: Then try again. >Error: Failed to configure poppler: poppler is active > > Note that I do not file bug reports unless I am 100% sure that it is indeed a > bug, and not my own silly fault; I've had this policy for 40+ years. > > So, > >ozzie:~ dave$ sudo port -f deactivate poppler >---> Unable to deactivate poppler @0.72.0_0, the following ports depend > on it: >---> gimp2 @2.10.8_3+python27 >Warning: Deactivate forced. Proceeding despite dependencies. >---> Deactivating poppler @0.72.0_0 >---> Cleaning poppler > > Hmmm... Proceed regardless: > >ozzie:~ dave$ sudo port -p upgrade outdated >Nothing to upgrade. > > (Yes, I'm in the habit of using "-p" to get past broken ports.) > > Well, I don't (yet) use GIMP, and I have no idea what "poppler" is, so I > guess I can live with it. > > -- Dave
Heads up: poppler won't build
Sierra 10.12.6 + latest security updates, MacPorts 2.5.4. Doing my regular Monday "port upgrade outdated", and... ---> Computing dependencies for poppler ---> Configuring poppler Error: poppler cannot be built while another version of poppler is active. Error: Please forcibly deactivate the existing copy of poppler, e.g. by running: Error: Error: sudo port -f deactivate poppler Error: Error: Then try again. Error: Failed to configure poppler: poppler is active Note that I do not file bug reports unless I am 100% sure that it is indeed a bug, and not my own silly fault; I've had this policy for 40+ years. So, ozzie:~ dave$ sudo port -f deactivate poppler ---> Unable to deactivate poppler @0.72.0_0, the following ports depend on it: ---> gimp2 @2.10.8_3+python27 Warning: Deactivate forced. Proceeding despite dependencies. ---> Deactivating poppler @0.72.0_0 ---> Cleaning poppler Hmmm... Proceed regardless: ozzie:~ dave$ sudo port -p upgrade outdated Nothing to upgrade. (Yes, I'm in the habit of using "-p" to get past broken ports.) Well, I don't (yet) use GIMP, and I have no idea what "poppler" is, so I guess I can live with it. -- Dave
