not only using -lc_r what would result in linking in libc and libc_r
Submitted by: Dirk Froemberg <ibex@physik.TU-Berlin.DE>
Obtained from: John Birrell
agreed by Josh Tiefenbach <josh@ican.net>, thanks Josh for your
previous work on this port.
Port is no more broken. Requested by new maintainer and tested by
me with a -current system.
/usr/ports/databases/mysql/work/mysql-3.21.33/scripts/mysql_install_db
Didn't find the 'data' directory in the current directory
You should be in the distribution directory when executing this script
Please go to the directory where you unpacked this distribution
and start this script with 'scripts/mysql_install_db'
*** Error code 1
Move msql to 87:87 so that package-building works again. I have an
extremely strong suspicion that msql does not need _reserved_ uid:gid's at
all, but I can't even fetch the distfile to check...
===
## make package
>> Checksum OK for PyGreSQL-2.1.tgz.
===> Extracting for py-PyGreSQL-2.1
===> py-PyGreSQL-2.1 depends on executable: python - found
===> py-PyGreSQL-2.1 depends on shared library: pq\.1\. - found
===> Patching for py-PyGreSQL-2.1
===> Configuring for py-PyGreSQL-2.1
test: syntax error
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/Makefile /usr/ports/databases/py-PyGreSQL/work
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/Makefile.in /usr/ports/databases/py-PyGreSQL/work
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/configure.in /usr/ports/databases/py-PyGreSQL/work
install -c -m 0555 /usr/ports/databases/py-PyGreSQL/scripts/install-sh /usr/ports/databases/py-PyGreSQL/work
install -c -m 0555 /usr/ports/databases/py-PyGreSQL/scripts/configure.local /usr/ports/databases/py-PyGreSQL/work/configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
checking for gcc... cc
checking whether the C compiler (cc -O2 -pipe -L/usr/local/lib/python1.5/config -L/usr/local/pgsql/lib) works... yes
checking whether the C compiler (cc -O2 -pipe -L/usr/local/lib/python1.5/config -L/usr/local/pgsql/lib) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for python... /usr/local/bin/python
checking for pow in -lm... yes
checking for read_history in -lreadline... yes
checking for crypt in -lcrypt... yes
checking for PyArg_Parse in -lpython1.5... no
configure: error: The Python 1.5 library could not be found.
*** Error code 1
:
===
Note the "test: syntax error" in the first line output from configure.
Satoshi
Many bugfixes and cosmetic changes
Changes by Scrappy and me
My additional changes:
- had to link libpgtcl.so with the crypt library to get rid of the
pgaccess error message, that crypt is missing
- had to add -i option in the startup script, so that pgaccess is
able to connect to the postmaster process
- removed all unnecessary patches
- updated PLIST
Thanks to the postgresql developement team, who did a great job to
simplify the postgresql port, by applying the patches and making
the autoconf mechanism more consistent.
Submitted by: The Hermit Hacker <scrappy@hub.org>
Now, I know you tested it (who doesn't? :), Andreas, but you need to
test it *twice* with a "make deinstall" in between, or you may not
catch files that were left from the previous installation (as it was
in this case).
the bug-gnats mailing list. There are a ton of bugfixes and
some good new features (like user defined states).
I should have used the makefile's patch code to deal with this,
but the patches had differning formats and there were order dependancies,
so I built these patch ffiles by hand.
From the author:
Date: Sun, 04 Jan 1998 12:44:48 +0200
From: Constantin Teodorescu <teo@flex.ro>
Organization: FLEX Consulting Braila
Subject: Bug in PgAccess 0.7x , fixed in 0.73 !
Hello all,
recently Dave Chapeskie has discovered a bug in visual query builder,
when deleting table or links! This was due to last changed in source
code made in order to allow table aliasing.
All previously released 0.7x versions of PgAccess are buggy from this
point of view!
I have released today the 0.73 version that fixes it! Please use the new
versions and keep me informed !!!
This new version is also using a drop-down-like combo for choosing
tables in visual query builder! I will probably use it in other places
in order to enhance PgAccess.
Thanks again for testing PgAccess.
from the author:
"I started to write at the Reports module.
from a table, no filters, no sorts (yet) !
Of course, no prints ! Only fields in output report (no labels, lines or
rectangles)!
I am working now at region resizing (page header, footer, detail, etc)
Reports will be generated as Postscript file!
stay close ..."
Update to version 0.70
From his announcement:
> PgAccess v0.70 handles now user defined forms and scripts!
>
> Manipulating forms, PgAccess could be enhanced by the user in order to
> generate new applications.
> The powerfull scripting feature inherited from Tcl/Tk, the native
> environment of PgAccess, allow users to define and use new procedures,
> libraries and even call "system" procedures that I have been used
> writting PgAccess. I would say that PgAccess will be able to accept
> "plugin" modules in order to make him more powerfull. It will make him
> just a "shell" who will set up only a "working environment" for newly
> developed applications!!!!
>
> More information and some examples you will find at
> http://www.flex.ro/pgaccess/pga-rad.html
>
> Once more, I would like to thank you folks for giving me PostgreSQL and
> Visual Tcl, and hoping that PgAcces would help making them more popular!
- author was so nice to add a version number in the source file, hurray.
- "dynamically" patch the path to libpgtcl.so ${PREFIX}/pgsql/lib/libpgtcl.so|
depending on the PREFIX variable using new post-configure script
- tested building, installing, packaging
number. HELP, need LOCAL_PORT ! Who with proper permissions could
please do a make fetch and place this tar archive under
LOCAL_PORT/pgaccess-0.52.tar.gz ? Thanks.
background because of the -S option.
- remove the -D datadir option, it's meaningless, because the pgsql
user environment overwrites it with the PGDATA env variable.
Since this is important and might cause some headache, I mentioned
this in ~pgsql/.profile and the startup script.
Submitted by: John Fiber
- in order to access the template1 database as pgsql user, the
environment needs the DISPLAY variable set to at least ":0"
- pgaccess loads dynamically the libpgtcl.1, some symbols from
another dynamic lib are needed as well -> libpq.so.1.0
Makefile (patch-af) modified (copied from the Linux clause),
so that shared lib libpgtcl is created with proper loader flags.
for building the tcl/tk based database frontend pgaccess.
For an updated version of this tool a separate port will
follow. Please test these changes well, so that we get a
nice PostgreSQL 6.2 version up and running "b4" port freeze ;-)
Please note: when performing a migration to 6.2 and you have an existing db,
then you have to use the *new* pg_dumpall script that comes with this new
postgresql release. The INSTALL file points this out explicitely !!!
Changes:
- startup script resides in FILESDIR
- renamed it to be in sync with INSTALL file from sources
- always install this startup script over an existing, because
of the nature of the rc.d directory I can't install it
to pgsql.sh-dist, if a pgsql.sh is already presend ...
- portlint detected trailing whitespace, usage of perl with absolute
path, usage of echo instead of ECHO and plenty things of this kind
- post installation notes updated, mentioned the mailing list
- copies the html pages as well to the share/doc directory (new manual dir)
- had to update PLIST
- shortened DESCR file, to match the 24 lines
- added post build target, that reminds the admin how to proceed when
already having a database -> INSTALL file describes migration
- updated manpages
