Re: set_rcvar() function use?

[Hiroki Sato]

Mateusz Piotrowski <0...@freebsd.org> wrote
  in <34921b6e-ce3a-13e4-0cc1-3ca47b5a9...@freebsd.org>:

0m> >  I am planning to revisit the multi-instance support shortly because I
0m> >  am using it for a long time and I think it is useful.  While I did
0m> >  not receive a strong objection to it so far, it is also true that
0m> >  adopting the set_rcvar() style was not discussed properly.  I would
0m> >  like more feedback before moving forward.
0m>
0m> AFAIR, manu@ was concerned at some point that using set_rcvar() extensively
0m> might result in slowdowns on embedded systems.

 A discussion in the past about the performance was an additional
 fork(2) when using set_rcvar() for rc_var=`set_rcvar`.  The use case
 of the resurrected one is "set_rcvar A B" as a replacement of "A=B",
 and it does not involve a subshell.

 I agree that the performance perspective should also be discussed,
 though.  The current rc.subr and network.subr already have more
 expensive operations, so we might want to gather profiling
 information.

-- Hiroki


pgpQtgSa7o0tQ.pgp
Description: PGP signature

Re: set_rcvar() function use?

[Hiroki Sato]

Pavel Timofeev  wrote
  in :

ti> Hello, dear community. I'm confused, please, help me.
ti>
ti> There is a rc.subr function which was buried[1] and resurrected[2] after a
ti> couple of years in almost the same form.
ti>
ti> I don't know what happened behind the scenes, but I have a question.
ti> Is it a preferable way to define a rc.conf variable these days in rc
ti> scripts (again/over and over)?

 I resurrected it because I wanted to change the standard style to use
 set_rcvar() to declare the user-configurable variables, their default
 values, and descriptions without losing backward compatibility.
 There is no clear consensus on this migration, however.

 The primary motivation was to add multi-instance support in rc
 scrupts[1].  To support this, the set_rcvar() style was required.

 [1] 
https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052706.html

 Another issue I am aware of is that rc scripts installed by ports/pkg
 that they cannot have related entries in /etc/defaults/rc.conf for
 the default values.  So a lot of ports tend to end up with
 assignments in the rc scripts like this:

 : ${foo_enable=YES}

 This introduces inconsistency and it is difficult to find
 documentation about which knobs are available.  The set_rcvar() style
 should mitigate this and also implements a support to obsolete a
 variable when needed.  set_rcvar_obsolete() will convert the old
 value to the new variable automatically or emit an error if there is
 no compatibility between the old and the new.

 I committed set_rcvar() part only in [1], not whole of the
 multi-instance support.  This is because it was quite difficult to
 control which version of rc.subr is installed.  If rc scipts in ports
 use set_rcvar() on older versions of FreeBSD which do not support it,
 the port breaks.  At this moment all of the supported FreeBSD
 versions have the resurrected set_rcvar(), so I think it is now safe
 to use it globally.  Probably we might want to add a version number
 or feature flags in rc.subr to prevent this kind of situation.

 I am planning to revisit the multi-instance support shortly because I
 am using it for a long time and I think it is useful.  While I did
 not receive a strong objection to it so far, it is also true that
 adopting the set_rcvar() style was not discussed properly.  I would
 like more feedback before moving forward.

-- Hiroki


pgpGu8YqCnq10.pgp
Description: PGP signature

Re: FreeBSD Port: ja-fcitx-mozc-2.23.2815.102.00_6

[Hiroki Sato]

Anton Wang  wrote
  in
 
:

un> The mozc IME indicator icon not show in fcitx ,why? i use xfce desktop

 It seems the current ja-fcitx-mozc is broken.  Can you manually fix
 the line "IconName=.." in
 /usr/local/share/fcitx/inputmethod/mozc.conf like the following:

  IconName=/usr/local/share/fcitx/mozc/icon/mozc.png

 and let me know if the icon image will appear or not?

-- Hiroki



pgp0w8LCrO8bN.pgp
Description: PGP signature

Re: loose dependency

[Hiroki Sato]

Koichiro Iwao  wrote
  in <20190315013227.cspgdqyw7gzua...@icepick.vmeta.jp>:

me> On Thu, Mar 14, 2019 at 06:50:43PM +0100, Tijl Coosemans wrote:
me> > You mean building from ports versus poudriere?  Poudriere would always
me> > select ImageMagick6 with the BUILD_DEPENDS line above, but that's fine.
me> > 
me> > Options aren't a good interface for this because the user can select an
me> > option that conflicts with the installed version.  It's not really a
me> > port option but a system-wide option.  If this needs to be configurable
me> > for poudriere then an entry should be added to bsd.default-versions.mk.
me> > Then the BUILD_DEPENDS line above can become:
me> > 
me> > BUILD_DEPENDS=convert:graphics/ImageMagick${IMAGEMAGICK_DEFAULT}
me> 
me> I'm still not sure whether OPTIONS for IM[67] are needed. tijl@ and
me> adamw@ say different thing but the below works fine for me in both ports
me> and pkg schenario. Even if IM6 installed, no problem for me.
me> 
me> BUILD_DEPENDS=  convert:graphics/ImageMagick7

 If I understand correctly, adamw@'s suggestion is like the
 following (please correct me if I am wrong):

OPTIONS_SINGLE= IMAGEMAGICK
OPTIONS_SINGLE_IMAGEMAGICK= IM6 IM7
OPTIONS_DEFAULT=IM7
IM6_BUILD_DEPENDS=  convert:graphics/ImageMagick6
IM6_DESC= Use ImageMagick6
IM7_BUILD_DEPENDS=  convert:graphics/ImageMagick7
IM7_DESC= Use ImageMagick7

 I tend to agree with tijl@ about this, however.  As he stated, these
 options do not guarantee availability of the specified version and
 make the user confusing since IM7 may not be installed when IM6 is
 already installed, for example.  Just putting BUILD_DEPENDS line with
 a default version you want works in the same way.

 In the case of runtime dependency such as LIB_DEPENDS or RUN_DEPENDS,
 using OPTIONS and/or FLAVORS are a good idea in general, of course.

-- Hiroki


pgp0nYu2DUoFK.pgp
Description: PGP signature

Re: loose dependency

[Hiroki Sato]

Koichiro Iwao  wrote
  in <20190314061242.ixvtakqiel4aa...@icepick.vmeta.jp>:

me> On Thu, Mar 14, 2019 at 01:40:14PM +0900, Hiroki Sato wrote:
me> >  There is no easy solution to solve it completely because currently
me> >  package dependency is solved in a strict manner including package
me> >  names and version numbers, not only existence of specific files.
me> >  Creating multiple ports which depend on each software or using
me> >  FLAVORS to make it easier is a way to provide packages with every
me> >  possible combinations of dependency and let one to choose.
me>
me> Specifically talking, net/tigervnc is the case. Actually, the dependency
me> is build dependency not runtime. ImageMagick is used to create multiple
me> sizes of icons such as 24x24, 32x32, 48x48 during the build. Whichever
me> versions of ImageMagick in the current ports tree can be used for the
me> purpose. Once the port is built, ImageMagick is not required at all and
me> can be uninstalled if no other packages depends on it.

 In this case BUILD_DEPENDS with bin/convert just works.  It does not
 record package-level dependency and it does not matter that where
 bin/convert came from while you have to put a specific version of
 ImageMagick on the BUILD_DEPENDS line.  An installed bin/convert will
 used if it exists already, and the specified version will be
 installed if not.

 One problem is that "a specific version" on the BUILD_DEPENDS line
 can be different from other ports.  In that case, which version will
 be installed during the build can depend on the order of builds
 including other ports.  We define Mk/bsd.default-versions.mk to make
 it consistent especially for runtime dependency.  It should work for
 build-time dependency though I am not sure if it is worth doing.

-- Hiroki


pgpXkiIzmypJ8.pgp
Description: PGP signature

Re: loose dependency

[Hiroki Sato]

Koichiro Iwao  wrote
  in <20190314062217.3wx3h2hp74mo3...@icepick.vmeta.jp>:

me> On Thu, Mar 14, 2019 at 03:12:43PM +0900, Koichiro Iwao wrote:
me> > On Thu, Mar 14, 2019 at 01:40:14PM +0900, Hiroki Sato wrote:
me> > >  There is no easy solution to solve it completely because currently
me> > >  package dependency is solved in a strict manner including package
me> > >  names and version numbers, not only existence of specific files.
me> > >  Creating multiple ports which depend on each software or using
me> > >  FLAVORS to make it easier is a way to provide packages with every
me> > >  possible combinations of dependency and let one to choose.
me> >
me> > Specifically talking, net/tigervnc is the case. Actually, the dependency
me> > is build dependency not runtime. ImageMagick is used to create multiple
me> > sizes of icons such as 24x24, 32x32, 48x48 during the build. Whichever
me> > versions of ImageMagick in the current ports tree can be used for the
me> > purpose. Once the port is built, ImageMagick is not required at all and
me> > can be uninstalled if no other packages depends on it.
me> >
me> > I think FLAVORS does not fit such case. Creating
me> > net/tigervnc@ImageMagick[67] sounds me stupid. But If I specify IM6,
me> > IM7 users cannot build net/tigervnc due to ImageMagick conflict and
me> > vise cersa.
me> >
me> > I'm stuck :(
me>
me> BTW, what about this idea?
me>
me> I prepare pre-converted icons and put it to public_distfiles. The port
me> fetches it as EXTRA_DIST.  It still sounds me a little bit stupid but
me> I can remove the dependency on ImageMagick from the port...

 That is a workaround while increasing maintenance cost.  It is at the
 maintainer's discretion.

-- Hiroki


pgpLBixZ6_1yO.pgp
Description: PGP signature

Re: loose dependency

[Hiroki Sato]

Koichiro Iwao  wrote
  in <20190314031726.aaspgwdcuithh...@icepick.vmeta.jp>:

me> Hi,
me>
me> If a port have runtime dependency on bin/convert command of ImageMagick
me> but whichever ImageMagick{6,7}{,-nox11} are OK, how port Makefile should
me> be written?
me>
me> ImageMagick6 and 7 conflicts each other. I want to respect user's
me> choice which ImageMagick to use.

 There is no easy solution to solve it completely because currently
 package dependency is solved in a strict manner including package
 names and version numbers, not only existence of specific files.
 Creating multiple ports which depend on each software or using
 FLAVORS to make it easier is a way to provide packages with every
 possible combinations of dependency and let one to choose.

-- Hiroki


pgp4W2rJhTP6u.pgp
Description: PGP signature

Re: Dropping maintainership for pydio / softether / wmconfig

[Hiroki Sato]

Hi,

Koichiro IWAO  wrote
  in 
<01010161bc060e73-5e01b825-b1eb-4f4a-a112-b280ae670da7-000...@us-west-2.amazonses.com>:

me>
me> I'll take the maintainership if nobody wants however
me> I think security/softether and security/softether-devel
me> should be maintained by the same maintainer.
me>
me> Sato-san, would you like to maintain net/softether as well?

 Yes, my time for FreeBSD is quite limited until AsiaBSDCon but I am
 considering to merge the two ports into one at least.  Please send me
 a patch if you have.

-- Hiroki


pgp7fJGYHjdVq.pgp
Description: PGP signature

Re: Are these Emacs ports still useful?

[Hiroki Sato]

Joseph Mingrone  wrote
  in <86d135nne8@phe.ftfl.ca>:

jr> A quick scan suggests that these port may have passed their usefulness.
jr> Could you speak up if they are still useful or if you feel they should
jr> be removed?

