Bug 228091 - textproc/gtkspell3 has wrong iso-codes prefix
Summary: textproc/gtkspell3 has wrong iso-codes prefix
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-gnome (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-09 10:37 UTC by Yuichiro NAITO
Modified: 2018-10-07 20:12 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuichiro NAITO 2018-05-09 10:37:02 UTC
We can see package build log in
http://gohan4.ysv.freebsd.org/data/11stable-amd64-quarterly-baseline/469160/logs/gtkspell3-3.0.8.log

In this log, iso-codes prefix is configured to /usr but it should be /usr/local.

```
configure: iso-codes prefix: /usr
``

So, my evolution (gnome3 application) warns as follows.

```
** (evolution:1376): WARNING **: iso_639.xml: Failed to open file '/usr/share/xml/iso-codes/iso_639.xml': open() failed: No such file or directory

** (evolution:1376): WARNING **: iso_3166.xml: Failed to open file '/usr/share/xml/iso-codes/iso_3166.xml': open() failed: No such file or directory
```

Workaround is to build gtkspell3 from ports tree.
I think gtkspell3 should have iso-codes in dependencies.
Comment 1 commit-hook freebsd_committer freebsd_triage 2018-10-07 20:02:22 UTC
A commit references this bug:

Author: kwm
Date: Sun Oct  7 20:01:47 UTC 2018
New revision: 481482
URL: https://svnweb.freebsd.org/changeset/ports/481482

Log:
  Update gtkspell3 to 3.0.10.

  * add license
  * pet portlint
  * Make sure iso-codes is available during package build so the package gets
    configured correctly. [1]

  PR:		228091 [1]
  Reported by:	Yuichiro NAITO <naito.yuichiro@gmail.com> [1]

Changes:
  head/textproc/gtkspell3/Makefile
  head/textproc/gtkspell3/distinfo
Comment 2 Koop Mast freebsd_committer freebsd_triage 2018-10-07 20:12:28 UTC
This problem should be fixed now, thanks for reporting!