Re: UID/GID dynamic allocation in net/isc-dhcp3-server: why?
Kris Kennaway wrote:
On Sat, Nov 11, 2006 at 10:05:05PM +0100, Simon L. Nielsen wrote:
On 2006.11.11 15:48:05 -0500, Kris Kennaway wrote:
On Sat, Nov 11, 2006 at 09:37:31PM +0100, Simon L. Nielsen wrote:
On 2006.11.11 21:12:09 +0200, Dmitry Pryanishnikov wrote:
I don't like the current behaviour of the net/isc-dhcp3-server port
of creating 'dhcpd' user and group using dynamic allocation instead of
having static one (as specified in /usr/ports/{U,G}IDs). I like the idea
of [ug]id ranges, and dynamic allocation doesn't keep within this idea
(ids of users and daemons get mixed). Is there specific reason why there
is no static [ug]id for net/isc-dhcp3-server?
Personally I have it precisely the other way around - I find the
static allocations rather annoying since they are bound to collide
with existing UID's at some point.
IMO the optimal solution would be to have some magic which auto
assigns ports/system UID/GID's from different ranges that normal
users.
Just so :)
UIDs below 1000 are (and have been for many years) allocated to the
system (ports/src), and are not supposed to be allocated by
administrators. This at least works out of the box with some of the
tools we have for allocating new users, so are you aware of any that
don't do this?
I know that people are not suposed to use 1000 and for normal users
and I havent seen any FreeBSD tools which uses low UID's for normal
users by default. I don't do use low UID's new systems/sites, but
sometimes you have old systems/sites where that is just not the
case. I'm certainly not saying we should bent over backwards to
support these legacy systems, I just want to point out that they do
exist. I'm really not trying to start a big debate over static
vs. dynamic UID/GID allocations, the original mail just made it sound
to me like it was a universal truth that ports should use hardcoded
UID/GID's and it was always a good thing.
And the site where I have UID/GID's in the 1000 range is called
FreeBSD.org :-) (we use UID/GID's from 500 and up).
I dunno what you are suggesting could be done on systems where the
administrators have chosen to ignore the conventions. Even supposing
the 1000 range was dynamically remapped to some other range on such
systems, what's to stop the rogue admin from allocating there too?
I have a bsd.port.mk patch in the works to create users/groups
automatically from uids/gids registered in the related files. It
wouldn't be too hard to include a UID_OFFSET/GID_OFFSET parameter so
that the local admin can reserve uids/gids in say range 2000-3000
instead of 0-1000 (which isn't really 0-1000 but I'm too lazy to check
where system uids/gids stop :-)
Would it be alright with you Simon?
--
Florent Thoumie
[EMAIL PROTECTED]
FreeBSD Committer
signature.asc
Description: OpenPGP digital signature
INDEX build failed for 4.x
INDEX build failed with errors: Generating INDEX - please wait.. Done. Warning: Duplicate INDEX entry: openoffice.org-2.0.4 Committers on the hook: ache anray clsung daichi fjoe itetcu jkim leeym maho mbr mezz pav rafan sat Most recent CVS update was: U devel/cvsnt/Makefile U devel/cvsnt/distinfo U devel/cvsnt/pkg-plist U devel/p5-PAR/Makefile U devel/p5-PAR/distinfo U devel/p5-PAR/pkg-plist U ftp/ncftp/Makefile U ftp/ncftpd/Makefile U news/husky-msged/Makefile U news/husky-msged/distinfo U news/husky-msged/pkg-plist U news/husky-msged/files/patch-Makefile U news/husky-msged/files/patch-fido.c U news/husky-msged/files/patch-msg.c U news/tin/Makefile U news/tin/pkg-plist U textproc/p5-XML-RSS/Makefile ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulators/qemu-launcher: unable to launch
martinko [EMAIL PROTECTED] writes: Hello list, I've just compiled and installed emulators/qemu-launcher and this is what I've got when trying to run it: $ qemu-launcher /libexec/ld-elf.so.1: /usr/local/lib/libgthread-2.0.so.0: Undefined symbol pthread_getschedparam What's wrong please? What am I to do now? When you installed the port, it printed out the pkg-message file for the port, which has the answer for this problem and a number of others. Specifically: - qemu now uses aio at least for ide dma, so if you get `Bad system call' crashes that is because aio is not (kld)loaded. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/10543: New port uploaded for xslj
Synopsis: New port uploaded for xslj Responsible-Changed-From-To: freebsd-ports-miwi Responsible-Changed-By: miwi Responsible-Changed-When: Sun Nov 12 16:46:29 UTC 2006 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=10543 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnucash will not install/run.... [SOLVED]
On Sun, 2006-10-22 at 10:11 +1000, Peter Jeremy wrote: On Sat, 2006-Oct-21 13:59:08 -0500, Jeremy Messenger wrote: On Sat, 21 Oct 2006 12:47:38 -0500, Eric Schuele [EMAIL PROTECTED] It appears there is a patch file (patch-aa) missing from the 1.3.4,1 version of the port that is present in 1.3.4_9. If its necessary I don't know... but that is one difference between the two ports. So I thought I'd mention it. ahze has patch to yet commit it, but I don't know if it will help with your problem. If you want to test it, feel free to do and report back. Adding ahze in the CC. No change. gnucash still SEGVs immediately. I've come up with a port for gnucash 2.0.2 and it seems to work so I might just migrate rather than trying to get gnucash 1.8 working. Peter is this port working? -- Scott T. Hildreth [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
INDEX build failed for 4.x
INDEX build failed with errors: Generating INDEX - please wait.. Done. Warning: Duplicate INDEX entry: openoffice.org-2.0.4 Committers on the hook: ache alepulver anray clsung daichi dinoex fjoe garga gerald itetcu jkim leeym maho mbr mezz novel pav rafan sat stefan Most recent CVS update was: U biology/adun/Makefile U devel/autoconf-archive/Makefile U devel/autoconf-archive/distinfo U devel/autoconf-archive/pkg-plist U devel/autoconf-archive/files/patch-Makefile.in U irc/ircII/Makefile U irc/ircII/distinfo U irc/ircII/pkg-plist U lang/gcc43/Makefile U lang/gcc43/distinfo U mail/dspam/Makefile U mail/dspam/files/UPDATING U mail/dspam-devel/Makefile U mail/dspam-devel/files/UPDATING ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UID/GID dynamic allocation in net/isc-dhcp3-server: why?
On 2006.11.12 10:45:21 +, Florent Thoumie wrote:
Kris Kennaway wrote:
On Sat, Nov 11, 2006 at 10:05:05PM +0100, Simon L. Nielsen wrote:
On 2006.11.11 15:48:05 -0500, Kris Kennaway wrote:
On Sat, Nov 11, 2006 at 09:37:31PM +0100, Simon L. Nielsen wrote:
On 2006.11.11 21:12:09 +0200, Dmitry Pryanishnikov wrote:
I don't like the current behaviour of the net/isc-dhcp3-server port
of creating 'dhcpd' user and group using dynamic allocation instead of
having static one (as specified in /usr/ports/{U,G}IDs). I like the idea
of [ug]id ranges, and dynamic allocation doesn't keep within this idea
(ids of users and daemons get mixed). Is there specific reason why there
is no static [ug]id for net/isc-dhcp3-server?
Personally I have it precisely the other way around - I find the
static allocations rather annoying since they are bound to collide
with existing UID's at some point.
IMO the optimal solution would be to have some magic which auto
assigns ports/system UID/GID's from different ranges that normal
users.
Just so :)
UIDs below 1000 are (and have been for many years) allocated to the
system (ports/src), and are not supposed to be allocated by
administrators. This at least works out of the box with some of the
tools we have for allocating new users, so are you aware of any that
don't do this?
I know that people are not suposed to use 1000 and for normal users
and I havent seen any FreeBSD tools which uses low UID's for normal
users by default. I don't do use low UID's new systems/sites, but
sometimes you have old systems/sites where that is just not the
case. I'm certainly not saying we should bent over backwards to
support these legacy systems, I just want to point out that they do
exist. I'm really not trying to start a big debate over static
vs. dynamic UID/GID allocations, the original mail just made it sound
to me like it was a universal truth that ports should use hardcoded
UID/GID's and it was always a good thing.
And the site where I have UID/GID's in the 1000 range is called
FreeBSD.org :-) (we use UID/GID's from 500 and up).
I dunno what you are suggesting could be done on systems where the
administrators have chosen to ignore the conventions. Even supposing
the 1000 range was dynamically remapped to some other range on such
systems, what's to stop the rogue admin from allocating there too?
As I tried to say above, it quite possible we shouldn't do anything to
support this, I just wanted to point out that there are issues with
statically assigning [GU]ID's.
I have a bsd.port.mk patch in the works to create users/groups
automatically from uids/gids registered in the related files. It
wouldn't be too hard to include a UID_OFFSET/GID_OFFSET parameter so
that the local admin can reserve uids/gids in say range 2000-3000
instead of 0-1000 (which isn't really 0-1000 but I'm too lazy to check
where system uids/gids stop :-)
Would it be alright with you Simon?
That would be very neat! Of course it would require that the ports
doesn't hardcode the allocations from ports/[GU]ID. Packages are of
course still something which must be dealt with somehow (though it
wouldn't be a problem for me if UID_OFFSET/GID_OFFSET didn't work with
packages since I only use packages I build myself)...
--
Simon L. Nielsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
INDEX build failed for 4.x
INDEX build failed with errors: Generating INDEX - please wait.. Done. Warning: Duplicate INDEX entry: openoffice.org-2.0.4 Committers on the hook: ache alepulver anray clsung daichi dinoex fjoe garga gerald itetcu jkim leeym linimon maho mbr mezz miwi novel pav rafan sat stefan Most recent CVS update was: U audio/libid3tag/Makefile U audio/libmad/Makefile U audio/mad/Makefile U audio/madplay/Makefile U audio/mpiosh/Makefile U deskutils/gtweakui/Makefile U games/ssamtse/Makefile U graphics/price/Makefile U graphics/price/distinfo U net-im/gloox/Makefile U net-im/gloox/distinfo U net-im/gloox/pkg-plist U net-mgmt/netwag/Makefile U net-mgmt/netwag/distinfo U net-mgmt/nfsen/Makefile U net-mgmt/nfsen/distinfo U net-mgmt/nfsen/pkg-plist U net-mgmt/zabbix/Makefile U security/gnome-password-generator/Makefile U x11-wm/ion-3ds/Makefile U x11-wm/ion-3ds/distinfo U x11-wm/ion-3ds/pkg-plist U x11-wm/ion-3ds/files/patch-system.mk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I deal with build-time port conflicts?
On Sun, Nov 12, 2006 at 07:59:01PM +0100, Stefan Sperling wrote:
Hello,
I am updating audio/beast to version 0.7.0.
At first it didn't seem to work, it was segfaulting like crazy when run.
With the friendly help of upstream developers I was able
to track this down to a shared library problem.
The port sets LDFLAGS=-L/usr/local/lib in the environment of the
configure script, because otherwise the configure script fails to
find required libraries, like libmad, for example.
It seems that this causes the beast-0.7.0 binaries to be linked
with beast-0.6.x libraries installed in /usr/local/lib.
Deinstalling beast-0.6.x before compiling 0.7.0 solves the issue,
the application runs just fine. So a clean upgrade requires
the previous version of the port to be removed *before* the new
version is built.
Is there any way I can make sure that the previous version of the port
is not installed while building the new version? I've tried setting
CONFLICTS to beast-[0-6]*, but CONFLICTS is not checked until install
time. I need the check to be performed before anything else.
Or is the rather ugly LDFLAGS hack to blame, i.e. should I try to find
a better way to make configure pick up required libraries?
The better way is to fix the port build to not pick up the wrong
libraries, i.e. by using -L. -L${LOCALBASE}/lib to pick up the local
versions first. Note also that you shouldn't be using /usr/local/lib.
Kris
pgpcEeIi3QFEe.pgp
Description: PGP signature
Can't do a portupgrade -rf on any of my mail/courier installation
hi, Strange problem trying to run portupgrade -rf mail/courier on both current and 6.2-PRERELEASE with all ports up to date. Only one of the machines has an older courier that I tried to update and get the error so I decided I would build a package from one of the up to date installations but much to my surprise I get the same error. One of the installations I just built within the las 15 days so it would seem that it can be built but not rebuilt which makes no sense to me. All of the courier installations are working fine. This all came to light with a portupgrade -afr on one machine. Same thing with a cd /usr/ports/mail/courier; make Any suggestions appreciated. thanks, ed gmake[2]: Entering directory `/usr/ports/mail/courier/work/courier-0.53.2/maildir' Linking maildirkw /usr/local/lib/libfam.a(fam.o)(.text+0x31): In function `FAMOpen2': : undefined reference to `operator new(unsigned int)' /usr/local/lib/libfam.a(fam.o)(.text+0xb7): In function `FAMOpen2': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(fam.o)(.text+0xd0): In function `FAMOpen2': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x121): In function `FAMClose': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x34b): In function `GroupStuff::GroupStuff()': : undefined reference to `operator new[](unsigned int)' /usr/local/lib/libfam.a(fam.o)(.text+0x475): In function `FAMMonitorCollection': : undefined reference to `operator delete[](void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x483): In function `FAMMonitorCollection': : undefined reference to `operator delete[](void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x564): In function `FAMMonitor(FAMConnection*, char const*, FAMRequest*, void*, int)': : undefined reference to `operator delete[](void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x58b): In function `FAMMonitor(FAMConnection*, char const*, FAMRequest*, void*, int)': : undefined reference to `operator delete[](void*)' /usr/local/lib/libfam.a(fam.o)(.text+0x68f): In function `GroupStuff::GroupStuff()': : undefined reference to `operator new[](unsigned int)' /usr/local/lib/libfam.a(fam.o)(.eh_frame+0x12): undefined reference to `__gxx_personality_v0' /usr/local/lib/libfam.a(Client.o)(.text+0xa22): In function `Client::storeUserData(int, void*)': : undefined reference to `operator new(unsigned int)' /usr/local/lib/libfam.a(Client.o)(.text+0xa82): In function `Client::storeEndExist(int)': : undefined reference to `operator new(unsigned int)' /usr/local/lib/libfam.a(Client.o)(.text+0xe1c): In function `global constructors keyed to _ZN6ClientC2Elji': : undefined reference to `std::ios_base::Init::Init()' /usr/local/lib/libfam.a(Client.o)(.text+0xe0c): In function `__tcf_0': : undefined reference to `std::ios_base::Init::~Init()' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.r._ZTI5BTreeIibE+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.r._ZTI5BTreeIiPvE+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE4NodeD1Ev+0x32): In function `BTreeint, void*::Node::~Node()': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvED1Ev+0x29): In function `BTreeint, void*::~BTree()': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvED0Ev+0x31): In function `BTreeint, void*::~BTree()': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvED0Ev+0x1f): In function `BTreeint, void*::~BTree()': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvED0Ev+0x42): In function `BTreeint, void*::~BTree()': : undefined reference to `operator delete(void*)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIibE4NodeD1Ev+0x32): more undefined references to `operator delete(void*)' follow /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE6insertEPNS1_4NodeERKiRKS0_+0xf6): In function `BTreeint, void*::insert(BTreeint, void*::Node*, int const, void* const)': : undefined reference to `operator new(unsigned int)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE6insertEPNS1_4NodeERKiRKS0_+0x17b): In function `BTreeint, void*::insert(BTreeint, void*::Node*, int const, void* const)': : undefined reference to `operator new(unsigned int)' /usr/local/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE6insertEPNS1_4NodeERKiRKS0_+0x1be): In function `BTreeint, void*::insert(BTreeint, void*::Node*, int const, void* const)': : undefined reference to `operator new(unsigned int)'
bug assumes in FreeBSD Port: apache-2.2.3
hi clement, platform: FreeBSD 6.2-BETA2 amd64 apache 2.2.3 When restarting the httpd process with either /usr/local/etc/rc.d/apache22 graceful or apachectl graceful, httpd actually spawns a new process without stopping the existing. replication: repeat the above. regards, Niek ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't do a portupgrade -rf on any of my mail/courier installation
On Sunday 12 November 2006 22:05, [EMAIL PROTECTED] wrote: hi, Strange problem trying to run portupgrade -rf mail/courier on both current and 6.2-PRERELEASE with all ports up to date. Only one of the machines has an older courier that I tried to update and get the error so I decided I would build a package from one of the up to date installations but much to my surprise I get the same error. One of the installations I just built within the las 15 days so it would seem that it can be built but not rebuilt which makes no sense to me. All of the courier installations are working fine. This all came to light with a portupgrade -afr on one machine. Same thing with a cd /usr/ports/mail/courier; make Any suggestions appreciated. thanks, ed This seems to be an issue with either fam or gamin as currently present in ports tree. I do not understand everything in detail, one does not link (just as you showed), the second one builds but does not run (imapd dumps core, so no usable imap server). If someone with more fam/gamin knowledge could help here, it would be great. As a temporary workaround, you could comment out line in Makefile telling WITH_FAM= YES (or something similar is there) and be just fine, loosing ENHANCED IDLE support, however. You could even update this way to 0.53.3, by the way. I did not try to put this update into PR yet exactly due this fam/gamin issue. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
bug assumed in FreeBSD Port: apache-2.2.3
Please note that I am using mod_proxy_ajp and that I notice many keepalive statuses in Tomcats' jk-8009 service. Perhaps (I just thought) that is the cause of the httpd processes that stay around. hi clement, platform: FreeBSD 6.2-BETA2 amd64 apache 2.2.3 When restarting the httpd process with either /usr/local/etc/rc.d/apache22 graceful or apachectl graceful, httpd actually spawns a new process without stopping the existing. replication: repeat the above. regards, Niek ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't do a portupgrade -rf on any of my mail/courier installation
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: Quoting Milan Obuch [EMAIL PROTECTED]: On Sunday 12 November 2006 22:05, [EMAIL PROTECTED] wrote: hi, Strange problem trying to run portupgrade -rf mail/courier on both current and 6.2-PRERELEASE with all ports up to date. Only one of the machines has an older courier that I tried to update and get the error so I decided I would build a package from one of the up to date installations but much to my surprise I get the same error. One of the installations I just built within the las 15 days so it would seem that it can be built but not rebuilt which makes no sense to me. All of the courier installations are working fine. This all came to light with a portupgrade -afr on one machine. Same thing with a cd /usr/ports/mail/courier; make Any suggestions appreciated. thanks, ed This seems to be an issue with either fam or gamin as currently present in ports tree. I do not understand everything in detail, one does not link (just as you showed), the second one builds but does not run (imapd dumps core, so no usable imap server). If someone with more fam/gamin knowledge could help here, it would be great. As a temporary workaround, you could comment out line in Makefile telling WITH_FAM= YES (or something similar is there) and be just fine, loosing ENHANCED IDLE support, however. You could even update this way to 0.53.3, by the way. I did not try to put this update into PR yet exactly due this fam/gamin issue. Regards, Milan Hi, Milan, The strange thing is that I built a new courier on Nov. 2. I installed it fine without having fam but it built gamin but then I had problems with courier until I built and installed fam and after that all was well. I didn't change anything else. From what you are saying and from the experience that I had, I would assume that what you suggest is basically what I did. That just might be worth a try but it seems a bit weird. Commenting out WITH_FAM= YES nor setting it to no didn't get the desired results. It still tried to build fam and died at the same place. Tomorrow, if I have time, I'll uninstall fam and try to rebuild the way I did on my last installation. ed Thanks for the reply. As always your help is invaluable. You've really got the freebsd courier port down. ed ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap mirrors not being updated (?)
martinko wrote: I've seen the following for around last two days: Looking up portsnap.FreeBSD.org mirrors... 2 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Latest snapshot on server matches what we already have. No updates needed. Is something going on with portsnap's mirror building ? Two problems happened almost simultaneously, actually: 1. Due to some chaos surrounding the relocation of the main FreeBSD.org cluster, the portsnap builds stopped for about 20 hours. They're running again now, but will probably stop on Monday as the FreeBSD.org cluster continues its relocation. (On the positive side, nobody can commit to the ports tree while the cluster is in transit, so portsnap users won't be missing anything at this point.) 2. One of the portsnap mirrors, portsnap1.freebsd.org, is not updating at the moment; I've sent an email to the administrator of this server asking him to investigate. Until it starts updating again (most likely a matter of hours), you can force portsnap to use the other mirror: # portsnap -s portsnap2.freebsd.org fetch Colin Percival ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
latest openoffice-2-devel does not compile on amd64
Hi, I think the topic says it all... [EMAIL PROTECTED] openoffice.org-2-devel make -DBATCH -DWITHOUT_GNOMEVFS [...] -- Making: ../../../../unxfbsdx.pro/slo/sw_exctools.obj g++41 -fmessage-length=0 -c -Os -fno-strict-aliasing -I. -I../../../../unxfbsdx.pro/inc/sw_excel -I../inc -I../../../../inc/pch -I../../../../inc -I../../../../inc/bf_sw -I../../../../unx/inc -I../../../../unxfbsdx.pro/inc -I. -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solver/680/unxfbsdx.pro/inc/stl -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solver/680/unxfbsdx.pro/inc/external -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solver/680/unxfbsdx.pro/inc -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solenv/unxfbsdx/inc -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solenv/inc -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/res -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solver/680/unxfbsdx.pro/inc/stl -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solenv/inc/Xp31 -I/u sr/local/jdk1.5.0/include -I/usr/local/jdk1.5.0/include/freebsd -I/usr/local/jdk1.5.0/include/bsd -I/usr/local/jdk1.5.0/include/linux -I/usr/local/jdk1.5.0/include/native_threads/include -I/usr/X11R6/include -I/mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/solver/680/unxfbsdx.pro/inc/offuh -I. -I../../../../res -I. -pipe -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -DCVER=C341 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=450 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/local/lib/gcc-4.1.2/include/c++ -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSRC680=SRC680 -DNUM_RELSPACE -DVERTICAL_LAYOUT -DACCESSIBLE_LAYOUT -DBIDI -DSHAREDLIB -D_DLL_ -DMULTITHREAD -DEXCEPTIONS_OFF -fno-exceptions -o ../ ../../../unxfbsdx.pro/slo/sw_exctools.o /mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/binfilter/bf_sw/source/filter/excel/sw_exctools.cxx /mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/binfilter/bf_sw/source/filter/excel/sw_exctools.cxx:36: warning: ignoring #pragma hdrstop ../../../../inc/bf_sw/doc.hxx:1287: warning: unused parameter 'rSrcFmt' ../../../../inc/bf_sw/doc.hxx:1287: warning: unused parameter 'rDestFmt' ../../../../inc/bf_sw/doc.hxx:1291: warning: unused parameter 'rSrcFmt' ../../../../inc/bf_sw/doc.hxx:1291: warning: unused parameter 'rDestFmt' ../../../../inc/bf_sw/doc.hxx:1440: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1440: warning: unused parameter 'nCnt' ../../../../inc/bf_sw/doc.hxx:1440: warning: unused parameter 'bBehind' ../../../../inc/bf_sw/doc.hxx:1442: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1442: warning: unused parameter 'nCnt' ../../../../inc/bf_sw/doc.hxx:1442: warning: unused parameter 'bBehind' ../../../../inc/bf_sw/doc.hxx:1444: warning: unused parameter 'rBoxes' ../../../../inc/bf_sw/doc.hxx:1445: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1446: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1451: warning: unused parameter 'rPam' ../../../../inc/bf_sw/doc.hxx:1458: warning: unused parameter 'rTab' ../../../../inc/bf_sw/doc.hxx:1458: warning: unused parameter 'rNew' ../../../../inc/bf_sw/doc.hxx:1458: warning: unused parameter 'rOld' ../../../../inc/bf_sw/doc.hxx:1458: warning: unused parameter 'pStart' ../../../../inc/bf_sw/doc.hxx:1458: warning: unused parameter 'bCurRowOnly' ../../../../inc/bf_sw/doc.hxx:1460: warning: unused parameter 'rTable' ../../../../inc/bf_sw/doc.hxx:1460: warning: unused parameter 'bSet' ../../../../inc/bf_sw/doc.hxx:1462: warning: unused parameter 'rBoxes' ../../../../inc/bf_sw/doc.hxx:1462: warning: unused parameter 'rNew' ../../../../inc/bf_sw/doc.hxx:1471: warning: unused parameter 'rBox' ../../../../inc/bf_sw/doc.hxx:1471: warning: unused parameter 'rSet' ../../../../inc/bf_sw/doc.hxx:1670: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1670: warning: unused parameter 'rSet' ../../../../inc/bf_sw/doc.hxx:1672: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1672: warning: unused parameter 'rNew' ../../../../inc/bf_sw/doc.hxx:1673: warning: unused parameter 'rCursor' ../../../../inc/bf_sw/doc.hxx:1673: warning: unused parameter 'rToFill' /mnt/movies/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m193/binfilter/bf_sw/source/filter/excel/sw_exctools.cxx: In member function 'void binfilter::XF_Buffer::CreateItemSets(UINT16)':
INDEX build failed for 4.x
INDEX build failed with errors: Generating INDEX - please wait.. Done. Warning: Duplicate INDEX entry: openoffice.org-2.0.4 Committers on the hook: ache ale alepulver alexbl anray clsung daichi dinoex fjoe garga gerald ijliao itetcu jkim kuriyama leeym linimon maho marcus markus mbr mezz miwi novel obraun oliver pav rafan sat sem stefan Most recent CVS update was: U audio/ncmpc/files/patch-po-ru.po U devel/p5-Module-Build-Convert/Makefile U devel/p5-Module-Build-Convert/distinfo U devel/uppaal/Makefile U editors/poedit/Makefile U editors/poedit/distinfo U misc/tellico/Makefile U misc/tellico/distinfo U multimedia/tunapie/Makefile U multimedia/tunapie/distinfo U multimedia/tunapie/pkg-plist U multimedia/tunapie/files/patch-install.sh U textproc/p5-Lingua-Ident/Makefile U textproc/p5-Lingua-Ident/distinfo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