jr>  - editors/psgml (use psgml-1.3.4.tar from 
http://elpa.gnu.org/packages/psgml.html ?)
jr>  - print/yatex (version almost 5 years old, newer release available)

 I will take a look into them.  These are not obsolete.

-- Hiroki


pgpD4EyOhMcLP.pgp
Description: PGP signature

Re: No reaction - what can I do?

[Hiroki Sato]

Kurt Jaeger  wrote
  in <20170206111716.gj13...@home.opsec.eu>:

li> Hi!
li>
li> > jh> > I have opened the PR 214665 on 19.11.2016. No reaction of the 
maintainer
li> > jh> > until today. He also does not react to e-mails. What else can I do?
li> [...]
li> >  I am aware of this PR but I am still not sure of the cause since I
li> >  could not reproduce it.
li>
li> In this case, please write a note into the PR that you can
li> not reproduce it. It helps the submitter to understand the situation.

 Okay, I will do it more actively.  Honestly I was leaning to working
 on upgrading TeXLive-related ports to the latest version instead of
 fixing issues which I could not reproduce but it has taken a longer
 time than I expected...

-- Hiroki


pgpz4zXyzgIti.pgp
Description: PGP signature

Re: No reaction - what can I do?

[Hiroki Sato]

"Julian H. Stacey"  wrote
  in <201702060901.v1691t6v084...@fire.js.berklix.net>:

jh> Hi, Reference:
jh> > From: Jochen Neumeister 
jh> > Date: Mon, 6 Feb 2017 09:27:52 +0100
jh>
jh> Jochen Neumeister wrote:
jh> > Hello everybody,
jh> >
jh> > I have opened the PR 214665 on 19.11.2016. No reaction of the maintainer
jh> > until today. He also does not react to e-mails. What else can I do?
jh> >
jh> > Is it normal that maintainers / committer will not respond?
jh> >
jh> > Best regards
jh> > Jochen
jh>
jh> https://www.freebsd.org/portmgr/policies_contributors.html
jh>   "The time limit for a maintainer to respond to a PR is two weeks.
jh>   After that period, ."
jh>
jh>   "A maintainer who does not respond to any port issues for 3 months
jh>   may be reset by any ports committer." ... 13 days from now.
jh>
jh> https://www.freebsd.org/portmgr/
jh> I added CC port...@freebsd.org
jh>
jh> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214665
jh> I added CC h...@freebsd.org in case of some mail filter blockage.

 I am aware of this PR but I am still not sure of the cause since I
 could not reproduce it.  Does defining USE_LOCALE fix it on your
 environment as Kurt described in the PR?

-- Hiroki


pgpai28Q5nIhe.pgp
Description: PGP signature

Re: libwraster

[Hiroki Sato]

jbe...@freebsd.org (Jan Beich) wrote
  in <20170101195127.6c0cb3...@freefall.freebsd.org>:

jb> Hiroki Sato <h...@freebsd.org> writes:
jb>
jb> >  I did not able to reproduce it even if ImageMagick was built with the
jb> >  OpenMP option.  I guess your environment has another issue which
jb> >  pulls -lomp into the build process.
jb>
jb> Clang >= 3.7 no longer ignores -fopenmp which now requires libomp.so
jb> from devel/openmp (for base compiler) or devel/llvm* built with OPENMP=on.
jb>
jb> For example:
jb>   1. Use FreeBSD >= 11.0
jb>   2. Install graphics/ImageMagick with OPENMP=on
jb>   3. Deinstall devel/openmp (just in case)
jb>   4. Build the port with default compiler
jb>
jb> The obvious fix is teach ImageMagick to not pollute namespace as nothing
jb> in its public API uses #pragma omp or omp_ symbols.

 So is the attached patch safe to avoid this?

-- Hiroki
Index: graphics/ImageMagick/files/patch-configure
===
--- graphics/ImageMagick/files/patch-configure	(nonexistent)
+++ graphics/ImageMagick/files/patch-configure	(working copy)
@@ -0,0 +1,10 @@
+--- configure.orig	2017-01-03 02:07:28.432298000 +0900
 configure	2017-01-03 02:09:38.248392000 +0900
+@@ -11691,7 +11691,6 @@
+
+
+ CFLAGS="$OPENMP_CFLAGS $CFLAGS"
+-MAGICK_PCFLAGS="$MAGICK_PCFLAGS $OPENMP_CFLAGS"
+
+ if test "$enable_openmp" != no; then
+   if test "$ac_cv_prog_c_openmp" != 'unsupported'; then

Property changes on: graphics/ImageMagick/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property


pgpJ_4clr0RzA.pgp
Description: PGP signature

Re: libwraster

[Hiroki Sato]

Stari Karp  wrote
  in <1483220783.1715.3.ca...@yandex.com>:

st> Hi!
st>
st> I try to install WindowMaker with Synth on FreeBSD 11-RELEASE (amd64)
st> and I have a problem with libwraster:

(snip)

 I could not reproduce this.  Can you please show all of options you
 chose?  "-fopenmp" in your build log comes from libMagikCore because
 you are using some non-default options at least for
 graphics/ImageMagick.

-- Hiroki


pgpkzZxZscZES.pgp
Description: PGP signature

Re: FreeBSD Port: print/gsfonts please make Japanese and Chinese fonts optional dependencies

[Hiroki Sato]

Miroslav Lachman <000.f...@quip.cz> wrote
  in <584ed3cb.1060...@quip.cz>:

00> Hi,
00>
00> we are using Xpdf which depends on Gsfonts and after last update there
00> are a bunch of new dependencies brought by Chinese and Japanese fonts"
00>
00> New packages to be INSTALLED:
00> zh-font-std: 0.0.20090602
00> zh-arphicttf: 2.11_5
00> mkfontdir: 1.0.7
00> mkfontscale: 1.1.2
00> xproto: 7.0.31
00> libfontenc: 1.1.3
00> ja-font-std: 0.0.20130501
00> ja-font-mplus-ipa: 1.0.20060520.p1_5
00> ja-font-ipa: 00303_6
00>
00> We are not using any of these so I think they are useless for us. Can
00> this be made as optional dependency? It can be default ON, we are
00> using own poudriere repo but we are unable to disable them now.

 Thank you for your report.  This problem should be fixed in the
 latest print/gsfonts.

-- Hiroki


pgphAF03K4wWn.pgp
Description: PGP signature

Re: Removal of print/ghostscript*-nox11

[Hiroki Sato]

Warren Block wbl...@wonkity.com wrote
  in alpine.bsf.2.20.1508221448070.93...@wonkity.com:

wb It's not clear to me how people that currently have the old
wb print/ghostscript should switch to the new version.
wb
wb 'portmaster -o print/ghostscript9-x11 ghostscript9-9.06_10' (in my
wb case) or even just 'portmaster ghostscript9-9.06_10' turns into an
wb endless loop:
wb
wb === print/ghostscript9-x11  print/ghostscript9-x11 
wb ghostscript9-9.06_10 (2/2)
wb
wb === The print/ghostscript9 port moved to print/ghostscript9-x11
wb === Reason: Split into print/ghostscript9-base and
wb print/ghostscript9-x11
wb
wb That will continue to recurse, adding one more print/ghostscript9-x11
wb each time.  UPDATING should show the correct method.  Maybe just
wb 'pkg delete -f ghostscript9-9.06_10' and then install
wb print/ghostscript9-x11?

 Does r395051 fix this issue?

-- Hiroki


pgp82_rHeJsnM.pgp
Description: PGP signature

Re: Removal of print/ghostscript*-nox11

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20150821.022521.792759762853683209@allbsd.org:

hr  So I would suggest either of the following two plans:
hr
hr  Plan A: Just remove print/ghostscript*-nox11.
...

hr  Plan B: Remove print/ghostscript*-nox11 and split the X11-dependent
hr  part of print/ghostscript9 into another port.

 Thank you all for your feedback!  I committed changes for Plan B as
 r395047.

 If you have a problem after this change, please report it to me.

-- Hiroki


pgpL9PLFP4o4W.pgp
Description: PGP signature

Removal of print/ghostscript*-nox11

[Hiroki Sato]

Hi,

 I would like your comments about removal of ghostscript*-nox11 ports,
 more specifically, whether many people think X11 library dependency
 is annoying or not.  After trying to fix -nox11 ports in the end of
 last month and then investigating them more carefully, I also reached
 a conclusion that they should be removed as several ports committers
 suggested.

 These -nox11 ports have originally been provided to build
 pre-compiled packages for people who want GS with no (heavy) X11
 dependency.  However, they have made dependency handling complicated
 because a package which depends on both X11 library and GS by default
 requires GS w/ X11 support in the dependency chain, but GS w/ and w/o
 X11 cannot co-exist.  This means that the -nox11 packages do not work
 well with pre-complied packages which require GS though they work if
 all of them are built w/o X11 support consistently on a system.  If
 ports are built manually with OPTIONS_UNSET=X11,
 print/ghostscript*-nox11 ports are not useful anymore.

 So I would suggest either of the following two plans:

 Plan A: Just remove print/ghostscript*-nox11.

  Currently ghostscript depends on X11 libraries of ice, sm, x11,
  xext, and xt.  While one can still eliminate these dependency by
  disabling X11 in PORT_OPTIONS, the pre-complied packages always
  depend on them.

  Pros: Simple.

  Cons: GS always depends on the X11 libraries.

 Plan B: Remove print/ghostscript*-nox11 and split the X11-dependent
 part of print/ghostscript9 into another port.

  Ghostscript can be built into two parts; one is a part without X11
  libraries and another is a shared library for X11-dependent
  functionality.  GS will find the shared library and transparently
  enable x11* devices only when available.  So we can split
  ghostscript ports into base and X11 part like this:

   print/ghostscript9-base: no X11 dependency
   print/ghostscript9-x11:  installs the shared library only

  Ports which require ghostscript can safely depend on
  ghostscript9-base regardless of X11 support.  If they need X11
  support in GS (print/gv, for example), USES=ghostscript:x11 picks up
  ghostscript9-x11 as an additional dependency.

  Pros: Minimal dependency.

  Cons: People may confuse what -base and -x11 mean and which package
should be installed when they want ghostscript.

 I have created patches for the both and confirmed technical
 feasibility but still wondering which looks better to people who are
 using ghostscript.  Any comments and/or questions are welcome.

-- Hiroki


pgpyErztv5AQr.pgp
Description: PGP signature

Re: FreeBSD Port: ghostscript9-9.06_8

[Hiroki Sato]

Ian Lord lo...@msdi.ca wrote
  in bced8573123e4689918ebe34793bf...@server02.ad.ezmax.ca:

lo We have some issues with imageMagick which has a dependencie to this
lo port and I've been told the problem is due to the old version of
lo ghostscript I am using...
lo
lo From this release history page:
lo http://www.ghostscript.com/doc/current/History9.htm#Version9.07
lo
lo It seem the version 9.06 was released more than 2 years ago and there
lo is no new release in the ports tree since then.
lo
lo Is there a reason (perhaps the license change to AGPL) or a
lo compatibility problem that prevents to go higher than 9.06 ?
lo
lo I don't have the competency to update the port myself but if you need
lo someone to make tests, I'll be more than happy to.

 You can use print/ghostscript9-agpl instead.  It is now 9.15.

-- Hiroki


pgpSl234JxoU8.pgp
Description: PGP signature

Re: eTeX in TeXlive

[Hiroki Sato]

Michael michip...@gmail.com wrote
  in 547ec79e.2040...@gmail.com:

mi Hi everyone!
mi
mi
mi In my current installation of TeXlive (texlive-base-20140525_3) there
mi is no command etex.  This is a problem, as some packages and programs
mi rely on etex (e.g. metapost).
mi
mi I am not sure which port to install to have an etex program again.

 etex was missing and I fixed in r373858.  Please try the latest ports
 tree and upgrate print/tex-formats.

mi Also I just noticed fmtutil-sys --all does nothing (just sit for half
mi a second or so), isn't it expected that it rebuilds all available
mi formats?

 In the fmtutil.cnf configuration file, all of the entries are
 disabled by default.  If you want to use it, please enable them.
 Normal users do not need to touch it because print/tex-formats (and
 other TeX-related ports) handles format files as necessary.

-- Hiroki


pgpT2_eoPtoML.pgp
Description: PGP signature

Re: GSSAPILIBDIR not filled while trying to build cyrus-sasl2-gssapi

[Hiroki Sato]

Scot Hetzel swhet...@gmail.com wrote
  in cacdu+f8fphx+a4ao_-tddkqh+ysqekhbdajbomam+n8jw4v...@mail.gmail.com:

sw On Tue, Dec 2, 2014 at 8:38 AM, Philippe Lauget li...@lrnx.net wrote:
sw  Hi,
sw 
sw  I'm trying to build /usr/ports/security/cyrus-sasl2-gssapi with MIT krb5
sw  from a fresh port tree :
sw 
sw  ===  License BSD4CLAUSE accepted by the user
sw  ===  Found saved configuration for cyrus-sasl-gssapi-2.1.26_3
sw  ===   cyrus-sasl-gssapi-2.1.26_3 depends on file: /usr/local/sbin/pkg -
sw  found
sw  === Fetching all distfiles required by cyrus-sasl-gssapi-2.1.26_3 for
sw  building
sw  ===  Extracting for cyrus-sasl-gssapi-2.1.26_3
sw  = SHA256 Checksum OK for cyrus-sasl-2.1.26.tar.gz.
sw  ===  Patching for cyrus-sasl-gssapi-2.1.26_3
sw  ===  Applying FreeBSD patches for cyrus-sasl-gssapi-2.1.26_3
sw  ===   cyrus-sasl-gssapi-2.1.26_3 depends on executable: libtool - found
sw  ===   cyrus-sasl-gssapi-2.1.26_3 depends on file: /libkrb5support.so -
sw  not found
sw  ===Verifying install for /libkrb5support.so in 
/usr/ports/security/krb5
sw  
^^^
sw 
sw  ===  License MIT accepted by the user
sw  ===  Found saved configuration for krb5-1.13
sw  ===   krb5-1.13 depends on file: /usr/local/sbin/pkg - found
sw  === Fetching all distfiles required by krb5-1.13 for building
sw  ===  Extracting for krb5-1.13
sw  
sw 
sw 
sw  krb5-1.13 is already installed on my system, i have KRB5_HOME=/usr/local
sw  in /etc/make.conf
sw 
sw  Of course, /libkrb5support.so does not exist, and the check should point
sw  to /usr/local/lib/libkrb5support.so, or, from the path computed from
sw  ${GSSAPILIBDIR}/libkrb5support.so defined in /usr/ports/Mk/Uses/gssapi.mk
sw 
sw  But, unlike base or heimdal, with MIT krb5, GSSAPILIBDIR is not defined.
sw 
sw  Have I missed a step, or is it a 'bug' ?
sw  Thanks,
sw 
sw Looks like it has been fixed in r373797
sw
sw http://svnweb.freebsd.org/ports/head/Mk/Uses/gssapi.mk?view=log

 Yes, sorry for the breakage.

-- Hiroki


pgp1wP3r8UGap.pgp
Description: PGP signature

Re: Unable to upgrade tex-xetex and tex-luatex: libpoppler.so.44 not found

[Hiroki Sato]

Dr. Peter Voigt pvo...@uos.de wrote
  in 20141125195336.590b7ffd@kirk.drpetervoigt.private:

pv On Tue, 25 Nov 2014 19:41:51 +0100
pv Marcus von Appen m...@freebsd.org wrote:
pv
pv  On, Tue Nov 25, 2014, Dr. Peter Voigt wrote:
pv 
pv   I am currently unable to upgrade tex-xetex and tex-luatex on
pv   10.1-RELEASE (amd64).
pv  
pv  [...]
pv 
pv   ' ... Shared object libpoppler.so.44 not found, required by
pv   xetex Error: `xetex -ini  -jobname=xetex -progname=xetex -etex
pv   xetex.ini ' failed
pv  
pv   
###
pv   fmtutil: Error! Not all formats have been built successfully.
pv   Visit the log files in directory
pv /usr/ports/print/tex-xetex/work/stage/usr/local/share/texmf-var/web2c
pv   for details.
pv   
###
pv  
pv   This is a summary of all `failed' messages:
pv   `xetex -ini  -jobname=xetex -progname=xetex -etex xetex.ini ' failed
pv   *** Error code 1
pv  
pv 
pv  The tex-xetex and tex-luatex ports use the first `xetex` or `luatex`
pv  that is found in your PATH environment, thus the build process uses
pv  the old (outdated) versions in /usr/local/bin. You can work around
pv  this by deinstalling both first, and then install them.
pv 
pv  Cheers
pv  Marcus
pv
pv Thank you both for your quick replies. Your solution worked for me.

 Thank you for your report.  I overlooked this case but committed a
 fix in r373439 just now.

-- Hiroki


pgpSMqJWLvXUB.pgp
Description: PGP signature

Re: devel/tex-web2c kpathsea/paths.h not found

[Hiroki Sato]

Erich Dollansky erichsfreebsdl...@alogt.com wrote
  in 20141102112717.69653...@x220.alogt.com:

er Hi,
er
er when I try to compile tex-web2c, I will get this:
er
er configure: You requested to build `web2c' using an installed
er `kpathsea' version, configure: which requires to locate the
er kpathsea/paths.h header file. configure: error: Sorry, not found
er under any of: /usr/local/include * ===  Script configure failed
er unexpectedly. Please report the problem to h...@freebsd.org [maintainer]
er and attach the
er 
/usr/home/PORTS/work/usr/ports/devel/tex-web2c/work/texlive-20140525-source/texk/web2c/config.log
er including the output of the failure of your make command. Also, it
er might be a good idea to provide an overview of all packages installed
er on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). ***
er Error code 1
er
er Stop.
er make: stopped in /usr/ports/devel/tex-web2c
er [X220]...devel/tex-web2c (root) 
er
er I hope it is a simple as the file kpathsea/paths.h does not exist at all.

 Do you have tex-kpathsea package on your box?  tex-web2c depends on
 it and your box should have it, but the error indicates that it does
 not exist.

-- Hiroki


pgptzMLU1CCZr.pgp
Description: PGP signature

[CFT] multiple instance support in rc.d script

[Hiroki Sato]

[Please reply to freebsd-rc@]

Hi,

 I would like your feedback and testers of the attached patch.  This
 implements multiple instance support in rc.d scripts.  You can try it
 by replacing /etc/rc.subr with the attached one.

 More details are as follow.  Typically, an rc.d/foo script has the
 following structure and rc.conf variables:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable
   ...
   load_rc_command $name
   run_rc_command $*
   

   /etc/rc.conf:
   
   foo_enable=YES
   foo_flags=-f -l -a -g
   

 The above supports one instance for one script.  After replacing
 rc.subr, you can specify additional instances in rc.conf:

   /etc/rc.conf:
   
   foo_instances=one two

   foo_one_enable=YES
   foo_one_flags=-f -l -a -g

   foo_two_enable=YES
   foo_two_flags=-F -L -A -G
   

 $foo_instances defines instances by space-separated list of instance
 names, and rc.conf variables for them are something like
 ${name}_${instname}_enable.  The following command

  # service foo start

 starts foo_one and foo_two with the specified flags.  Instances can
 be specified in the following form:

  # service foo start:one

 or multiple instances in a particular order:

  # service foo start:two,one

 Basically, no change is required for the rc.d/foo script itself.
 However, there is a problem that default values of the instantiated
 variables are not defined.

 For example, if an rc.d/script uses $foo_mode, you need to define
 $foo_one_mode.  The default value of $foo_mode is usually defined in
 etc/defaults/rc.conf for rc.d scripts in the base system and :
 ${foo_mode:=value} idiom in scripts from Ports Collection.  So all
 of the variables should be defined for each instance, too.  As you
 noticed, this is not easy without editing the script itself.

 To alleviate this, set_rcvar() can be used:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable

   set_rcvar foo_enable YES Enable $name
   set_rcvar foo_program/tmp/test Command for $name
   ...
   load_rc_command $name
   run_rc_command $*
   

 The three arguments are varname, default value, and description.  If
 a variable is defined by set_rcvar(), default values instantiated
 variables will be set automatically---foo_one_program is set by
 foo_program if it is not defined.

 This approach still has another problem.  set_rcvar() is not
 supported in all branches, so a script using it does not work in old
 supported branches.  One solution which can be used for scripts in
 Ports Collection is adding both definitions before and after
 load_rc_command() until EoL of old branches like this:

   /etc/rc.d/foo:
   
   name=foo
   rcvar=foo_enable

   if type set_rcvar /dev/null 21; then
set_rcvar foo_enableYES Enable $name
set_rcvar foo_program   /tmp/test Command for $name
   fi
   ...
   load_rc_command $name

   # will be removed after all supported branches have set_rcvar().
   if ! type set_rcvar /dev/null 21; then
: ${foo_enable:=YES}
: ${foo_program:=/tmp/test}
for _i in $foo_instances; do
for _j in enable program; do
eval : \${foo_${_i}_enable:=\$foo_$_j}
done
done
   fi

   run_rc_command $*
   

 This is a bit ugly but should work fine.

 I am using this patch to invoke multiple named (caching
 server/contents server) and syslogd (local only/listens INET/INET6
 socket only) daemons.  While $foo_instances is designed as a
 user-defined knob, this can be applied to software which need to
 invoke multiple/different daemons which depend on each other in a
 script, too.

 I am feeling this patch still needs more careful review from others.
 Any comments are welcome.  Thank you.

-- Hiroki
Index: etc/rc.subr
===
--- etc/rc.subr	(revision 272976)
+++ etc/rc.subr	(working copy)
@@ -698,7 +698,10 @@
 #		start stop restart rcvar status poll ${extra_commands}
 #	If there's a match, run ${argument}_cmd or the default method
 #	(see below).
+#	_run_rc_command0() is the main routine and run_rc_command() is
+#	a wrapper to handle multiple instances.
 #
+#
 #	If argument has a given prefix, then change the operation as follows:
 #		Prefix	Operation
 #		--	-
@@ -755,6 +758,9 @@
 #
 #	${name}_nice	n	Nice level to run ${command} at.
 #
+#	${name}_pidfile	n	This to be used in /etc/rc.conf to override
+#${pidfile}.
+#
 #	${name}_user	n	User to run ${command} as, using su(1) if not
 #using ${name}_chroot.
 #Requires /usr to be mounted.
@@ -863,6 +869,57 @@
 #
 run_rc_command()
 {
+	local _act _instances _name _desc _rcvar
+
+	_act=$1
+	shift
+	eval _instances=\$${name}_instances
+
+	# Check if instance is specified, e.g. start:instance,
+	case ${_act%:*} in
+	$_act)	;;			# no instance specified
+	*)
+		_instances=$(echo ${_act#*:} | tr ,  )
+		_act=${_act%:*}
+	;;
+	esac
+
+	# Use 

Re: texlive-texmf

[Hiroki Sato]

Chris Rees cr...@bayofrum.net wrote
  in 650e7086-e6d4-4503-865d-bc5aad3b7...@bayofrum.net:

cr Hello Hiroki-san,
cr
cr I think it would be a good idea to add
cr
cr CONFLICTS_BUILD=texlive-texmf-201[23]*
cr
cr to texlive-base Makefile.  It appears several people would appreciate this 
clue!
cr
cr Do you agree?

 Thank you for your suggestion.  I added CONFLICTS on the both sides
 to keep the versions in sync with each other and an additional
 version check into print/texlive-full.

-- Hiroki


pgpgmdGp76veq.pgp
Description: PGP signature

Re: TeXLive 2014

[Hiroki Sato]

Greg Lewis gle...@eyesbeyond.com wrote
  in 20140823174220.ga46...@misty.eyesbeyond.com:

gl After the TeXLive 2014 update a number of the tex related ports won't
gl build.  An example is print/tex-aleph.  It currently dies like this:
gl
gl Transcript written on lamed.log.
gl fmtutil: 
/usr/ports/print/tex-aleph/work/stage/usr/local/share/texmf-var/web2c/aleph/lamed.fmt
 installed.
gl /bin/rm -f 
/usr/ports/print/tex-aleph/work/stage/usr/local/share/texmf-dist/ls-R 
/usr/ports/print/tex-aleph/work/stage/usr/local/share/texmf-var/ls-R 
/usr/ports/print/tex-aleph/work/stage/usr/local/share/texmf-dist/web2c/texmf.cnf
gl /bin/rmdir 
/usr/ports/print/tex-aleph/work/stage/usr/local/share/texmf-dist/web2c || true
gl  Compressing man pages (compress-man)
gl  Running Q/A tests (stage-qa)
gl Error: 'share/texmf-var/web2c/aleph/aleph.log' is referring to 
/usr/ports/print/tex-aleph/work/stage
gl Error: 'share/texmf-var/web2c/aleph/lamed.log' is referring to 
/usr/ports/print/tex-aleph/work/stage
gl *** Error code 1
gl
gl There are a number of other ports in the same boat.  In this case, and
gl others where the errors are regarding log files, the errors are spurious.
gl We shouldn't even install these log files since they serve no purpose and
gl are just artifacts of the build.
gl
gl For other ports (e.g. japanese/tex-ptex) the errors seem much more serious:
gl
gl Error: 'share/texmf-var/web2c/euptex/uplatex.fmt' is referring to 
/usr/ports/japanese/tex-ptex/work/stage
gl
gl In this case the .fmt files are a needed file for things to work.
gl
gl I haven't yet looked into how to possibly fix these.  Can others reproduce?

 This is reproducible and has also been filed as PR 192933.  I am
 wondering if I should fix this and how to do it if should.  I agree
 that it is better to fix them if possible, but it is harmless in this
 case and difficult to properly fix it.

 foo.fmt and foo.log which are generated for a TeX format foo.  They
 contain ${STAGEDIR} because they are processed within the directory,
 but they are just recorded, not used as pathname.  Although we can
 replace the pathnames by using sed(1) in foo.log since it is a plain
 text, it is difficult for foo.fmt.

 One way to fix it is to run fmtutil after necessary texmf files
 installed.  However, .fmt file generation in ${STAGEDIR} is
 friendlier with packaging and safer in terms of possible failures
 (i.e. errors can be detected before installing).

 For whether installing .log file or not, I intentionally installed
 them because the output is required for diagnostic purpose.  Building
 a .fmt can be screwed up in various ways without compile-time error
 even if taking countermeasures, and it is difficult to detect
 malformed one without .log.

-- Hiroki


pgpUFMQbfj6uu.pgp
Description: PGP signature

TeXLive 2014

[Hiroki Sato]

Hello,

 First, I am sorry for my being lazy and not responding to problem
 reports on teTeX/TeXLive ports in a timely manner.  I just updated
 TeXLive ports to 2014 and trying to figure out what problems we still
 have now.  Please report your trouble to freebsd-tex@ list or file a
 PR.

 I think it is safe to upgrade a system with TL2012.
 Incompatibilities of TeX engines are quite small though some of very
 old macros were removed in TL2014.  At this moment, TeXLive-specific
 management tools such as tlmgr do not work well because package
 management by them conflicts with pkg(8) and can damage the installed
 files in an unexpected way.

-- Hiroki


pgpeQ3D6IaBjE.pgp
Description: PGP signature

Re: Postponing the switch to TeXLive

[Hiroki Sato]

Michael Gmelin free...@grem.de wrote
  in d01d7e6a-c576-4dd8-9068-fd4d2f0e4...@grem.de:

fr
fr
fr  On 24 Jul 2014, at 20:38, Baptiste Daroussin b...@freebsd.org wrote:
fr 
fr  On Thu, Jul 24, 2014 at 02:05:35PM -0400, Lowell Gilbert wrote:
fr  Andrea Venturoli m...@netfence.it writes:
fr 
fr  I've read in /usr/ports/UPDATING that TeXLive is now the default.
fr  Since I've no time to test it now, I'd like to stay with TeTeX for a
fr  further litte while.
fr 
fr  So I put TEX_DEFAULT=tetex in /etc/make.conf; however this does not
fr  seem to work: portupgrade -R teTeX tries (and obviously fail) to
fr  convert everything to TeXLive.
fr 
fr  Is it possible to avoid this for now?
fr 
fr  Based on 20 seconds of searching /usr/ports/Mk/bsd.tex.mk, I think you
fr  just need to capitalize 'tetex'.
fr  ___
fr  freebsd-ports@freebsd.org mailing list
fr  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
fr  To unsubscribe, send any mail to
fr  freebsd-ports-unsubscr...@freebsd.org
fr 
fr  No teTeX has been totally removed, as it it was not happily living
fr  along with
fr  TeXlive (leading to too many conflicts and complexity)
fr 
fr  regards,
fr  Bapt
fr
fr I'm using TeX quite extensively for business reasons as well as
fr private purposes. Are there any known pitfalls when migrating from
fr teTeX to TeXlive?

 Basically it is backward compatible with teTeX but some of features
 in texconfig and tlmgr do not work.  For example, texconfig paper
 no longer works well to configure the default paper size because most
 of dviware use libpaper now.  Currently tlmgr does not work mainly
 because of conflict with FreeBSD ports/package framework.

 TeX engines are changed (etex is deprecated, for example) and TeX
 macros in TeXLive distribution are newer than teTeX, so there are
 some incompatibilities.  Please report if you have a specific problem
 after upgrading.

-- Hiroki


pgp3GYE8Vz6fA.pgp
Description: PGP signature

Re: Differences between iconv from ports and iconv in base (transliteration)

[Hiroki Sato]

Michael Gmelin free...@grem.de wrote
  in 20131206001554.0d9d3...@bsd64.grem.de:

fr I'm in the process of changing ports from ports iconv to iconv in base.
fr I noticed that transliteration doesn't work in base as it does with
fr iconv from ports. Examples:
fr
fr T\xc5\xbdst
fr ports: TZst
fr base: Tst
fr
fr T\xe2\x82\xacst
fr ports: TEURst
fr base: Tst
fr
fr Conversion done using:
fr iconv_open(ISO8859-1//IGNORE//TRANSLIT, UTF-8);
fr
fr Any ideas?

 //TRANSLIT is a GNU iconv specific extension and iconv in base (and
 other POSIX systems) does not support it.  Does your software depend
 on it?

-- Hiroki


pgpnC6G4SUdyE.pgp
Description: PGP signature

Re: [CFT] TPM(Trusted Platform Modules) replated ports

[Hiroki Sato]

Andrey Fesenko f0and...@gmail.com wrote
  in CA+K5SrOCqSs5f8iDh+d+wAp4kX-U2D6us=OPyj=vxryegyr...@mail.gmail.com:

f0 On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara
f0 hiren.panchas...@gmail.com wrote:
f0  On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko f0and...@gmail.com wrote:
f0 
f0  security/trousers - need add user in comand line and remove path var
f0  directory pkg-plist
f0  hrs@ just fixed this port a few mins back.
f0 
f0 Yes, install not error :)
f0
f0  security/opencryptoki - checking for csulincl.h... no
f0  configure: error: tpm token build requested but TSS development files 
not found
f0  ===  Script configure failed unexpectedly.
f0 
f0  Try sending this report on ports@ ?
f0 
f0  cheers,
f0  Hiren
f0
f0 No, make cc this message.
f0 ports revision 335651

 Can you try r335654?  security/trousers has to be updated because of
 iconv library conflict.

-- Hiroki


pgpyVIbmfFcEA.pgp
Description: PGP signature

Re: security/trousers build failing on -current

[Hiroki Sato]

hiren panchasara hiren.panchas...@gmail.com wrote
  in calcpeufneryvopoq7fccynwmlvashfftnbplimqath58nov...@mail.gmail.com:

hi My poudriere (from last night current and ports tree) reported the failure:
hi
hi full logs:
hi
hi http://bpaste.net/show/155463/

 Thank you for your report.  It should be fixed in r335632.

-- Hiroki


pgpFhStiIJ94l.pgp
Description: PGP signature

Re: security/trousers build failing on -current

[Hiroki Sato]

hiren panchasara hiren.panchas...@gmail.com wrote
  in CALCpEUF=lx7evcvk9_hafepbgevzhrjwheywecnxfqr5cpc...@mail.gmail.com:

hi On Wed, Dec 4, 2013 at 12:47 PM, Hiroki Sato h...@freebsd.org wrote:
hi  hiren panchasara hiren.panchas...@gmail.com wrote
hiin calcpeufneryvopoq7fccynwmlvashfftnbplimqath58nov...@mail.gmail.com:
hi 
hi  hi My poudriere (from last night current and ports tree) reported the 
failure:
hi  hi
hi  hi full logs:
hi  hi
hi  hi http://bpaste.net/show/155463/
hi 
hi   Thank you for your report.  It should be fixed in r335632.
hi
hi Upgraded my ports tree and it failed at a later stage.
hi
hi full logs:
hi http://bpaste.net/show/17/

 Gr, please try r335650.  I misunderstood how to handle empty
 directories when !NO_STAGE.

-- Hiroki


pgpxqI0_DY9QY.pgp
Description: PGP signature

Re: multimedia/rtmpdump shared lib issue... (now not work)

[Hiroki Sato]

Andrey Fesenko f0and...@gmail.com wrote
  in ca+k5srnu5s5zb9_uuhq2kir_vi65ma5fvccpgqw7sfogc20...@mail.gmail.com:

f0 This patch http://www.freebsd.org/cgi/query-pr.cgi?pr=180283 now not work
f0
f0 # uname -a
f0 FreeBSD x220.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256773: Sun
f0 Oct 20 03:42:58 MSK 2013
f0 andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK  amd64
f0
f0 multimedia/rtmpdump # make install clean
f0 ===  Building for rtmpdump-2.4.20130923
f0 --- librtmp/librtmp.a ---
f0 --- rtmpsrv ---
f0 cc  -Wl,-rpath=/usr/local/lib -L/usr/local/lib -fstack-protector -o
f0 rtmpsrv rtmpsrv.o thread.o -pthread -Llibrtmp -lrtmp -lssl -lcrypto
f0 -lz
f0 /usr/bin/ld: warning: libssl.so.7, needed by
f0 /usr/local/lib/librtmp.so, may conflict with libssl.so.8
f0 /usr/bin/ld: warning: libcrypto.so.7, needed by
f0 /usr/local/lib/librtmp.so, may conflict with libcrypto.so.8
f0 rtmpsrv.o: In function `doServe':
f0 rtmpsrv.c:(.text+0x1955): undefined reference to `RTMP_TLS_Accept'
f0 rtmpsrv.o: In function `main':
f0 rtmpsrv.c:(.text+0x1e36): undefined reference to 
`RTMP_TLS_AllocServerContext'
f0 rtmpsrv.c:(.text+0x1f67): undefined reference to 
`RTMP_TLS_FreeServerContext'
f0 cc: error: linker command failed with exit code 1 (use -v to see invocation)

 Do you have openssl port installed on your system?

-- Hiroki


pgp3wzVvQW3L5.pgp
Description: PGP signature

Re: tlmgr fails

[Hiroki Sato]

Jerry je...@seibercom.net wrote
  in 20130720120139.0108b37f@scorpio:

je I have tried running tlmgr from the command line, and it fails. This
je is the output:
je
je tlmgr update --list
je cannot setup TLPDB in /usr at /usr/local/bin/tlmgr line 4965.
je
je Is this a known problem and is there a fix for it?

 It is a known problem.  It is intentionally disabled because tlmgr
 changes the installed files in an incompatible way with ports
 framework.  It will be fixed, but is not available at this moment.

-- Hiroki


pgpJMZT_NxR9I.pgp
Description: PGP signature

Re: Installing texlive-base-20120701_7...pkg-static: texlive-base-20120701_7 conflicts with tex-formats20120701 (installs files into the same place)

[Hiroki Sato]

Anton Shterenlikht me...@bris.ac.uk wrote
  in 201306031116.r53bgrei013...@mech-cluster241.men.bris.ac.uk:

me This is on ia64 r247266 with ports at r319750.
me
me ===   Registering installation for texlive-base-20120701_7 as automatic
me pkg-static: duplicate directory listing: /usr/local/share/texmf-dist/, 
ignoring
me pkg-static: lstat(/usr/local/share/texmf-local/): No such file or directory
me pkg-static: duplicate directory listing: /usr/local/share/texmf-config/, 
ignoring
me Installing texlive-base-20120701_7...pkg-static: texlive-base-20120701_7 
conflicts with tex-formats20120701 (installs files into the same place).  
Problematic file: /usr/local/bin/mptopdf
me *** [fake-pkg] Error code 70
me
me Stop in /usr/ports/print/texlive-base.
me
me === A backup package for texlive-base-20120701_2 should
mebe located in /usr/ports/packages/portmaster-backup
me
me === Installation of texlive-base-20120701_7 (print/texlive-base) failed
me === Aborting update

 Please deinstall tex-formats first since both were updated to fix a
 glitch at the same time.  texlive-base-20120701_7 +
 tex-formats-20120701_1 should work while texlive-base-20120701_7 +
 tex-formats-20120701 does not work.

-- Hiroki


pgpPYHGctjyDK.pgp
Description: PGP signature

Re: Proposal: do not show up the dialog(1) by default?

[Hiroki Sato]

Baptiste Daroussin b...@freebsd.org wrote
  in 20130523054541.gh96...@ithaqua.etoilebsd.net:

ba hi,
ba
ba A lot of people seems to be complaining about the configuration dialog 
popping
ba up all the time.
ba
ba What if we change the default behaviour to not pop up the dialog each time 
there
ba is a changed option but only when the user explicitly type make config?
ba
ba Just a proposal, please give your opinion.
ba
ba Of course make config-recursive behaviour won't change.

 I am using the attached patch locally to make the four global knobs
 silent.  This is a kind of overkill, but adding OPTIONS_NOMENU and
 making the do-config target skip the dialog invocation when all of
 values in OPTIONS_DEFINE are defined in OPTIONS_NOMENU would be a
 compromise.  If one wants dialog for the global knobs, OPTIONS_NOMENU
 can always be redefined in make.conf.

 I think each port should define their knobs in OPTIONS_DEFINE even
 for global ones like DOCS because it is more consistent.

-- Hiroki
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk	(revision 317459)
+++ Mk/bsd.port.mk	(working copy)
@@ -6128,6 +6128,9 @@
 .undef opt
 .endif # pre-config

+OPTIONS_MENUTIMEOUT?=	5
+OPTIONS_NOMENU?=	DOCS NLS EXAMPLES IPV6
+TPUT_CMD?=	/usr/bin/tput
 .if !target(do-config)
 do-config:
 .if empty(ALL_OPTIONS)  empty(OPTIONS_SINGLE)  empty(OPTIONS_MULTI)  empty(OPTIONS_RADIO)  empty(OPTIONS_GROUP)
@@ -6144,13 +6147,41 @@
 	${MKDIR} $${optionsdir} 2 /dev/null) || \
 	(${ECHO_MSG} === Cannot create $${optionsdir}, check permissions; exit 1)
 .endif
