Re: Java wildfly port
Hi! I updated archive (with tweaks from both Kurt and Horst). https://home.gits.kiev.ua/wildfly80.tar.bz2 I worked on the port, found a solution for the install as user/group www/www issue and submitted it to my mentors. See http://people.freebsd.org/~pi/misc/wildfly80-8.0.0.log for the build log and http://people.freebsd.org/~pi/misc/wildfly80.tgz for the current state. I hope we'll have it in the ports system soon. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On Sun, 11 May 2014 10:22:58 +0200 John Marino wrote: On 5/11/2014 04:02, Montgomery-Smith, Stephen wrote: I have noticed that make all now includes the staging as well as building. That is to say, it looks like there is a rather wholesale reordering of how ports build and install. From this I conclude it is becoming harder to include the legacy NO_STAGE code, which presumably must stick to the old way of doing things. I don't understand this paragraph. I never use make all at the ports level. make install will do 2 steps: install into the staging area and then install onto the system. If you just want to install in the staging area, you use make stage target. By definition all is do everything, so that's not a surprise that's not a surprise. Maybe stop using all? A lone make is equivalent to make build, so just use that perhaps? He was referring to this in bsd.port.mk: .if !target(all) . if defined(NO_STAGE) all: build . else all: stage . endif .endif ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
What should I replace @exec and @unexec with?
I was taking a look at the Porter's Handbook today and noticed that
@exec and @unexec are considered deprecated, but I couldn't find out
what should be used instead.
Should all uses of @exec and @unexec be replaced with pkg-{un}install
scripts in the future?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] 353669: 4x leftovers
- revert to libtool:oldver - Build ID: 20140511101400-32289 Job owner: din...@freebsd.org Buildtime: 16 minutes Enddate: Sun, 11 May 2014 10:30:03 GMT Revision: 353669 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=353669 - Port:graphics/graphviz 2.36.0_6 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~din...@freebsd.org/20140511101400-32289-329978/graphviz-2.36.0_6.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~din...@freebsd.org/20140511101400-32289-329979/graphviz-2.36.0_6.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~din...@freebsd.org/20140511101400-32289-329980/graphviz-2.36.0_6.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~din...@freebsd.org/20140511101400-32289-329981/graphviz-2.36.0_6.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140511101400-32289 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] 353665: 3x leftovers, 1x depend (??? in x11-toolkits/wxgtk28)
Chase the upgrade of kicad in CONFLICTS. Approved by:portmgr (implicit) - Build ID: 20140511100400-15385 Job owner: thie...@freebsd.org Buildtime: 30 minutes Enddate: Sun, 11 May 2014 10:34:24 GMT Revision: 353665 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=353665 - Port:cad/kicad-devel r4313_5 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~thie...@freebsd.org/20140511100400-15385-329962/kicad-devel-r4313_5.log Buildgroup: 8.4-QAT/i386 Buildstatus: DEPEND (??? IN X11-TOOLKITS/WXGTK28) Log: https://qat.redports.org//~thie...@freebsd.org/20140511100400-15385-329963/wx28-gtk2-2.8.12_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~thie...@freebsd.org/20140511100400-15385-329964/kicad-devel-r4313_5.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~thie...@freebsd.org/20140511100400-15385-329965/kicad-devel-r4313_5.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140511100400-15385 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: emulators/wine: could not run any applications under wine-1.6.2_2, 1
You have a running wine binary - either a left-over program, or a crashed or hung server - left over from before you updated. If you can't find a running wine program to close, use 'ps wax |grep wine' to find any remaining wine programs, and either kill them or 'kill -9' them if they are stubborn. On 11 May 2014 18:48, KOT MATPOCKuH matpoc...@gmail.com wrote: Hi all! I can't start any windows application under wine 1.6.2 on FreeBS10/i386. For example: $ wine putty.exe wine: created the configuration directory '/home/dima/.wine' wine client error:0: version mismatch 431/447. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? $HOME/.wine directory was removed, but problem stil exists. Any ideas to fix this issue? -- MATPOCKuH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: emulators/wine: could not run any applications under wine-1.6.2_2, 1
Omg. I'm complete idiot. I had a wrong alias for wine, that run wine from full root environment with old wine's packages. 2014-05-11 14:45 GMT+04:00 Robert Backhaus rob...@robbak.com: You have a running wine binary - either a left-over program, or a crashed or hung server - left over from before you updated. If you can't find a running wine program to close, use 'ps wax |grep wine' to find any remaining wine programs, and either kill them or 'kill -9' them if they are stubborn. On 11 May 2014 18:48, KOT MATPOCKuH matpoc...@gmail.com wrote: Hi all! I can't start any windows application under wine 1.6.2 on FreeBS10/i386. For example: $ wine putty.exe wine: created the configuration directory '/home/dima/.wine' wine client error:0: version mismatch 431/447. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? $HOME/.wine directory was removed, but problem stil exists. Any ideas to fix this issue? -- MATPOCKuH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- MATPOCKuH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On 05/11/2014 03:22 AM, John Marino wrote:
On 5/11/2014 04:02, Montgomery-Smith, Stephen wrote:
On 05/10/2014 08:48 PM, Jonathan Chen wrote:
On 11 May 2014 03:33, Bryan Drewery bdrew...@freebsd.org wrote:
[...]
I have noticed that make all now includes the staging as well as
building. That is to say, it looks like there is a rather wholesale
reordering of how ports build and install. From this I conclude it is
becoming harder to include the legacy NO_STAGE code, which presumably
must stick to the old way of doing things.
I don't understand this paragraph. I never use make all at the ports
level. make install will do 2 steps: install into the staging area
and then install onto the system. If you just want to install in the
staging area, you use make stage target. By definition all is do
everything, so that's not a surprise that's not a surprise. Maybe stop
using all? A lone make is equivalent to make build, so just use
that perhaps?
When you type make by itself, you are implicitly meaning make all.
(You can see this by looking at bsd.port.mk.)
It used to be that when you typed make, it would build the sources.
Then make install would create a staging area, and then directly copy
the staged stuff it to ${PREFIX}.
But now, when you type make, it builds the source, AND installs the
stuff into the staging area. All make install does is copy the staged
stuff to ${PREFIX}.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On Sat, 10 May 2014 10:47:42 -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 5/10/2014 10:33 AM, Bryan Drewery wrote: You are receiving this mail as it affects FreeBSD ports that you maintain. You can see the full list here: http://people.freebsd.org/~bapt/notstaged.txt -- Regards, Bryan Drewery Regarding graphic/darktable, there have been for months an update proposal that included stage support: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186979 (while I don't agree on enforcing the entirely optionnal ninja as cmake bakend). -- Matthieu Volat ma...@alkumuna.eu signature.asc Description: PGP signature
staging
Is there a way to find out if a port is being used? Some of my ports are pretty old. No point in upgrading them if no one is using them. Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: staging
On Sun, 11 May 2014 12:18:56 -0500 Paul Schmehl wrote: Is there a way to find out if a port is being used? Some of my ports are pretty old. No point in upgrading them if no one is using them. You can deprecate a port with an expiration date. If nobody shows up before that date you can delete the port. And if somebody shows up after that it can still be restored. DEPRECATED= yes EXPIRATION_DATE=-MM-DD ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Kalzium build fails (part of KDE4 port upgrade)
portupgrade kalzium ... [ 48%] Generating parser.cmx [ 49%] Generating datastruct.cmx [ 50%] Generating chem.cmi [ 51%] Generating lexer.cmx [ 51%] Generating chem.cmx File /usr/ports/science/kalzium/work/kalzium-4.12.5/src/solver/chem.ml, line 1: Error: /usr/local/lib/ocaml/facile/facile.cmi is not a compiled interface for this version of OCaml. It seems to be for an older version of OCaml. *** [src/chem.cmx] Error code 2 1 error *** [src/CMakeFiles/kalzium.dir/all] Error code 2 ... uname -a FreeBSD amd.asgard.uk 9.2-RELEASE-p5 FreeBSD 9.2-RELEASE-p5 #0: Tue Apr 29 19:09:13 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/binutils and devel/gnulibiberty version mismatch
On 05/09/14 20:08, Gerald Pfeifer wrote: On Fri, 9 May 2014, Geoff Speicher wrote: Bringing in other parties for feedback, based on their mention in the binutils commit (svn link below). This reminded me of ports/184327: devel/binutils erroneously installs $PREFIX/include/ansidecl.h. That has been fixed, when I updated devel/binutils to 2.24. Regards! -- Niclas Zeising ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Kalzium build fails (part of KDE4 port upgrade)
Dave freebs...@dgmm.net writes: [ 48%] Generating parser.cmx [ 49%] Generating datastruct.cmx [ 50%] Generating chem.cmi [ 51%] Generating lexer.cmx [ 51%] Generating chem.cmx File /usr/ports/science/kalzium/work/kalzium-4.12.5/src/solver/chem.ml, line 1: Error: /usr/local/lib/ocaml/facile/facile.cmi is not a compiled interface for this version of OCaml. It seems to be for an older version of OCaml. Does it help if you rebuild math/facile? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
sage build error
Trying build sage I get the following error: [reference] updating environment: 2 added, 0 changed, 0 removed [reference] reading sources... [ 50%] index [reference] reading sources... [100%] todolist [reference] Merging environment/index files... [reference] algebras: 2 todos, 16 index, 5 citations, 416 modules [reference] arithgroup: 0 todos, 12 index, 9 citations, 295 modules [reference] calculus: 2 todos, 23 index, 2 citations, 438 modules [reference] categories: 13 todos, 130 index, 6 citations, 567 modules [reference] cmd: 0 todos, 6 index, 0 citations, 277 modules [reference] coding: 0 todos, 10 index, 6 citations, 576 modules [reference] coercion: 0 todos, 4 index, 0 citations, 579 modules ./sage: line 134: 75966 Killed: 9 $SAGE_ROOT/src/bin/sage $@ gmake: *** [doc-html] Error 137 *** [do-build] Error code 1 Stop in /usr/ports/math/sage. *** [install] Error code 1 Stop in /usr/ports/math/sage. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Standard procedures for var directory
Hi, What's the standard procedure for creating files or folders after installation? pkg-install/pkg-deinstall or @exec/@unexec? Thanks in advance. BR, Muhammad ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Kalzium build fails (part of KDE4 port upgrade)
On Sunday 11 May 2014 22:56:52 Raphael Kubo da Costa wrote: Dave freebs...@dgmm.net writes: [ 48%] Generating parser.cmx [ 49%] Generating datastruct.cmx [ 50%] Generating chem.cmi [ 51%] Generating lexer.cmx [ 51%] Generating chem.cmx File /usr/ports/science/kalzium/work/kalzium-4.12.5/src/solver/chem.ml, line 1: Error: /usr/local/lib/ocaml/facile/facile.cmi is not a compiled interface for this version of OCaml. It seems to be for an older version of OCaml. Does it help if you rebuild math/facile? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org I did rebuild math/facile but I have problem to install science/avogadro (FreeBSD 10.0-RELEASE, amd64): Compressing man pages (compress-man) === Starting check for runtime dependencies === Gathering dependency list for science/avogadro from ports === Dependency check complete for science/avogadro === kalzium-4.12.4 science/avogadro (1/1) === Installing for avogadro-1.1.1_2 === Checking if science/avogadro already installed === Registering installation for avogadro-1.1.1_2 as automatic pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site- packages/Avogadro.so): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/): No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/science/avogadro *** Error code 1 Stop. make: stopped in /usr/ports/science/avogadro === Installation of avogadro-1.1.1_2 (science/avogadro) failed === Aborting update === Update for science/avogadro failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags science/kalzium science/avogadro -- ajtiM http://www.redbubble.com/people/lumiwa ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/binutils and devel/gnulibiberty version mismatch
On Sun, May 11, 2014 at 3:56 PM, Niclas Zeising zeis...@freebsd.org wrote: On 05/09/14 20:08, Gerald Pfeifer wrote: On Fri, 9 May 2014, Geoff Speicher wrote: Bringing in other parties for feedback, based on their mention in the binutils commit (svn link below). This reminded me of ports/184327: devel/binutils erroneously installs $PREFIX/include/ansidecl.h. That has been fixed, when I updated devel/binutils to 2.24. Regards! Actually, I have a question about ports/184327. This bug report asserts that ansidecl.h is an internal file necessary only to build the GNU toolchain and should not be installed by devel/binutils. However, binutils also installs bfd.h which happens to include ansidecl.h (at least, it does in v2.24). Therefore, the installed bfd.h is broken. This fact either contradicts the original assertion that ansidecl.h should not be installed, or else it implies that bfd.h should not be installed either. However, if we did not install bfd.h then we probably shouldn't install bfd.a either, and at least some ports seem to rely on binutils to provide them both. So I am questioning whether the removal of ansidecl.h from the devel/binutils install is the optimal fix, or if there is a better way to handle this that allows lang/gcc49 to work without breaking devel/binutils and programs that rely on BFD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/binutils and devel/gnulibiberty version mismatch
On Sun, May 11, 2014 at 5:41 PM, Geoff Speicher ge...@sea-incorporated.comwrote: Actually, I have a question about ports/184327. This bug report asserts that ansidecl.h is an internal file necessary only to build the GNU toolchain and should not be installed by devel/binutils. However, binutils also installs bfd.h which happens to include ansidecl.h (at least, it does in v2.24). Therefore, the installed bfd.h is broken. This fact either contradicts the original assertion that ansidecl.h should not be installed, or else it implies that bfd.h should not be installed either. There was a third possibility that I had overlooked, and appears to be a decent compromise: bfd.h doesn't actually need to directly include ansidecl.h for anything that I can see, so if we patch the port to remove the include directive then bfd.h is no longer broken and ports/184327 is also satisfied. Any objections to this? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On 11/05/2014 1:47 AM, Bryan Drewery wrote: On 5/10/2014 10:33 AM, Bryan Drewery wrote: You are receiving this mail as it affects FreeBSD ports that you maintain. You can see the full list here: http://people.freebsd.org/~bapt/notstaged.txt Thanks for sharing the list of 3851 ports in nonstaged.txt. It is a little disconcerting that 759 maintainers have decided to either not convert to staging or decided to walk away. # cat notstaged.txt | cut -d: -f2 | sort | uniq | cut -d@ -f1 | uniq | wc -l 759 John alluded to a plan for ports, of which staging is a prerequisite, is there a current plan available to be shared? It might help some maintainers to buy-in to the staging paradigm and continue their valuable contribution to the FreeBSD project. The prospect of freezing my ports tree, at end of June, and cherry-picking ports isn't pleasant. Dewayne. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
editors/uemacs
On Sat 2014-05-10 10:33:52 UTC-0500, Bryan Drewery (bdrew...@freebsd.org) wrote: On June 31st, all unstaged ports will be marked DEPRECATED and have their MAINTAINER reset. On August 31st, all unstaged ports will be removed from the ports tree. I'm the listed maintainer of editors/uemacs, which is currently unstaged. Since I switched to JED some time ago I haven't used MicroEMACS, so have little motivation in working through this just for a single port. If anyone still using uemacs would like to take over as maintainer, that'd be cool. Regards Andrew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/doxygen: Need TeX help
On 03/18/14 18:32, Naram Qashat wrote: On 03/18/14 11:56, A.J. 'Fonz' van Werven wrote: Naram Qashat wrote: I basically get the following when it comes up to ./langhowto.tex: ! LaTeX Error: Environment longtable undefined. [snip] It's probably not as simple as this, but I'll ask anyway: have you tried the following? # texconfig-sys rehash I hadn't tried that, but I did that just now and I still get the same error. Would've been nice if it had been that simple. :P Bummer, sorry it didn't help. However, as you may have noticed I quoted your entire message in my first reply and CC'ed it to the freebsd-tex@ mailing list. So hopefully someone on either list (the other being freebsd-ports@) knows what else to try. Furthermore: are you getting this error during building or during use? I tried building devel/doxygen with PDF support and it built perfectly fine here. AvW It was during building. The port is currently at 1.8.3.1, and I actually ran into the problem in the email when I initially was trying to update to 1.8.4. That was the main reason I haven't pushed out an update to the port yet. Oddly enough, when I try to build 1.8.3.1 on my machine currently, I also get a TeX error, but an entirely different one. I can't recall what the error was, but it had nothing to do with longtable. Thanks, Naram Qashat I'm going to try bringing this back up, since it has been a bit over a month now. Doxygen updated to 1.8.7, so I went back to trying to update the port. Now, I am getting two different stopping points with TeX depending on if I use teTeX or TeXLive. If I use teTeX, then I get the following error: ! Package keyval Error: pdfencoding undefined. I'm not exactly sure what part of the manual is causing this, but it seems to happen pretty quickly upon starting the PDF creation process. If I use TeXLive, though, it gets past that point and then ends up with the same error as I was getting with 1.8.6, with the longtable error shown earlier in this thread. Because I wasn't sure if something in my own system's environment was the issue, I built the ports using Tinderbox and Poudriere in a virtual machine. So apparently it isn't an issue with my system, as a pristine and jailed system has the same issue. Both my system as well as the one in the VM are 9-STABLE, since I think I did forget to mention that earlier in the thread (oops). One thing, though, about the keyval error, someone reported it on a mailing list, but there was no reply. It appears to have come about since 1.8.7 got released. I really would appreciate some insight on this, though. I know nothing about TeX and these errors just keep making the doxygen port get more and more outdated. Thanks, Naram Qashat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: editors/uemacs
I'm a bit busy, but if no one else comes forward, let me know. On Mon, 12 May 2014 10:13:46 +1000 andrew clarke m...@ozzmosis.com wrote: On Sat 2014-05-10 10:33:52 UTC-0500, Bryan Drewery (bdrew...@freebsd.org) wrote: On June 31st, all unstaged ports will be marked DEPRECATED and have their MAINTAINER reset. On August 31st, all unstaged ports will be removed from the ports tree. I'm the listed maintainer of editors/uemacs, which is currently unstaged. Since I switched to JED some time ago I haven't used MicroEMACS, so have little motivation in working through this just for a single port. If anyone still using uemacs would like to take over as maintainer, that'd be cool. Regards Andrew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: editors/uemacs
On Mon 2014-05-12 10:13:46 UTC+1000, andrew clarke (m...@ozzmosis.com) wrote: I'm the listed maintainer of editors/uemacs, which is currently unstaged. Since I switched to JED some time ago I haven't used MicroEMACS, so have little motivation in working through this just for a single port. If anyone still using uemacs would like to take over as maintainer, that'd be cool. Update: Joseph Benden submitted a patch already! http://www.freebsd.org/cgi/query-pr.cgi?pr=189689 Thanks Joseph. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
On Sun, May 11, 2014 at 5:31 PM, andrew clarke m...@ozzmosis.com wrote:
On Sat 2014-05-10 10:47:42 UTC-0500, Bryan Drewery (bdrew...@freebsd.org)
wrote:
On 5/10/2014 10:33 AM, Bryan Drewery wrote:
You are receiving this mail as it affects FreeBSD ports that you
maintain.
You can see the full list here:
http://people.freebsd.org/~bapt/notstaged.txt
A short script I threw together to show any ports installed that are
marked as unstaged in the above list:
#!/bin/sh
pkg info -oa | awk '{ print $2 }' | sort /tmp/installed.list
fetch -o - http://people.freebsd.org/~bapt/notstaged.txt | awk -F: '{
print $1 }' | sort | uniq /tmp/notstaged.list
cat /tmp/installed.list /tmp/notstaged.list | sort | uniq -d
rm -f /tmp/installed.list /tmp/notstaged.list
Output on my system:
- 100% of 139 kB 162 kBps
00m01s
editors/uemacs
lang/spidermonkey17
mail/dovecot
misc/jive
misc/zoneinfo
multimedia/mediainfo
net/istgt
net/torsocks
security/xinetd
sysutils/rename
Regards
Andrew
Many thanks!
Boy, do I have a LOT of port, many very important (to me) that are on the
list. I won't put it out here, but it's 72 ports long.
Guess I need to sit sown and fix many of them. Some may be more than I can
deal with, especially the Gnome ones, but I'll be ditching those shortly,
anyway. Hopefully most of the remainder are fairly straight forward,
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Kalzium build fails (part of KDE4 port upgrade)
This affected me, and rebuilding math/facile fixed it. Maybe math/facile needs to be bumped. But I had no problems rebuilding or reinstalling avogadro. On 12 May 2014 07:11, Ajtim lum...@gmail.com wrote: On Sunday 11 May 2014 22:56:52 Raphael Kubo da Costa wrote: Dave freebs...@dgmm.net writes: [ 48%] Generating parser.cmx [ 49%] Generating datastruct.cmx [ 50%] Generating chem.cmi [ 51%] Generating lexer.cmx [ 51%] Generating chem.cmx File /usr/ports/science/kalzium/work/kalzium-4.12.5/src/solver/ chem.ml, line 1: Error: /usr/local/lib/ocaml/facile/facile.cmi is not a compiled interface for this version of OCaml. It seems to be for an older version of OCaml. Does it help if you rebuild math/facile? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org I did rebuild math/facile but I have problem to install science/avogadro (FreeBSD 10.0-RELEASE, amd64): Compressing man pages (compress-man) === Starting check for runtime dependencies === Gathering dependency list for science/avogadro from ports === Dependency check complete for science/avogadro === kalzium-4.12.4 science/avogadro (1/1) === Installing for avogadro-1.1.1_2 === Checking if science/avogadro already installed === Registering installation for avogadro-1.1.1_2 as automatic pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site- packages/Avogadro.so): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/): No such file or directory pkg-static: lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/): No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/science/avogadro *** Error code 1 Stop. make: stopped in /usr/ports/science/avogadro === Installation of avogadro-1.1.1_2 (science/avogadro) failed === Aborting update === Update for science/avogadro failed === Aborting update === Killing background jobs Terminated === You can restart from the point of failure with this command line: portmaster flags science/kalzium science/avogadro -- ajtiM http://www.redbubble.com/people/lumiwa ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: To all port maintainers: libtool
Am 08.05.2014 00:24, schrieb Tijl Coosemans: Hi, I've been asked to write something about USES=libtool to clarify a few things about what it does and why. Tijl, thanks for the effort. I have two findings I do not currently fully understand, perhaps someone who has done more digging into either of these items can help me with them: Issue #1: .la files I just received PR 189491 (which proposes USES=libtool:keepla) and looked at it, and thought it good to kill the .la files, so I have tried USES=libtool, without keepla or stuff. The port also has a patch to flip from -avoid-version to -version-info 0:0:0, and I tried to build with or without. (It should not matter much because libdb does not have non-system requisites, i. e. the port has no LIB_DEPENDS - it only uses libpthreads.) Now, with USES=libtool added, I either have both the foo.so.0 and foo.so.0.0.0 files, with the SONAME being the libdb-4.8.so.0, or if I leave the original upstream -avoid-version setting, I get libdb-4.8.so as SONAME and see libdb-4.8.so.0 files missing. With USES=libtool:keepla, this does not happen. It is utterly unclear to me how that fits together, so my first question is: can you reproduce this behaviour, or is my system goofing up? What concerns me about that is (1) that the file matching the SONAME of the library is merely a symlink, and (2) that the USES=libtool:keepla option apparently might have more effects than documented, namely, adding more library_names with the .0.0.0 and .0 suffix. Issue #2: libpthread. An .la file might look like this: [...] # Linker flags that can not go in dependency_libs. inherited_linker_flags=' -pthread' # Libraries that this one depends upon. dependency_libs=' -lpthread' [...] Now, if I remove the .la file, and a slave port that uses libtool to link will then have to list -pthread explicitly on the newer FreeBSD releases (because those fail linking if indirect .so requisites are missing). :keepla causes the inherited_linker_flags=-pthread to remain set, so I presume it is safe in this case. However, it does not appear to me that keepla is a temporary measure here, but it looks like it needs to stay forever. Any insights, from anyone? Cheers, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
qgis, mapserver, deegree ports
Hi, I'm working with OSGeo to get the various projects they work with to provide upstream support for FreeBSD, including maintaining ports so that they stay up to date. You can find a list of these projects at https://github.com/OSGeo/osgeo4freebsd/ I was wondering if you would be interested in continuing to maintain these ports, or if you'd rather see their maintenance move upstream. Thanks, --- Harrison ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qgis, mapserver, deegree ports
Am 12.05.2014 06:59 (UTC+1) schrieb Harrison Grundy: Hi, I'm working with OSGeo to get the various projects they work with to provide upstream support for FreeBSD, including maintaining ports so that they stay up to date. You can find a list of these projects at https://github.com/OSGeo/osgeo4freebsd/ I was wondering if you would be interested in continuing to maintain these ports, or if you'd rather see their maintenance move upstream. Hi Harrison, there was a change with graphics/qgis, the maintainership changed from wen@ to me (rhur...@gwdg.de). I would like to keep maintainership for the foreseeable future. There is another gis desktop application, I am the maintainer of: math/saga. SAGA GIS also belongs to the OSGEO distributions and is available for FreeBSD, see supported platforms for example at http://live.osgeo.org/en/overview/saga_overview.html . I think, SAGA GIS should be incorporated in your list? Thanks for your work, Rainer Thanks, --- Harrison ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Standard procedures for var directory
On 11/05/2014 21:56, Muhammad Moinur Rahman wrote: What's the standard procedure for creating files or folders after installation? pkg-install/pkg-deinstall or @exec/@unexec? Right now, what the standard should be is unclear. @exec/@unexec is apparently slated for removal -- but does that apply to all uses or just standard actions like handling config files which have recently grown their own @escapes? There is no target date for when @exec/@unexec might disappear and there's a lot of prior-art around the ports tree still. pkg-install/pkg-deinstall is supported, but seems a bit heavy-weight for a lot of the common use cases. A third alternative, where applicable, is to test for and set up any necessary directory structures (presumably under /var) from a rc script. Files should always be created from the pkg plist, even if they are just empty. There is a change coming which will allow directories to be treated pretty much exactly the same as regular files or sym-links -- but this depends on the last vestiges of pkg_tools support being purged from the tree. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
