search

DragonFlyBSD / DPorts

The dedicated application build system for DragonFly BSD
Other
91 stars 43 forks source link

Applications using PDF format cannot print anymore #44

Closed ftigeot closed 11 years ago

ftigeot commented 11 years ago

Some applications such as Firefox and LibreOffice send PDF data to printers.

After the last update of print/cups-base, they are now unable to print.

This error is present in /var/log/cups/error_log: E [20/May/2013:22:44:08 +0200] Filter "pdftops" not found.

ftigeot commented 11 years ago

Removing the line CUPS_PDFTOPS?= ${LOCALBASE}/libexec/xpdf/pdftops from print/cups-base/Makefile is fixes the issue.

jrmarino commented 11 years ago

okay, feel free to remove that line. Otherwise I'll do it myself this weekend, thanks.

ftigeot commented 11 years ago

Fix committed to Deltaports.

jrmarino commented 11 years ago

There are two problems with that commit. 1) genpatch wasn't used to generate the patch. All patches need to be generated by genpatch (or portfix). Remember that I built this utility, and it's in ports-mgmt? 2) The amd64 was committed as x86_64. That's because the patch was generated from dports makefile and not ports makefile (the amd64 are sed changed to x86_64, but it happens after patching). You can see these extra commit lines when you review the commit..

ftigeot commented 11 years ago

1) I thought genpatch was to be used only for patching third-party software and not for deltaports itself. 2) I had no idea a particular patching order was to be followed. Can we not make amd64 the default port architecture instead and avoid all this patching ?

jrmarino commented 11 years ago

no, it's not feasible to use amd64. The 3rd party software knows dragonfly platform is x86_64 In this case, the patch was added when it's not necessary, it's not extra. Thirdly: patching makefile should be rare. We need to avoiding if at all possible. For this port, it's not possible.

jrmarino commented 11 years ago

regenerated