-	@TMPOPTIONSFILE=$$(mktemp -t portoptions); \
+	@if [ ${_RECURSIVE} != 1 ]; then \
+		for opt in ${PORT_OPTIONS}; do \
+			oskip=0; \
+			for nom in ${OPTIONS_NOMENU}; do \
+case $$opt in \
+$$nom)	oskip=1 ;; \
+esac; \
+			done; \
+			case $$oskip in \
+			0)	break ;; \
+			esac; \
+		done; \
+	else \
+		oskip=0; \
+	fi; \
+	if [ $$oskip = 1 ]; then \
+		trap ${TPUT_CMD} me 1 2 3 5 10 13 15; \
+		${TPUT_CMD} md; \
+		${ECHO_MSG} === This port has user configuration options.; \
+		if read -t ${OPTIONS_MENUTIMEOUT} \
+		-p === To open the configuration menu, hit enter key in ${OPTIONS_MENUTIMEOUT} seconds. \
+		DUMMYARG; then \
+			oskip=0; \
+		fi; \
+		${TPUT_CMD} me; \
+	fi; \
+	TMPOPTIONSFILE=$$(mktemp -t portoptions); \
 	trap ${RM} -f $${TMPOPTIONSFILE}; exit 1 1 2 3 5 10 13 15; \
+	if [ $$oskip = 0 ]; then \
 	${SETENV} ${D4P_ENV} ${SH} ${PORTSDIR}/Tools/scripts/dialog4ports.sh $${TMPOPTIONSFILE} || { \
 		${RM} -f $${TMPOPTIONSFILE}; \
 		${ECHO_MSG} === Options unchanged; \
 		exit 0; \
 	}; \
+	fi; \
 	${ECHO_CMD}; \
 	if [ ! -e $${TMPOPTIONSFILE} ]; then \
 		${ECHO_MSG} === No user-specified options to save for ${PKGNAME}; \
@@ -6196,7 +6227,7 @@
 config-recursive:
 	@${ECHO_MSG} === Setting user-specified options for ${PKGNAME} and dependencies;
 	@for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
-		(cd $$dir; ${MAKE} config-conditional); \
+		(cd $$dir; ${MAKE} _RECURSIVE=1 config-conditional); \
 	done
 .endif # config-recursive

@@ -6204,7 +6235,7 @@
 config-conditional: pre-config
 .if defined(COMPLETE_OPTIONS_LIST)  !defined(NO_DIALOG)
 .  if !defined(_FILE_COMPLETE_OPTIONS_LIST) || ${COMPLETE_OPTIONS_LIST:O} != ${_FILE_COMPLETE_OPTIONS_LIST:O}
-	@cd ${.CURDIR}  ${MAKE} do-config;
+	@cd ${.CURDIR}  ${MAKE} _RECURSIVE=${_RECURSIVE} do-config;
 .  endif
 .endif
 .endif # config-conditional


pgpQFe1esZUAw.pgp
Description: PGP signature

TeXLive build error on poudriere (Was: [patch included] teTeX and TeXLive)

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130519.070840.2265196291393572686@allbsd.org:

hr Christopher J. Ruwe c...@cruwe.de wrote
hr   in 20130518025801.0659b...@dijkstra.cruwe.de:
hr
hr cj I have included the patches, they are rather trivial, although, I
hr cj think, dirty. I have also included a complete logfile of a failed
hr cj build for tex-formats.
hr
hr  Where is the log file?
hr
hr  What I need to investigate here is a build+install log for
hr  print/texlive-base on your environment.  Running texconfig rehash in
hr  pre-install just hides your error and makes another problem.

 I committed a fix in r318651.  Please try it if you got a build error
 when using poudriere.

-- Hiroki


pgpmCTt3BkeDv.pgp
Description: PGP signature

freebsd-tex mailling list

[Hiroki Sato]

Hi,

 JFYI, freebsd-tex mailing list[*] has been created for discussing TeX
 related ports.  If you are interested in porting and/or have
 questions about TeX and its applications on FreeBSD, please subscribe
 it.

 [*] http://lists.freebsd.org/mailman/listinfo/freebsd-tex

-- Hiroki


pgpc7NvU7WAPK.pgp
Description: PGP signature

Re: [patch included] teTeX and TeXLive

[Hiroki Sato]

Christopher J. Ruwe c...@cruwe.de wrote
  in 20130518025801.0659b...@dijkstra.cruwe.de:

cj I have included the patches, they are rather trivial, although, I
cj think, dirty. I have also included a complete logfile of a failed
cj build for tex-formats.

 Where is the log file?

 What I need to investigate here is a build+install log for
 print/texlive-base on your environment.  Running texconfig rehash in
 pre-install just hides your error and makes another problem.

-- Hiroki


pgp3MISBwpLKb.pgp
Description: PGP signature

Re: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o

[Hiroki Sato]

Boris Samorodov b...@passap.ru wrote
  in 51939aed.3060...@passap.ru:

