Re: net/libarcus fails to install
On Wed, Dec 30, 2020 at 11:01:05AM +1030, Shane Ambler wrote:
> On 28/12/20 4:40 am, Torfinn Ingolfsen wrote:
> > On Sun, Dec 27, 2020 at 2:41 PM Torfinn Ingolfsen wrote:
> >>
> >> net/libarcus builds, but fails to install:
>
> > FWIW, devel/libsavitar has the same "problem"; with python38 installed
> > it fails to install because it builds for 3.8 instead of 3.7.
>
> The issue is in cmake - I have just reported it as a bug
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252277
Thanks for tracking this down! This bug of course fails to show
up on poudriere.
>
> For a workaround try adding the following to the end of the libarcus
> Makefile (above the last .include line) indents are tabs not spaces
> The same addition should also work for libsavitar
>
> post-patch:
> ${REINPLACE_CMD} -e 's|VERSION_LESS 3.12|VERSION_LESS 4.12|g' \
> ${WRKSRC}/CMakeLists.txt \
> ${WRKSRC}/cmake/FindSIP.cmake
>
Should we do this for now? Or wait for CMake to be fixed?
I can certainly add this snippet to the port for now.
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qrc:/Desktop.qml:26 module "QtQuick.Dialogs" is not installed
On Fri, Apr 03, 2020 at 08:44:14AM +0200, Wojciech Puchar wrote: > what package am i missing? Try x11-toolkits/qt5-quickcontrols -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
firefox
I used seamonkey for years without problems. Now with seamonkey no longer available I have tried firefox. It crashes regularly and isn't nearly as good as seamonkey. When are you bringing seamonkey back? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: category for VPN softwares?
On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote: > On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> wrote: > > > > On Tue, 2 Apr 2019 at 10:58, Stefan Esser wrote: > > > > > Am 02.04.19 um 07:42 schrieb Koichiro Iwao: > > > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote: > > > >> Create a real category vpn and move everything to it ? > > > > > > > > Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also have > > > > net-dialup category. PPP/PPPoE/L2TP softwares are put under net-dialup > > > > but I feel that classification is too fine. At least creating vpn or > > > > net-vpn souds good. > > > > > > How about a new "real" category vpn > > > > > > I am not sure if it should be vpn or net-vpn. I feel net-vpn is > > more suitable. > > > > > > > and preserving the current categories > > > of the ports as their additional categories (assuming that they are in net > > > vs. security for a reason). > > > > > > > I like the idea. > > Creating new categories is absolutely doable! However, we have a > pretty high bar for justifying it. There's no magic number, but our > (portmgr's) precedent is that the new category must, at the time of > creation, be as full as other categories like it. > > The most important thing in the new category proposal is a > comprehensive list of ports that will be moved to it. Put that into a > review or a PR and we can move forward. Fair warning though, if it's > only about a dozen ports, it most likely will not be approved. > > My approach here is that new categories should be virtual unless the > evidence for hard category is incontrovertible. It's far easier making a virtual category and easier to count ports. e.g. https://www.freshports.org/hamradio We have 101 hamradio related ports with more coming... korean has 43,portuguese has 15,russian has 42 although languages are a special case palm has 15 ports but whatever. ;) I'd be surprised if there weren't more vpn ports than 101 so why not go with a virtual ports category to start with? > > # Adam > > > -- > Adam Weinberger > ad...@adamw.org > https://www.adamw.org > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: category for VPN softwares?
On Tue, Apr 02, 2019 at 11:38:15AM +0200, Mateusz Piotrowski wrote: > On Tue, 2 Apr 2019 at 10:58, Stefan Esser wrote: > > > Am 02.04.19 um 07:42 schrieb Koichiro Iwao: > > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote: > > >> Create a real category vpn and move everything to it ? ... ... > > > and preserving the current categories > > of the ports as their additional categories (assuming that they are in net > > vs. security for a reason). > > > > I like the idea. Hey if you can convince port managers that a new real category is in order I'll petition for a real hamradio category. We are currently split between audio, comms, misc, cad ... ;) It will be much easier getting a new virtual category than a real category. I'd agree a real category for both vpn and hamradio would be nice but it's a PITA and personally I don't feel it matters that much. -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > wrote: > > > > On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > > > > > If I were the lang/gcc maintainer this -rpath problem would be my number > > > > one priority. The current maintainer has never proposed any solutions > > > > and when I submit patches he always resists. I'm done wasting my time > > > > fighting him. > > > > > > I'm late to this discussion (not being a Fortran/Python user) but is there > > > any way to remove a recalcitrant maintainer? > > > > > > > Dave, > > > > Can you explain what you mean? The maintainer of the lang/gcc > > ports is a long-time member of the GCC steering committee > > and a long-time maintainer of all gcc FreeBSD ports. There > > are very few FreeBSD users (like 3 of us) who have commit access > > to the gcc tree. Seems like a dubious idea to remove one of > > those 3. > > Given the amount of time unsuspecting and half-suspecting users wasted > on making Fortran code (often in form of a Python extension) working > on FreeBSD (e.g. I probably wasted weeks), time is high to do > something, e.g. commit the said patches---there is an agreement that > they are correct, right? > > Dima > http://users.ox.ac.uk/~coml0531/ Dima, gerald has always been very helpful in all my communications with him. Have you filed a PR for the fix? dropped him an email? I know we (gerald and ?? can't remember) tried a static lib change a few years ago. I believe it didn't work at the time due to missing symbols which we have since added. > > > > > -- > > Steve Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 01:46:46PM -0800, Steve Kargl wrote:
> On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
> >
> > Yes yes and yes. It would be a right PITA. Perhaps it could be done
> > with some weak symbols but personally I think that's another hack.
> > I'll go look for whatever symbols we are missing and see if we
> > can fix our libgcc_s
> >
>
> Diane,
>
> The missing symbols are
>
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> __addtf3@@GCC_4.6.0
> __divtf3@@GCC_4.6.0
> __eqtf2@@GCC_4.6.0
> __floatditf@@GCC_4.6.0
> __floatsitf@@GCC_4.6.0
> __floatunditf@@GCC_4.6.0
> __getf2@@GCC_4.6.0
> __gttf2@@GCC_4.6.0
> __letf2@@GCC_4.6.0
> __lttf2@@GCC_4.6.0
> __multf3@@GCC_4.6.0
> __netf2@@GCC_4.6.0
> __subtf3@@GCC_4.6.0
> __unordtf2@@GCC_4.6.0
>
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
>
> It looks like we might be able to grab a few more from NetBSD:
> eqtf2.c and unordtf2.c
>
> --
> steve
Thank you.
Diane
--
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >> So I must dig deeper. Perhaps with rpaths interacting with the system > >> paths? > > > > You got it. ;) > > Except python doesn't have an rpath which is why this keeps coming > > up over and over again. > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > without depending on gcc. Then python should use gcc libgcc_s when > it exists and fall back to base system libgcc_s when it doesn't. Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed a specific port will require a fortran built binary module later. > > Maybe we should compile *all* ports with gcc rpaths without depending > on gcc, just like we already compile everything with -fstack-protector > in LDFLAGS. > > There's also the fact that gfortran behaves differently from the C > compilers (both clang and gcc) when it comes to libgcc_s. Gfortran > always links with libgcc_s. The C compilers link with libgcc.a first > and then with libgcc_s only as needed. This eliminates almost all What is really happening is gfortran links with libgfortran (surprise surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > links with libgcc_s. The only ones left are for exception handling > and stack unwinding and gcc libgcc_s and base system libgcc_s are > version compatible for that so it doesn't matter which one gets picked > up. The attached patch for lang/gcc8 makes gfortran behave just like > the C compilers. Something like this was tried already. I'll have to dig into my old notes. > > We cannot rename the base system libgcc_s to libclang_s because then a > process could load both gcc libgcc_s and base system libclang_s and I > think that could break exception handling and stack unwinding in weird > ways. Yes yes and yes. It would be a right PITA. Perhaps it could be done with some weak symbols but personally I think that's another hack. I'll go look for whatever symbols we are missing and see if we can fix our libgcc_s ... Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 10:42:03PM +0700, Eugene Grosbein wrote: > 17.02.2019 22:15, Diane Bruce wrote: > > > Basically all we need is a pre-loader script for interpreters ... > > We already have libmap.conf(5). It should be possible to work around the > problem > creating /usr/local/etc/libmap.d/python.conf with contents: > > [python2.7] > libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 > > [python3.4] > libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 > Sure but I'm guessing not all python ports *need* gfortran hence we shouldn't force all python coded ports to use the gfortran libgcc_s.so Moreover, the libmap would have to be updated everytime gfortran got updated which is true for the PRELOAD script but at least it would be with the port, not system wide. That's my two Canadian cents. (We don't even have pennies anymore up here ;) ) - Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote: > 17.02.2019 8:02, Russell L. Carter wrote: > > > Greetings, > > > > Restarting the FreeCAD 0.17 discussion on a different tangent. > > ... > > /usr/local/lib/gcc8/libgfortran.so.5 not found > > > > This is probably fatal to practical use of FreeCAD on FreeBSD. I was > > able to open most of my previous models, created on debian-testing, > > but some were fail. > > > > 2 threads, no happy ending: > > > > https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html > > https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html > > > > Question to experienced porters, how is this best practice solved? I've just updated my wiki entry. I think the old entry was way too long so the TLDR; solution I suggest comes first https://wiki.freebsd.org/libgcc%20problem#preview The problem is simple. Python code is not linked with libgcc_s so the system 'fake' libgcc_s is preferred over the one that Fortran prefers since python doesn't 'know' about gfortran at all no RPATH is ever seen in time. Hence if a python binary module is loaded that does use libgcc_s.so it's the system libgcc_s not the one that Fortran "needs". > > I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got > this: > > # ldd /usr/local/lib/gcc8/libgfortran.so.5 > /usr/local/lib/gcc8/libgfortran.so.5: > libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) > libz.so.6 => /lib/libz.so.6 (0x8016ad000) > libm.so.5 => /lib/libm.so.5 (0x8018c5000) > libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) > libc.so.7 => /lib/libc.so.7 (0x800823000) > > So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 > but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. > > I assume something is broken in your installation. Try removing gcc8 and > reinstalling > it using package. No, it's as I outlined above. I have a possible longer term transparent workaround I've mentioned to @emaste but it will take some trivial port changes. Basically all we need is a pre-loader script for interpreters that run into this such as python. (I suspect there have to be other interpreters that run into this.) Perhaps something like python2_gfortran or the like, all it has to do is PRELOAD or modify the library path so we get the 'right' libgcc_s.so. - Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > On 2/16/19 6:21 PM, Eugene Grosbein wrote: > > 17.02.2019 8:02, Russell L. Carter wrote: > > > >> Greetings, ... > root@feyerabend> > > So I must dig deeper. Perhaps with rpaths interacting with the system > paths? > > Russell You got it. ;) Except python doesn't have an rpath which is why this keeps coming up over and over again. - Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote:
> 17.02.2019 13:19, Steve Kargl wrote:
>
> > For whatever reason, there are situations where the rpath
> > isn't set in the library. Read the rtld manpage. You're
> > hitting #5 in the list.
>
> Our package building system sets rpath for dependants of gcc8,
> so Fortran libraries (and others) do have rpath for its runtime.
>
> Setting rpath for resulting binary should solve the problem.
No no no no no. Not for an interpreter. The interpreter doesn't 'know'
you are about to load a binary module that needs libgcc_s and until
it loads something that uses gfortran it doesn't matter
which libgcc_s so it picks the 'wrong' one.
As my wiki page article says:
We can rename our libgcc (Yes other complications but...)
We can fix our system libgcc to have the missing functions/data that
current libgcc has then bump our version
We can use a specific port which PRELOADs the gfortran libgcc_s.so
e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
it would work)
Individual python ports could be modified to do the PRELOAD with
a tiny sh script e.g. opencad could envoke a small sh script
that then starts the python interpreter. This would mean exposing the
PATH from Mk/USES/fortan.mk
e.g. we currently do this:
FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
exposed
blah. I finally just looked at openscad it's a binary not a python script
As Steve sez it's missing the -Wl,-rpath stuff then
- Diane
--
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 09:56:55PM -0800, Steve Kargl wrote: > On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote: > > 17.02.2019 12:11, Steve Kargl wrot: > > > > > > > > There is a problem with the order of libgcc_s.so.1 > > > in the cache created by ldconfig. rtld will use ... > 4) bump the major library version number for /lib/libgcc.so.1 >to 2; > 5) fix rtld to not fail on the first found library in the cache. >Iterated over all entries and only fail if the library isn't found; Not so easy. I looked at it but it would not be easy. > 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach >llvm/clang/rtld to not misappropriate a well-known GCC library >name. For the record I have been arguing for this for a few years as well. Read my wiki page on it. - Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Strange interaction between py-pyglet and py-numpy
On Mon, Nov 26, 2018 at 11:59:36PM +, Montgomery-Smith, Stephen wrote: > Using python2.7, if I run this code: > > import numpy as np > from pyglet.gl import * > > everything works fine. But if I put the same code in the other order: > > from pyglet.gl import * > import numpy as np > > I get: > > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line > 142, in > from . import add_newdocs > File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py", > line 13, in > from numpy.lib import add_newdoc > File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", > line 8, in > from .type_check import * > File "/usr/local/lib/python2.7/site-packages/numpy/lib/type_check.py", > line 11, in > import numpy.core.numeric as _nx > File "/usr/local/lib/python2.7/site-packages/numpy/core/__init__.py", > line 26, in > raise ImportError(msg) > ImportError: > Importing the multiarray numpy extension module failed. Most > likely you are trying to import a failed build of numpy. > If you're working with a numpy git repo, try `git clean -xdf` (removes all > files not under version control). Otherwise reinstall numpy. > > Original error was: /lib/libgcc_s.so.1: version GCC_4.8.0 required by > /usr/local/lib/gcc7/libgfortran.so.4 not found > > > Any ideas? I want my pony still. https://wiki.freebsd.org/libgcc%20problem > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Do you support creation of "chemistry" and "physics" virtual categories?
On Mon, Jul 30, 2018 at 01:07:07AM -0700, Yuri wrote: ... > > Do you support creation of "chemistry" and "physics" virtual categories? Of course. Have fun! > > > Thanks, > > Yuri > Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Runtime loader issue
On Thu, May 10, 2018 at 08:15:22AM -0700, Steve Kargl wrote: > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > > > s...@troutmask.apl.washington.edu> wrote: > > > ... > > > > Yep. > > See https://wiki.freebsd.org/libgcc%20problem > > > > Interesting page. I was aware that in the past you tried working > out a solution to the problem. I did not realize you docoumented > the issue. A few corrections to your wiki page. > > 1) The correct spelling of the name of the language is Fortran (with a >capital F). It has been the official standard spelling since Fortran >90. Fixed > > 2) You have "... to always support quad math (*8) and ...". Quad >precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard). I think I got it right this time... > > 3) "subsitute" is normally spelled with an extra 't'. :-) OOOps ;) fixed > > Very ;) > > Just started reading the source code. Don't scare the unwary. :-) ;) > > -- > Steve Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Runtime loader issue
On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > In review PR 228007, it came to my attention some individuals are > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > issue". See Indeed. I've tried to make it clear it is a name conflict with libgcc in my own bug reports on the subject. > > > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > > > The problem can be summarized by the following ... > > gfortran7 is installed from ports/lang/gcc7. This is not > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > > > Specifically, there is a shared library name clash. > > > > % ldconfig -r | grep gcc_ > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > >716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 Yep. See https://wiki.freebsd.org/libgcc%20problem > > > > So, the runtime loader finds 6 instead of 716, tries to link, > > fails, and issues an error message. There are a number ways to > > fix this issue. > > > > 1) By far, the best solution would be to stop hijacking the libgcc > >name in libraries installed on FreeBSD that are not related to > >actual GCC software. Agreed, however this has the side effect of meaning conflicts with libraries between clang and gcc libs. Notably gfortran and flang use different conventions for I/O :( See http://people.FreeeBSD.org/~db/fortran_libs.txt > > > >Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > >aware that clang does not work on all archs and the ancient gcc > >lives on. > > I've argued for this as well and frankly I still think it is the best solution all around. > > 2) Given the expected push back againt solution 1), this solution > >proposes bumping the library version for /lib/libgcc_s.so.1 from > >1 to some larger value, say, 10. It is unlikely that GCC will > >bump its shared library number anytime soon. GCC bumped it from > >0 to 1 some 16 years ago. > > > >https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > > >This solution, however, papers over the general problem with > >name clashes. Yep. I know work is slowly being done to modernise our libgcc already but the toolchain folks are busy... > > > > 3) This solution is to actually fix the runtime loader. If an error > >occurs with loading a shared library, then iterate over the entries > >in the hints file to check to see if another hint would satisfy > >the linking. Here, instead of issuing the above error, the loader > >would find entry 716, and load the correct libgcc_s.so.1. This breaks if the bad libgcc is already linked. We'd have to rip out the original bindings at run time, then re-bind to a new libgcc. I looked at the rtld code months ago. Nasty and silly. > > > >Admittedly, I haven't looked to see how difficult this solution > >would be. Very ;) > > > > 4) Bump the shared library number of the individual ports. As a proof > >of concept, I've done this with ports/lang/gcc6. > > ... > > > > Finally, can people stop referring to the above error as > > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. Yes, please. I tracked it down to libgcc months ago, made my findings generally available and yet people are still calling it a libgfortran problem. > > > > Our libgcc also lacks some functionality compared to the original one: > https://reviews.freebsd.org/D11482 Yes. Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: new icestorm/arachne/yosys fpga toolchain port for cad/
On Wed, Jan 10, 2018 at 10:47:57AM -0500, Ash Gokhale wrote: > I've ported Cliford Wolf's/ Cotton Seed's amazing > icestorm/yosys/arachne-pnr open source toolchain for the lattice fpga > bitstream generation, verilog translation, place and route engine and > supporting synthesis tools. > > It works for me (tm) to the point of actually programming hadware. I would > appreciate feedback or inclusion into the ports tree. > https://github.com/agokhale/freebsd-port-arachne-pnr > https://github.com/agokhale/freebsd-port-yosys > https://github.com/agokhale/freebsd-port-icestorm I'll take this on and give Ash a hand with these ports after I catch up with things. We need more porters. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Linrad
On Sun, Nov 19, 2017 at 02:27:03AM +0100, Leif Asbrink wrote: > Hello, > > As the author of Linrad I would appreciate feedback from > anyone who can suggest improvements. Presumably most - if not > all - changes that have been done for FreeBSD could be > implemented in the Linrad package. Hi Leif, I've worked with you before on improving linrad in the past and I'd be happy to send you what diffs had to be made to linrad to compile on FreeBSD. I suspect since we've been moving to team approach for hamradio ports (hamradio@) sending these diffs upstream got overlooked. I'll send you some updates via your email. > Regards > > Leif > > Begin forwarded message: 73 Diane VA3DB -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Confirm: About freebsd Registration
On Wed, Oct 18, 2017 at 05:06:14PM -0400, scratch65...@att.net wrote: > I've forwarded this to the FreeBSD Foundation at > i...@freebsdfoundation.org for their action. http://www.techrepublic.com/blog/it-security/the-chinese-domain-scam/ > > I would guess that Runbang Holdings should not be granted the > freebsd.*.cn domain names, since they probably have little or no > connection to the FreeBSD Foundation and its work. I might be > wrong about that, of course, but the Foundation staff are the > ones to sort it out in any case. > > > [Default] On Thu, 19 Oct 2017 00:21:04 +0800, "Tony Liu" > wrote: > > >Dear Manager, > >(Please forward this to your CEO, because this is urgent. Thanks) > >This is Tony Liu, Senior Manager of a Network Service Company which is the > >domain name registration center in Shanghai, China. On October 16th, 2017, > >we received an application from Runbang Holdings Ltd requested ??freebsd?? > >as their internet keyword and China (CN) domain names( freebsd.cn/ > >freebsd.com.cn/ freebsd.net.cn/ freebsd.org.cn). But after checking it, we > >find this name conflict with your company name or trademark. In order to > >deal with this matter better, it??s necessary to send email to you and > >confirm whether this company is your distributor or business partner in > >China? > >Best Regards > >Tony Liu > >Senior Manager > > > > > >China Registrar Headquarters > >www.chinaregistrar.org > >8008, Tianan Building, No. 1399 Jinqiao Road, > >Shanghai 200120, China > >0086-21-6191-8696(Tel) > >0086-1377-4400-340( Mobi) > >0086-21-6191-8697(Fax) > >___ > >freebsd-ports@freebsd.org mailing list > >https://lists.freebsd.org/mailman/listinfo/freebsd-ports > >To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Using blaslapack
On Mon, Oct 16, 2017 at 07:19:49AM -0700, Steve Kargl wrote: > On Mon, Oct 16, 2017 at 02:18:01AM -0700, Yuri wrote: > > On 10/15/17 23:20, Gleb Popov wrote: > > > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there > > > is ... > > Fortran implementation based on gcc is faulty due to libgcc_s.so being > > present in 2 versions, in base and in gcc port, making any code > > containing both C++ and fortran impossible to run. Your application > > probably can't work on FreeBSD using gcc fortran for this reason. > > > > Huh? I use Netlib blas/lapack compiled with gfortran on FreeBSD > with no problem. If you're having problems with gfortran finding > the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6 > or gcc7) to yout Fortran options. Steve is correct IFF it's a simple program, but wrong if it is a module. What has been biting us are interpreters (e.g. python) not linked against gfortran with the right -rpath but linked against our native libgcc. When a binary module is loaded bad things happen if module was built with fortran. If it is known beforehand that such modules will be loaded then the work around is to LD_PRELOAD the gfortran libgcc or use LD_LIBRARY_PATH to force the gfortran libgcc to be loaded first instead of ours. The problem is figuring out which programs load such binary modules in the first place. There are a myriad of proper fixes possible including bringing our libgcc up to spec. Incidentally, flang compiled modules are one possible fix but is limited to amd64 at the moment. Do not mix gfortran and flang compiled modules in one program if they use I/O. Of course they use their own I/O routines. *sigh* > Steve Diane (looking for that pony still) -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sage
Hi, I have been trying to compile sage for months now. I am using freebsd 11.1 on amd 64 and it never succeeds. I am beginning to wounder why it is still in ports. Can anyone help? Bruce ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sword compile errors
Hi,
updating sword with portmaster caused the following errors:
../src/keys/treekeyidx.cpp:64:12: error: ordered comparison between
pointer and
zero ('sword::FileDesc *' and 'int')
if (datfd <= 0) {
~ ^ ~
../src/keys/treekeyidx.cpp:334:12: error: ordered comparison between
pointer and
zero ('sword::FileDesc *' and 'int')
if (datfd > 0) {
~ ^ ~
../src/keys/treekeyidx.cpp:388:12: error: ordered comparison between
pointer and
zero ('sword::FileDesc *' and 'int')
if (idxfd > 0) {
~ ^ ~
../src/keys/treekeyidx.cpp:425:12: error: ordered comparison between
pointer and
zero ('sword::FileDesc *' and 'int')
if (idxfd > 0) {
~ ^ ~
../src/keys/treekeyidx.cpp:491:12: error: ordered comparison between
pointer and
zero ('sword::FileDesc *' and 'int')
if (idxfd > 0) {
~ ^ ~
5 errors generated.
thanks for any help.
Bruce
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: manpath change for ports ?
On Tue, Mar 07, 2017 at 06:29:19AM +, Jan Beich wrote: > Baptiste Daroussin writes: > > > Hi all, > > > > I would like to propose a change in the localbase hier for ports > > > > I think we should add /usr/local/share/man in the manpath along with at > > first > > and maybe instead of in long term. > > > > The reason is: > > - /usr/local/share/man seems more consistent to me with base which have: > > /usr/share/man > > - It will remove lots of patches from the ports tree where were we need to > > patch > > upstream build system to install in a non usual path. > > Can you also move /usr/local/info to /usr/local/share/info? texinfo is > gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still > try to encroach on GNU defaults. A big yes from me for both of these proposals. -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADSUP] Default Perl changed to 5.24.
I was wondering why the port which is now default is version 5.24-RC4 instead of 5.24.0? Perl 5.24.0 was released on 2016-05-09 (May 9th). Even if RC4 and 5.24.0 have no code differences besides the versioning, I fail to understand why you would not update the perl 5.24 port to use the final release before making it the default perl. On 11/03/16 10:00, Mathieu Arnold wrote: Instructions on how to switch are in UPDATING. If you do not want to switch, you do not have to do anything. EVERYTHING IS FINE. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Sun, Aug 21, 2016 at 03:37:58PM +0930, Shane Ambler wrote:
> On 20/08/2016 21:30, Diane Bruce wrote:
> > On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> >> On 19/08/2016 10:13, Steven G. Kargl wrote:
> > ...
> >> You should find that all newer copies of libgcc_s contain compatibility
> >> support for binaries that were linked to earlier versions.
> >>
> >
...
>
> Actually the problem is going the other way. A port gets compiled and
> linked against the newer libs but at run time it finds the base system
*sigh* No.
> lib first and loads that which doesn't support the binary that is being
> run. If the gcc6 libgcc_s was always installed and found first then we
> wouldn't have this problem.
That's exactly what the -Wl,rpath=/usr/local/lib/lib is supposed to
do.
Look at
/usr/ports/Mk/Uses/gfortran.mk
FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin
Any use of GCC to compile a port *SHOULD* have the same -rpath
otherwise it gets linked with our base libgcc_s which is *harmless*
99% of the time. The cases where it isn't are outlined here:
https://people.freebsd.org/~db/libgcc.txt
Your problem is cmake here.
>From blender Makefile
USES= cmake:outsource compiler:features desktop-file-utils \
jpeg python:3.5 shebangfix
Look at this PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=20812
What happens is cmake strips the necessary rpath when it installs
the final binary.
This hack:
add to CMAKE_ARGS
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"
Will tell cmake to not strip the necessary gcc rpath information.
BTW I'd be interested if this fixed blender for you.
However, if this is the way to fix these problems, then it should
be documented or fixed cmake. However a naive non ports infrastructure build
using gcc/gfortran or cmake will still run into these problems.
>
> I first found this issue trying to import numpy into blender. As blender
> had started and was using the base libgcc_s, when I tried to import
> numpy that needed the newer libgcc_s for it's fortran code it failed. I
> discovered that setting LD_LIBRARY_PATH in the environment when starting
> blender got it to load the newer libgcc_s which then worked when
Yes. Or a LD_PRELOAD (man rtld)
The stanza added in the ports infrastructure is a kludge added to
work around our out of date base libgcc_s.so
> importing numpy, so I've been happy doing that for a couple of years.
This is exactly the sort of bugs that have been reported in the ports
system for years.
>
> I have seen the same thing were a python module has brought in the base
> libgcc_s before numpy which needed the newer one. The dynamic loading of
> python modules seems to be the only time I have seen this. Either
> changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
> the first time has solved the issue.
Yep. You are SOL if your base program does not have a -rpath linking
/usr/local/lib libgcc_s first. (BTW A LD_PRELOAD will fix your
problem here as it forces the port libgcc_s to be already loaded
before rtld has to search for it. It will satisfy the linking requirements
without messing around with LD_LIBRARY_PATH) Any program that does
a dlopen then requiring a ports libgcc_s will also fail, not just
python.
>
> So one solution could be to copy the newer libgcc_s into /lib but the
> newer library won't get added to base as it contains GPLv3 code. Maybe
> remove /lib/libgcc_s.so to force the search for a newer version.
If you read my original post. (Did you read it?) That's exactly what
I suggest. We should rename it to libcc_s.so
...
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
>
Diane Bruce (Getting tired and testy at explaining this bug 1000 times)
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote: > On 19/08/2016 10:13, Steven G. Kargl wrote: ... > You should find that all newer copies of libgcc_s contain compatibility > support for binaries that were linked to earlier versions. > Indeed. And the version masquerading as a GNU libgcc_s in base does the same thing. Two problems: our base libgcc_s only covers version up to GCC_4.2.0 and there is a name conflict on the library name with libgcc_s from the gnu compiler. Hence if a program links against base libgcc_s first then requires libgfortran which itself requires support for above GCC_4.2.0, the program fails. OR Whenever a program requires support that is missing on the platform it is running on from our libgcc_s, it will fail. There are numerous PR's on this which all have the common problem of linking with a libgcc_s that does not support > GCC_4.2.0 Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote: > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > > > For example, on one of my systems, I now have these: > > > > entry: 5 > d_tag: DT_RPATH > d_val: /usr/local/lib/gcc6 > > I don't know how ELF or the ldd work, but shouldn't the DT_RPATH > tell ldd to look for all of the above libraries in /usr/local/lib/gcc6 > first. If a library isn't present, it would then look in ldconfig's > hints file or fallback to /lib and /usr/lib/. But, I suppose we > still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1 > from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps > libcxxrt.so.1?). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 Anything compiled with cmake infrastructure loses the DT_RPATH. > -- > Steve > ___ > freebsd-toolch...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote:
> On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
> > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> > >
> > > Freebsd-ports could also use a wrapper:
> > > % cat ~/bin/gfc7
> > > #! /bin/sh
> > > DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
> > > export DIR
> > >
> > > LD_LIBRARY_PATH=$DIR/work/7/lib
> > > export LD_LIBRARY_PATH
> > >
> > > LD_RUN_PATH=$DIR/work/7/lib
> > > export LD_RUN_PATH
> > >
> > > $DIR/work/7/bin/gfortran -fno-backtrace $@
> >
> > Yes. I have also suggested we use a wrapper to the ports guys.
> >
>
> I thought about this a bit, and cleaner solution might be
> to add the program suffix to libgcc_s.so.1. For example,
>
> % cat foo.f90
> program foo
>print *, 'Hello'
> end program
> % gfortran6 -o z foo.f90 && ./z
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> /usr/local/lib/gcc6/libgfortran.so.3 not found
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>
> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could
> be convinced to build, install, and use libgcc_s6.so.1, then the
> problem is solved without a wrapper.
I like this solution.
>
> --
> Steve
>
Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
>
> > The reason ports gcc now has this requirment on 4.6 or better is
> > fortran standard says we have to support quad floating point math.
> > e.g. /usr/local/lib/gccXX/libquadmath.so
>
> Diane,
>
> Can you please stop with the dis-information? No Fortran standard
I'm happy to be corrected. In this case it's immaterial if it is a
Fortran standard or not. It is what our present gcc from ports has given us.
...
>
> FreeBSD-ports could avoid libquadmath issues by building gcc
> without it. See --without-libquadmath or --without-quadmath (I
> don't remember the config option because it would be questionable
> to neuter one of gfortran's strength).
Correct. This blog entry I read some months ago outlines this
exact problem we are having and suggests the identical solution.
http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html
quadmath does have an impact on performance.
>
> Freebsd-ports could also use a wrapper:
> % cat ~/bin/gfc7
> #! /bin/sh
> DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
> export DIR
>
> LD_LIBRARY_PATH=$DIR/work/7/lib
> export LD_LIBRARY_PATH
>
> LD_RUN_PATH=$DIR/work/7/lib
> export LD_RUN_PATH
>
> $DIR/work/7/bin/gfortran -fno-backtrace $@
Yes. I have also suggested we use a wrapper to the ports guys.
- Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Problems with our libgcc_s.so in base
Problems with libgcc_s.so in base
If you compile with gcc and use our base libgcc it should DTRT
*provided* our libgcc has defined functions that are up to date
with current libgcc
We compile with gcc, it needs foo() from libgcc to run
doesn't matter what foo() is (A typical function would be T __multi3)
So our libgcc provides a foo() and gcc is happy
This means in theory, we can interchangeably use gcc and clang in ports.
This also means it made the initial port work from from gcc in base
to clang in base a lot easier.
The problems come when we try to use architectures not fully
supported by our libgcc_s.so or when we use fortran.
However, our libgcc lies in two ways
1) our libgcc is mostly not GPL code anymore, though there are
bits and pieces of GPL depending on what we don't have.
This includes (or did) some of the work ian@ was trying to do with arm,
various bits that arm libgcc provides from gcc were missing.
2) It claims to be only up to date with GCC 4.2.4
Everything is peachy keen until someone references a symbol which is in
anything gcc compiled using a newer > GCC 4.2.4 compiler.
The moment you load libgfortran, it has a requirement for GCC_4.6 or better,
and if our libgcc is already loaded things fail.
The reason ports gcc now has this requirment on 4.6 or better is
fortran standard says we have to support quad floating point math.
e.g. /usr/local/lib/gccXX/libquadmath.so
We *could* lie in our libgcc_s and claim to be 4.6 which would simply
mean libgfortran would not complain and simply load the missing libquadmath.
If we updated the claimed GCC version in our libgcc_s.so to claim
GCC_4.6, we really also should provide a libquadmath subsitute.
The other approach is to rename our libgcc_s.so to libclang_s.so or
some such and link base with it instead of libgcc_s.so
I frankly think this in the long term is the cleaner solution.
In the ports world, we have papered over this problem by adding
-Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link
against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so
However, any program that uses python to build has to be patched
to force this stanza and our ports cmake presently does not force
this stanza to be added.
Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Poudriere testport failure but manual jailed build success
On Tue, Mar 03, 2015 at 05:24:15PM -0800, Chris H wrote: > On Tue, 3 Mar 2015 23:37:30 +0100 Marin Bernard wrote > > > Hi, > > > > I've been banging my head for several days on what follows and I've come to > > the point where I have to get some help. Here's the point. > > > > I'm trying to port LizardFS (a distributed file system for Unix/Linux) on > > FreeBSD and I built a port candidate I would like to submit. But first I > > needed to be sure everything was OK, so I ran some tests. As of now: > > - The port builds fine on FreeBSD 10.1-RELEASE amd64 host. > > - portlint does not report any issue (on the same host as above) > > - port test (from porttools) happily validates the port (on the same host > > as above) - BUT poudriere fails to build the port. > > > > I'm using poudriere 3.1.1 on FreeBSD 11-Current, and failure occurs within a > > FreeBSD 10.1-RELEASE amd64 jail. > > > > What basically happens is that the build process runs fine until it reaches > > man page generation. There, a2x throws an error because xlstproc returns > > with > > return code 5 (= "error in the stylesheet"), whereas it shouldn't. What > > kills > > me here is that if I enter the jail after the failure and try to build the > > port manually, everything builds fine! You'll find poudriere log at the end > > of this message. > > > Any reason you couldn't simply lower the risk of failure based > on tools you have no control over; by simply creating a valid > man page to begin with? In other words; if the man is already > properly formatted groff/troff/mandoc (take your pick). You > wouldn't ever need to worry again. :) > > Just a thought, and hope it helps. I just ran into this one. Here is the fix. (months late) You need a LIBDEPENDS on libxslt.so:textproc/libxslt This probably should be documented in the porters handbook. > > --Chris > .. > > Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
cmake and rpath problems
This is a heads up about a bug some of you have run into
and I've reported here.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120
To summarize: any binary or .so object linked using cmake will indeed
have a DT_RPATH entry, but it gets stripped out on install.
I worked around this with comms/sdr-wspr
by stripping the Fortran Flags to determine the RPATH and setting it
manually in CMakeLists.txt
+# temporary ugly hack
+string(REGEX MATCH "-rpath=.*" CMAKE_RPATH_ARG ${CMAKE_Fortran_FLAGS} )
+string(SUBSTRING ${CMAKE_RPATH_ARG} 7 -1 CMAKE_RPATH)
+set(CMAKE_INSTALL_RPATH ${CMAKE_RPATH} )
I know other ports have run into this.
Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Porting questions for teslams port
Hi porters-- I'm working on a port of teslams, which is a Node.js implementation of the client side of the API for querying and (in a limited way!) controlling a Tesla Model S. I know next to nothing about Node.js, but the example programs are useful for some stuff I'm working on. https://github.com/hjespers/teslams Two questions: 1. What port category should this go under? I'm thinking "misc" for lack of anything else but that seems unsatisfying...AFAIK there isn't really an "Internet of Things" category. Is there any existing precedent for something like this? 2. Licensing...teslams itself appears to be BSD, but when it gets installed, npm resolves dependencies for other Node.js packages that teslams depends on, which have a variety of other (open source AFAIK) licenses. A package of teslams would contain that code plus all of its dependencies. So would the correct LICENSE basically be the union of all the licenses of teslams and all its dependencies, with LICENSE_COMB=multi? Thanks for any clues... Bruce. signature.asc Description: OpenPGP digital signature
Re: USES=fortran can't mix with the libraries requiring /lib/libgcc_s.so.1 from the base
On Wed, Dec 23, 2015 at 07:38:47AM -0800, Yuri wrote: > On 12/23/2015 06:34, Diane Bruce wrote: > > No. The core problem is due to our version of libgcc not having quadmath > > support. > > > > If the separate port would have been created for gcc with only fortran > in it, and it would have been compiled with clang, this would have > solved this problem. It is not that simple. Please read the various threads to understand why. > > Yuri > Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: USES=fortran can't mix with the libraries requiring /lib/libgcc_s.so.1 from the base
On Wed, Dec 23, 2015 at 04:35:29AM -0800, Yuri wrote: > I found that ports with USES=fortran can't mix with anything in C++ > compiled with the base clang++, because USES=fortran forces the current > gcc that links with its /usr/local/lib/libgcc_s.so.1 It's a well known bug. The long term fix would be bringing in quad math support which is what (gcc) fortran libs are looking for and we do not supply currently. Start here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196491 I tried very hard to make gnuradio compiled only with clang for the 'C' parts but we were forced to use gcc. > Getting this particular error from the python process, because one > python module has USES=fortran, and another has C++ in it: > ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by > /usr/local/lib/gcc48/libgfortran.so.3 not found Yep. > > What is the general solution for this problem? Is there a non-gcc > version of fortran? No there is currently no clang version of Fortran. 'flang' was a SOC project to bring in clang support for fortran but it is moribund. The clang guys are the ones you should bug. In any case, the Fortran spec now requires quad math support so that would have to be provided as well. > > One thing is when gcc is required because clang can't compile something, > and another things is when fortran language requires it. The latter is > here to stay. > > Can there be the separate fortran from gcc that is build with clang? Or > can we switch /usr/ports/lang/gccNN to be always built with the base > clang? I know this is certainly possible. No. The core problem is due to our version of libgcc not having quadmath support. > > Yuri Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gfortran (was: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?)
It looks good to me.
On Mon, Nov 23, 2015 at 01:16:38AM +0100, Gerald Pfeifer wrote:
> On Tue, 22 Jul 2014, Diane Bruce wrote:
> > Any chance we could have a script "gfortran" which by default
> > ran the default gcc from bsd.default-versions.mk and make.conf ?
>
> I know this took a little, ahem, but what do you think about
> the patch below?
>
> With this change, lang/gcc, our canonical GCC port, now features
> gfortran as well as gcc and g++ without the appended major version
> number.
>
> (Not committed yet; feedback very welcome.)
>
> Gerald
>
> Index: Makefile
> ===
> --- Makefile (revision 402204)
> +++ Makefile (working copy)
> @@ -3,6 +3,7 @@
>
> PORTNAME=gcc
> PORTVERSION= 4.8.5
> +PORTREVISION=1
> CATEGORIES= lang java
> MASTER_SITES=GCC/releases/gcc-${DISTVERSION}
>
> @@ -158,5 +159,10 @@
> fi
> .endfor
> cd ${WRKDIR} ; ${SED} -i -e "/PLIST.lib/ r PLIST.lib" ${TMPPLIST}
> + # This is the canonical GCC port, so add key commands without
> + # version numbers as part of their names.
> + for c in gfortran g++ gcc; do \
> + ${LN} -s ${PREFIX}/bin/$$c${SUFFIX} ${STAGEDIR}${PREFIX}/bin/$$c; \
> + done
>
> .include
> Index: pkg-plist
> ===
> --- pkg-plist (revision 402204)
> +++ pkg-plist (working copy)
> @@ -8,12 +8,15 @@
> bin/%%GNU_HOST%%-gfortran%%SUFFIX%%
> bin/c++%%SUFFIX%%
> bin/cpp%%SUFFIX%%
> +bin/g++
> bin/g++%%SUFFIX%%
> +bin/gcc
> bin/gcc%%SUFFIX%%
> bin/gcc-ar%%SUFFIX%%
> bin/gcc-nm%%SUFFIX%%
> bin/gcc-ranlib%%SUFFIX%%
> bin/gcov%%SUFFIX%%
> +bin/gfortran
> bin/gfortran%%SUFFIX%%
> @comment info/gcc%%SUFFIX%%/dir
> man/man1/cpp%%SUFFIX%%.1.gz
>
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: No pkg-1.6 on FreeBSD 10.2?
On 9/29/15 4:23 PM, markham breitbach wrote: How do I work around this? I now have ports telling me "pkg(8) must be version 1.6.0 or greater" but I can't upgrade pkg for another 3 days or more? I got pkg 1.6.1 thought ports on 10.2, since I have packages like doxygen that I needed to customize (and hence build from ports) to avoid pulling in X etc. I presume security issues in packages will be fixed sooner and won't wait for the quarterly update? -- Bruce ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: all those c++ ABI variations in ports
The problem is now known. It's a lack of quad math support in our libcompiler_rt. gfortran requires quad math support which our clang compiler does not support yet, since Fortran itself needs quad math by the standard. Normally this is never a problem if rpath is used and the local/lib libgcc is used, but it does become a problem if a core program is used which loads a module compiled with gfortran. The module loaded expects quad math and will fail against our version of libgcc. Actually it will fail in rtld.c code complaining that our version of libgcc is not compatible with the version the gfortran code was compiled against. On Mon, Apr 27, 2015 at 12:56:36PM -0700, Don Lewis wrote: > On 27 Apr, Diane Bruce wrote: > > A problem I have not seen noted here are ports that load run time modules. > > > > gnuradio is a case in point. The dependancies are all built (by default) > > with stock clang++ & system libs but some of the runtime code it loads > > for operation has modules compiled with gfortran. > > That should be a valid combination. Fortran is part of ports gcc, but > code compiled with it doesn't link to libstdc++, so there should not be > a conflict with code compiled with clang++ and linked to libc++. I > haven't run into any issues with octave built with openblas, which is > the combo that you describe. > > % ldd /usr/local/bin/octave > /usr/local/bin/octave: > libX11.so.6 => /usr/local/lib/libX11.so.6 (0x800823000) > libutil.so.9 => /lib/libutil.so.9 (0x800b5c000) > libm.so.5 => /lib/libm.so.5 (0x800d6e000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x800f96000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801255000) > libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x801471000) > libthr.so.3 => /lib/libthr.so.3 (0x801687000) > libc.so.7 => /lib/libc.so.7 (0x8018ab000) > libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x801c57000) > librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x801e76000) > libXau.so.6 => /usr/local/lib/libXau.so.6 (0x80207f000) > libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 > (0x802281000) > libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x802482000) > > > % ldd /usr/local/lib/octave/3.8.2/liboctave.so > /usr/local/lib/octave/3.8.2/liboctave.so: > libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x802341000) > libumfpack.so.1 => /usr/local/lib/libumfpack.so.1 (0x8025aa000) > libsuitesparseconfig.so.1 => /usr/local/lib/libsuitesparseconfig.so.1 > (0x802858000) > libcholmod.so.1 => /usr/local/lib/libcholmod.so.1 (0x802a59000) > libamd.so.1 => /usr/local/lib/libamd.so.1 (0x802d43000) > libcamd.so.1 => /usr/local/lib/libcamd.so.1 (0x802f4a000) > libcolamd.so.1 => /usr/local/lib/libcolamd.so.1 (0x803152000) > libccolamd.so.1 => /usr/local/lib/libccolamd.so.1 (0x803359000) > libcxsparse.so.1 => /usr/local/lib/libcxsparse.so.1 (0x803564000) > libarpack.so.1 => /usr/local/lib/libarpack.so.1 (0x80378f000) > libqrupdate.so.1 => /usr/local/lib/libqrupdate.so.1 (0x803a27000) > libfftw3_threads.so.3 => /usr/local/lib/libfftw3_threads.so.3 > (0x803c3d000) > libfftw3.so.3 => /usr/local/lib/libfftw3.so.3 (0x803e43000) > libfftw3f_threads.so.3 => /usr/local/lib/libfftw3f_threads.so.3 > (0x8041a8000) > libfftw3f.so.3 => /usr/local/lib/libfftw3f.so.3 (0x8043ae000) > libopenblasp.so => /usr/local/lib/libopenblasp.so (0x80480) > libreadline.so.8 => /lib/libreadline.so.8 (0x806576000) > libncurses.so.8 => /lib/libncurses.so.8 (0x8067b9000) > libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x806a06000) > libgfortran.so.3 => /usr/local/lib/gcc48/libgfortran.so.3 (0x806c79000) > libquadmath.so.0 => /usr/local/lib/gcc48/libquadmath.so.0 (0x806f9) > libutil.so.9 => /lib/libutil.so.9 (0x8071cb000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x8073dd000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80769c000) > libm.so.5 => /lib/libm.so.5 (0x8078b8000) > libthr.so.3 => /lib/libthr.so.3 (0x807ae) > libc.so.7 => /lib/libc.so.7 (0x800821000) > libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x807d04000) > libssl.so.7 => /usr/lib/libssl.so.7 (0x807f1a000) > libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x808186000) > libhx509.so.11 => /usr/lib/libhx509.so.11 (0x80838c000) > libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8085d6000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x8087d8000) > libasn1.so.11 => /usr/lib/libasn1
Re: all those c++ ABI variations in ports
A problem I have not seen noted here are ports that load run time modules. gnuradio is a case in point. The dependancies are all built (by default) with stock clang++ & system libs but some of the runtime code it loads for operation has modules compiled with gfortran. -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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"
sysutils/open-vm-tools: fixing runProgramInGuest
Scott, I noticed today that vmrun's runProgramInGuest didn't seem to work on FreeBSD, and have a (hackish) fix. Background: I'm trying to automate some nasty operations I need to run across our test topology at work. I have dozens of multi-gigabyte FreeBSD VMs with ZFS, and these need to be shrunk to fit onto BD-R media for publication. Without ZFS BP-rewrite, recreating the pool on a new device is the only way to do this. VMware's "shrink disk" feature only really understands a subset of Windows and Linux filesystems. Issue: The PAM configuration installed with the port refers to non-existent PAM modules. If I try to use vmrun with a (known passwordless) account, I get the following log message: %%% Nov 27 16:49:11 ilnp-builder vmsvc[1127]: in openpam_load_module(): no pam_unix2.so found %%% Workaround: Remove the missing PAM modules from the vmtoolsd PAM configuration entirely, e.g. %%% sed -i.orig -e '/pam_unix2/d;/pam_unix_auth/d;/pam_unix_acct/d' /usr/local/etc/pam.d/vmtoolsd %%% I can confirm that this allows the following vmrun commands to work: copyFileFromHostToGuest, runProgramInGuest, runScriptInGuest. Other details: Whilst mostly documented, this functionality isn't great (and is fairly Windows centric). E.g. the runScriptInGuest command takes the actual content of a script to be executed, error messages are logged to stdout, and need to be parsed for guest command return codes. I'd be happy to share the scripts once I've got the ZFS pool rebuild automated. thanks, -- BMS (sent via webmail) ___ 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: py-imaging vs. py-pillow
On Fri, Oct 03, 2014 at 02:01:32PM +0200, Stefan Ehmann wrote: > On 03.10.2014 13:37, William Grzybowski wrote: > > Coexist how? They are essentially the same package. I don't see how > > thats possible. > > I meant that you should be able to install ports that depend on > py-imaging and ports that depend on py-imaging at the same time. > > > py-imaging is deprecated, they should be switched to py-pillow and thats it. > > If py-pillow is a compatible drop-in replacement of py-imaging then > that's probably the best solution. There is also the small matter of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193958 I don't know how many ports rely upon _imagingtk.so being installed other than the ones I am blocked on. I need py-pillow since my ports use python3. I just noticed there is also another conflict that needs a PR filed. pkg-static: py27-imaging-1.1.7_3 conflicts with py33-pillow-2.5.1 (installs files into the same place). Problematic file: /usr/local/bin/pilconvert.py *** [fake-pkg] Error code 70 - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Is LibreOffice dependency on Java 1.6 still valid?
On 09/07/14 14:26, Gökşin Akdeniz wrote: >>> As far as I can tell, LibreOffice on other platforms has supported >>> Java 1.7+ since the LibreOffice 3.6 release (or maybe earlier), and >>> OpenOffice supports Java 1.7+ also. Why does the FreeBSD port >>> require Java 1.6 for building when the Java option is set? >>> >> Probably no one tried it yet. > I did it. It did not build. > >> Changing a libreoffice build dependency is a big job to validate. >> My advice would be to open an account on http://www.redports.org, and >> submit a patch changing editors/libreoffice/Makefile to either change >> JAVA_VERSION to 1.7+, and see if it passes a redports build. >> > First attempt was defining JAVA version 1.7 via /etc/make.conf. > Libreoffice started to build and it stopped. Second attempt was > editing /usr/ports/editors/libreoffice/Makefile and build process was > stopped again. AFAK @bapt mentioned that problem when JAVA default > version swtiched to 1.7+. His message is available at mailing list > archives. Both attempts were limited to java version not compiler or > else. > I just changed the JAVA_VERSION=1.6 to JAVA_VERSION=1.7+, deleted openjdk1.6, did a make clean, make deinstall reinstall, and libreoffice built successfully on FreeBSD 10.0-RELEASE-p7 amd64. I was able to start up libreoffice, and in the preferences, the Java options finds the openjdk7 runtime and lets me select it as my Java runtime environment. Off hand, I'm not sure how to exercise the Java bits. I did try to open some IRS 1040 spreadsheets I have, and they had some errors in their macros, so it's possible that the errors are related to Java 1.7. I'll have to try reinstalling openjdk1.6 and rebuild against it and see if the errors go away. ___ 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"
Is LibreOffice dependency on Java 1.6 still valid?
As far as I can tell, LibreOffice on other platforms has supported Java 1.7+ since the LibreOffice 3.6 release (or maybe earlier), and OpenOffice supports Java 1.7+ also. Why does the FreeBSD port require Java 1.6 for building when the Java option is set? ___ 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: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?
On Mon, Jul 21, 2014 at 11:32:11PM +0200, Gerald Pfeifer wrote: > On Thu, 17 Jul 2014, Lev Serebryakov wrote: > > Maybe, we should encourage ports, which is needed gcc, to use only one > > version? If many ports needs 4.8, maybe, we should bump "any" version to > > 4.8 for gcc-less systems? And move all other versions to 4.8? > > I would love to do that, in fact, I hope that at one point we can > eventually get rid of USE_GCC=any. > > What I can do for now, and have been planning to do for a few weeks, > is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192025 aka > "Update default version of GCC (USE_GCC=yes, lang/gcc,...) to GCC 4.8". Any chance we could have a script "gfortran" which by default ran the default gcc from bsd.default-versions.mk and make.conf ? .. > > Gerald > ___ > 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" -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Drop Maintainership, need help
On Thu, Jun 12, 2014 at 10:23:34PM +0200, Dennis Herrmann wrote: > Ahoi, > libdsp would fit in nicely with hamradio@ team I think. I'll grab it. > > Thanks > > Regards, > Dennis 'dhn' Herrmann > ___ > 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" -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: math/sage error log message
At this time I get the same error at the same place. I have had sage on
this computer before freebsd-9.2 and haven't been able to build it
since. Every time I notice a change in the sage port I try again. I
have tried about 4 times in the last week. Before the last Makefile
change in the port it got a lot farther and the error was during the
building of the html documentation.
I have tried MAKE_JOBS_UNSAFE and it gets farther.
I am using a Shuttle xpc with amd 64 and freebsd-9.2
uname -a FreeBSD 192.168.1.4 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898:
Thu Sep 26 22:50:31 UTC 2013
r...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
Thanks for your help.
Montgomery-Smith, Stephen wrote:
On 05/13/2014 07:17 PM, Bruce wrote:
-Wl,-rpath=/usr/local/lib/gcc47 -g -fPIC -c linbox-sage.C -fPIC -DPIC
-o .libs/linbox-sage.o
{standard input}: Assembler messages:
{standard input}:669830: Warning: end of file not at end of a line;
newline inserted
{standard input}:670930: Error: unknown pseudo-op: `.lvl719'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
g++47: internal compiler error: Killed: 9 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
.
What a horrible error! Do you get the error in the same place every
time you try to compile sage?
It might be a hardware error, or maybe the compiler is running out of
memory. Did you try building it with MAKE_JOBS_UNSAFE set? How many
cores do you have on your processor?
___
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"
math/sage error log message
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../.. -I../.. -I. -I../../linbox -DDISABLE_COMMENTATOR -O2 -g
-DNDEBUG -U_LB_DEBUG -DDISABLE_COMMENTATOR
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include -pipe
-Wl,-rpath=/usr/ports/math/sage/work/sage-6.1.1/local/lib
-Wl,-rpath=/usr/local/lib/gcc47
-Wl,-rpath=/usr/ports/math/sage/work/sage-6.1.1/local/lib
-Wl,-rpath=/usr/local/lib/gcc47 -g -fPIC -c -o linbox-sage.lo linbox-sage.C
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I.
-I../../linbox -DDISABLE_COMMENTATOR -O2 -g -DNDEBUG -U_LB_DEBUG
-DDISABLE_COMMENTATOR
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include
-I/usr/ports/math/sage/work/sage-6.1.1/local/include -pipe
-Wl,-rpath=/usr/ports/math/sage/work/sage-6.1.1/local/lib
-Wl,-rpath=/usr/local/lib/gcc47
-Wl,-rpath=/usr/ports/math/sage/work/sage-6.1.1/local/lib
-Wl,-rpath=/usr/local/lib/gcc47 -g -fPIC -c linbox-sage.C -fPIC -DPIC
-o .libs/linbox-sage.o
{standard input}: Assembler messages:
{standard input}:669830: Warning: end of file not at end of a line;
newline inserted
{standard input}:670930: Error: unknown pseudo-op: `.lvl719'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
g++47: internal compiler error: Killed: 9 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[6]: *** [linbox-sage.lo] Error 1
make[6]: Leaving directory
`/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0/src/interfaces/sage'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
`/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0/src/interfaces'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0/src'
Error building LinBox.
real3m21.911s
user2m59.280s
sys 0m12.563s
Error installing package linbox-1.3.2.p0
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
/usr/ports/math/sage/work/sage-6.1.1/logs/pkgs/linbox-1.3.2.p0.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0
and type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd
'/usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0'
&& '/usr/ports/math/sage/work/sage-6.1.1/sage' --sh)
When you are done debugging, you can type "exit" to leave the subshell.
(END)
___
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"
math/sage compile error
Error on amd freebsd-9.2 Error building Sage. The following package(s) may have failed to build: package: linbox-1.3.2.p0 log file: /usr/ports/math/sage/work/sage-6.1.1/logs/pkgs/linbox-1.3.2.p0.log build directory: /usr/ports/math/sage/work/sage-6.1.1/local/var/tmp/sage/build/linbox-1.3.2.p0 The build directory may contain configuration files and other potentially helpful information. WARNING: if you now run 'make' again, the build directory will, by default, be deleted. Set the environment variable SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. gmake: *** [build] Error 1 *** [do-build] Error code 1 Stop in /usr/ports/math/sage. *** [stage] 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"
math/sage build error
Trying build sage I get the following error on amd and freebsd-9.2: [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"
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"
Maintainer reset of textproc/kdiff3
I no longer have time to work on FreeBSD: could someone reset the maintainer of textproc/kdiff3 please? -- Bruce Cran ___ 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: Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock
On 27/06/2013 17:03, Steven Kreuzer wrote: I've adopted benchmarks/fio from you. Thanks. It needs updated to 2.1.1 - I've attached the patch, though the Makefile change probably won't apply now. -- Bruce Index: Makefile === --- Makefile(revision 321878) +++ Makefile(working copy) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= fio -PORTVERSION= 2.0.15 +PORTVERSION= 2.1.1 CATEGORIES=benchmarks MASTER_SITES= http://brick.kernel.dk/snaps/ Index: distinfo === --- distinfo(revision 321878) +++ distinfo(working copy) @@ -1,2 +1,2 @@ -SHA256 (fio-2.0.15.tar.bz2) = 3cc1b5e6c6955f9acad016b4d2ef619061ad9937874c7663e2a29777ed845ac4 -SIZE (fio-2.0.15.tar.bz2) = 258773 +SHA256 (fio-2.1.1.tar.bz2) = bbe68cb9b6d4c5ec3da4dbf22b30605358bf593702baae4566ec291ac3d8076b +SIZE (fio-2.1.1.tar.bz2) = 316673 Index: pkg-plist === --- pkg-plist (revision 321878) +++ pkg-plist (working copy) @@ -1,25 +1,25 @@ bin/fio bin/fio_generate_plots -%%PORTEXAMPLESEXAMPLESDIR%%/1mbs_clients -%%PORTEXAMPLESEXAMPLESDIR%%/aio-read -%%PORTEXAMPLESEXAMPLESDIR%%/cpuio -%%PORTEXAMPLESEXAMPLESDIR%%/disk-zone-profile -%%PORTEXAMPLESEXAMPLESDIR%%/e4defrag -%%PORTEXAMPLESEXAMPLESDIR%%/e4defrag2 -%%PORTEXAMPLESEXAMPLESDIR%%/enospc-pressure -%%PORTEXAMPLESEXAMPLESDIR%%/falloc -%%PORTEXAMPLESEXAMPLESDIR%%/flow -%%PORTEXAMPLESEXAMPLESDIR%%/fsx +%%PORTEXAMPLESEXAMPLESDIR%%/1mbs_clients.fio +%%PORTEXAMPLESEXAMPLESDIR%%/aio-read.fio +%%PORTEXAMPLESEXAMPLESDIR%%/cpuio.fio +%%PORTEXAMPLESEXAMPLESDIR%%/disk-zone-profile.fio +%%PORTEXAMPLESEXAMPLESDIR%%/e4defrag.fio +%%PORTEXAMPLESEXAMPLESDIR%%/e4defrag2.fio +%%PORTEXAMPLESEXAMPLESDIR%%/enospc-pressure.fio +%%PORTEXAMPLESEXAMPLESDIR%%/falloc.fio +%%PORTEXAMPLESEXAMPLESDIR%%/flow.fio +%%PORTEXAMPLESEXAMPLESDIR%%/fsx.fio %%PORTEXAMPLESEXAMPLESDIR%%/fusion-aw-sync.ini -%%PORTEXAMPLESEXAMPLESDIR%%/iometer-file-access-server -%%PORTEXAMPLESEXAMPLESDIR%%/netio -%%PORTEXAMPLESEXAMPLESDIR%%/null -%%PORTEXAMPLESEXAMPLESDIR%%/numa -%%PORTEXAMPLESEXAMPLESDIR%%/rdmaio-client -%%PORTEXAMPLESEXAMPLESDIR%%/rdmaio-server +%%PORTEXAMPLESEXAMPLESDIR%%/iometer-file-access-server.fio +%%PORTEXAMPLESEXAMPLESDIR%%/netio.fio +%%PORTEXAMPLESEXAMPLESDIR%%/null.fio +%%PORTEXAMPLESEXAMPLESDIR%%/numa.fio +%%PORTEXAMPLESEXAMPLESDIR%%/rdmaio-client.fio +%%PORTEXAMPLESEXAMPLESDIR%%/rdmaio-server.fio %%PORTEXAMPLESEXAMPLESDIR%%/ssd-steadystate.fio -%%PORTEXAMPLESEXAMPLESDIR%%/ssd-test -%%PORTEXAMPLESEXAMPLESDIR%%/surface-scan -%%PORTEXAMPLESEXAMPLESDIR%%/tiobench-example -%%PORTEXAMPLESEXAMPLESDIR%%/zipf +%%PORTEXAMPLESEXAMPLESDIR%%/ssd-test.fio +%%PORTEXAMPLESEXAMPLESDIR%%/surface-scan.fio +%%PORTEXAMPLESEXAMPLESDIR%%/tiobench-example.fio +%%PORTEXAMPLESEXAMPLESDIR%%/zipf.fio %%PORTEXAMPLES%%@dirrm %%EXAMPLESDIR%% ___ 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"
Maintainer reset for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock
I've given up my commit bit: could someone reset the maintainer for benchmarks/fio, sysutils/ataidle and x11-clocks/wmclock please? -- Bruce Cran (brucec) ___ 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: Is latest portsnap snapshot corrupted?
On 27/05/2013 22:13, Gökşin Akdeniz wrote: Ia am not a dev, but portstree snapshot is fixed. Simply run '# portsnap fetch extract && portsdb -u' and you will get a fresh snapshot of ports tree. Is '# portsnap fetch update' not sufficient? It seemed to work here. -- Bruce Cran ___ 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: FreeBSD can now receive DAB(+) radio (and stereo wideband FM)
On Mon, Apr 29, 2013 at 12:50:41AM +0400, Lev Serebryakov wrote: > Hello, Juergen. > You wrote 28 2013 ??., 22:58:31: > > JL> http://www.freshports.org/comms/dabstick-radio > JL> Homepage: > JL> http://www.sdr-j.tk/ > Cool! And what about support for DVB-T sticks with Realtek chipset, > which could be used as wideband SDR? martymac and I have been working on that. gnuradio 3.6.3 will shortly be in ports and when martymac is back from vaction, we will have gr-osmosdr / gqrx ports. > > -- > // Black Lion AKA Lev Serebryakov > > ___ > freebsd-multime...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to "freebsd-multimedia-unsubscr...@freebsd.org" - Diane (VA3DB) -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: pkg info list sources?
On Wed, Apr 17, 2013 at 11:23:35PM -0700, Beeblebrox wrote: > I want a list of all installed packages in the form category/port. I will > feed the list to poudriere. > $ pkg info -ao > pkg.list > gives a list but needs cleaning - gcc-4.6.3: lang/gcc > How can I remove the left part of the colon and keep the trailing bit? pkg info -ao |cut -f 2 -d ' ' - -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Fwd: Problem with svn properties on non-ascii file
On Sat, Mar 23, 2013 at 05:22:54PM +0400, Ruslan Makhmatkhanov wrote:
>
>
> Original message
> Subject: Problem with svn properties on non-ascii file
> Date: Sat, 23 Mar 2013 17:20:55 +0400
> From: Ruslan Makhmatkhanov
> To: FreeBSD Developers
>
> Hi,
>
> I'm trying to commit update to deskutils/gourmet, that have this patch file:
> https://github.com/thinkle/gourmet/commit/9ad4df6f1387df10d3bd79752cfb6fbf0c285fa4
>
> I got this error both with using psvn and manually setting the
> properties (svn propset svn:mime-type text/plain
> patch-gourmet__defaults__defaults_ru.py):
That mime-type is clearly wrong if it is a binary file
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.mime-type
If you are using psvn it forces a mime type of text which is wrong in this case.
${SVN} -q propset svn:mime-type text/plain ${_file}
You'll have to manually make sure this file has the right properties
and commit with svn not psvn.
>
> """
> "svn-commit.3.tmp" 20L, 883C
> SendingMakefile
> Sendingdistinfo
> Adding files
> Adding files/patch-gourmet__defaults__defaults_ru.py
> Sendingpkg-descr
> Sendingpkg-plist
> Transmitting file data .svn: E165001: Commit failed (details follow):
> svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
> Path
> "head/deskutils/gourmet/files/patch-gourmet__defaults__defaults_ru.py"
> contains binary but has svn:mime-type "text/plain"
> Try application/* (application/octet-stream) or image/* instead.
> == Pre-commit problem count: 1
>
> svn: E165001: Your commit message was left in a temporary file:
> svn: E165001:'/home/rm/learn/free/004/deskutils/svn-commit.3.tmp'
> """
>
> I believe that the problem is because of utf-8 in patch file. So it's me
> who should fix something, or there is a problem with the hook itself?
> Thanks.
>
> --
> Regards,
> Ruslan
>
> Tinderboxing kills... the drives.
- Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: pkgng: perl5.12/perl5.14 conflict
On 11/10/2012 11:44, Baptiste Daroussin wrote: You have messed up your system long ago, you should have only one single perl on your system, so before completing your conversion you have to make sure you are on a sane system, meaning the perl5.12 -> perl5.14 conversion has been done correctly for exemple. Thanks - I'll uninstall/reinstall everything that's still depending on 5.12. -- Bruce Cran ___ 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"
pkgng: perl5.12/perl5.14 conflict
I migrated my ports to pkgng on one machine but I'm getting a conflict between perl5.12 and perl5.14 because they install files to the same location, and are required by other packages: e.g. gtk-2.24.6_2 requires perl-5.14.2_2 but glib depends on perl-5.12.4_4. I've force-uninstalled perl5.12 for now to fix 'pkg upgrade', but is there any way to fix the dependencies - I guess the solution is to get ports updated so they all use perl5.14? Trying to install perl-5.12.4_4 again results in: pkg: WARNING: locally installed perl-5.14.2_2 conflicts on /usr/local/bin/c2ph with: - perl-5.12.4_4 There are no errors, but "pkg info" shows that 5.12 wasn't installed. -- Bruce Cran ___ 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: [HEADSUP] current switched by default to pkgng
On 10/10/2012 17:31, Baptiste Daroussin wrote: Yes there is http://pkg.FreeBSD.org (no website in there no need to try to there) which will point you to pkgbeta.freebsd.org where some packages resides. On my systems pkg.freebsd.org doesn't seem to exist: > ping pkg.freebsd.org ping: cannot resolve pkg.freebsd.org: No address associated with name -- Bruce Cran ___ 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 install error
Freebsd 8.2 release processor amd64 #more start.log [2012-05-07 01:11:58] Sage version 4.8, released 2012-01-20 Setting permissions of DOT_SAGE directory so only you can read and write it. Traceback (most recent call last): File "/usr/ports/math/sage/work/sage-4.8/local/bin/sage-eval", line 4, in from sage.all import * File "/usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/all.py", line 78, in import sage.symbolic.pynac File "expression.pxd", line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19189) File "expression.pyx", line 145, in init sage.symbolic.expression (sage/symbolic/expression.cpp:35722) File "function.pyx", line 31, in init sage.symbolic.function (sage/symbolic/function.cpp:11736) ImportError: /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/ext/fast_eval.so: Undefined symbol "log2" [2012-05-07 08:23:04] Sage version 4.8, released 2012-01-20 Traceback (most recent call last): File "/usr/ports/math/sage/work/sage-4.8/local/bin/sage-eval", line 4, in from sage.all import * File "/usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/all.py", line 78, in import sage.symbolic.pynac File "expression.pxd", line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19189) File "expression.pyx", line 145, in init sage.symbolic.expression (sage/symbolic/expression.cpp:35722) File "function.pyx", line 31, in init sage.symbolic.function (sage/symbolic/function.cpp:11736) ImportError: /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/ext/fast_eval.so: Undefined symbol "log2" ___ 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: ports/comms/dfu-util
On 16 Apr 2012, at 13:57, Matthias Apitz wrote: > El día Monday, April 16, 2012 a las 02:25:37PM +0200, Martin Jansa escribió: > > Your port in ports/comms/dfu-util is version 0.1 from from Feb 2009; any > chance that you could update it to a more recent version? Sorry, I haven't had a FreeRunner for years and so can't test any new versions. Someone else needs to take over maintenance of the port. -- Bruce Cran___ 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: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: > On 2012-02-21 20:42, Steve Kargl wrote: > ... > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > > that this is a heads up for gerald@. lang/gcc is used by > > the ports collections to build a large number of other > > ports, so others are likely to hit this issue. Does -rpath not help ? man ld -rpath dir Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath is not used when linking an ELF executable, the contents of the environment variable "LD_RUN_PATH" will be used if it is defined. Or is this another problem? -rpath is added in /usr/ports/Mk > However, at runtime, it links against the system libstdc++: I ran into this with two of my own ports. -rpath needed to be passed to ld. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: subversion 1.7.0 is coming. Many ports are not ready -- what should I do?
If memory serves me right, Lev Serebryakov wrote: > Hello, Attila. > You wrote 14 октября 2011 г., 18:32:34: > >> Maybe renaming the current port to subversion16 and replace the svn >> dependency of the above ports until they support 1.7? > One problem: library version was not bumped. So, if user has > subversion-1.7.x installed, port will start to build (because > svn_client-1.so.1 is installed), but failed later. > Add BUILD_CONFLICTS too? Maybe. Hi Lev-- You're probably aware of this already, but the Subversion release engineer wants to roll a 1.7.1 build soon-ish to fix a number of issues that have cropped up in 1.7.0 testing. I'm not sure how that will interact with your plan to have Subversion 1.7.x in FreeBSD 9.0. Thanks, Bruce. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE]: clang compiling ports, take 2
On Mon, Jul 25, 2011 at 05:59:20PM +0200, Roman Divacky wrote: > Hi! > > > Flz@ just run another exp-build with CC=clang and CXX=clang++. The results > can be > seen here: > > > http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ > It would be good to also do an exp run on i386. I ran into one port that compiled fine with clang on amd64, but failed under i386. (inline asm error) - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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
Thank you very much for the info. I will give it a try. Bruce Mark Felder wrote: On Tue, 21 Jun 2011 16:03:48 -0500, Bruce Meier wrote: Does anyone know if there will ever be a wine64 port? The guy working on it is posting packages here: http://www.mediafire.com/wine_fbsd64 Feel free to install them -- they work very well. Regards, Mark ___ 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"
emulators/wine
Hi, Does anyone know if there will ever be a wine64 port? Thanks Bruce ___ 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: 2nd deprecation campaign
On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote: > 2011/6/16 Baptiste Daroussin : > > Hi all, > > ... > > Do not hesitate to manifest and undeprecate ports that would have > > deprecated by mistake. Even better do not hesitate to propose yourself > > to maintain them. I've posted on the bsd-ham[1] list to see if anyone is using sattrack. I do note an earlier version is available on amsat.org. Other BSD users are on bsd-ham, so we'll see. [1] BSD-Ham mailing list Home: http://mailman.qth.net/mailman/listinfo/bsd-ham - Diane db@ -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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"
tt-rss
Hi,
Had to add "define('PUBSUBHUBBUB_ENABLED', true);" to config.php to get
update to work.
Bruce Meier
___
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: pint/cups-base?
Thank you for your help. ___ 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: pint/cups-base?
Chris Rees wrote: On 23 May 2011 21:12, Bruce Meier wrote: When will the pint/cups-base port be upgraded? It has been marked "IGNORE" for a long time now. Thanks > From /usr/ports/print/cups-base: .if defined(WITH_XPDF) IGNORE= pick ghostscript or xpdf, not both .endif Have you actually read the IGNORE message? It's a problem with your make.conf knobs or OPTIONS. Chris ___ 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" The message is "missing function" ___ 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"
pint/cups-base?
When will the pint/cups-base port be upgraded? It has been marked "IGNORE" for a long time now. Thanks ___ 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: patch for force fetch
On Mon, May 16, 2011 at 10:22:23PM +0300, Andriy Gapon wrote: > on 16/05/2011 19:53 Eitan Adler said the following: > >> I've run into this myself and simply done the manual rm -f. This looks like > >> a great addition. > > > > what about make distclean ? > > Can you please elaborate? > If you mean that I could just run 'make distclean', then my answer is why > should > I. I.e. if the ports infrastructure already knows that there is something > wrong > with a local copy of a distfile (wrong size, wrong checksum), then it should > just do the right thing and not annoy me to run some cleanup action. I agree. Moreover, I've been thinking about the fetch operation in ports for a while, discussed with linimon@ once. There should be a way to have a little more intelligence in that. e.g. if we are expecting a binary tarball and we get back a html file, we know something has gone wrong. One of these years. -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: patch for force fetch
On Mon, May 16, 2011 at 10:02:57AM +0300, Andriy Gapon wrote: > > I've noticed the following problem. > If a distfile is updated by a distributor without renaming it (so that > checksum > and possibly size change), then more often than not the port build system > would > fail to fetch the distfile. I've run into this myself and simply done the manual rm -f. This looks like a great addition. -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: FreeBSD Port: squeezeboxserver-7.5.3, build okay but fails to start.
If memory serves me right, Brooks Davis wrote: > On Wed, Apr 27, 2011 at 07:15:07AM -0700, spotter wrote: >> I am having the exact same problem with a brand new FreeBSD 8.1-RELEASE >> install and a fresh squeezeboxserver (v7.5.3) port build. >> (Slimserver was working fine under FreeBSD 6.2, until I tried to get >> miniDLNA working, as well, for a BluRay player access to same music library. >> sigh) >> Any solutions worked out for squeezeboxserver v7.5.3 under FreeBSD >> 8.1-RELEASE? > > Assuming you aren't using mysql for anything else, you might try > manually installing an older version and then reinstalling the port. My > squeezeboxserver is running with 5.0. If that works we should be able > to restrict the allowed versions of mysql to ones that work. Just another data point: I have squeezeboxserver-7.5.3 running successfully with mysql-server-5.1.55 on FreeBSD 8.2-RELEASE/amd64. Thanks, Bruce. signature.asc Description: OpenPGP digital signature
Re: saving a few ports from death
On Wed, Apr 27, 2011 at 08:02:34AM -0700, Chip Camden wrote: > Quoth Eric on Wednesday, 27 April 2011: ... > > >> My search for "popularity" metrics is intended to point me, as a > > >> maintainer, to ports I might want to adopt now, rather than wait for > > >> someone to complain about them. Everything *I* use is already > > >> maintained, so I've moved on to looking for things other people might > > >> need. But I don't want to waste my time on something that nobody uses. > > >> :) I have suggested in the past that part of the ports infrastructure could toggle a count somewhere each time a port is made. This should be opt in of course. It would make it very easy to see which port might need a maintainer. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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: Dropping maintainership of my ports
On Wed, Apr 27, 2011 at 07:35:58AM -0400, Jerry wrote: > On Wed, 27 Apr 2011 09:49:58 +0200 > Erik Trulsson articulated: > > > On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote: > > > On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote: > > > > ... > > > > > > Every response from the committers ignored what I said I was trying > > > to do, and instead repeated the same old arguments about stale, > > > unfetchable, broken or superceded ports. That "talking points" No, no and no. If you have a copy of the upstream package the port was based upon and it is open source, you can 'fork' it. Create a project on sourceforge, or Berlioz, or somewhere, put the package there, announce it get some people together to maintain it. That has the advantage of having FreeBSD minded people maintaing it upstream. That's all. Easy Peasy. That's for unfetchable ports or even superceded ports. If you prefer an older program than a supposed newer suggested replacement, you can fork the older program. That's how it works. > > (Actually the policy is that unmaintained and non-working ports should > > be let to die, unless somebody steps up to fix the port and take > > maintainership.) Exactly. > > > > Nobody is stopping you from assuming maintainership of one or more of > > those unmaintained ports, and thus preventing them from being removed. > > I concur with Erik. I think you are totally missing the point of the > original post. The desired wish was to remove dead ports that could not > be fetched, or would not build. Possibly, even superseded ports; Right. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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"
Java version and JRuby port
When the JRuby port is installed, it updates the jruby script to force the JAVA_HOME to be the JAVA_HOME the port was built with. I've got both diablo-jdk1.6.0 and openjdk6 installed, but I can't figure out how to force the JRuby port to use openjdk6, and I can't override the JAVA_HOME unless I'm willing to modify the jruby script. Why is this port set up this way? What's the rationale for not allowing JAVA_HOME to be overridden? ___ 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"
sysutils/fusefs-ntfs broken due to devel/libublio being marked deprecated
Hi, devel/libublio has recently been marked DEPRECATED (there's a spelling mistake - "Abandonned and no distfiles provided" should be "Abandoned...") so if sysutils/fusefs-ntfs was built with the UBLIO option enabled (which is the default), it now fails when being upgrading. -- Bruce Cran ___ 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"
tt-rss-1.5.2.tar.gz
Hi, I have tt-rss installed and ran portupgrade to update my system and found that a bad sha256 checksum for tt-rss-1.5.2.tar.gz The correct sum is "ec90eb0c8d19fb9895a78fdc480462790d0e9e7c63afbf82a99762290ef069ab" Thanks Bruce ___ 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: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Fri, Jan 07, 2011 at 02:46:29PM -0600, Tom Judge wrote: > On 01/07/2011 02:04 PM, Doug Barton wrote: > > On 01/07/2011 11:57, Olli Hauer wrote: > > ... > > Maybe we need a more generic way of doing this rather than each port > providing their own implementation? I like that idea. I was for a while running two openvpn instances, it was a right pita modifying one. *t_j* i.e. '/etc/rc.d/openvpn restart link1' will restart the process for +/etc/openvpn/link1.conf *t_j* it was discussed in #bsdports briefly *agreed* that would be nice. > > Tom > > This is my slightly biased opinion as I am the author of one such script > in the tree. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Multiple subdirectories/sub-builds
On Wed, Oct 27, 2010 at 11:44:54AM -0500, Jim Riggs wrote: > I am working on a new port that has several "sub-builds." That is, the > distfile has several subdirectories, each with its own > configure/make/install. Are there any best practices or suggestions for > dealing with this scenario? I didn't find anything in the handbook, and list > searches didn't turn up anything (though I don't know what exactly to search > for). I have in the past simply created my own Makefile that descends into each subdir and builds them. Stick it into files. Look at comms/trustedqsl - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: KDE 4.4 problems
On 5/14/2010 5:43 PM, Adam K Kirchhoff wrote: On Fri, 14 May 2010 09:58:47 -0400 Adam K Kirchhoff wrote: On Sat, 2010-05-15 at 00:28 +1100, Dima Panov wrote: On Saturday 15 May 2010 00:02:45 Adam K Kirchhoff wrote: On Wed, 12 May 2010 19:47:44 -0400 Adam K Kirchhoff wrote: On Thu, 13 May 2010 02:23:28 +0400 Max Brazhnikov wrote: On Wed, 12 May 2010 17:42:58 -0400, Adam K Kirchhoff wrote: So when I attempted to upgrade KDE4.3 to KDE4.4 via ports (following the instructions in /usr/ports/UPDATING) it failed in x11/kdelibs4 with: gmake[2]: Leaving directory `/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build' /usr/local/bin/cmake -E cmake_progress_report /usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build/CMakeFiles 48 49 50 51 52 [ 48%] Built target kio gmake[1]: Leaving directory `/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/x11/kdelibs4. Build kdelibs with DISABLE_MAKE_JOBS and with CMAKE_VERBOSE (make -DDISABLE_MAKE_JOBS -DCMAKE_VERBOSE) and show us actual error message. Max Thanks, this is what I'm getting now: [ 20%] Building CXX object nepomuk/core/CMakeFiles/nepomuk.dir/resourcedata.o cd /usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build/nepomuk/core && /usr/bin/c++ -DMAKE_NEPOMUK_LIB -D_GNU_SOURCE -DQT_NO_STL -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DKDE_DEFAULT_DEBUG_AREA=30 -O2 -pipe -fno-strict-aliasing -Woverloaded-virtual -fvisibility=hidden -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -fPIC -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build/nepomuk/core -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/nepomuk/core -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3 -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/interfaces -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/nepomuk -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/KDE -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kio -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kio/bookmarks -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kio/kio -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kio/kfile -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/actions -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/colors -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/config -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/dialogs -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/findreplace -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/fonts -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/icons -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/itemviews -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/jobs -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/kernel -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/notifications -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/paged -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/plotting -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/shortcuts -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/sonnet -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/util -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/widgets -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/windowmanagement -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdeui/xmlgui -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kjs -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build/kjs -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/build/kdecore -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/compression -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/config -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/date -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/io -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/jobs -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/kernel -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/auth -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/network -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/services -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/localization -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/sycoca -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/text -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/util -I/usr/ports/x11/kdelibs4/work/kdelibs-4.4.3/kdecore/sonnet -I/usr/local/include/QtCrypto -I/utils -I/usr/local/include/qt4/KDE -I/usr/local/include/qt4 -I/usr/local/include/qt4/phonon -I/usr/local/include/qt4/QtXmlPatterns -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4/QtWebKit -I/usr/local/include/qt4/QtUiTools -I/usr/local/include/qt4/QtTest -I/usr/local/include/qt4/QtSvg -I/usr/local/include/qt4/QtSql -I/usr/local/include/qt4/QtScriptTools -I/usr/local/include/qt4/QtScript -I/usr/local/inclu
Re: Responding to a challenge
On Tue, Apr 20, 2010 at 03:05:22PM -0400, Thomas Abthorpe wrote: ... > > How about you two sing a duet at BSDCAN? > > > > - Diane > > Sadly my band is trapped in Europe, and I am personally unable to travel at > this time, and will not be at BSDCan this year :( Pity! I was going to suggest it would be worth a buck a piece for developers to witness you singing, all proceeds to the FreeBSD foundation. ;-) - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Responding to a challenge
On Tue, Apr 20, 2010 at 09:39:17PM +0400, Max Brazhnikov wrote: > On Sun, 18 Apr 2010 23:52:43 -0400, Thomas Abthorpe wrote: > > edwin@ threw down this gauntlet when I accepted my recent hat, > > http://blogs.freebsdish.org/tabthorpe/2010/03/25/catching-up-on-recent-even > > ts/comment-page-1/#comment-13022 > > > > I have responded. Sure it is lame, I am a porter, not a song writer! > > Great! We are waiting for audio version now! :) How about you two sing a duet at BSDCAN? - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Responding to a challenge
On Sun, Apr 18, 2010 at 11:52:43PM -0400, Thomas Abthorpe wrote: > edwin@ threw down this gauntlet when I accepted my recent hat, > http://blogs.freebsdish.org/tabthorpe/2010/03/25/catching-up-on-recent-events/comment-page-1/#comment-13022 > > I have responded. Sure it is lame, I am a porter, not a song writer! Don't give up your day job. > -- > Thomas Abthorpe | FreeBSD Committer > tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: net/xorp - scattering file locations.
P.S. there is a pkg-message for the legacy net/xorp package which explains why XORP needs PREFIX to be set to other than the default. If this is a problem for you consider net/xorp-devel ___ 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: net/xorp - scattering file locations.
On 03/20/10 01:19, jhell wrote: The above mentioned port installs or otherwise scatters quite a few (10 or more) new directories into /usr/local/. Did I miss some configuration setting that I had to explicitly state in order for everything to just be installed in /usr/local/xorp or maybe in a more proper place. XORP as of 1.7-WIP in SVN is now compliant with the Filesystem Hierarchy Standard. Its directory is thus more in line with other packages for free UNIX-like operating systems. I appreciate your feedback that this may have violated POLA for you, however, it's pretty much a prerequisite for getting it shipped in Ubuntu and other UNIX-like systems. If you have any further queries please direct them to the xorp-users and xorp-hackers mailing lists. Thank you for your interest in XORP. regards, BMS ___ 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"
[Fwd: Re: cvs commit: ports/net/py-txamqp Makefile distinfo pkg-plist]
So they cut over to easy_install -- how do I tell it to record the egg information? This wasn't in the Porter's Handbook. Perhaps someone more familiar with the python ports knows? --- Begin Message --- The Restless Daemon identified a mtree error while trying to build: py26-txamqp-0.3 maintained by b...@freebsd.org Makefile ident: $FreeBSD: ports/net/py-txamqp/Makefile,v 1.2 2009/08/19 13:15:14 bms Exp $ Excerpt from http://QAT.TecNik93.com/logs/7-STABLE-FPT-NPD/py26-txamqp-0.3.log : ===> py26-txamqp-0.3 depends on file: /usr/local/lib/python2.6/site-packages/thrift/__init__.py - found ===> py26-txamqp-0.3 depends on file: /usr/local/bin/easy_install-2.6 - found ===> py26-txamqp-0.3 depends on file: /usr/local/bin/python2.6 - found ===> py26-txamqp-0.3 depends on file: /usr/local/lib/python2.6/site-packages/twisted/__init__.py - found ===> Generating temporary packing list ===> Checking if net/py-txamqp already installed running easy_install Processing txAMQP-0.3-py2.6.egg creating /usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg Extracting txAMQP-0.3-py2.6.egg to /usr/local/lib/python2.6/site-packages Adding txAMQP 0.3 to easy-install.pth file Installed /usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg ===> Registering installation for py26-txamqp-0.3 ===> Building package for py26-txamqp-0.3 Creating package /tmp/packages/All/py26-txamqp-0.3.tbz Registering depends: py26-twistedCore-8.2.0 py26-zopeInterface-3.5.2 py26-setuptools-0.6c9 py26-thrift-20090622 python26-2.6.2_2. Creating bzip'd tar ball in '/tmp/packages/All/py26-txamqp-0.3.tbz' Deleting py26-txamqp-0.3 === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 11085374 drwxr-xr-x4 root wheel 512 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg 11085384 drwxr-xr-x4 root wheel1024 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp 11085634 drwxr-xr-x2 root wheel 512 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp/contrib 11085640 -rwxr-xr-x1 root wheel 0 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp/contrib/__init__.py 11085654 -rw-r--r--1 root wheel 173 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp/contrib/__init__.pyc 11086144 -rw-r--r--1 root wheel 173 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp/contrib/__init__.pyo 11085774 drwxr-xr-x2 root wheel1024 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/txamqp/test 11085964 drwxr-xr-x2 root wheel 512 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO 11085974 -rw-r--r--1 root wheel 221 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO/PKG-INFO 11085984 -rw-r--r--1 root wheel 902 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO/SOURCES.txt 11085994 -rw-r--r--1 root wheel 1 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO/dependency_links.txt 11086004 -rw-r--r--1 root wheel 7 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO/top_level.txt 11086014 -rw-r--r--1 root wheel 1 Aug 19 13:13 usr/local/lib/python2.6/site-packages/txAMQP-0.3-py2.6.egg/EGG-INFO/not-zip-safe build of /usr/ports/net/py-txamqp ended at Wed Aug 19 13:13:06 UTC 2009 The tarballed WRKDIR can be found here: http://QAT.TecNik93.com/wrkdirs/7-STABLE-FPT-NPD/py26-txamqp-0.3.tbz PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=net&portname=py-txamqp The build which triggered this BotMail was done under tinderbox-devel-3.2_4; dsversion: 3.2 on RELENG_7 on amd64, kern.smp.cpus: 4 with tinderd_flags="-nullfs -plistcheck -onceonly" and ccache support, with the "official" up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better,
Re: devel/boost: new patch for testing update to 1.39
Thanks for this much needed work. Detailed diagnostic info and patches follow. System under test: %%% FreeBSD anglepoise.lon.incunabulum.net 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 10 09:58:47 BST 2009 r...@anglepoise.lon.incunabulum.net:/home/obj/usr/src/sys/ANGLEPOISE amd64 %%% Note: kernel+world ARE out of sync, world ahead by ~2 weeks, due to some catastrophic USB regressions in RELENG_7 affecting this machine. I got a few warnings during 'make index' which indicate there are stragglers: %%% anglepoise# make index Generating INDEX-7 - please wait..make_index: avogadro-0.9.6: no entry for /usr/ports/devel/boost-python make_index: avogadro-0.9.6: no entry for /usr/ports/devel/boost-python ^^^ boost-python in LIB_DEPENDS make_index: peekabot-0.6.0: no entry for /usr/ports/devel/boost make_index: peekabot-0.6.0: no entry for /usr/ports/devel/boost ^^^ boost in LIB_DEPENDS make_index: flyhard-0.42: no entry for /usr/ports/devel/boost ^^^ boost in BUILD_DEPENDS Warning: Duplicate INDEX entry: cvsup-without-gui-16.1h_4 Warning: Duplicate INDEX entry: mod_rpaf-ap2-0.6 ^^^ these look unrelated Done. %%% I've attached a diff for the stragglers, this fixes the 'make index' warnings. %%% anglepoise# portupgrade -o devel/boost-libs devel/boost [Updating the portsdb in /usr/ports ... - 20370 port entries found .1000.2000.3000.4000.5000.6000.7000.8000.9000.1.11000.12000.13000.14000.15000.16000.17000.18000.19000.2... . done] cd: can't cd to /usr/ports/devel/boost [chose VERBOSE_BUILD, DEBUG, ICU from options] %%% reinstall ok. now upgrade dependent ports installed on my system: %%% anglepoise# portupgrade -rfx devel/boost devel/boost %%% no-op. try something else: %%% anglepoise# portupgrade -rfx devel/boost-libs devel/boost-libs ===> Extracting for boost_build-2.0.m12 => MD5 Checksum OK for boost-build-2.0-m12.tar.bz2. => SHA256 Checksum OK for boost-build-2.0-m12.tar.bz2. ===> Patching for boost_build-2.0.m12 ===> Applying FreeBSD patches for boost_build-2.0.m12 ===> Configuring for boost_build-2.0.m12 ---> Backing up the old version ---> Uninstalling the old version ---> Deinstalling 'boost_build-2.0.m12' pkg_delete: unable to completely remove directory '/usr/local/share/boost_build/tools' pkg_delete: unable to completely remove directory '/usr/local/share/boost_build' pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) [Updating the pkgdb in /var/db/pkg ... - 945 packages found (-1 +0) (...) done] ---> Installing the new version via the port ===> Installing for boost_build-2.0.m12 ===> boost_build-2.0.m12 depends on file: /usr/local/bin/bjam - not found ===>Verifying reinstall for /usr/local/bin/bjam in /usr/ports/devel/boost-jam ===> Vulnerability check disabled, database not found ===> Extracting for boost-jam-1.39.0 => MD5 Checksum OK for boost_1_39_0.tar.bz2. => SHA256 Checksum OK for boost_1_39_0.tar.bz2. ===> Patching for boost-jam-1.39.0 ===> Configuring for boost-jam-1.39.0 ===> Building for boost-jam-1.39.0 cd /usr/ports/devel/boost-jam/work/boost_1_39_0/tools/jam/src && ./build.sh gcc; ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 47 targets... ...updating 2 targets... [MKDIR] bin.freebsdx86_64 [COMPILE] bin.freebsdx86_64/bjam ...updated 2 targets... ===> Installing for boost-jam-1.39.0 ===> Generating temporary packing list /bin/mkdir -p /usr/local/bin install -s -o root -g wheel -m 555 /usr/ports/devel/boost-jam/work/boost_1_39_0/tools/jam/src/bin.freebsdx86_64/bjam /usr/local/bin/ ===> Registering installation for boost-jam-1.39.0 ===> Returning to build of boost_build-2.0.m12 ===> Generating temporary packing list To use boost_build, it is necessary to set BOOST_ROOT in your environment: sh/bash/ksh: BOOST_ROOT=/usr/local/share/boost_build ; export BOOST_ROOT csh: setenv BOOST_ROOT /usr/local/share/boost_build Note: The default toolchain is gcc. To override this on a system-wide basis, edit this file: /usr/local/share/boost_build/site-config.jam For an example of a per-user settings file which may be
Re: [Patch] Proposal: USE_GNU89 switch
Hi, On Sat, May 30, 2009 at 04:34:43PM +0200, Ed Schouten wrote: > * Gabor Kovesdan wrote: > > As for LLVM, probably it won't work out for the whole ports > > tree. I don't know what's the portmgr opinion on this, if we start to > > use LLVM in Ports Collection, we should reconsider the knob, though. As the plan is to have both gcc + clang in -9 we are still going to run into this problem. I would expect a lot of users are going to just expect ports to work with clang as well as gcc. > LLVM/Clang support is trivial. Erwin Lansing fired up an experimental > ports build for us and the numbers are *very* promising. There are still > some issues with the compiler itself, but so far it seems the only > architectural change to the tree that needs to be made, is a hint to > fall back to C89. By the time FreeBSD-9 is released clang support will be solid and all ports will compile with clang as well as gcc. Clang was chosen because of their committment to have full gcc compatibility. > > This is not just about LLVM/Clang support. If the GCC folks ever decide > to switch to C99 by default, we'll have exactly the same issue. Agreed. I don't see the harm in trying Ed_'s diff on a exp. run with both gcc and clang and compare a gcc run with a stock run. Perhaps this is something Itetcu could help with. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: Unhappy Xorg upgrade
Alex Goncharov wrote: I hate to say this, but the new X (as exists in the current FreeBSD ports) sucks and gets in the way of work big time. There are definitely issues with xorg-7.4 at the moment. The root issue seems to be that USB mice simply don't work for me, and running Xorg appears to destabilise the 7-STABLE USB stack in some way which I just don't understand. The condition isn't recoverable without a reboot. I am the only person who's reported these symptoms in any great detail yet. I spent a lot of time yesterday debugging with rnoland@ the USB problem I've been having. He sent me a patch, however, it doesn't solve the problem. My understanding is that a lot has changed in this Xorg release to do with input drivers, specifically mouse -- and that platform specific code got shuffled off out of the server itself, and into the drivers. Good from an academic software engineering point of view, but if this is the cause, not good from a regression point of view. Whilst bisecting all the conditions, and tracing it back to this upgrade is easy to do, I can't readily identify the causal relationship -- I don't know what's going on which has broken Xorg for me in this way, and haven't seen anything like this before. Since upgrading, I've seen stability problems with hald enabled. I have had to turn off hald mode on both my laptop and desktop 7-STABLE machines, as it can totally hang the machine, no DDB break, etc. Scanning SVN, nothing appears to have changed in the 7-STABLE train in terms of USB, moused, the ums driver, or anything else. A ktrace of the moused process bound to ums0 goes dead (no I/O, no syscalls) after X is started. One theory is that somehow the mouse driver ioctls which are passed to ums, are somehow hosing USB, although why that would be, I don't understand. ums currently doesn't have driver instrumentation in that path. I pulled a fairly detailed IRC log of my collaborative debugging session with Robert, please ping me if you need details of this. thanks BMS ___ 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"
Problem with aclocal, pkg.m4 and ports
Hi, I basically just ran into the same problem as this guy did, whilst trying to roll a FUSE port: http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/172377.html It seems if I run the *same* aclocal binary from the command line, pkg.m4 is expanded in aclocal.m4 inside WRKSRC. But if I let it run from the Makefile targets, it doesn't. What's going on? I have reworked the port in progress to just push CPPFLAGS in the environment, obviously this isn't "the pkgconfig way". thanks, BMS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems building ports - Error code 2 when attempting to cd
On Wed, Nov 05, 2008 at 09:04:18PM -0500, Scott Ullrich wrote: ... > Anything else you can think to check? Look for this variable set somewhere. ALWAYS_BUILD_DEPENDS > ===> rrdtool-1.2.26_1 depends on shared library: freetype.9 - found >(but building it anyway) This message "but building it anyway" is odd. looking in /usr/ports/Mk , I'd like to know why ALWAYS_BUILD_DEPENDS is set. That can't be right. What are you typing to do the make? -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: libxml2-2.6.31
On Sat, May 10, 2008 at 04:23:59PM -0500, Jeremy Messenger wrote: > On Sat, 10 May 2008 16:12:46 -0500, Fabien Debuire <[EMAIL PROTECTED]> > wrote: > > >Hello there is a mismatch with the checksum for this port since you > >change > >mirrors order can you please update this > > I have tested on all mirrors before I have committed this change. I still > can't reproduce it here. This is probably one of the bugs that stalks the ports system. It is possible you got a html text message saying the server was too busy stored into libxml2-2.6.31.tar.gz; the ports system at present does not use file to check that the file it has fetched matches what it was expecting. This is one of the cases where manual intervention is necessary and you have to remove the file downloaded and try again. It's not that easy a bug to fix unfortunately. - Diane -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: fldigi-2.10
On Tue, Apr 22, 2008 at 11:26:45AM -0700, Chris Maness wrote: Resolved. It never occured to me Chris was missing a soundcard. This is the assert trap from portaudio2. ;-) It's a very cryptic message. - Diane (VA3DB) -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: fldigi-2.10
On Tue, Apr 22, 2008 at 10:33:37AM -0700, Chris Maness wrote: > > Here is what I got after rebuilding. > ... > Hamlib version 1.2.6.1 > PortAudio V19-devel 1899 > libsndfile-1.0.17 > Abort trap: 6 (core dumped) At this point, it sounds like a hardware problem. Check your RAM. - 73 Diane VA3DB -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: fldigi-2.10
On Mon, Apr 21, 2008 at 06:39:46PM -0700, Chris Maness wrote: > Hello, Diane, > > I am having trouble getting fldigi to compile. Also, the binary install > core dumps (signal 11) on two different FreeBSD installs. This is on > release 7.0. hrmmm ugh fldigi-2.10 runs fine here on i386 FreeBSD 7.0. What architecture are you on? Does it happen to be amd64? I'll need to see a gdb bt if you can. > > /usr/bin/ld: cannot find -lgio-2.0 > gmake: *** [libgiofam.la] Error 1 > *** Error code 2 > > Stop in /usr/ports/devel/gio-fam-backend. > *** Error code 1 This problem is actually in devel/gio-fam-backend I have duplicated the problem. /usr/bin/ld: cannot find -lgio-2.0 gmake: *** [libgiofam.la] Error 1 *** Error code 2 But I am not sure how this could happen. Are your ports up to date? Basically gio-fam-backend has a dependancy on /usr/ports/devel/glib20 or should have. Unless glib20 port is installed first, libgiofam will fail. I've only taken a quick cursory look, but it appears this might be related to a commit to /usr/ports/Mk/bsd.gnome.mk # $FreeBSD: ports/Mk/bsd.gnome.mk,v 1.146 2008/03/24 15:59:55 marcus Exp $ In the meantime, cd /usr/ports/devel/glib20;make install then return to your fldigi build. > Also, I have been able to get tlf working in console using screen. You > might have already known this, but I just found out about it a couple of > weeks ago. Maybe put a small notice about screen for vt100 > compatibility in the install script. I had sent you an e-mail regarding > the terminal issues a while back, but I guess that would be a good fix. > The only issue I have found is that backspace still does not work under > FreeBSD. Yes, I remember your comment about that. I'll look at it again, thanks. - 73 Diane VA3DB -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Port: comms/acfax
On Mon, Apr 21, 2008 at 07:41:07PM -0400, Roland Burgan wrote: > What is considered the best Satellite Tracking program & predictor, in > real time, for Ubuntu? Why not run http://www.pcbsd.org instead and just install the PBI for gpredict or predict? It is a lot easier. - 73 Diane VA3DB (amsat coordinator) -- - [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
