Re: set_rcvar() function use?
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?
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
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
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
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
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
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
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?
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?
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?
"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
jbe...@freebsd.org (Jan Beich) wrote in <20170101195127.6c0cb3...@freefall.freebsd.org>: jb> Hiroki Sato 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
Stari Karp wrote in <1483270342.3111.1.ca...@yandex.com>: st> On Sun, 2017-01-01 at 09:14 +0900, Hiroki Sato wrote: st> > Stari Karp wrote st> > in <1483220783.1715.3.ca...@yandex.com>: st> > st> > st> Hi! st> > st> st> > st> I try to install WindowMaker with Synth on FreeBSD 11-RELEASE st> > (amd64) st> > st> and I have a problem with libwraster: st> > st> > (snip) st> > st> > I could not reproduce this. Can you please show all of options you st> > chose? "-fopenmp" in your build log comes from libMagikCore because st> > you are using some non-default options at least for st> > graphics/ImageMagick. st> > st> > -- Hiroki st> st> Thank you very much for the help. I did uncheck openmp option in st> ImageMagick and it works :). I did not able to reproduce it even if ImageMagick was built with the OpenMP option. I guess your environment has another issue which pulls -lomp into the build process. -- Hiroki pgpV4lx3U9K87.pgp Description: PGP signature
Re: libwraster
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
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
Warren Block wrote in : 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 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
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
Ian Lord wrote in : 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
Michael 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
Scot Hetzel wrote
in :
sw> On Tue, Dec 2, 2014 at 8:38 AM, Philippe Lauget 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
"Dr. Peter Voigt" wrote in <20141125195336.590b7ffd@kirk.drpetervoigt.private>: pv> On Tue, 25 Nov 2014 19:41:51 +0100 pv> Marcus von Appen 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 not found
Erich Dollansky 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> 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 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
[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 2>&1; 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 2>&1; 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 "," " "
Re: TeXLive 2014
Greg Lewis 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
Re: texlive-texmf
Chris Rees 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
TeXLive 2014
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
Michael Gmelin wrote in : fr> fr> fr> > On 24 Jul 2014, at 20:38, Baptiste Daroussin wrote: fr> > fr> >> On Thu, Jul 24, 2014 at 02:05:35PM -0400, Lowell Gilbert wrote: fr> >> Andrea Venturoli 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)
Michael Gmelin 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
Andrey Fesenko wrote in : f0> On Thu, Dec 5, 2013 at 5:10 AM, hiren panchasara f0> wrote: f0> > On Wed, Dec 4, 2013 at 5:01 PM, Andrey Fesenko 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
hiren panchasara wrote in : hi> On Wed, Dec 4, 2013 at 12:47 PM, Hiroki Sato wrote: hi> > hiren panchasara wrote hi> > in : 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: security/trousers build failing on -current
hiren panchasara wrote in : 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: multimedia/rtmpdump shared lib issue... (now not work)
Andrey Fesenko wrote in : 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
Jerry 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)
Anton Shterenlikht 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 me>be 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?
Baptiste Daroussin 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
freebsd-tex mailling list
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
TeXLive build error on poudriere (Was: [patch included] teTeX and TeXLive)
Hiroki Sato wrote in <20130519.070840.2265196291393572686@allbsd.org>: hr> "Christopher J. Ruwe" 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
Re: [patch included] teTeX and TeXLive
"Christopher J. Ruwe" 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: [patch included] teTeX and TeXLive
"Christopher J. Ruwe" 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
Re: teTeX and TeXLive
Matthias Andree 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: teTeX and TeXLive
David Demelier wrote in : de> 2013/5/12 Florent Peterschmitt : 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: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o
Boris Samorodov 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: TEX_DEFAULT problem
RyōTa SimaMoto wrote in : 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
teTeX and TeXLive
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
Hiroto Kagotani wrote in : 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
Anton Shterenlikht wrote in <201305091538.r49fcwmj040...@mech-cluster241.men.bris.ac.uk>: me> me> > Stephen Montgomery-Smith wrote me> > in <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: USE_TEX question
Stephen Montgomery-Smith 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
Hiroto Kagotani wrote in : hi> 2013/5/7 Hiroki Sato hi> hi> > Stephen Montgomery-Smith wrote hi> > in <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: pkg: tex-kpathsea-6.1.0 conflicts with tex-kpathsea-6.1.0
Anton Shterenlikht 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: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}
Hiroki Sato 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: Problem with japanese/tex-ptex going very slowly
Stephen Montgomery-Smith 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 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: [print/tex-formats] does not install share/texmf-var/web2c/tex/tex.fmt but /usr/ports/mk/bsd.tex.mk uses it
Hi, Boris Samorodov 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: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}
Hiroki Sato 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: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}
Hiroki Sato wrote in <20130505.133807.335570424077607008@allbsd.org>: hr> Tadaaki Nagao 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: mozc-server 1.10.1390.102_2 build fail
Kenichi Niioka wrote in <20130429.183738.696763324454038489@iij4u.or.jp>: ni> From: h...@freebsd.org ni> Subject: Re: mozc-server 1.10.1390.102_2 build fail ni> Date: Mon, 29 Apr 2013 00:31:42 +0900 (JST) ni> ni> > ni> > Kenichi Niioka wrote ni> > in <20130428.234909.1246626834376249672@iij4u.or.jp>: ni> > ni> > ni> Dear porters. ni> > ni> ni> > ni> I have following error with FreeBSD 10.0-CURRENT #0 r250017 amd64. ni> > ni> ni> > ni> $ cd /usr/ports/japanese/mozc-server ni> > ni> $ make ni> > ni> ni> > ni> [snip] ni> > ni> > Please try the following and let me know if they work or not: ni> > ni> > http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130428-2.diff (patch) ni> > http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130428-2.tar.gz (tarball of the patched ports) ni> ni> I have folloing error. ni> ni> $ make ni> ===> ja-mozc-server-1.10.1390.102_3 depends on file: /usr/local/sbin/pkg - found ni> ===> Fetching all distfiles required by ja-mozc-server-1.10.1390.102_3 for building ni> ===> Extracting for ja-mozc-server-1.10.1390.102_3 ni> => SHA256 Checksum OK for mozc-1.10.1390.102.tar.bz2. ni> ===> Patching for ja-mozc-server-1.10.1390.102_3 ni> ni> [snip] ni> ni> CXX(host) out_linux/Release/obj.host/gen_symbol_rewriter_dictionary_main/rewriter/gen_symbol_rewriter_dictionary_main.o ni> CXX(host) out_linux/Release/obj.host/gen_usage_rewriter_dictionary_main/rewriter/gen_usage_rewriter_dictionary_main.o ni> LINK(host) out_linux/Release/gen_mock_segmenter_bitarray_main ni> CXX(host) out_linux/Release/obj.host/gen_existence_data/rewriter/gen_existence_data.o ni> /usr/bin/ld:out_linux/Release/obj.host/converter/libgen_segmenter_bitarray.a: file format not recognized; treating as linker script ni> /usr/bin/ld:out_linux/Release/obj.host/converter/libgen_segmenter_bitarray.a:1: syntax error ni> gmake: *** [out_linux/Release/gen_mock_segmenter_bitarray_main] Error 1 ni> gmake: *** Waiting for unfinished jobs ni> Traceback (most recent call last): ni> File "build_mozc.py", line 1485, in ni> main() ni> File "build_mozc.py", line 1470, in main ni> BuildToolsMain(cmd_opts, cmd_args, original_directory_name) ni> File "build_mozc.py", line 1005, in BuildToolsMain ni> BuildMain(options, [build_tools_target], original_directory_name) ni> File "build_mozc.py", line 1098, in BuildMain ni> BuildOnLinux(options, targets, original_directory_name) ni> File "build_mozc.py", line 1051, in BuildOnLinux ni> RunOrDie([make_command] + build_args + target_names) ni> File "/home/ken/src/ports/japanese/mozc-server/work/mozc-1.10.1390.102/build_tools/util.py", line 97, in RunOrDie ni> '=='])) ni> build_tools.util.RunOrDieError: ni> == ni> ERROR: /home/ken/src/ports/japanese/mozc-server/work/mozc-1.10.1390.102/mozcmake -j16 MAKE_JOBS=16 BUILDTYPE=Release builddir_name=out_linux build_tools ni> == ni> *** [pre-build] Error code 1 ni> ni> Stop in /home/ken/src/ports/japanese/mozc-server. Thank you for the feedback. Can you send me a whole build log when doing "make DEBUG=V=1" and the result of "uname -a"? -- Hiroki pgppyuMM8FDMy.pgp Description: PGP signature
Re: mozc-server 1.10.1390.102_2 build fail
Kenichi Niioka 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
Jeffrey Bouquet 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
Hiroto Kagotani wrote in : hi> 2013/2/28 Hiroki Sato hi> hi> > hi> > http://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
Stephen Montgomery-Smith 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
Re: CFT: texlive ports
Zhihao Yuan wrote in : li> On Wed, Feb 27, 2013 at 10:11 AM, Anton Shterenlikht li> 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
CFT: texlive ports
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?
Nathan Whitehorn 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?
Chris Rees wrote in : cr> On 6 February 2013 13:50, Nathan Whitehorn 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 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)
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 2>&1; then
+ check_namevarlist fib && return 0
+ fi
sysctl net.fibs >/dev/null 2>&1 || 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 2>&1
- ret=$?
- [ $ret -gt 0 ] && return 0
+ if command -v check_namevarlist > /dev/null 2>&1; then
+ check_namevarlist fib && return 0
+ fi
+
+ $SYSCTL net.fibs >/dev/null 2>&1 || 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 2>&1 || return 0
+ if command -v check_namevarlist > /dev/null 2>&1; then
+ check_namevarlist fib && return 0
+ fi
+ ${SYSCTL} net.fibs >/dev/null 2>&1 || 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 (revisi
Re: huge distfiles policy
Romain Tartière 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
Florent Peterschmitt wrote in <4fe67fb7.30...@gmail.com>: fp> On 24.06.2012 02:46, Hiroki Sato wrote: fp> > Florent Peterschmitt 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> > fp> > print/ghostscript9 depends on graphics/svgalib which provides vga.h. fp> > Please 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
Florent Peterschmitt 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
Chris Rees wrote in : cr> On 28 May 2012 18:11, Stephen Montgomery-Smith 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
Boris Samorodov 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 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)
Da Rock 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 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: Acroread: contacting maintainer
Da Rock wrote in <4f139c43.1050...@herveybayaustralia.com.au>: fr> What is the correct way to contact the maintainer for a port? Does one fr> contact directly? Or through a list (this one?)? Or pr? fr> 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. fr> fr> I tried a direct email, but I've received no response as yet after fr> several days; and I'm not 100% sure I did the right thing. I got your email on last Saturday and it's Monday afternoon. I need to test it in multiple environments before committing the change at least, so please give me time to investigate. -- Hiroki pgpu5tF5Y9Fgv.pgp Description: PGP signature
Re: Clicking URLs with acroread8
Doug Barton 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
Doug Barton 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
Romain Tartière 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'
"O. Hartmann" 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
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
Peter Olsson 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
Jamie Griffin 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: Attempted upgrade of ghostscript8-8.64_7 -> ghostscript-8.70 failed
David Wolfskill 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: FreeBSD Port: pcb-20081128_1
William Bulley 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" "Tab"}}
+{"Flip left/right" checked=flip_x SwapSides(H) a={"Shift-Tab" "ShiftTab"}}
+- {"Spin 180ｰ" SwapSides(R) a={"Ctrl-Tab" "CtrlTab"}}
++ {"Spin 180" SwapSides(R) a={"Ctrl-Tab" "CtrlTab"}}
+{"Swap Sides" SwapSides() a={"Ctrl-Shift-Tab" "Ctrl ShiftTab"}}
+{"Center cursor" Center() a={"C" "c"}}
+{"Show soldermask" checked=showmask Display(ToggleMask)}
pgp6Vw2cGbQOl.pgp
Description: PGP signature
Re: FreeBSD Port: openbgpd-4.5.20090709
Hi, Lasta Yani 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
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 wrote in <20090617.141203.07900852@allbsd.org>: hr> Robert Huff 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.
Robert Huff 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> > ro> > Can you add more detailed information on your environment? Packages ro> > you installed and compat.linux.osrelease sysctl are needed at the ro> > very least. ro> ro> compat.linux.osrelease: 2.6.16 ro> linux_base-f8-8_11 ro> ro> > Acrobat 9 works with compat.linux.osrelease=2.4.2 and ro> > linux_base-fc-4_13 on 7.2-RELEASE. On other environments it may ro> > or 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.
eculp 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
Romain Tartière 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
Re: RFC: $USE_[GU]ID for consistent [GU]ID handling
"Florent Thoumie" <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: fl> There's an open PR with patches for this feature (ports/108514). Could fl> you have a look and maybe send your comments? Oh, sorry, I did not notice that. I will read the PR and follow-ups first. Thank you for the pointer. -- | Hiroki SATO pgpI8tRGzvN39.pgp Description: PGP signature
RFC: $OPTIONS in line-oriented terminal
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" ;;
+
RFC: $USE_[GU]ID for consistent [GU]ID handling
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 2>&1 || ( ${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 2>&1; 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 2>&1;
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 2>&1;
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 2>&1 || ( ${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 2>&1; then \
+ ${PW} groupadd -n "$${1}" -g "$${3}"; \
+ fi; \
+ ${ECHO_CMD} "@exec if ! ${PW} groupshow \"$${1}\" > /dev/null
2>&1; then ${PW} groupadd -n \"$${1}\" -g \"$${3}\"; fi" >> ${TMPPLIST}; \
+ ${ECHO_CMD} "@unexec if ${PW} groupshow \"$${1}\" > /dev/null
2>&1; 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
\
Re: print/cm-super size mismatch
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
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
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
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
Nikola Lečić <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: ni> > - acroread8 + GTK_IM_MODULE=xim + [EMAIL PROTECTED] ni> ni> Not for me. Linux im-scim.so must be present, and GTK_IM_MODULE must be ni> changed to scim. Otherwise, acroread8 will load linux im-xim.so and SCIM ni> won't work. XMODIFIERS doesn't matter in this case. ni> ni> (Again, I think that xim/XIM isn't preferable combination for SCIM user, ni> as stated above.) ni> ni> > - acroread8 + GTK_IM_MODULE=scim ni> ni> * With linux im-scim.so present, yes, it works. ni> * Without linux im-scim.so, nothing bad happens. acroread8 just loads ni> Linux im-xim.so and SCIM won't work. Thank you for the report. In my environment, [EMAIL PROTECTED] works well, and when Linux im-scim.so does not exist, acroread8+GTK_IM_MODULE=scim does not load Linux im-xim.so and just gets hosed just after FreeBSD's im-scim.so loaded. ni> ... and that's why this confuses me: do you mean that you get ni> acroread8+SCIM working without linux im-scim.so? Yes, by setting GTK_IM_MODULE=xim + [EMAIL PROTECTED] Linux im-xim.so is used at that time. Hmm, these two cases are different from me. Let me investigate this further... This problem is due to interaction between FreeBSD's gtk library and Linux's, so I am guessing there is consistency in some degree and want to figure out it. And honestly, I do not want to add a separate port that installs the Linux im-scim.so if possible because if the acroread8 port should depend on it or not is a moot point. Any other people can reproduce these symptoms? I received both "OK" and "NG" reports when both GTK_IM_MODULE=xim and [EMAIL PROTECTED] are set at a time so far, and bit confused. -- | Hiroki SATO pgpnLClWSawfk.pgp Description: PGP signature
Re: CFT: Adobe Reader 8 + SCIM/UIM
Nikola Lečić <[EMAIL PROTECTED]> wrote
in <[EMAIL PROTECTED]>:
ni> 3. Now acroread7 doesn't work (for me at least), with all SCIM-related
ni>environment variables schemes. It just returns me back to the shell
ni>prompt without any error message;
ni>
ni> 4. However, if I use the environment scheme I suggested in my previous
ni>mail and change GTK_IM_MODULE/XMODIFIERS in acroread7 startup
ni>script 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
Re: CFT: Adobe Reader 8 + SCIM/UIM
"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
CFT: Adobe Reader 8 + SCIM/UIM (was Adobe Reader and SCIM)
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