bs Hi,
bs
bs I've got an error while building texlive-base at fresh CURRENT:
bs -
bs % uname -a
bs FreeBSD BB049.int.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #21 r250633:
bs Tue May 14 13:53:42 SAMT 2013
bs b...@bb049.int.wart.ru:/usr/obj/usr/src/sys/BB64X  amd64
bs -
bs
bs I have TEX_DEFAULT=texlive at the /etc/make.conf.
bs
bs Here is a tail of te log (full log 719 KB
bs ftp://ftp.wart.ru/pub/FreeBSD/errorlogs/texlive.make.log.txt ):

 Thank you for the report.  I am trying to reproduce this now.

-- Hiroki


pgpiQruc2Y8EH.pgp
Description: PGP signature

Re: teTeX and TeXLive

[Hiroki Sato]

David Demelier demelier.da...@gmail.com wrote
  in CAO+PfDe0nEdG=6zvnce90ktjsy4jyrk9jr1pmfbawrbj5cb...@mail.gmail.com:

de 2013/5/12 Florent Peterschmitt flor...@peterschmitt.fr:
de  Le 11/05/2013 20:36, Hiroki Sato a écrit :
de  Hello,
de 
de   As you already noticed, TeXLive ports have been imported and one can
de   choose teTeX or TeXLive while the default value for pre-compiled
de   packages is still teTeX.
de 
de   If you want to use TeXLive, please try to use the following knob:
de 
de   TEX_DEFAULT= texlive
de 
de   To do this, almost all of ports which use TeX will depend on TeXLive.
de   Although some ports which install a new TeX macro package may not
de   work because of incompatibility such as difference of directory
de   structure between the two, ones which use TeX for typesetting should
de   work fine.  Ones to install macro packages which were non-standard in
de   teTeX but are included in TeXLive will be fixed or removed.
de 
de   Please test TeXLive and send your failure report to me.  Once it is
de   confirmed that TEX_DEFAULT=texlive works, I will switch the default
de   value from tetex to texlive at some point.
de 
de 
de Thank you very much, however I have a install failure on poudriere
de with ports tree up to date 5 minutes ago:

 Thank you for your report.  I have received several reports about
 install failures on poudriere and am investigating them.

-- Hiroki


pgp1NQuUTYl0t.pgp
Description: PGP signature

Re: teTeX and TeXLive

[Hiroki Sato]

Matthias Andree matthias.and...@gmx.de wrote
  in 51941f70.2060...@gmx.de:

ma I have been looking at the texlive-base and -texmf ports, prompted by a
ma discussion on IRC involving marino, Niclas Zeising and myself, and I
ma must say that I am impressed - not to say scared - by the sheer size of
ma the ports' distfiles (130 MB for base, 1.4 GB for -texmf), and have not
ma yet taken the time to install and test the port.
ma
ma I suppose the -texmf port would be all of texlive.
ma
ma Is there any optimization we can make to get the texlive material more
ma manageable?  People have expressed concerns about daily download limits
ma (although that situation does not affect me personally currently).
ma
ma Are you aware of a list/overview/... that would explain the difference
ma between the -base and the -texmf ports?

 -base is binary part of the TeXLive, and -texmf includes data such as
 TeX macro packages, fonts, configuration files, and documentation.
 Both are needed to make TeX (yes, strictly speaking it is much more
 than pure TeX) work.

 The reason why -texmf is huge is fonts and docs.  Both are about 1GB
 respectively.  The other tex-* ports that I committed/will commit are
 ones split from -base and -texmf in per functionality basis.  I will
 continue to split down them until the granularity reaches where the
 other ports require.  It means -base and -texmf will be shrunk (and
 the number of */tex-* ports will increase).

 -full always installs everything but most of ports which need TeX do
 not require it in building stage or runtime and blindly specifying
 this as a dependency is a pain for users.  So, every ports which
 require TeX must specify the minimal set of USE_TEX knobs.  We should
 complete this stage to go further.  I expect the number of split TeX
 ports will be ~100 (FYI, the number of ports which directly depend on
 TeX is currently around 150).  Some minimal installation options will
 also be added.

 This is my mid-term goal in 1-2 months.  Although modularization is
 also planned, it will be happened once we confirm the new ports work
 fine in the current shape.  I agree that the size of the distfiles is
 another pain, but it is what TeXLive is, unfortunately.

-- Hiroki


pgpEDHtyhe8Hj.pgp
Description: PGP signature

Re: [patch included] teTeX and TeXLive

[Hiroki Sato]

Christopher J. Ruwe c...@cruwe.de wrote
  in 20130517001153.1d7d4...@dijkstra.cruwe.de:

cj  de Thank you very much, however I have a install failure on poudriere
cj  de with ports tree up to date 5 minutes ago:
cj 
cj   Thank you for your report.  I have received several reports about
cj   install failures on poudriere and am investigating them.
cj 
cj  -- Hiroki
cj
cj Hello,
cj
cj I had exactly the same issue. I have a manual solution so far and am
cj trying out the automation from ports. I am posting my progress hoping
cj to save someone some time.

 Could you try r318346?

-- Hiroki


pgpSFJcFjoOqQ.pgp
Description: PGP signature

teTeX and TeXLive

[Hiroki Sato]

Hello,

 As you already noticed, TeXLive ports have been imported and one can
 choose teTeX or TeXLive while the default value for pre-compiled
 packages is still teTeX.

 If you want to use TeXLive, please try to use the following knob:

 TEX_DEFAULT= texlive

 To do this, almost all of ports which use TeX will depend on TeXLive.
 Although some ports which install a new TeX macro package may not
 work because of incompatibility such as difference of directory
 structure between the two, ones which use TeX for typesetting should
 work fine.  Ones to install macro packages which were non-standard in
 teTeX but are included in TeXLive will be fixed or removed.

 Please test TeXLive and send your failure report to me.  Once it is
 confirmed that TEX_DEFAULT=texlive works, I will switch the default
 value from tetex to texlive at some point.

-- Hiroki


pgpPCKVZwk_YU.pgp
Description: PGP signature

Re: TEX_DEFAULT problem

[Hiroki Sato]

RyōTa SimaMoto liangtai...@gmail.com wrote
  in CABDoUfCn5zw8GjcMqQ=u=_xmtxsobbiqjb1pecepi3bas7t...@mail.gmail.com:

li Hi,
li 
li Please resolve %%TEXMFDIR%% of devel/tex-kpathsea/pkg-plist
li that could be once unfolded with definition at Mk/bsd.tex.mk
li which you unloaded.  I have no idea where TEXMFDIR?=share/texmf
li should be suggested and processed in the PLIST_SUB variable list
li when USE_TEX macro is unavailable.

 Should be fixed now.  Thanks for the report.

-- Hiroki


pgpb2lCEGGVaI.pgp
Description: PGP signature

Re: TEX_DEFAULT problem

[Hiroki Sato]

Hiroto Kagotani hiroto.kagot...@gmail.com wrote
  in cac_w2ocakcnzkegw15ts6e8v35vaacywtbjy4m6vxxqtto7...@mail.gmail.com:

hi I am using ports tree of r317759.
hi
hi Without setting TEX_DEFAULT, tex-kpathsea depends on teTeX-base.
hi So, when I make print/texlive-full, installation stops by conflict with
hi teTeX-*.
hi
hi By setting TEX_DEFAULT=texlive in /etc/make.conf, there are cyclic
hi dependencies.
hi Here is the result of make in print/texlive-full.

 I already fixed this in r317773.

-- Hiroki


pgpcC8aEBEym0.pgp
Description: PGP signature

Re: Problem with japanese/tex-ptex going very slowly

[Hiroki Sato]

Hiroto Kagotani hiroto.kagot...@gmail.com wrote
  in cac_w2odjg2yt8df5aksiptyizghn8vuo_fxpd1xtxnvqu5z...@mail.gmail.com:

hi 2013/5/7 Hiroki Sato h...@freebsd.org
hi
hi  Stephen Montgomery-Smith step...@missouri.edu wrote
hiin 5187c454.2050...@missouri.edu:
hi 
hi  st Many thanks for creating the texlive port!
hi  st
hi  st I am trying to install the recent japanese/tex-ptex port.  It seems to
hi  st spend several hours doing:
hi  st
hi  st fmtutil: running `ptex -ini   -jobname=ptex -progname=ptex ptex.ini
hi  st #ptex' ...
hi 
hi 
hi I have exactly the same problem, ptex won't finish.
hi I am using a newly installed FreeBSD 9.1 virtual machine.
hi
hi
hi   No, it is odd.
hi 
hi   Can you send me the result of the following two commands?
hi 
hi   % grep -A2 lastarg /usr/local/bin/fmtutil
hi   % find /usr/local/share/texmf* $HOME/.tex*
hi 
hi
hi The first one is:
hi 
hi   eval lastarg=\$$#
hi   case $lastarg in
hi   \#*)  eval lastarg=\$$(($# - 1)) ;;
hi   esac
hi   inifile=`echo $lastarg | sed 's%^\*%%'`
hi
hi   # See if we can find $inifile for return code:
hi 
hi
hi And the result of % tail -3 /usr/local/share/texmf-config/web2c/fmtutil.cnf
hi ---
hi ptex ptex - ptex.ini#ptex
hi ptex eptex language.def *eptex.ini#ptex
hi platex eptex language.dat *platex.ini#ptex
hi ---
hi
hi I'm not sure why there are 2 ptex lines.
hi
hi The result of % find /usr/local/share/texmf* $HOME/.tex* is very huge.
hi Do you really need it?

 I have no idea unless the necessary information is provided.

-- Hiroki


pgp26ucNcLdbj.pgp
Description: PGP signature

Re: USE_TEX question

[Hiroki Sato]

Stephen Montgomery-Smith step...@missouri.edu wrote
  in 518bde81.3060...@missouri.edu:

st So I have a port, math/sage, which now contains in Makefile the line
st USE_TEX=tetex
st
st I have intalled the texlive ports.  So now if I try to install
st math/sage, it gives me error messages about CONFLICTS, which I think
st arise from the fact that math/sage thinks that it has to first install
st tetex, and this conflict with various texlive ports.
st
st But, math/sage is TEX agnostic.  It doesn't care whether it is tetex
st or texlive that is installed.  All it really wants to know is if there
st is a useable latex in PATH.
st
st It would be nice if there was a USE_TEX=yes option, or something like
st that, which I could put into the math/sage port.

 It is possible after r317744, but please wait until problem reports
 about the TeXLive ports are quieted down first.

-- Hiroki


pgpXYWWKgUt0X.pgp
Description: PGP signature

Re: Problem with japanese/tex-ptex going very slowly

[Hiroki Sato]

Anton Shterenlikht me...@bris.ac.uk wrote
  in 201305091538.r49fcwmj040...@mech-cluster241.men.bris.ac.uk:

me
me  Stephen Montgomery-Smith step...@missouri.edu wrote
mein 5187c454.2050...@missouri.edu:
me 
me  st Many thanks for creating the texlive port!
me  st
me  st I am trying to install the recent japanese/tex-ptex port.  It 
seems to
me  st spend several hours doing:
me  st
me  st fmtutil: running `ptex -ini   -jobname=ptex -progname=ptex 
ptex.ini
me  st #ptex' ...
me 
me 
me I have exactly the same problem, ptex won't finish.
me I am using a newly installed FreeBSD 9.1 virtual machine.
me
me same here on ia64 -current.
me However, killing the process and restarting helps.
me I now have:
me
me $ pkg info -xo full
me texlive-full-20120701: print/texlive-full

 Killing the process can lead to an incomplete installation.

 At this moment the best guess in my mind is some old TeXLive or teTeX
 installation in the home directory or somewhere prevented it from
 working, but I am not sure of the exact cause because of lack of
 information.

-- Hiroki


pgpVrCVzj5nW5.pgp
Description: PGP signature

Re: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130503.215135.1987071730491164980@allbsd.org:

hr hr  Thanks for the feedback!  A revised version is as follows:
hr hr
hr hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130501-1.diff
hr hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130501-1.tar.gz
hr hr
hr hr  In addition to fixing the spotted issues, toolchain handling has been
hr hr  fixed.  I am waiting for a report from one who got a build error on a
hr hr  10-CURRENT box.  Any comments are welcome.

 Another minor build issue when binutils package is installed has been
 fixed.

 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130508-1.tar.gz
 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130508-1.diff

 A brief summary of the changes is as follows:

  mozc_port_20130508-1.diff 
 - Add Japan Post zip code dictionary.
 - Add LICENSE.
 - Fix malformed BUILD_DEPENDS and remove unnecessary dependencies.
   Use USE_* in a consistent manner.
 - Fix inconsistency toolchain usage in build_tools and the others.
   Hardcoded g++ was always used only for the former even if both gcc
   and clang were available.
 - Enable -Werror.
 - Fix SSP issue on i386 platform.
 - Let cpp(1) to replace LOCALBASE instead of patching and sed(1).
 - Use GYP_DEFINES for build variables instead of patching.
 - Separate the stages of configuration and build from each other.
 - Add options for localbase and openssl-related configuration to gyp
   instead of patching.
 - Fix makesum target.
 - Fix whitespaces to make portlint happy.
 - Disable serialization for linking.  It is not needed.
 - Remove hardcoded mozc.xml.
 - Respect DISABLE_MAKE_JOBS=yes.  Do not calculate the factor using the
   number of CPUs.
 - Remove a confusing message after pkg-message.
 - Rename a deprecated function (inactivate-current-input-method-function)
   in mozc.el in a compatible fashion with the older emacsen [1].
 - Add leim-list.el for registration of mozc-mode via LEIM API.
   (require 'mozc) is no longer needed.
 - Fix a build problem when binutils is installed and ${LOCALBASE}/bin
   comes first in $PATH [2].

 Submitted by:   Tadaaki Nagao [1]
 Reported by:Kenichi Niioka [2]
 

-- Hiroki


pgpvjF47ni_np.pgp
Description: PGP signature

Re: pkg: tex-kpathsea-6.1.0 conflicts with tex-kpathsea-6.1.0

[Hiroki Sato]

Anton Shterenlikht me...@bris.ac.uk wrote
  in 201305071613.r47gdhdf075...@mech-cluster241.men.bris.ac.uk:

me On ia64 r247266 with ports at r317606:
me
me ===   Compressing manual pages for tex-kpathsea-6.1.0
me ===   Running ldconfig
me /sbin/ldconfig -m /usr/local/lib
me ===   Registering installation for tex-kpathsea-6.1.0
me Installing tex-kpathsea-6.1.0...pkg: tex-kpathsea-6.1.0 conflicts with 
tex-kpathsea-6.1.0 (installs files into the same place).  Problematic file: 
/usr/local/man/man1/kpseaccess.1.gz
me *** [fake-pkg] Error code 70
me
me Stop in /usr/ports/devel/tex-kpathsea.

 Can you send me installed package lists displayed by pkg info and
 pkg_info?

-- Hiroki


pgpf1kroNa_NR.pgp
Description: PGP signature

Re: [print/tex-formats] does not install share/texmf-var/web2c/tex/tex.fmt but /usr/ports/mk/bsd.tex.mk uses it

[Hiroki Sato]

Hi,

Boris Samorodov b...@passap.ru wrote
  in 51877bf5.9050...@passap.ru:

bs Hello Hiroki-san,
bs
bs Thank you for working on tex* ports!
bs
bs I have a problem installing print/tex-formats:

 Can you send me a whole log of the following commands?

 # cd /usr/ports/print/tex-formats
 # make deinstall clean
 # make package

 And I am interested in what was displayed by the following commands
 after make package failed:

 % cat /usr/local/share/texmf-config/web2c/fmtutil.cnf | grep -v ^#
 % find /root -name *texlive* -o -name *texmf*

-- Hiroki



pgpvx_RPAcMAm.pgp
Description: PGP signature

Re: Problem with japanese/tex-ptex going very slowly

[Hiroki Sato]

Stephen Montgomery-Smith step...@missouri.edu wrote
  in 5187c454.2050...@missouri.edu:

st Many thanks for creating the texlive port!
st
st I am trying to install the recent japanese/tex-ptex port.  It seems to
st spend several hours doing:
st
st fmtutil: running `ptex -ini   -jobname=ptex -progname=ptex ptex.ini
st #ptex' ...
st
st Is this normal?

 No, it is odd.

 Can you send me the result of the following two commands?

 % grep -A2 lastarg /usr/local/bin/fmtutil
 % find /usr/local/share/texmf* $HOME/.tex*

Stephen Montgomery-Smith step...@missouri.edu wrote
  in 5187c52e.8060...@missouri.edu:

st I installed the texlive-full port (without tex-ptex).  I tried to change
st the page size with the following command (as root):
st
st tlmgr paper letter
st cannot setup TLPDB in /usr at /usr/local/bin/tlmgr line 4965.

 Sorry, tlmgr still does not work and disabled intentionally at this
 moment because it can confuse installed files by FreeBSD's ports
 framework.  It will be fixed in the next update.

-- Hiroki


pgpGrSis3A0qZ.pgp
Description: PGP signature

Re: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130505.133807.335570424077607008@allbsd.org:

hr Tadaaki Nagao a...@shitamachi.org wrote
hr   in 20130505.112636.1254348787605646288.a...@shitamachi.org:
hr
hr ab Just one more thing I'd like to suggest:
hr ab 'deactivate-current-input-method-function' was introduced on Emacs 24.3
hr ab by renaming the misspelled 'inactivate-current-input-method-function'.
hr ab To retain our support for older Emacsen, how about the following as
hr ab patch-unix_emacs_mozc.el?
hr
hr  Ah, it makes sense.  Thank you for the suggestion.  A new patchset is
hr  available via the following URLs:
hr
hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130505-1.tar.gz
hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130505-1.diff

 I've added Japanese zipcode dictionary, too:

  http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130505-2.tar.gz
  http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130505-2.diff

 This patchset is now in a good shape for average users, though I am
 still working on build issue on big-endian platforms while mozc
 supports only LE in the original distribution.

-- Hiroki


pgpmxKSBqZ5fM.pgp
Description: PGP signature

Re: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20130505.163103.757541635420675768@allbsd.org:

hr  I've added Japanese zipcode dictionary, too:
hr
hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130505-2.tar.gz
hr   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130505-2.diff
hr
hr  This patchset is now in a good shape for average users, though I am
hr  still working on build issue on big-endian platforms while mozc
hr  supports only LE in the original distribution.

 Gr, I forgot to add leim-list.el to the patch.

  http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130505-3.tar.gz
  http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130505-3.diff

 After installing japanese/mozc-el, mozc is automatically added as an
 Emacs input method.  Note that noisy message may be displayed when
 both editors/tamago and mozc.el are installed.  It will be fixed on
 the Tamago side once mozc ports are updated.

-- Hiroki


pgpkznWE3f17x.pgp
Description: PGP signature

Re: mozc-server 1.10.1390.102_2 build fail

[Hiroki Sato]

Kenichi Niioka nii...@kk.iij4u.or.jp wrote
  in 20130428.234909.1246626834376249672@iij4u.or.jp:

ni Dear porters.
ni
ni I have following error with FreeBSD 10.0-CURRENT #0 r250017 amd64.
ni
ni $ cd /usr/ports/japanese/mozc-server
ni $ make
ni
ni [snip]

 Please try the following and let me know if they work or not:

 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130428-2.diff (patch)
 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130428-2.tar.gz 
(tarball of the patched ports)

-- Hiroki


pgpBJE2ZXKQYE.pgp
Description: PGP signature

Re: CFT: texlive ports

[Hiroki Sato]

Jeffrey Bouquet jeffreybouq...@yahoo.com wrote
  in 1362459608.22538.yahoomailclas...@web164006.mail.gq1.yahoo.com:

je Maybe off topic to this thread, but... [ reply at bottom]
...
je One of the three recent teTeX ports [that had minor version bumps] would not
je install without /usr/local/bin/grep being temporarily moved to use instead 
the
je one from base... it apparently stalled with a high CPU usage.

 Do you have a log when the installation failed?

-- Hiroki


pgpfhY2JhCVd6.pgp
Description: PGP signature

Re: CFT: texlive ports

[Hiroki Sato]

Hiroto Kagotani hiroto.kagot...@gmail.com wrote
  in cac_w2oem6ndybdmxrocsuup1w0dj20sfmjbednrd-cmdsaf...@mail.gmail.com:

hi 2013/2/28 Hiroki Sato h...@freebsd.org
hi
hi 
hihttp://people.allbsd.org/~hrs/FreeBSD/texlive-20130228-1.tar.gz
hi 
hi   Please try this instead.
hi 
hi
hi I tried this version and succeeded to install on 9.1R.
hi But I miss symlinks etex and lualatex in /usr/local/bin,
hi which was installed by the portshaker version.

 Thank you.  The following tarball should fix it:

 http://people.allbsd.org/~hrs/FreeBSD/texlive-20130301-1.tar.gz

-- Hiroki


pgpzcUGpXynV2.pgp
Description: PGP signature

Re: CFT: texlive ports

[Hiroki Sato]

Zhihao Yuan lich...@gmail.com wrote
  in cagsoruavw2ivat3k3ghnrglajujva9_4jwvuvzyp4jbz8l8...@mail.gmail.com:

li On Wed, Feb 27, 2013 at 10:11 AM, Anton Shterenlikht
li me...@bristol.ac.uk wrote:
li  for D in /usr/local/share/texmf /usr/local/share/texmf-dist 
/usr/local/share/texmf-local /usr/local/share/texmf-var; do  if [ -r $D/ls-R ]; 
then /usr/local/bin/mktexlsr $D; fi;  done
li
li Only the first dir presents on a clean installed system.  So...

 Thank you for the report.  A new version which fixes this issue can
 be found at:

  http://people.allbsd.org/~hrs/FreeBSD/texlive-20130228-1.tar.gz

 Please try this instead.

-- Hiroki


pgp6Z3BrHErez.pgp
Description: PGP signature

Re: CFT: texlive ports

[Hiroki Sato]

Stephen Montgomery-Smith step...@missouri.edu wrote
  in 512ed882.2030...@missouri.edu:

st -BEGIN PGP SIGNED MESSAGE-
st Hash: SHA1
st
st On 02/27/2013 07:10 PM, Hiroki Sato wrote:
st
st  http://people.allbsd.org/~hrs/FreeBSD/texlive-20130228-1.tar.gz
st
st It built successfully.  But when I tried to run the command
st tlmgr
st I got the following error message:
st Can't locate TeXLive/TLConfig.pm in @INC (@INC contains:
st /usr/texmf/scripts/texlive /usr/tlpkg
st /usr/local/lib/perl5/5.14.2/BSDPAN
st /usr/local/lib/perl5/site_perl/5.14.2/mach
st /usr/local/lib/perl5/site_perl/5.14.2 /usr/local/lib/perl5/5.14.2/mach
st /usr/local/lib/perl5/5.14.2 .) at /usr/local/bin/tlmgr line 81.
st BEGIN failed--compilation aborted at /usr/local/bin/tlmgr line 81.
st
st tlmgr is rather important, for example, it allows me to set the
st default page size (us-letter or A4).
st
st tlmgr does work on my version of texlive:
st http://people.freebsd.org/~stephen/ (but my version has other flaws so
st I would prefer that your version worked).

 Ah, yes, tlmgr is not supported in the patchset yet, but I am
 planning to add it as a separate port which will be installed as a
 dependency of print/texlive-full.  Package management tools in
 TeXLive tend to conflict with our ports framework, so patching them
 to minimize the impact is planned.

-- Hiroki


pgpeO_ZpUu3sd.pgp
Description: PGP signature

CFT: texlive ports

[Hiroki Sato]

Hello,

 Ports to replace print/*teTeX* with TeX Live 2012 are ready for
 testing.  Please note that this is not the final version and
 committing the new ones into the ports tree will go in the following
 phases:

  1. Commit print/texlive-full for full version of TeX Live.

  2. Update ports which depend on teTeX to make them possible to
 select teTeX or TeX Live.  teTeX by default at this phase.  Split
 TeX Live ports into smaller ones as necessary in parallel.

  3. Switch the default to TeX Live.

  4. Remove print/*teTeX*.

 The patch for phase 1 can be found at the following URL:

  http://people.allbsd.org/~hrs/FreeBSD/texlive-20130227-1.tar.gz

 This consists of the following ports:

  print/texlive-full
  print/texlive-base
  print/texlive-texmf
  print/tex-ptexenc
  print/xetex
  print/luatex
  devel/kpathsea
  devel/web2c

 Please try to install print/texlive-full.  The total size of the
 installed files will be ~3GB, so be careful of free space on your
 disk.  While these ports still include some rough edges, all bits of
 the TeX Live 2012 should be installed.  Note that they cannot coexist
 with the other TeX-related ports based on teTeX---this means you need
 to remove all of TeX-related ports first.  If you want a stable
 version, please wait for migration procedure which will be submitted
 in the end of phase 2.

 Non-English engines like pTeX also work but dviware (xdvi, dvips,
 dvipdfmx, ...) for them and non-standard font maps are not included
 (or activated) yet.  They will be added when updating the existing
 ports for the engine-specific versions of dviware.

 Some combinations of the ports on which TeX Live depends may lead to
 a build problem due to version mismatch.  If you notice build failure
 or something wrong with the behavior, please send a report to me
 directly via email.  Thank you.

-- Hiroki


pgpZD9k6FPMrv.pgp
Description: PGP signature

Re: New version of TeX?

[Hiroki Sato]

Nathan Whitehorn nwhiteh...@freebsd.org wrote
  in 5129044b.20...@freebsd.org:

nw On 02/16/13 14:41, Hiroki Sato wrote:
nw   I will start to commit a bunch of ports based on
nw   texlive-20120701-source in this week.  At first they are several big
nw   ports (much like Dominic's one), then will be split into smaller ones
nw   to support the existing TeX-related packages, and print/teTeX* will
nw   be removed eventually.
nw 
nw  -- Hiroki
nw 
nw
nw Any news here?

 Going steadily.  After ports/176399 is cleared, I will commit
 full-version of TeXLive first.

-- Hiroki


pgpQ2mIWF8ZtU.pgp
Description: PGP signature

Re: New version of TeX?

[Hiroki Sato]

Chris Rees cr...@freebsd.org wrote
  in CADLo8388+-47_nqrGWJs3ioGcwrjdKKE=n0-exudwaz-afk...@mail.gmail.com:

cr On 6 February 2013 13:50, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
cr  On 02/05/13 21:01, Dominic Fandrey wrote:
cr  On 04/02/2013 21:08, Boris Samorodov wrote:
cr  04.02.2013 10:21, Dominic Fandrey пишет:
cr  On 04/02/2013 02:04, Danilo Egea wrote:
cr  Well, there is this project http://code.google.com/p/freebsd-texlive/
cr 
cr  http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171571
cr 
cr  I use the patch from this PR together with the attached diff
cr  and portmaster seems to DTRT with dependencies.
cr 
cr  Seeing that someone else actually uses it, I just attached a little
cr  update fixing a problem I discovered only a couple of days ago. I
cr  recommend you to install texlive-base again.
cr 
cr  Also I think it would be nice if you attached your patches to the PR.
cr 
cr  Regards
cr 
cr 
cr  Is there any chance this could be committed now pending a longer-term
cr  rearchitecture of the TeX stuff? I just installed it on three machines
cr  (thanks!) with no trouble at all and everything is working perfectly.
cr  Waiting for some long-term solution seems to be making the perfect the
cr  enemy of the good -- and this Friday will mark 8 years since the last
cr  teTeX update.
cr 
cr I would very much like to put Dominic's version in (for no particular
cr reason other than simplicity, and it was the first I looked at-- I
cr can't see any major advantage of one over the other).
cr 
cr Hiroki-san, can we please move this forward?  I'm happy to test and
cr commit this one.  If the worst comes to the worst, we could have
cr alternative TeXLive ports accompanied by a USE_LATEX knob and
cr bsd.latex.mk

 I will start to commit a bunch of ports based on
 texlive-20120701-source in this week.  At first they are several big
 ports (much like Dominic's one), then will be split into smaller ones
 to support the existing TeX-related packages, and print/teTeX* will
 be removed eventually.

-- Hiroki


pgpW07EKw8KRR.pgp
Description: PGP signature

Re: ${name}_fib fix in rc.d script (ports/173366)

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20121118.031240.1840537590824524280@allbsd.org:

hr Hello,
hr
hr  I will commit the attached patch for the following today to fix a
hr  breakage of the rc.d script after ${name}_fib is introduced into
hr  rc.subr:
hr
hr   net/sslh
hr   www/apache22
hr   www/cblog
hr   www/fcgiwrap
hr   www/shellinabox
hr   www/squid
hr   www/squid31
hr   www/squid32
hr   net/sslh
hr
hr  The change should be compatible with both of the older releases and
hr  head.  If this commit is not convenient for you or there is something
hr  wrong with it, please let me know as soon as possible.  Thank you.

 I committed the patch just now.  If you notice there is something
 wrong with it, please let me know.  Thank you.

-- Hiroki


pgpc0G0nWseDJ.pgp
Description: PGP signature

${name}_fib fix in rc.d script (ports/173366)

[Hiroki Sato]

Hello,

 I will commit the attached patch for the following today to fix a
 breakage of the rc.d script after ${name}_fib is introduced into
 rc.subr:

  net/sslh
  www/apache22
  www/cblog
  www/fcgiwrap
  www/shellinabox
  www/squid
  www/squid31
  www/squid32
  net/sslh

 The change should be compatible with both of the older releases and
 head.  If this commit is not convenient for you or there is something
 wrong with it, please let me know as soon as possible.  Thank you.

-- Hiroki
Index: net/sslh/Makefile
===
--- net/sslh/Makefile	(revision 307518)
+++ net/sslh/Makefile	(working copy)
@@ -7,6 +7,7 @@

 PORTNAME=	sslh
 PORTVERSION=	1.13
+PORTREVISION=	1
 CATEGORIES=	net
 MASTER_SITES=	http://www.rutschle.net/tech/

Index: net/sslh/files/sslh.in
===
--- net/sslh/files/sslh.in	(revision 307518)
+++ net/sslh/files/sslh.in	(working copy)
@@ -17,7 +17,6 @@
 # sslh_mode=fork | select
 # fork: stable but slow performance
 # select: new but high performance
-# sslh_fib=NONE
 # sslh_pidfile=/var/run/sslh.pid
 # sslh_ssltarget=localhost:443
 # sslh_sshtarget=localhost:22
@@ -26,9 +25,13 @@
 # sslh_uid=nobody
 # sslh_flags

-sslh_setfib() {
+sslh_precmd() {
+	if command -v check_namevarlist  /dev/null 21; then
+		check_namevarlist fib  return 0
+	fi
 	sysctl net.fibs /dev/null 21 || return 0

+	sslh_fib=${sslh_fib:-NONE}
 	case $sslh_fib in
 	[Nn][Oo][Nn][Ee])
 		;;
@@ -43,14 +46,13 @@
 name=sslh
 rcvar=sslh_enable

-start_precmd=sslh_setfib
+start_precmd=sslh_precmd
 stop_postcmd=sslh_postcmd

 load_rc_config $name

 sslh_enable=${sslh_enable:-NO}
 sslh_mode=${sslh_mode:-fork}
-sslh_fib=${sslh_fib:-NONE}
 sslh_listening=${sslh_listening:-0.0.0.0:443}
 sslh_sshtarget=${sslh_sshtarget:-localhost:22}
 sslh_ssltarget=${sslh_ssltarget:-localhost:8443}
Index: www/apache22/Makefile
===
--- www/apache22/Makefile	(revision 307518)
+++ www/apache22/Makefile	(working copy)
@@ -2,7 +2,7 @@

 PORTNAME=	apache22
 PORTVERSION=	2.2.23
-#PORTREVISION=	1
+PORTREVISION=	1
 CATEGORIES=	www ipv6
 MASTER_SITES=	${MASTER_SITE_APACHE_HTTPD}
 DISTNAME=	httpd-${PORTVERSION}
Index: www/apache22/files/apache22.in
===
--- www/apache22/files/apache22.in	(revision 307518)
+++ www/apache22/files/apache22.in	(working copy)
@@ -47,7 +47,6 @@
 [ -z $apache22limits_enable ]  apache22limits_enable=NO
 [ -z $apache22limits_args ]apache22limits_args=-e -C daemon
 [ -z $apache22_http_accept_enable ]  apache22_http_accept_enable=NO
-[ -z $apache22_fib ]  apache22_fib=NO

 apache22_accf() {

@@ -174,9 +173,13 @@
 }

 apache22_checkfib () {
-	$SYSCTL net.fibs /dev/null 21
-	ret=$?
- 	[ $ret -gt 0 ]  return 0
+	if command -v check_namevarlist  /dev/null 21; then
+		check_namevarlist fib  return 0
+	fi
+
+	$SYSCTL net.fibs /dev/null 21 || return 0
+
+	apache22_fib={apache22_fib:-NO}
 	if [ x$apache22_fib != xNO ]
 	then
 		command=/usr/sbin/setfib -F ${apache22_fib} ${command}
Index: www/cblog/Makefile
===
--- www/cblog/Makefile	(revision 307518)
+++ www/cblog/Makefile	(working copy)
@@ -7,6 +7,7 @@

 PORTNAME=	cblog
 PORTVERSION=	0.1.6
+PORTREVISION=	1
 CATEGORIES=	www
 MASTER_SITES=	http://files.etoilebsd.net/cblog/

Index: www/cblog/files/cblog.in
===
--- www/cblog/files/cblog.in	(revision 307518)
+++ www/cblog/files/cblog.in	(working copy)
@@ -13,7 +13,6 @@
 # cblog_enable=YES
 #
 # You can fine tune others variables too:
-# cblog_fib=NONE
 # cblog_socket=unix:/var/run/cblog/cblog.sock
 # syntax can be :
 # unix:/patch/to/socket
@@ -21,8 +20,13 @@
 # Use cblog_user to run cblog as user

 cblog_setfib() {
-	sysctl net.fibs /dev/null 21 || return 0
+	if command -v check_namevarlist  /dev/null 21; then
+		check_namevarlist fib  return 0
+	fi

+	${SYSCTL} net.fibs /dev/null 21 || return 0
+
+	cblog_fib=${cblog_fib:-NONE}
 	case $cblog_fib in
 	[Nn][Oo][Nn][Ee])
 		;;
@@ -48,7 +52,6 @@

 load_rc_config $name
 cblog_enable=${cblog_enable:-NO}
-cblog_fib=${cblog_fib:-NONE}
 cblog_user=${cblog_user:-root}
 cblog_socket=${cblog_socker:-unix:/var/run/cblog/cblog.sock}

Index: www/fcgiwrap/Makefile
===
--- www/fcgiwrap/Makefile	(revision 307518)
+++ www/fcgiwrap/Makefile	(working copy)
@@ -7,7 +7,7 @@

 PORTNAME=	fcgiwrap
 PORTVERSION=	1.0.3
-PORTREVISION=	4
+PORTREVISION=	5
 CATEGORIES=	www
 MASTER_SITES=	http://cloud.github.com/downloads/gnosek/fcgiwrap/

Index: www/fcgiwrap/files/fcgiwrap.in
===
--- www/fcgiwrap/files/fcgiwrap.in	(revision 307518)
+++ www/fcgiwrap/files/fcgiwrap.in	(working copy)
@@ -13,7 +13,6 @@
 # fcgiwrap_enable=YES
 #
 # You can 

Re: huge distfiles policy

[Hiroki Sato]

Romain Tartière rom...@freebsd.org wrote
  in 20120930153124.ga4...@blogreen.org:

ro Hi!
ro 
ro On Sun, Sep 30, 2012 at 12:17:03AM +0200, Baptiste Daroussin wrote:
ro  My second concern was discussed when Dominic Fandrey called for testing 
this
ro  port: at least 2 people have been working on texlive with different 
approach:
ro  hrs and romain.
ro  
ro  In particular Romain and I discussed on merging texlive to the ports tree 
based
ro  on http://code.google.com/p/freebsd-texlive/ he has been contacted some 
company
ro  to mirror the splitted distfiles for us, and was suppose to resumer his 
work on
ro  this when back from vacations which should be the case now given that he 
has
ro  done some commit last week :D
ro  
ro  I CCed both hrs and romain so they can give their opinion and the status 
of
ro  their work.
ro 
ro Yes, after 2 months away, I am back :-)
ro 
ro While I was away,
ro   - I received access to a jail for hosting versionned distfiles;
ro   - I received a mail from hrs@ where he exposes a migration plan to
ro TeX Live and asked for comments / suggestions.
ro 
ro I replied to hrs@ and told him I would be happy to help, but have no
ro feedback yet.
ro 
ro Regarding the mirror of versionned distfiles, I have everything to set
ro it up I think, and I just have to take some time to hack something that
ro do the right thing and use it in my ports.  However, since there are
ro some boring flaws in the updating infrastructure, I postponed this,
ro thinking that an answer from hrs@ would have lead to working on funnier
ro things (with a better infrastructure).  While I have no news, I may
ro however setup the repository, it won't hurt I guess.

 Sorry, I was swamped with real life issues and could not respond in a
 timely manner.  In short, what I am working on is splitting the
 texlive distribution into pieces about ~200 ports (tex engines and
 macro packages) and generating versioned distfiles from a local CTAN
 mirror.  A port just for installing whole part of texlive is
 difficult to handle in the ports tree because there are many software
 that have to depend on a part of it but texlive is really huge.  I am
 considering to remove print/teTeX* (since I am the maintainer) and
 update the dependencies to use the modular texlive ports seamlessly.

 I have several prototype but I need to fix them to some recent
 changes in the ports tree before making one public for review.
 Although I was thinking it could be done in September, it didn't
 unfortunately.  I will continue to work on it and probably make it in
 public after EuroBSDCon.

-- Hiroki


pgpRvkpcf2XRr.pgp
Description: PGP signature

Re: print/ghostscript9 build fail : vga.h not found

[Hiroki Sato]

Florent Peterschmitt fpeters...@gmail.com wrote
  in 4fe67fb7.30...@gmail.com:

fp On 24.06.2012 02:46, Hiroki Sato wrote:
fp  Florent Peterschmitt fpeters...@gmail.com wrote
fp in 4fe1b98b.5040...@gmail.com:
fp 
fp  fp gmake: *** [so] Erreur 2
fp  fp *** Error code 1
fp  fp
fp  fp Stop in /usr/ports/print/ghostscript9.
fp  fp *** Error code 1
fp  fp
fp  fp Stop in /usr/ports/print/ghostscript9.
fp  fp
fp  fp Problem : no vga.h in my system, even in source tree.
fp 
fpprint/ghostscript9 depends on graphics/svgalib which provides vga.h.
fpPlease check if svgalib is installed properly.
fp 
fp  -- Hiroki
fp graphics/svgalib is installed, but even after deinstall and reinstall,
fp no vga.h and vgagl.h. Manual copy from work build directory of svgalib
fp to /usr/local/include of these two files makes print/ghostscript9
fp build.
fp
fp Should I submit a PR to svgalib ?

 If you do not have vga.h after installing graphics/svgalib there is
 something wrong with your system, I think.  Submitting a PR may be
 useful, but you need to describe the details of installed files and
 the build log on your system at least.

-- Hiroki


pgpJDWuPVNPzI.pgp
Description: PGP signature

Re: print/ghostscript9 build fail : vga.h not found

[Hiroki Sato]

Florent Peterschmitt fpeters...@gmail.com wrote
  in 4fe1b98b.5040...@gmail.com:

fp gmake: *** [so] Erreur 2
fp *** Error code 1
fp
fp Stop in /usr/ports/print/ghostscript9.
fp *** Error code 1
fp
fp Stop in /usr/ports/print/ghostscript9.
fp
fp Problem : no vga.h in my system, even in source tree.

 print/ghostscript9 depends on graphics/svgalib which provides vga.h.
 Please check if svgalib is installed properly.

-- Hiroki


pgpQt9rBjTjdK.pgp
Description: PGP signature

Re: Request to review: print/texlive-install

[Hiroki Sato]

Chris Rees cr...@freebsd.org wrote
  in CADLo8380zGtCETzGrKzMrD_3Fwm2bZOMpEFLupaD_=mpu5k...@mail.gmail.com:

cr On 28 May 2012 18:11, Stephen Montgomery-Smith step...@missouri.edu wrote:
cr  On 05/28/2012 11:35 AM, Gábor Kövesdán wrote:
cr 
cr  On 2012.05.28. 18:16, Stephen Montgomery-Smith wrote:
cr 
cr 
cr 
cr  On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote:
cr 
cr 
cr  How about if I add lines like this:
cr 
cr  .if !defined(IGNORE_SECURITY_RISK)
cr  IGNORE= has a security risk because it downloads a file \
cr  without a checksum. Define IGNORE_SECURITY_RISK to build this port
cr  .endif
cr 
cr  Would it be considered OK to commit it then?
cr 
cr  could you host it somewhere that won't go away at missouri.edu?
cr 
cr 
cr 
cr  I could host it somewhere at missouri.edu that will stay as long as I
cr  am alive or keep my job.
cr 
cr  Better to host it on the FreeBSD mirrors. You only have to create a
cr  public_distfiles in your home directory after logging in to freefall and
cr  drop the file there. This is the usual way of doing it.
cr 
cr 
cr  Thank you for the info.  Here is my latest version:
cr 
cr  http://people.freebsd.org/~stephen/
cr 
cr 
cr I'm afraid my concerns still hold [1].
cr 
cr This port fetches $WHOKNOWSWHAT from $WHOKNOWSWHERE outside the fetch
cr stage, which isn't how ports are supposed to work.
cr 
cr I know 'having a port' is usually considered a good thing, but as I
cr said before, it's no easier or safer to install this via the port than
cr just download and run the script.
cr 
cr Also, on deinstall/upgrade the port will clobber anything that was
cr there on install (automatic plist generation also sucks in anything
cr that was there) [2].

 I also think this port is too tricky.  Although I do understand one
 big package for texlive is easy to install and it will be one which
 can satisfy many people, it should get along with the ports
 framework---I do not think defining IGNORE_SECURITY_RISK is what we
 want to do.

 I spent a lot of time for teTeX-to-texlive migration in the ports
 tree but I could not accomplish it actually so far since I could find
 only a suboptimal solution.  Importing a texlive port should replace
 the current teTeX ports at one burst because there are many ports
 which depend on TeX.  I may not be qualified to say no here because
 I have not been able to create an alternative for a long time, but
 adding a texlive port with no specific migration plan would make the
 ports tree confused.

 I have created and used a prototype which consists of modularized
 texlive ports (~200 ports) generated from macro package list in
 texlive source and metadata from texlive.tlpdb to replace
 print/teTeX* in the tree completely.  It is because strong demands
 for modularity and/or smaller configurations from TeX users who are
 using it in non-X11 environment, for example, still remain.  It has
 worked, but one big problem is that it is not compatible with tlmgr.
 If people use a tlmgr-like tool to download and install a macro
 package instead of the ports, the texmf tree will be broken easily.
 In addition, inconsistency between package database and actually
 installed files breaks our ports framework in various ways.  Trouble
 reports on print/teTeX* ports I received were mostly due to broken
 texmf trees, so I am feeling this should be mitigated in some way.

 I can post the port set with disabling some of tlmgr's capability
 (package install/removal part).  Is it still an interesting one for
 people?

-- Hiroki


pgp8H7WvvfUDW.pgp
Description: PGP signature

Re: print/libpaper problem

[Hiroki Sato]

Boris Samorodov b...@passap.ru wrote
  in 4f5075cc.9010...@passap.ru:

bs So what if install a system wide default paper size while installing
bs print/libpaper? That may help both in gs case (when a binary is linked
bs with libpaper) and those that just use libpaper if it is installed.

 No.  defaultpapername() returns a constant value at compile time.
 Nothing to do with the $PREFIX/etc/papersize file.

bs   I think WITH_A4SIZE option should be deprecated at some point and the
bs   default paper size can be selected by libpaper in run-time because it
bs   will be more consistent and flexible,
bs
bs I'd propose to leave a system wide default variable for a paper size.
bs I don't care if it is WITH_A4SIZE, DEFAULT_PAPERSIZE=A4 or else.
bs
bs  but the current code in gs
bs   prevents it because it uses defaultpapername(), not systempapername()
bs   for some reason.
bs 
bs   So, the functionality the libpaper provides in gs is only to define
bs   /DEFAULTPAPERSIZE but it is confusing due to the above reason.  This
bs   was why I decided to disable libpaper at this moment.
bs
bs Yea, but those who will choose that non-default option and install
bs print/libpaper (in current state, i.e. without installing
bs /usr/local/etc/papersize file) will fall in trouble anyway.

 What is the non-default option and what trouble will occur by it?

-- Hiroki


pgp68RX1s1qAT.pgp
Description: PGP signature

print/ghostscript9 fix

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 201202130231.q1d2vixp051...@repoman.freebsd.org:

hr hrs 2012-02-13 02:31:18 UTC
hr
hr   FreeBSD ports repository
hr
hr   Modified files:
hr print/ghostscript9   Makefile
hr print/ghostscript9/files patch-base-Makefile.in
hr   Added files:
hr print/ghostscript9/files patch-base-openjpeg.mak
hr  patch-openjpeg-libopenjpeg-opj_includes.h
hr  patch-openjpeg-libopenjpeg-opj_malloc.h
hr   Log:
hr   Add missing patches.  This should fix build on !amd64 platforms.

 This commit should fix the build breakage in the openjpeg related
 files.  If the compile error still persists even after this, please
 let me know.

-- Hiroki


pgpTz9cueUaaw.pgp
Description: PGP signature

acroread8/9 cups support (Re: acroead8 and libcups dependencies)

[Hiroki Sato]

Da Rock freebsd-po...@herveybayaustralia.com.au wrote
  in 4f139c43.1050...@herveybayaustralia.com.au:

fr I'm trying to contact the maintainer of the acroread ports to see if
fr they can put in a dependency on linux-f10-cups-libs for the ease of
fr use by general users, and to enable acceptance by the graphics
fr industry niche.

Cejka Rudolf cej...@fit.vutbr.cz wrote
  in 2002110904.ga...@fit.vutbr.cz:

ce   do you have plans to add support for cups printing from acroread9-9.4.2?

 I added CUPS support into both acroread8 and acroread9.  It seems
 working as far as I can check all versions in the ports tree, but
 please test them.  Thank you.

-- Hiroki


pgpBi2Ilo8Ev4.pgp
Description: PGP signature

Re: Clicking URLs with acroread8

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4ee6dce1.5090...@freebsd.org:

do On 12/09/2011 16:14, Doug Barton wrote:
do  I receive PDF documents with URLs that I need to click, and so I would
do  like to get that working in acroread8. I symlink'ed firefox into
do  /compat/linux/usr/local/bin, and set the preferences in acroread
do  accordingly. That got me from a firefox not found error to this,
do  printed out in the terminal:
do 
do  libfam.so.0: cannot open shared object file: No such file or directory
do  Failed to load module: /usr/lib/gio/modules/libgiofam.so
do 
do  Since I have that lib installed as a result of the linux-base port, I
do  assume that what is missing is something that it depends on.
do 
do  Any help resolving this is welcome.
do 
do  Alternatively, if I could extract the URL from the link, that'd be
do  awesome too. :)
do
do I tried everyone's suggestions, no luck.
do
do Adding the gamin port prevents the error, but doesn't make the url
do clicking work.
do
do I tried an sh version of Sean's script, caused my system to lock up
do completely.
do
do I tried 'export LD_LIBRARY_PATH='' ; acroread8 file.pdf' and got a long
do wristwatch icon, but never any actual result.

 Hmm, can you see what happens by specifying a script which contains
 the following in the browser command field and clicking a URL, and
 then invoking firefox at command line prompt with the arguments and
 the environment variables found in /tmp/env.log?

 #!/bin/sh
 (echo $@; env )  /tmp/env.log

 I think by doing it we can see whether browser invocation works or
 not.

-- Hiroki


pgpWh5ZFkbebt.pgp
Description: PGP signature

Re: Clicking URLs with acroread8

[Hiroki Sato]

Doug Barton do...@freebsd.org wrote
  in 4ee2a456@freebsd.org:

do I receive PDF documents with URLs that I need to click, and so I would
do like to get that working in acroread8. I symlink'ed firefox into
do /compat/linux/usr/local/bin, and set the preferences in acroread
do accordingly. That got me from a firefox not found error to this,
do printed out in the terminal:
do
do libfam.so.0: cannot open shared object file: No such file or directory
do Failed to load module: /usr/lib/gio/modules/libgiofam.so
do
do Since I have that lib installed as a result of the linux-base port, I
do assume that what is missing is something that it depends on.
do
do Any help resolving this is welcome.

 Does the following command line do the trick on your environment?

  % acroread8 -setenv LD_LIBRARY_PATH=

 The LD_LIBRARY_PATH set by the acroread script often prevents a
 utility invoked in Acrobat Reader from working.

-- Hiroki


pgprifNYDzZHT.pgp
Description: PGP signature

Re: TeXLive

[Hiroki Sato]

Romain Tartière rom...@freebsd.org wrote
  in 20111011101902.gb14...@blogreen.org:

ro Hello!
ro 
ro On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote:
ro  On 10/10/2011 06:44 AM, Eitan Adler wrote:
ro   Are there any plans on getting these committed to the mainline ports
ro   tree? I'd be willing to work with you on that.
ro  
ro  I agree with Eitan.
ro 
ro I would also be pleased to see TeXLive in the FreeBSD ports (obviously).
ro There are a few issues to sort out before however:
ro   - The way TeXLive sources are distributed is not convenient: all
ro binaries are built and installed from a single sources tarball.
ro This leads to the big print/texlive-core but really lacks
ro scalability.  Back in 2008, Hiroki Sato was working on splitting all
ro this AFAICR.  Hiroki, I added you in Cc, can you please tell us if
ro you had any progress on this topic?

 I feel guilty about this because although I had/have several
 prototypes and plans to integrate TeXLive into the ports tree, it
 have not actually happened so far.  There were two obstacles in the
 work.  One was there were technical issues (compatibility-related)
 that prevented some existing TeX-related software we had in the ports
 tree from working.  This was in around 2007 but solved now.  Another
 one was how many ports we should have for TeX-related software.
 After testing several prototypes including a single port version, a
 set of ~2000 ports (one port for one macro), ~150 ports, or ~30
 ports, I think it seems good for us to have one of basic utilities,
 one for basic (stripped-down) macro sets as something like
 texlive-core + texlive-texmf, and the others for optional macro
 packages.  The basic idea is the same among them regardless of the
 total number of ports.  In practical, 100 would be the maximum
 number.

 So, primary issues described above were basically solved.  Although
 there are still trivial issues such as handling of a large distfile,
 it is not difficult to solve.  However, how to handle updating a
 macro package in the basic port is a problem to me and time passed
 when I was thinking about that.  More specifically, currently we have
 many latex-* and tex-* ports to install new macro packages or
 override the default ones.  It becomes complex over time.  Committing
 a single large TeXLive port is easy, but I do not want to create the
 same situation again in the new world and want consistency for
 updating a macro package in the distribution.  So, I wanted some
 compatibility with TeXLive's package management utility (tlmgr).
 Unfortunately it was too premature when I first looked into it
 (around 2007, IIRC).  The current version is much better than before,
 but I still need some investigation about that.  If we have or use
 reliable package catalogs of CTAN including file lists of each macro
 package via tlmgr or something, we can take an approach like BSDPAN,
 I think.

 A version based on TeXLive 2011 with a small number of ports can be
 committed if we ignore the last concern and clean up the current
 teTeX-related ports.  Any comments about that?

 I am very sorry for being unresponsive to many people who contacted
 me about that...

-- Hiroki


pgpC4zaNhW7Wb.pgp
Description: PGP signature

Re: ports/153337: print/acroread9: terminate called after throwing an instance of 'RSException'

[Hiroki Sato]

O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote
  in 4de28663.5080...@mail.zedat.fu-berlin.de:

oh On 05/29/11 19:30, h...@freebsd.org wrote:
oh  Synopsis: print/acroread9: terminate called after throwing an instance
oh  of 'RSException'
oh 
oh  State-Changed-From-To: suspended-closed
oh  State-Changed-By: hrs
oh  State-Changed-When: Sun May 29 17:29:50 UTC 2011
oh  State-Changed-Why:
oh  This issue should be fixed in the latest version.  Please give it a
oh  try.
oh 
oh  http://www.freebsd.org/cgi/query-pr.cgi?pr=153337
oh
oh No. Negative. Still the same issue on FreeBSD
oh 9.0-CURRENT/amd64. Suggest you reopen it.

 Did you really try the latest one which I committed 20 min ago?

-- Hiroki


pgpemjS1IQMRA.pgp
Description: PGP signature

:${foo_enable:=NO} in rc.d script

[Hiroki Sato]

Hi,

 This may be discussed already but I could not find which was correct,
 so please point out it if we already have a consensus...

 Well, I am wondering if an rc.d script installed by a port must have
 : ${foo_enable:=NO} line.  An example in the porter's handbook
 includes this, and I can understand it works fine.  My question is
 this is really needed or not.

 When $foo_enable is not defined, checkyesno() displays WARNING:
 $foo_enable is not set properly - see rc.conf(5) and it is
 interpreted as NO.  I was thinking this message is useful for letting
 people know which knob(s) should be configured by themselves after
 the installation, but recently someone pointed out this was not
 consistent and the default value should be defined as NO in the
 script.

 I can understand setting it as NO by default and allowing a user to
 override YES/NO in rc.conf work fine and intuitive.  However, is
 there a case that the $foo_enable is set as YES by default?  If not,
 what is the reason why the warning is displayed instead of simply
 thinking it as NO when $foo_enable is undefined?

 My feeling is that 1) $foo_enable should be interpreted as NO if not
 defined and a user should configure it (YES/NO) by herself after the
 installation, and 2) other variables like $foo_flags or $foo_pidfile
 should have their default values to allow the software be able to run
 simply by adding a line foo_enable=YES into rc.conf.

 While I do not have a strong opinion on 1), I am not sure if it is
 the correct interpretation.  Setting the variable as NO by default
 will make the warning message disappear, but in that case it is
 difficult for the user to find the knobs.  And if it is equivalent to
 NO when the variable is not defined, I don't understand what is the
 advantage of setting it as NO explicitly by default.

 Since most of ports I am maintaining do not have this line, I need to
 fix them if setting the variable as NO consistently is preferable.

-- Hiroki


pgpv4P0QQ26b8.pgp
Description: PGP signature

Re: Massive port bloat caused by the recommended en-freebsd-doc

[Hiroki Sato]

Peter Olsson p...@leissner.se wrote
  in 1269804756.2864.94.ca...@x61s:

po I added no options to the configs that were displayed, just removed some
po (e.g. X11 from ghostscript IIRC). I'm not so concerned with the time
po that passed, I'm just shocked by the number of ports that got installed.
po
po I'm glad this was a test install, I won't install en-freebsd-doc again.
po I suggest a big warning sign on the installation page which recommends
po installing en-freebsd-doc. Anyway, no worries and keep up the very good
po work you do with FreeBSD.

 This is because building the documentation set needs a bunch of
 toolchains.  If you want this but not want to install the toolchains,
 install it by using the corresponding packages.

-- Hiroki


pgpadR3lFVLZM.pgp
Description: PGP signature

Re: Attempted upgrade of ghostscript8-8.64_7 - ghostscript-8.70 failed

[Hiroki Sato]

David Wolfskill da...@catwhisker.org wrote
  in 20091220133238.gr...@bunrab.catwhisker.org:

da On Sun, Dec 20, 2009 at 01:27:31PM +, Anton Shterenlikht wrote:
da  ...
da   (Though I note that 
/bkp/ports/print/ghostscript8/work/ghostscript-8.70/base/
da   does seem to be populated with several other files.)
da 
da  is this i386?
da
da Aye
da
da  I reported this already for sparc and ia64:
da  http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058432.html
da
da Ah, yes -- I reall you did... (sorry; I glanced at the note for ia64
da and made a silly assumption -- and I know what *that* means).

 Fixed just now.  This build error occurred only when WITH_FT_BRIDGE
 was enabled regardless of the platform.

-- Hiroki


pgpI8AZITeXef.pgp
Description: PGP signature

Re: Attempted upgrade of ghostscript8-8.64_7 - ghostscript-8.70 failed

[Hiroki Sato]

Jamie Griffin j...@koderize.com wrote
  in 20091221005442.ga54...@bsdbox.koderize.com:

jg On Mon, Dec 21, 2009 at 02:06:39AM +0900, Hiroki Sato wrote:
jg
jg   Fixed just now.  This build error occurred only when WITH_FT_BRIDGE
jg   was enabled regardless of the platform.
jg
jg I'm still not able to build this. I've updated my ports tree which
jg hasn't helped. Is there anything else I can do to get it to build?

 If you are still suffering from the build failure, please send me
 privately the error log and output of make showconfig.

-- Hiroki


pgpupQEMBmB1h.pgp
Description: PGP signature

Re: FreeBSD Port: pcb-20081128_1

[Hiroki Sato]

William Bulley w...@umich.edu wrote
  in 20090929175944.gk23...@itcom245.staff.itd.umich.edu:

we I am building cad/pcb on 7.2-STABLE and I get this:
we
we cc -std=gnu99 -DNDEBUG -O2 -fno-strict-aliasing -pipe
we -I/usr/local/include -I/usr/local/include  -I/usr/local/include
we -Wall -Wdeclaration-after-statement  -pthread -L/usr/local/lib
we -rdynamic -o pcb action.o autoplace.o autoroute.o buffer.o
we change.o clip.o command.o compat.o copy.o create.o crosshair.o
we data.o djopt.o draw.o drill.o edif.o error.o file.o find.o flags.o
we fontmode.o heap.o insert.o intersect.o line.o lrealpath.o main.o
we mirror.o misc.o move.o mtspace.o mymem.o netlist.o parse_l.o parse_y.o
we polygon.o polygon1.o puller.o print.o rats.o remove.o report.o res_parse.o
we res_lex.o rotate.o rtree.o rubberband.o search.o select.o set.o strflags.o
we thermal.o undo.o vector.o vendor.o hid/common/actions.o hid/common/flags.o
we hid/common/hidinit.o hid/common/hidnogui.o hid/common/extents.o
we liblesstif.a liblpr.a libbom.a libgerber.a libnelma.a libpng.a libps.a
we -lXm -lXpm -lXmu -lXt -lXext -lSM -lICE -lX11 -lfl -lm-lXrender
we -L/usr/local/lib -R/usr/local/lib   -L/usr/local/lib -L/usr/local/lib -lgd 
-lgd
we main.o(.text+0xc8e): In function `main':
we : undefined reference to `bindtextdomain'
we main.o(.text+0xca2): In function `main':
we : undefined reference to `bind_textdomain_codeset'
we gmake[4]: *** [pcb] Error 1
we gmake[4]: Leaving directory `/usr/ports/cad/pcb/work/pcb-20081128/src'
we gmake[3]: *** [all-recursive] Error 1
we gmake[3]: Leaving directory `/usr/ports/cad/pcb/work/pcb-20081128/src'
we gmake[2]: *** [all] Error 2
we gmake[2]: Leaving directory `/usr/ports/cad/pcb/work/pcb-20081128/src'
we gmake[1]: *** [all-recursive] Error 1
we gmake[1]: Leaving directory `/usr/ports/cad/pcb/work/pcb-20081128'
we gmake: *** [all] Error 2
we *** Error code 1
we
we My build line in /usr/ports/cad/pcb was:
we
we   # make WITH_MOTIF_GUI=yes install
we
we It builds fine if I use:
we
we   # make install
we
we Regards,

 Thanks for the report.  Could you try the attached patch and let me
 know if it works or not?

-- Hiroki
Index: files/patch-src-pcb-menu.res
===
RCS file: files/patch-src-pcb-menu.res
diff -N files/patch-src-pcb-menu.res
--- /dev/null	1 Jan 1970 00:00:00 -
+++ files/patch-src-pcb-menu.res	10 Oct 2009 02:01:42 -
@@ -0,0 +1,11 @@
+--- src/pcb-menu.res.orig	2009-10-10 10:44:44.0 +0900
 src/pcb-menu.res	2009-10-10 11:00:58.0 +0900
+@@ -52,7 +52,7 @@
+   {View
+{Flip up/down checked=flip_y SwapSides(V) a={Tab KeyTab}}
+{Flip left/right checked=flip_x SwapSides(H) a={Shift-Tab ShiftKeyTab}}
+-   {Spin 180ｰ SwapSides(R) a={Ctrl-Tab CtrlKeyTab}}
++   {Spin 180 SwapSides(R) a={Ctrl-Tab CtrlKeyTab}}
+{Swap Sides SwapSides() a={Ctrl-Shift-Tab Ctrl ShiftKeyTab}}
+{Center cursor Center() a={C Keyc}}
+{Show soldermask checked=showmask Display(ToggleMask)}


pgp6Vw2cGbQOl.pgp
Description: PGP signature

Re: FreeBSD Port: openbgpd-4.5.20090709

[Hiroki Sato]

Hi,

Lasta Yani la...@orion.net.id wrote
  in 10117348.18611249508132935.javamail.r...@mail.orion.net.id:

la Hello Hiroki,
la
la I'm sorry if I send directly this email to you.

 No problem.

la When I try to upgrade my machine to openbgpd-4.5.20090709, something
la weird had happened.
(snip)
la I dont change this configuration from OpenBGPD v4.2, and usually with
la this setting, I'm not receiving any prefixes from $nap2 (ke-NAP2),
la only receiving from $nap1 (ke-NAP1).
la Its weird when I upgraded via port to openbgpd-4.5.20090709, its still
la receiving prefixes, I can't deny it.
la
la Is there anything wrong with my configuration ?
la Thank you.

 I think there is no problem with the configuration itself.  Just in
 case, please send me the output of bgpd -nv?  I will try to
 reproduce your symptom on my box.

-- Hiroki


pgp3ZDnZrZmmV.pgp
Description: PGP signature

CFT: net/openbgpd

[Hiroki Sato]

Hi,

 I would like your help for testing net/openbgpd.  A diff from 4.4.1
 and a complete tarball of the new port for the latest version from
 the OpenBSD source tree as of July 9, can be found at:

 http://people.allbsd.org/~hrs/FreeBSD/openbgpd-4.5.20090709.diff.gz
 http://people.allbsd.org/~hrs/FreeBSD/openbgpd-4.5.20090709.tar.gz

 Changes from 4.4.1 include support for RIB table and connect-retry.
 Nexthop using IPv6 link-local address is also supported (equivalent
 to neighbor X interface Y in Quagga).  Note that CARP and route
 priority are disabled because they are not supported on FreeBSD.

 Please let me know if you notice something wrong with it.  Thanks!

-- Hiroki


pgpI26SNL7s7x.pgp
Description: PGP signature

Re: acroread9 crashes after maybe 10 seconds of operation.

[Hiroki Sato]

Hiroki Sato h...@freebsd.org wrote
  in 20090617.141203.07900852@allbsd.org:

hr Robert Huff roberth...@rcn.com wrote
hr   in 18997.22089.242834.29...@jerusalem.litteratus.org:
hr ro Um.
hr ro Are there plans to get it to work with something more recent?
hr ro I was under the (uninformed) impression linux_base-fc-4 was, ah,
hr ro workable but no longer favored.
hr
hr  The ports collection still assumes fc4 as the default, so I think it
hr  is the primary target.
hr
hr  Anyway, I will try other configurations including one in your report.
hr  I guess the issue is due to some incomplete (or not-fully-compatible)
hr  compat-layer implementations of features available in Linux 2.6.x.

 I could reproduce the symptom (RSException), but this has also been
 reported on Linux: http://forums.adobe.com/message/1931692.  The
 release note of 9.1.2 says it is solved but it remains as far as I
 can check.

 BTW, could you give it a try to set sysctl
 compat.linux.osrelease=2.4.2 and let me know if it works or not?

-- Hiroki


pgpM15Xi34PTj.pgp
Description: PGP signature

Re: acroread9 crashes after maybe 10 seconds of operation.

[Hiroki Sato]

Robert Huff roberth...@rcn.com wrote
  in 18997.22089.242834.29...@jerusalem.litteratus.org:

ro Hiroki Sato writes:
ro
ro   ec Is anyone else seeing the following termination message after maybe 
10
ro   ec seconds of acroread9 operation?
ro 
roCan you add more detailed information on your environment?  Packages
royou installed and compat.linux.osrelease sysctl are needed at the
rovery least.
ro
ro compat.linux.osrelease: 2.6.16
ro linux_base-f8-8_11
ro
roAcrobat 9 works with compat.linux.osrelease=2.4.2 and
rolinux_base-fc-4_13 on 7.2-RELEASE.  On other environments it may
roor may not work.
ro
ro Um.
ro Are there plans to get it to work with something more recent?
ro I was under the (uninformed) impression linux_base-fc-4 was, ah,
ro workable but no longer favored.

 The ports collection still assumes fc4 as the default, so I think it
 is the primary target.

 Anyway, I will try other configurations including one in your report.
 I guess the issue is due to some incomplete (or not-fully-compatible)
 compat-layer implementations of features available in Linux 2.6.x.

-- Hiroki


pgpaxT359l0UU.pgp
Description: PGP signature

Re: acroread9 crashes after maybe 10 seconds of operation.

[Hiroki Sato]

eculp ec...@encontacto.net wrote
  in 20090611184440.64570233jo01s...@econet.encontacto.net:

ec On my laptop running uptodate current and kernel although not rebooted
ec for 2 days.
ec
ec # uname -a
ec FreeBSD ed.local.net.mx 8.0-CURRENT FreeBSD 8.0-CURRENT #235: Tue Jun
ec 9 09:08:35 CDT 2009
ec r...@ed.local.net.mx:/usr/obj/usr/src/sys/ENCONTACTO i386
ec
ec
ec Is anyone else seeing the following termination message after maybe 10
ec seconds of acroread9 operation?
ec
ec # acroread9
ec terminate called after throwing an instance of 'RSException'
ec
ec Maybe I should open a ticket?

 Can you add more detailed information on your environment?  Packages
 you installed and compat.linux.osrelease sysctl are needed at the
 very least.

 Acrobat 9 works with compat.linux.osrelease=2.4.2 and
 linux_base-fc-4_13 on 7.2-RELEASE.  On other environments it may or
 may not work.

-- Hiroki


pgpqbcizz8WQy.pgp
Description: PGP signature

Re: TeXLive

[Hiroki Sato]

Romain Tartière rom...@blogreen.org wrote
  in 20081224131012.ga8...@blogreen.org:

ro Hi!
ro 
ro There have been numerous mails about adding ports for TeXLive to FreeBSD
ro [1,2,3,4], unfortunately, nothing is available so far.
ro 
ro 
ro Since I really think TeXLive can be a plus for FreeBSD, and because I
ro use TeXLive on another system, I started another effort to bring it to
ro the ports tree.  In order to avoid loosing everything if I run out of
ro time, I created a Google code project for working:
ro 
ro http://code.google.com/p/freebsd-texlive/
ro 
ro 
ro Currently, I have all TeXLive binaries compiling from source
ro (installation is still not perfect though) and quite a precise idea of
ro how all TeXLive distfiles are organised and how to build FreeBSD ports
ro from the metadata they enclose (refer to the project's wiki for details,
ro I am trying to dump all there [5]).
ro 
ro 
ro I am now facing the problem of the organisation of the ports to create.
ro The freebsd-ports archives reveal some interesting points:

 I am the one who were saying the porting was going, and sorry for
 being out of touch with public lists, but the points include not only
 how to import them to our ports tree but also how to integrate them
 with the large number of ports depending TeX.  The reasons why I
 could not import them so far are: 1) some remaining issues could not
 be solved until the last month and 2) I need to wait for the recent
 releases being rolled out (much-delayed, as you know).

 I have three sort of experimental ports of texlive now; the first is
 a large one, the second is completely-modularized one, and the last
 is a combination of modularized binaries and macro part in a few
 ports with scripts to interface CTAN between the installed macros.
 Considering migration from teTeX, I am planning to commit a part of
 1) just after 7.1R is rolled out, then break them, and finally form
 them into 3).  This integration involves many other ports which
 depend on TeX, and probably the new category named tex.  Also, we
 are using TeX in our documentation infrastructure, so updating the
 related ports are very sensitive.  I think discussion of the
 organization in the ports tree would be a good thing, but please also
 consider this factor; for example, if we are not able to make JadeTeX
 work as before we need to solve the issue first, and we have solve
 the current situation that we have print/tex independent from the old
 teTeX, which often confuses the users.  Anyway, I think major
 technical issues (functionality, compatibility, and so on) are solved
 now while a large change is needed to TeX-related ports in the
 current ports tree.  And I think unless we are sure that these points
 and long-standing complaints which exist from the teTeX era can be
 solved, it should not be imported.

 Again, please accept my sincere apologies for your inconvenience of
 missing TeXLive in FreeBSD for a long time.  I do not want to make
 others do duplicated work and conflict with other efforts, but at the
 same time I have no right to bothering your effort.  This is my
 comment at this moment as one of people who are involved.

-- 
| Hiroki SATO


pgpQSVTciNzsx.pgp
Description: PGP signature

RFC: $USE_[GU]ID for consistent [GU]ID handling

[Hiroki Sato]

Hello,

 I would like your comments about the attached patch.  This is for
 adding USE_UID and USE_GID which allow uid/gid addition on
 installation and the removal on deinstallation.  It uses
 ${PORTSDIR}/[GU]IDs for the detail information and can eliminate
 complex shell scripts from individual ports.

 For example, if you define

 USE_UID= foo

 in Makefile, the uid foo is added before pre-su-install, and
 removed on deinstallation by using pw(8).  If the uid already exists,
 no error occurred.  The multiple uids are also allowed.

 The attached patch includes an example of rewrite of an existing
 ports (japanese/sj3-server).  After investigating ~300 ports in the
 ports tree which add uid/gid I think the attached implementation can
 cover most of the use case, but there may be something I missed.
 Comments are welcome.

--
| Hiroki SATO
Index: Mk/bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.604
diff -d -u -I\$FreeBSD:.*\$ -I\$NetBSD:.*\$ -I\$OpenBSD:.*\$ -I\$DragonFly:.*\$ 
-I\$Id:.*\$ -I\$Translation:.*\$ -I\$hrs:.*\$ -r1.604 bsd.port.mk
--- Mk/bsd.port.mk  5 Sep 2008 19:41:43 -   1.604
+++ Mk/bsd.port.mk  23 Nov 2008 18:48:13 -
@@ -524,6 +524,16 @@
 # RC_SUBR_SUFFIX
 #  - Contains the suffix of installed rc.subr 
scripts.
 ##
+#
+# USE_UID  - List UIDs to be used by the port/package.  The UID 
must be
+# a symbolic name defined in ${PORTSDIR}/UIDs, and
+# added on installation and removed on uninstallation.
+#
+# USE_GID  - List GIDs to be used by the port/package.  The GID 
must be
+# a symbolic name defined in ${PORTSDIR}/GIDs, and
+# added on installation and removed on uninstallation.
+#
+##
 # USE_APACHE   - If set, this port relies on an apache webserver.
 #
 # USE_CDRTOOLS - If set, this port depends on sysutils/cdrtools, unless
@@ -2109,6 +2119,50 @@
 .endif
 .endif

+.if defined(USE_UID)
+UIDFILE?=  ${PORTSDIR}/UIDs
+.for U in ${USE_UID}
+_PASSWDREGEX+= ^${U}:\\\|
+.endfor
+_PASSWDLINES=  set -- ${_PASSWDREGEX}; IFS=''; ${GREP} $${*%\|} ${UIDFILE}
+add-uid:
+   @${_PASSWDLINES}  /dev/null 21 || ( ${ECHO_MSG} '=== $$USE_UID 
consistency error.'  ${FALSE} )
+   @( ${_PASSWDLINES} ) | while read L; do \
+   IFS=:; set -f; set -- $${L}; \
+   ${ECHO_MSG} === Adding user account: \$${1}($${3})\; \
+   if ! ${PW} usershow $${1}  /dev/null 21; then \
+   ${PW} useradd -n $${1} -u $${3} -g $${4} -c 
$${8} -d $${9} -s $${10}; \
+   fi; \
+   ${ECHO_CMD} @exec if ! ${PW} usershow $${1}  /dev/null 21; 
then ${PW} useradd -n \$${1}\ -u \$${3}\ -g \$${4}\ -c \$${8}\ -d 
\$${9}\ -s \$${10}\; fi  ${TMPPLIST}; \
+   ${ECHO_CMD} @unexec if ${PW} usershow $${1}  /dev/null 21; 
then ${PW} userdel -n \$${1}\ -u \$${3}\; fi  ${TMPPLIST}; \
+   done
+.else
+add-uid:
+   @${DO_NADA}
+.endif
+
+.if defined(USE_GID)
+GIDFILE?=  ${PORTSDIR}/GIDs
+.for G in ${USE_GID}
+_GROUPREGEX+=  ^${G}:\\\|
+.endfor
+_GROUPLINES=   set -- ${_GROUPREGEX}; IFS=''; ${GREP} $${*%\|} ${GIDFILE}
+add-gid:
+   @${_GROUPLINES}  /dev/null 21 || ( ${ECHO_MSG} '=== $$USE_GID 
consistency error.'  ${FALSE} )
+   @( ${_GROUPLINES} || false ) | while read L; do \
+   IFS=:; set -f; set -- $${L}; \
+   ${ECHO_MSG} === Adding group account: \$${1}($${3})\; \
+   if ! ${PW} groupshow $${1}  /dev/null 21; then \
+   ${PW} groupadd -n $${1} -g $${3}; \
+   fi; \
+   ${ECHO_CMD} @exec if ! ${PW} groupshow \$${1}\  /dev/null 
21; then ${PW} groupadd -n \$${1}\ -g \$${3}\; fi  ${TMPPLIST}; \
+   ${ECHO_CMD} @unexec if ${PW} groupshow \$${1}\  /dev/null 
21; then ${PW} groupdel -n \$${1}\ -g \$${3}\; fi  ${TMPPLIST}; \
+   done
+.else
+add-gid:
+   @${DO_NADA}
+.endif
+
 # Macro for doing in-place file editing using regexps
 REINPLACE_ARGS?=   -i.bak
 REINPLACE_CMD?=${SED} ${REINPLACE_ARGS}
@@ -4136,7 +4190,7 @@
 _INSTALL_SEQ=  install-message check-conflicts \
run-depends lib-depends apply-slist pre-install 
\
pre-install-script generate-plist 
check-already-installed
-_INSTALL_SUSEQ= check-umask install-mtree pre-su-install \
+_INSTALL_SUSEQ= check-umask install-mtree add-gid add-uid pre-su-install \
pre-su-install-script do-install 
install-desktop-entries \
post-install post-install-script add-plist-info 
\
add-plist-docs add-plist-examples 
add-plist-data \
Index: japanese/sj3-server/Makefile
===
RCS file: /home/ncvs/ports/japanese/sj3-server/Makefile,v
retrieving

RFC: $OPTIONS in line-oriented terminal

[Hiroki Sato]

Hello,

 I would like your comments about the attached patch.  This is for
 making $OPTIONS work on line-oriented terminals.  To see the
 difference, you can try the following after applying the patch:

  % cd /usr/ports/print/ghostscript8  env TERM=foo make config

 The current implementation of $OPTIONS uses dialog(1) for listing the
 options, but dialog(1) requires a screen-oriented terminal.  Although
 today's most of terminals used are virtual ones with the capability,
 there are still a few situations that line-oriented operation is
 useful; operations over low-speed serial console, for example.  Also,
 another problem of the current implementation is that it silently
 skips the selection menu if the $TERM is invalid and prevents the
 selection itself.

--
| Hiroki SATO
Index: Mk/bsd.commands.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.commands.mk,v
retrieving revision 1.3
diff -d -u -I\$FreeBSD:.*\$ -I\$NetBSD:.*\$ -I\$OpenBSD:.*\$ -I\$DragonFly:.*\$ 
-I\$Id:.*\$ -I\$Translation:.*\$ -I\$hrs:.*\$ -r1.3 bsd.commands.mk
--- Mk/bsd.commands.mk  14 Apr 2008 16:46:41 -  1.3
+++ Mk/bsd.commands.mk  7 Dec 2008 18:13:35 -
@@ -33,7 +33,7 @@
 CPIO?= /usr/bin/cpio
 CUT?=  /usr/bin/cut
 DC?=   /usr/bin/dc
-DIALOG?=   /usr/bin/dialog
+DIALOG?=   ${PORTSDIR}/Tools/scripts/dialog.sh
 DIFF?= /usr/bin/diff
 DIRNAME?=  /usr/bin/dirname
 EGREP?=/usr/bin/egrep
Index: Tools/scripts/dialog.sh
===
RCS file: Tools/scripts/dialog.sh
diff -N Tools/scripts/dialog.sh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ Tools/scripts/dialog.sh 7 Dec 2008 18:17:00 -
@@ -0,0 +1,222 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+#  Copyright 2003, 2004, 2005, 2006, 2007, 2008 Hiroki Sato [EMAIL 
PROTECTED],
+#  All rights reserved.
+#
+#  Redistribution and use in source and binary forms, with or without
+#  modification, are permitted provided that the following conditions
+#  are met:
+#  1. Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+#  2. Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
+#
+#  THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+#  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+#  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+#  ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+#  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+#  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+#  OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+#  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+#  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+#  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+#  SUCH DAMAGE.
+#
+DIALOG_CMD=/usr/bin/dialog
+
+if ${DIALOG_CMD} --clear 2 /dev/null; then
+   exec ${DIALOG_CMD} $@
+fi
+
+shjot()
+{
+   _sj_num=$1
+   _sj_begin=$2
+
+   case ${_sj_num}:${_sj_begin} in
+   [0-9]*:[0-9]*)
+   _sj_i=${_sj_begin}
+   _sj_num=$(( ${_sj_num} + ${_sj_begin} ))
+   ;;
+   *)
+   _sj_i=1
+   ;;
+   esac
+
+   while [ ${_sj_i} -le ${_sj_num} ]; do
+   echo ${_sj_i}
+   _sj_i=$(( ${_sj_i} + 1 ))
+   done
+}
+
+print_sep()
+{
+   echo  $*
+}
+
+calc_b_e()
+{
+   _cbe_begin=$((${IPAGE} * ${CPAGE} + 1))
+   case ${CPAGE} in
+   ${NPAGE})   _cbe_ritems=$(((${NITEMS} - ${IPAGE} * ${CPAGE}) % 
${IPAGE})) ;;
+   *)  _cbe_ritems=${IPAGE} ;;
+   esac
+   _cbe_end=$((${_cbe_begin} + ${_cbe_ritems} - 1))
+
+   echo ${_cbe_begin} ${_cbe_end} ${_cbe_ritems}
+}
+
+print_knobs()
+{
+   set -- `calc_b_e`
+   _pk_begin=$1
+   _pk_end=$2
+   _pk_ritems=$3
+
+   for _i in `shjot $(( ${_pk_ritems} - 1 )) ${_pk_begin}`; do
+   printf %3d) [%3s] %s\n ${_i} `eval echo \\$PSW_${_i}` 
`eval echo \\$PITEM_${_i}`
+   done
+}
+
+print_prompt()
+{
+   print_sep
+
+   set -- `calc_b_e`
+   _begin=$1
+   _end=$2
+   _ritems=$3
+
+   case ${_begin}:${_ritems}:${CPAGE} in
+   1:1:*)  echo -n ${_begin},le,ld,?,q)  ;;
+   1:*:${NPAGE})   echo -n ${_begin}-${_end},le,ld,?,q)  ;;
+   *:1:*)  echo -n ${_begin},p,le,ld,?,q) ;
+   VALIDC=p  ;;
+   *:*:${NPAGE})   echo -n ${_begin}-${_end},p,le,ld,?,q) ;
+   VALIDC=p  ;;
+   1:*:*)  echo -n ${_begin}-${_end}(max:${NITEMS

Re: print/cm-super size mismatch

[Hiroki Sato]

Frank Shute [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

fr Hi,
fr
fr I just had a problem when building print/cm-super.
fr
fr cm-super.zip doesn't seem to exist in /usr/ports/distfiles/.
fr = Attempting to fetch from ftp://ftp.funet.fi/pub/TeX/CTAN/fonts/ps-type1/.
fr fetch: ftp://ftp.funet.fi/pub/TeX/CTAN/fonts/ps-type1/cm-super.zip: size 
mismatch: expected 67310332, actual 67319909
fr = Attempting to fetch from 
ftp://ctan.unsw.edu.au/tex-archive/fonts/ps-type1/.
fr fetch: ftp://ctan.unsw.edu.au/tex-archive/fonts/ps-type1/cm-super.zip: 
Connection refused
fr = Attempting to fetch from ftp://ftp.tex.ac.uk/tex-archive/fonts/ps-type1/.
fr fetch: ftp://ftp.tex.ac.uk/tex-archive/fonts/ps-type1/cm-super.zip: size 
mismatch: expected 67310332, actual 67319909
fr = Attempting to fetch from ftp://ftp.kddlabs.co.jp/CTAN/fonts/ps-type1/.
fr
fr It did fetch it from the jp mirror but slowly  build it.
fr
fr But I would have thought that the tarball at ftp.tex.ac.uk would be
fr the canonical one. Any thoughts?

 This was because the distfile was updated.  The port was also updated
 just now, so please try the latest ports tree.  Thank you for the
 report!

--
| Hiroki SATO


pgpOeWTP0CXvg.pgp
Description: PGP signature

Re: FreeBSD Port: latex-mathabx-1.0.20050518_1

[Hiroki Sato]

Hello, sorry for the delay,

Joey Mingrone [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

jo Hi,
jo
jo I get the following error when I try to install this port:
jo
jo /bin/mkdir -p /usr/local/share/texmf-local/fonts/map/dvips/mathabx
jo install  -o root -g wheel -m 444
jo /usr/ports/print/latex-mathabx/work/abxtype1/map/mathabx.map
jo /usr/local/share/texmf-local/fonts/map/dvips/mathabx
jo /usr/local/bin/mktexlsr
jo mktexlsr: Updating /usr/local/share/texmf/ls-R...
jo mktexlsr: Updating /var/tmp/texfonts/ls-R...
jo mktexlsr: Done.
jo /usr/bin/env PATH=/usr/local/bin:${PATH}  /usr/local/bin/updmap-sys
jo --enable Map=mathabx.map
jo env: /usr/local/bin/updmap-sys: No such file or directory
jo *** Error code 127
jo
jo
jo Thanks for any help you can provide and if there is any other
jo information I can provide, just let me know.

 It looks your system does not have /usr/local/bin/updmap-sys for some
 reason which is installed by print/teTeX-base.  Maybe reinstalling
 teTeX-base (or all tex-related ports) will fix the problem.  Or, do
 you still see this symptom in a newly-installed system?

--
| Hiroki SATO


pgp8zPyqyZ9ip.pgp
Description: PGP signature

Re: poscript display problems

[Hiroki Sato]

Chuck Robey [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ch This time I'm copying Hiroki Sato, who is the fellow who did the last few
ch ghostscript commits ... why?  Because I just tried to compile
ch ghostscript-8.62.tar.bz2 directly from the version that was downloaded by 
the
ch port into distfiles.  I only used autogen.sh (with the only options being
ch - --prefix=/usr/local), used gmake, and then executed it from the 
preinstallation
ch ./bin directory.  Result: it displays fine, no error.  I think that hrs 
ought to
ch take a look at his port now, does that sould right?

 A patch has been committed, so please try the latest version.  Or, I
 think the following commands also fix the problem:

 % pstops 1:0 lbx.PS  lbx2.PS
 % gs lbx2.PS

 (For pstops(1) you need print/psutils-*)

--
| Hiroki SATO


pgpgWlBXt7Vmg.pgp
Description: PGP signature

Re: poscript display problems

[Hiroki Sato]

Chuck Robey [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ch This time I'm copying Hiroki Sato, who is the fellow who did the last few
ch ghostscript commits ... why?  Because I just tried to compile
ch ghostscript-8.62.tar.bz2 directly from the version that was downloaded by 
the
ch port into distfiles.  I only used autogen.sh (with the only options being
ch - --prefix=/usr/local), used gmake, and then executed it from the 
preinstallation
ch ./bin directory.  Result: it displays fine, no error.  I think that hrs 
ought to
ch take a look at his port now, does that sould right?

 I need the questionable postscript file to reproduce the problem.
 Could you send it to me?  I will investigate.

--
| Hiroki SATO


pgpR0RQq8wuKC.pgp
Description: PGP signature

Re: CFT: Adobe Reader 8 + SCIM/UIM

[Hiroki Sato]

Nikola Lečić [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ni 3. Now acroread7 doesn't work (for me at least), with all SCIM-related
nienvironment variables schemes. It just returns me back to the shell
niprompt without any error message;
ni 
ni 4. However, if I use the environment scheme I suggested in my previous
nimail and change GTK_IM_MODULE/XMODIFIERS in acroread7 startup
niscript as proposed, all applications work, and SCIM in them.

 From further investigation, the cause of this problem turns out to be
 as follows:

 a) When GTK_IM_MODULE=xim and one runs a Linux binary that uses
linux-gtk2 library, the binary uses im-xim.so in linux-gtk2 and it
works.

 b) When GTK_IM_MODULE=scim (or other than xim) and one runs a Linux
binary that uses linux-gtk2 library, the binary tries to load the
corresponding immodule file.  If the corresponding file is found
in /usr/compat/linux/usr/lib/gtk-2.0 (i.e. Linux binary), it is
loaded and should work fine.  If the corresponding file is found
in /usr/local/lib/gtk-2.0 (i.e. FreeBSD native binary), it is
loaded but does not work.  In the latter case, if the loading
fails gracefully, it falls back into loading im-xim.so.

 c) acroread7 works only with im-xim.so and loading FreeBSD binary
fails gracefully.  This means setting GTK_IM_MODULE=scim falls
back into GTK_IM_MODULE=xim automatically. (probably this is the
reason why GTK_IM_MODULE=scim + QT_IM_MODULE=scim +
[EMAIL PROTECTED] works.)

 d) acroread8 works with both im-xim.so and im-scim.so as far as I can
check, and loading FreeBSD binary makes the process get hosed.

 So, the individual cases can be classified as follows:

 - acroread7 + GTK_IM_MODULE=xim + [EMAIL PROTECTED]

   - should work.  @im=foo other than SCIM also works.

 - acroread7 + GTK_IM_MODULE=scim

   - should work.  Even if FreeBSD native im-scim.so exists it is
  always ignored and XIM is used.  Note that if Linux im-scim.so
  exists it prevents the acroread7 from working, but there is no
  port of im-scim.so in the Ports Collection now.

 - acroread8 + GTK_IM_MODULE=xim + [EMAIL PROTECTED]

   - should work.  @im=foo other than SCIM also works.

 - acroread8 + GTK_IM_MODULE=scim

   - does not work unless Linux im-scim.so exists.  If FreeBSD native
  im-scim.so exists the acroread8 process gets hosed (no fall-back
  happens).

 So, the safest way to loading Linux version of im-xim.so is setting
 GTK_IM_MODULE=xim forcibly.  And if setting XMODIFIERS properly there
 should be little difference in its behavior from the user's point of
 view.

 I pondered over adding ports of the Linux immodules in my previous
 post or a hack for GTK_IM_MODULE variable into print/acroreadwrapper,
 but I think changing acroreadwrapper is better.  A patch for
 acroreadwrapper that sets GTK_IM_MODULE=xim forcibly and sets
 [EMAIL PROTECTED] according to GTK_IM_MODULE, has been attached.

 However, in your post you said when GTK_IM_MODULE=xim +
 [EMAIL PROTECTED], the behavior is bad.  Could you elaborate it?  I
 could not reproduce it.

-- 
| Hiroki SATO
Index: Makefile
===
RCS file: /home/ncvs/ports/print/acroreadwrapper/Makefile,v
retrieving revision 1.9
diff -d -u -I\$FreeBSD:.*\$ -I\$NetBSD:.*\$ -I\$OpenBSD:.*\$ -I\$DragonFly:.*\$ 
-I\$Id:.*\$ -I\$Translation:.*\$ -I\$hrs:.*\$ -r1.9 Makefile
--- Makefile4 Jan 2008 20:20:20 -   1.9
+++ Makefile11 Jan 2008 14:25:27 -
@@ -6,7 +6,7 @@
 #

 PORTNAME=  acroreadwrapper
-PORTVERSION=   0.0.20071020
+PORTVERSION=   0.0.20080110
 CATEGORIES=print
 MASTER_SITES=  # empty
 DISTFILES= # empty
@@ -29,7 +29,7 @@
 ADOBEBASE= Adobe
 ACROBASE7= ${ADOBEBASE}/Acrobat7.0
 ACROBASE8= ${ADOBEBASE}/Reader8
-PLUGINDIR= lib/browser_linux_plugins
+PLUGINDIR= lib/npapi/linux-acroread

 do-fetch:
@${DO_NADA}
Index: files/acroread.in
===
RCS file: /home/ncvs/ports/print/acroreadwrapper/files/acroread.in,v
retrieving revision 1.5
diff -d -u -I\$FreeBSD:.*\$ -I\$NetBSD:.*\$ -I\$OpenBSD:.*\$ -I\$DragonFly:.*\$ 
-I\$Id:.*\$ -I\$Translation:.*\$ -I\$hrs:.*\$ -r1.5 acroread.in
--- files/acroread.in   4 Jan 2008 20:20:20 -   1.5
+++ files/acroread.in   11 Jan 2008 14:28:58 -
@@ -1,4 +1,4 @@
-#!%%LINUXBASE%%/bin/sh
+#!/bin/sh
 # $FreeBSD: ports/print/acroreadwrapper/files/acroread.in,v 1.5 2008/01/04 
20:20:20 hrs Exp $

 # environment variables:
@@ -13,6 +13,14 @@
 # When this script is invoked as acroread7 and acroread8,
 # ADOBE_VER is automatically set.
 #
+# ADOBE_DISABLEIMMODULEHACK:
+# This script sets GTK_IM_MODULE as xim by default because
+# immodules other than xim require the corresponding module files
+# in Linux binary, not FreeBSD native versions (if a FreeBSD
+# native immodule library exists and the corresponding

Re: Adobe Reader and SCIM

[Hiroki Sato]

Nikola Lečić [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ni 1. Is the purpose of
ni 
ni  case ${ADOBE_LANG} in
ni  .
ni  JPN) : ${GTK_IM_MODULE:=xim}; export GTK_IM_MODULE ;;
ni 
nito override any other existing value?

 This line does not override the existing value.  Just setting the
 default value if not defined.

niit will not work in Linux and QT apps (incl. Reader 7). The problem
niis (I don't know if this is FreeBSD specific) that GTK_IM_MODULE,
nionce set to 'scim', can't be changed to 'xim' in the same X session,
niso the line like aforementioned JPN-specific setting will not have
niany effect in such environment. The same goes for XMODIFIERS once set
nito @im=SCIM.

 As explained above, the acroread script does not change them if
 defined already.

 I basically think the user should be responsble for environment
 variables that he sets by himself, and the acroread script should set
 the default values at the most.  However, I agree with setting some
 variables to work around problems that prevent acroread from working,
 but I am not sure if your suggestion is reasonable yet.  On my box,

   GTK_IM_MODULE=scim
   QT_IM_MODULE=scim
   [EMAIL PROTECTED]

 works fine with acroread7 (not for acroread8, btw), and I could not
 understand the reason why changing XMODIFIER to @im=XIM does the
 trick.

-- 
| Hiroki SATO


pgpg3PNm3e1Jh.pgp
Description: PGP signature

CFT: Adobe Reader 8 + SCIM/UIM (was Adobe Reader and SCIM)

[Hiroki Sato]

Hi all,

 If you are using Adobe Reader 8.1.1 with SCIM or UIM, please try the
 following and then run acroread8:

 # cd /usr/ports
 # fetch http://people.allbsd.org/~hrs/FreeBSD/imm-ports.tar.gz
 # tar xzvf imm-ports.tar.gz
 # cd /usr/ports/textproc/linux-scim-libs  make install
 # cd /usr/ports/textproc/linux-uim-gtk2  make install

 imm-ports.tar.gz includes three new ports of immodules in Linux
 binary which should make SCIM and UIM work with acroread8.  If they
 work, I will commit them as dependency.

--
| Hiroki SATO


pgpyAUuIjNDTm.pgp
Description: PGP signature

Re: CFT: Adobe Reader 8 + SCIM/UIM

[Hiroki Sato]

Aryeh M. Friedman [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ar Where do I find acroread8?

 See http://www.freshports.org/print/acroread8/.

--
| Hiroki SATO



pgphR4ln4i3sY.pgp
Description: PGP signature

Adobe Reader 8 ports

[Hiroki Sato]

Hello all,

 As you already noticed, ports of Adobe Reader 8.1.1 have been
 committed.  I tested the functionality as much as I could, but the 15
 languages are beyond me anyway ;) So, please try them and let me know
 if it works well on your environment or not.

 ${PREFIX}/bin/acroread invokes 8.x if both 7.x and 8.x are installed.
 The logic of acroread is as follows:

 if ($ADOBE_VER == 7)
invoke 7.x
 elif ($ADOBE_VER == 8)
invoke 8.x
 elif (exists 8.x)
invoke 8.x
 elif (exists 7.x)
invoke 7.x
 fi

 You can also use acroread7 or acroread8 if you want to run the
 specific version.

 If a localized version is installed and $ADOBE_LANG is set, the
 localized version is invoked.  The logic is the following:

 if (not defined $ADOBE_LANG)
if (defined $LANG)
set $ADOBE_LANG based on $LANG
else
ADOBE_LANG:=ENU (english version)
fi
 fi

 if (exists Adobe Reader in $ADOBE_LANG)
 invoke Adobe Reader in $ADOBE_LANG
 else
 invoke Adobe Reader in ENU (english version)
 fi

 Known problems:

  - Adobe Reader 8 needs libgtkembedmoz.so to render HTML documents.
The current ports use it from www/linux-nvu which is the one that
works well in my investigation.  The FreeBSD native libraries from
xulrunner or firefox do not work AFAICT.  Please let me know if
you have another solution---such as another more stripped-down
distribution including libgtkembedmoz.so or so.

  - XIM does not work at least in japanese/acroread8 even if
GTK_IM_MODULE=xim is defined.  Since several Linux users around me
pointed out this, this seems not FreeBSD-specific.  I have heard
that SCIM works, but I do not check it yet.

  - Gothic font family is not supported in japanese/acroread8.  I am
not sure why, but Adobe does not provide it.

--
| Hiroki SATO


pgpJ9nMqrmOiV.pgp
Description: PGP signature

Re: TeTeX and TeXLive

[Hiroki Sato]

Nikola Lečić [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ni On Fri, 14 Dec 2007 07:43:00
ni Doug Barton [EMAIL PROTECTED] wrote:
ni 
ni  On Fri, 14 Dec 2007, Nikola Lečić wrote:
ni [...]
ni   I must add that I tried two times to contact two FreeBSD developers
ni   who
ni   (according to the public sources) seemed to be interested in this;
ni   never got a single word of reply. Having in mind that I offered a
ni   help, some experience and maintaining/testing availability, I can't
ni   understand this. It's very discouraging.
ni 
ni  please feel free to take that as a sign that you should take the ball
ni  and run with it. :)
ni 
ni Well, according to
ni 
ni   http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/040511.html
ni 
ni porting of TeXLive has already been undertaken. :-) The problem is
ni that it's not possible to get any further information on this work.
ni 
ni But anyway, I don't think I can do it alone, of course. I could
ni probably create port(s), but the biggest challenge is that so many
ni other ports depend on teTeX, and re-configuring all dependencies
ni obviously requires huge experience, computer horsepower and
ni developers' hands. Therefore a help was offered and sharing future
ni maintaining load as well:
ni 
ni http://lists.freebsd.org/pipermail/freebsd-ports/2007-July/042729.html
ni http://lists.freebsd.org/pipermail/freebsd-ports/2007-August/043453.html
ni 
ni So, once again:
ni 
ni * If any FreeBSD developer is currently working on TeXLive port,
ni   please, can we users know something about it?
ni * If not, is any FreeBSD developer willing to lead that project,
ni   publicly discuss port's infrastructure/concept, and then give us
ni   (who are happy to help :-)) some tasks?
ni * Or some user should start porting (and discuss infrastructure
ni   first?) and then developers will jump in?

 I have tried to create TeXLive port and have some working results,
 but I cannot commit it because the following issues still remain:

 1. Compatibility with other packages which uses TeX.  Some depend on
old teTeX structure, some depend on hard-coded directory
structure, and so on.  teTeX in the current ports tree has various
glues for such software which are not integrated into teTeX yet.

 2. Finer-grained package management is needed.  Creating a TeXLive
port as one very large package is possible but I do not think it
would work well.  There are many people who do not want to install
such a large package (TeXLive needs 500MB disk space) for a
simple use, and who can install it but want to update some
specific macro packages after that.  Also, I want to solve a
situation that we have print/tex and print/teTeX separately.

 Actually, 1. has been almost solved by adding similar hacks, but
 2. is still a moot point.  My first prototype consisted of two or
 three ports based on the large package model like the current
 teTeX, but I noticed it was too large and difficult to commit.
 Another prototype is based on finer-grained packages---it has
 ports/tex for TeX related ports.  The number of packages which
 extracted from TeXLive distribution and created as ports is 1232 (in
 my local tree).  And then I created meta-ports that installs
 predefined package sets called core, basic, latex, and full
 for example.  core means Plain TeX + METAFONT + some DVIware,
 latex means LaTeX macro set, basic means core+latex, and full
 includes all other packages (this can be broken down more finely).
 And ports that use TeX needs a line like USE_TEX=basic in the
 Makefile as GNOME-related ports do.  I think this is the way we have
 to pursue on a long-term basis.

 In short, modularization of TeXLive distribution is needed for such a
 way.  At first I thought it is not difficult because package
 management information was included in the TeXLive distribution (in
 XML), but I noticed that it was totally broken.  So I am in the
 middle of fixing the information.

 This is a progress report from the current teTeX maintainer who is
 trying to update TeX in the ports tree to TeXLive.  As I explained,
 if we go with the finer-grained package model, over 1000 ports have
 to be added at a time, so testing them should be done in a separate
 tree at least.  I hope I will be able to set up a public tree for
 testing and collaborative work this month...

 Any comments are welcome.  Thanks.

-- 
| Hiroki SATO


pgpDspG6LGCAj.pgp
Description: PGP signature

Re: TeTeX and TeXLive

[Hiroki Sato]

Nikola Lečić [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ni I'm curious to hear more about your ideas related to this partition of
ni full part: what USE_TEX actually does? Invokes parts of TeXLive
ni install scripts? For example, if I want to install Omega -- is it one
ni port or meta-port? -- how the integration happens?

 core or full in USE_TEX specifies the port's dependency in an
 easier way, and mainly for TeX-related ports maintainer.  Omega will
 be a port which has a USE_TEX=foo line, and when you install the
 Omega port, necessary (minimum) packages will also be installed by
 the line.  

ni (And BTW, what source are you using for your work? 2007 release or
ni current SVN version?)

 Both.  Basically I am using the 2007 release and importing bug fixes
 from the current SVN repo.

ni (a) They have so many micro-packages, but as for a lot of software
ni included, TeXLive behaves like a distro: projects are nearly
ni independent. For example, TeXLive source can be compiled with ~100
ni --without-AAAs. Among these AAAs are large projects such as
ni bibTeX, Aleph/Omega, pdfTeX, pdfeTeX, XeTeX... Can a single separate
ni port be created for each addition of this kind?

 I think it is better to create a separate port for each software, and
 it is possible.  In print/teTeX-base, dviware (dvipsk and xdvik) is
 disabled during the building stage, and print/dvipsk-tetex is used as
 a dependency, for example.

ni (b) Update of independent projects. I shall take XeTeX as example:
ni XeTeX-0.996 that is included in TeXLive2007 is very old. New devel
ni version (0.997) exists for a long time and users are very
ni interested in it because it's very stable and contains some amazing
ni features (Graphite support, Unicode math typesetting, etc.).
ni 
ni XeTeX-devel can be compiled against existing TexLive2007, but it
ni asks for some experience, more than average TeX user has. That's the
ni space for FreeBSD port: a possibility to have ports such as
ni print/xetex-devel would be great because some users don't want to
ni wait 2008 to update it through new TeXLive. This goes for many other
ni projects which are actively developed. In the case of XeTeX, this
ni means that we could have:
ni 
ni   print/xetex   (TeXLive core rebuilt with --with-xetex)
ni   print/xetex-devel (third-party XeTeX source, with independent
ni  install scripts specially tweaked for
ni  FreeBSD port if necessary)
ni   devel/libgraphite (currently used by XeTeX-devel only, but
ni  usable for many other non-TeX projects,
ni  therefore ported and maintained intependently)
ni 
ni Of course, these -devel ports would be a challenge for maintainers,
ni but it would be great to have some kind of infrastructural
ni relationship between print/BBB (officially in TeXLive) and
ni BBB-devel ports.
ni 
ni What do you think about some kind of support like this for replacing
ni of old parts of full part with new versions and how does your
ni working version behave regarding this?

 Yes, replacing a part of TeXLive has to be supported.  One of the
 reasons why a separate port print/dvipsk-tetex is created is almost
 the same.  As long as it works correctly, there is no problem that
 newer version is installed as a dependency of TeXLive port in the
 FreeBSD ports tree, I think.

 Although my idea is not fixed yet, in the previously explained
 framework, which package is installed can be controlled by using a
 knob such as TEX=texlive2007only (pure TeXLive2007) or TEX=texlive
 (TeXLive2007 + updated software).  This knob is for users, not for
 port maintainers like USE_TEX.

-- 
| Hiroki SATO



pgpNutJtbrwPH.pgp
Description: PGP signature

Re: TeTeX and TeXLive

[Hiroki Sato]

Bakul Shah [EMAIL PROTECTED] wrote
  in [EMAIL PROTECTED]:

ba Why not add TeXLive port even as it is, so that people can
ba play with it?  As for modularization, I hope you don't go the
ba extreme of a zillion little pieces but instead break it in a
ba few pieces to cover about 90% of the use(rs).  More pieces
ba means more things can go wrong [just my opinion]

 It is because we cannot make a port of software that is not in
 TeXLive.  Some localized TeX variants use non-standard software and
 sometimes it conflicts ones in TeXLive for example, so a TeXLive port
 as it is does not work there (the current teTeX port and the related
 ports work, btw).  Also, I do not want to bother people who are not
 interested in using TeX itself but need to install software which
 depends on TeX (not related TeX and just for typesetting a document
 during the building stage, for example).  I do not like an 500MB
 package will be installed when I just want to install a small piece
 of software.

 Supporting minimal installation is needed for these reasons.  One
 large package of TeXLive would make people happy for the moment, but
 they would notice and suffer from issues of integration with other
 ports and consistent upgrading.

 Do you think splitting it to small packages will be a big problem?  I
 realize it takes additional time, but considering pros and cons I
 think it is better to do so.  If you have any ideas that points to a
 bad scenario, please let me know more specific.

--
| Hiroki SATO


pgpGUszTrdozU.pgp
Description: PGP signature