Re: libreoffice-3.4.3 fails to upgrade
## Leslie Jensen (les...@eskk.nu): checking for dbopen in -ldb4... no checking for __db185_open in -ldb4... no configure: error: db not installed or functional Looks as if you need to install one of databases/db[45]*. At a quick glance through configure, I guess one of db41, db5, db48 or db47 will do. Regards, Christoph -- Spare Space ___ 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: Maintainership of py-zopetesting and py-zopeevent
Doug Barton wrote on 06.09.2011 04:38: On 09/05/2011 16:35, wen heping wrote: Would you send a PR of repocopy to rename these ports? My understanding is that we don't do port names with . in them. Can someone who knows more than I confirm one way or the other? Doug, Mark, here is my point why there is nothing actually criminal: a) porters handbook doesn't discourages dot usage in port names (but it suggest to use PREFIX and POSTFIX for the cases where port name contains `-` in it). b) we already have plenty of portnames with dot in them: [rm@smeshariki3 www] find /usr/ports -type d -depth 2 -name *.* -print | wc -l 105 c) it's not convenient to maintain ports with some (compeletely unnecessary) parts of them tweaked. as for now, DISTNAME, PYDISTUTILS_PKGNAME should be changed to avoid the dots and to make this ports actually work. Please see this list: http://pypi.python.org/pypi?%3Aaction=searchterm=zopesubmit=search It's a lot of work to change some Makefile parts for all of them if we ever decide to port them all. d) while working on that, i erroneously ported already existing deps just because i wasn't able to find it, and this is something terrible that i really angry of. How would one decide which deps is needed to one port or another? He will consult the port docs, offsite requirements, may be check the code itself. So, for example, i want to port some code that depends on zope.proxy (just that, as it may be founded in distribution's setup.py and all the docs), so what should i (the user) do? `make search name=zope.proxy`. Oh, nothing there, so it seems i should port it too (OR - so it seems we lacking some dependency so i'm lazy to go with it and port it too). How could i know that somebody decides to name it zopeproxy just to avoid some dots in the name? I think that principle of least surprise should be there for such cases, otherwise user just can't find the port that they need. I believe that all of this is reasonable enough to pass some new dots to the tree, isn't it? -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: Maintainership of py-zopetesting and py-zopeevent
On 09/06/2011 00:19, Ruslan Mahmatkhanov wrote: we already have plenty of portnames with dot in them That's not a good reason to add more. I did read the rest of your post, and while I sympathize with your arguments, I'm not convinced by them. The good news for you however is that I'm not in charge of anything. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Maintainership of py-zopetesting and py-zopeevent
Doug Barton wrote on 06.09.2011 11:24: On 09/06/2011 00:19, Ruslan Mahmatkhanov wrote: we already have plenty of portnames with dot in them That's not a good reason to add more. I did read the rest of your post, and while I sympathize with your arguments, I'm not convinced by them. The good news for you however is that I'm not in charge of anything. :) Doug Ok, assume, you are developer :). And you ship some app on your website (we name it portmaster). And you implement plugin framework for it, and release the first plugin that you name portmaster-plugin.do-the-best (i know it's rather stupid name, but it's an example), that will allow to user successfully build any port (even if it broken on that user's arch, and even if it not exists yet) without any problems. And you just announce it on the offsite: Please install that portmaster-plugin.do-the-best and you will forget about all the problems you expected earlier days. And there is some kind soul that added it to ports tree with name portmaster-plug-in_dothebest, since he decide that it's better than original name and some unnecessary dots and spaces is avoided too. User just can't find it in the tree and will continue crying on the ports@ that FreeBSD ports is such unprofessional and unconvinient :) -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: sysutils/cfs
On Mon, 5 Sep 2011 21:02:14 +0300 Kostik Belousov kostik...@gmail.com wrote: Second, I personally consider the crusade to remove old but compiling and working (*) ports as a damage both to the project functionality and to the project reputation. I find this whole discussion rather strange. You use the highly loaded term crusade and someone else refers to drive by ports shootings and yet you claim it is the FreeBSD ports developers who are being immature and unprofessional. I am a happy user of FreeBSD and have been for years. I currently have 1341 ports installed. From time to time that brings difficulties, but I know from experience that they will be resolved pretty quickly. I follow the ports mailing list and read /usr/ports/UPDATING. If I am using a port that is no longer being maintained and is known to have vulnerabilities or potentially data-destroying bugs, I would much prefer to know about that and, if necessary, move to another port that provides equivalent functionality, even if that means I have to learn another set of options, configurations etc. I do not want abandoned and broken software on my computer so having them removed from ports (or put into the attic) seems to me exactly right - it pushes me to learn some other program that will do the same thing more securely or more correctly. How can that be a bad thing? The irresponsible thing surely would be to leave everything in ports and wonder why FreeBSD got a reputation for supporting broken or vulnerable software. I use FreeBSD because it is so stable and does what I need it to do. Paradoxically, that stability requires constant change. Of course I understand the concern about release users who might be faced with a surprise when they upgrade. But for such users I guess upgrading is a big deal anyway and they would presumably research the impact of the move before jumping to a newer version. I suppose, for what it's worth, I just wanted to offer a different point of view from the rather negative posts I've read recently. I see the work being done to clean up the ports tree as necessary in the short term and very beneficial in the longer term. Best, Tony ___ 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
libreoffice-3.4.3 fails to upgrade
... checking which db to use... external checking for db41/db.h... no checking for db41/db.h... no checking for db-5.0/db.h... no checking for db5.0/db.h... no checking for db-5/db.h... no checking for db5/db.h... no checking for db-4.8/db.h... no checking for db4.8/db.h... no checking for db-4.7/db.h... no checking for db4.7/db.h... no checking for db-4/db.h... no checking for db4/db.h... yes checking whether db is at least 4.1... configure: error: no. you need at least db 4.1 === Script configure failed unexpectedly. Please report the problem to off...@freebsd.org [maintainer] and attach the /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/editors/libreoffice. *** Error code 1 Stop in /usr/ports/editors/libreoffice. === make failed for editors/libreoffice === Aborting update === You can restart from the point of failure with this command line: portmaster flags editors/libreoffice [root@timbsd ~]# pkg_info | grep db apr-devrandom-gdbm-db42-ldap24-mysql55-1.4.5.1.3.12 Apache Portability Library db4-4.0.14_1,1 The Berkeley DB package, revision 4 db42-4.2.52_5 The Berkeley DB package, revision 4.2 dbus-1.4.6 A message bus system for inter-application communication dbus-glib-0.88 GLib bindings for the D-BUS messaging system deadbeef-0.4.4_2DeaDBeeF is an audio player eggdbus-0.6_1 D-Bus bindings for GObject gdbm-1.8.3_3The GNU database manager libcddb-1.3.2_1 A library to access data on a CDDB server mdbtools-0.5_14 Utilities and libraries to export data from MS Access datab php5-odbc-5.3.8 The odbc shared extension for php py27-dbus-0.83.2Python bindings for the D-BUS messaging system tdb-1.2.9,1 Trivial Database xcmsdb-1.0.2Device Color Characterization utility for X xrdb-1.0.6_1X server resource database utility ___ 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
HEADS UP --- Update to x11-toolkits/fltk coming
Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpljO6anW6rM.pgp Description: PGP signature
Re: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This is needed science/vis5d+. graphics/qslim has no maintainer. c++ -c -O2 -pipe -DMIX_ANSI_IOSTREAMS -fpermissive -fPIC -I/usr/local/include -DHAVE_BOOL -fno-strict-aliasing MxStdGUI.cxx MxStdGUI.cxx:18:32: error: FL/fl_file_chooser.H: No such file or directory In file included from MxAsp.h:17, from MxStdGUI.h:20, from MxStdGUI.cxx:14: MxDynBlock.h: In member function 'void MxDynBlockT::room_for(int)': MxDynBlock.h:38: warning: there are no arguments to 'resize' that depend on a template parameter, so a declaration of 'resize' must be available MxDynBlock.h: In member function 'typename MxBlockT::iterator MxDynBlockT::end()': MxDynBlock.h:65: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available MxDynBlock.h: In member function 'typename MxBlockT::const_iterator MxDynBlockT::end() const': MxDynBlock.h:66: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available In file included from MxSMF.h:22, from MxStdGUI.cxx:16: MxStack.h: In member function 'T MxStackT::top()': MxStack.h:29: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'const T MxStackT::top() const': MxStack.h:30: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'bool MxStackT::is_empty()': MxStack.h:32: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStack.h: In member function 'T MxStackT::pop()': MxStack.h:34: warning: there are no arguments to 'drop' that depend on a template parameter, so a declaration of 'drop' must be available MxStack.h: In member function 'void MxStackT::push()': MxStack.h:44: warning: there are no arguments to 'add' that depend on a template parameter, so a declaration of 'add' must be available MxStack.h:44: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStdGUI.cxx: In member function 'virtual void MxStdGUI::cmdline_file(const char*)': MxStdGUI.cxx:89: error: 'fl_file_chooser' was not declared in this scope gmake: *** [MxStdGUI.o] Error 1 *** Error code 1 Stop in /usr/ports/graphics/qslim. wilberforce# ___ 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: libreoffice-3.4.3 fails to upgrade
On Tue, Sep 06, 2011 at 08:54:16AM +0200, Christoph Moench-Tegeder wrote: ## Leslie Jensen (les...@eskk.nu): checking for dbopen in -ldb4... no checking for __db185_open in -ldb4... no configure: error: db not installed or functional Looks as if you need to install one of databases/db[45]*. At a quick glance through configure, I guess one of db41, db5, db48 or db47 will do. Regards, Christoph in fact the configure script is patched to automatically check the version you have installed. There seems to be failures the installed version 4.4, not sure about that yet. I'm pondering to modify the USE_BDB to force 4.4+ but I need more testings regards, Bapt pgpLaeq7tAJd7.pgp Description: PGP signature
Re: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H ___ 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: libreoffice-3.4.3 fails to upgrade
Baptiste Daroussin wrote on 06.09.2011 16:09: On Tue, Sep 06, 2011 at 08:54:16AM +0200, Christoph Moench-Tegeder wrote: ## Leslie Jensen (les...@eskk.nu): checking for dbopen in -ldb4... no checking for __db185_open in -ldb4... no configure: error: db not installed or functional Looks as if you need to install one of databases/db[45]*. At a quick glance through configure, I guess one of db41, db5, db48 or db47 will do. Regards, Christoph in fact the configure script is patched to automatically check the version you have installed. There seems to be failures the installed version4.4, not sure about that yet. I'm pondering to modify the USE_BDB to force 4.4+ but I need more testings regards, Bapt It looks like it actually need 4.7+: http://development.openoffice.org/releases/3.2.1.html But i may be wrong. I just don't get if they bundle own version of bdb47. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: HEADS UP --- Update to x11-toolkits/fltk coming
On 2011-Sep-06, 06:26, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This is needed science/vis5d+. graphics/qslim has no maintainer. I have a patch for that, which you can find here: http://people.freebsd.org/~gahr/qslim-fltk.diff Thanks! c++ -c -O2 -pipe -DMIX_ANSI_IOSTREAMS -fpermissive -fPIC -I/usr/local/include -DHAVE_BOOL -fno-strict-aliasing MxStdGUI.cxx MxStdGUI.cxx:18:32: error: FL/fl_file_chooser.H: No such file or directory In file included from MxAsp.h:17, from MxStdGUI.h:20, from MxStdGUI.cxx:14: MxDynBlock.h: In member function 'void MxDynBlockT::room_for(int)': MxDynBlock.h:38: warning: there are no arguments to 'resize' that depend on a template parameter, so a declaration of 'resize' must be available MxDynBlock.h: In member function 'typename MxBlockT::iterator MxDynBlockT::end()': MxDynBlock.h:65: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available MxDynBlock.h: In member function 'typename MxBlockT::const_iterator MxDynBlockT::end() const': MxDynBlock.h:66: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available In file included from MxSMF.h:22, from MxStdGUI.cxx:16: MxStack.h: In member function 'T MxStackT::top()': MxStack.h:29: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'const T MxStackT::top() const': MxStack.h:30: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'bool MxStackT::is_empty()': MxStack.h:32: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStack.h: In member function 'T MxStackT::pop()': MxStack.h:34: warning: there are no arguments to 'drop' that depend on a template parameter, so a declaration of 'drop' must be available MxStack.h: In member function 'void MxStackT::push()': MxStack.h:44: warning: there are no arguments to 'add' that depend on a template parameter, so a declaration of 'add' must be available MxStack.h:44: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStdGUI.cxx: In member function 'virtual void MxStdGUI::cmdline_file(const char*)': MxStdGUI.cxx:89: error: 'fl_file_chooser' was not declared in this scope gmake: *** [MxStdGUI.o] Error 1 *** Error code 1 Stop in /usr/ports/graphics/qslim. wilberforce# -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpQt9P748gQK.pgp Description: PGP signature
Re: HEADS UP --- Update to x11-toolkits/fltk coming
On 2011-Sep-06, 07:28, Stephen Montgomery-Smith wrote: On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H Yes, that is correct. diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgp3hUSAckEt7.pgp Description: PGP signature
Re: libreoffice-3.4.3 fails to upgrade
Ruslan Mahmatkhanov wrote on 06.09.2011 16:30: Baptiste Daroussin wrote on 06.09.2011 16:09: On Tue, Sep 06, 2011 at 08:54:16AM +0200, Christoph Moench-Tegeder wrote: ## Leslie Jensen (les...@eskk.nu): checking for dbopen in -ldb4... no checking for __db185_open in -ldb4... no configure: error: db not installed or functional Looks as if you need to install one of databases/db[45]*. At a quick glance through configure, I guess one of db41, db5, db48 or db47 will do. Regards, Christoph in fact the configure script is patched to automatically check the version you have installed. There seems to be failures the installed version4.4, not sure about that yet. I'm pondering to modify the USE_BDB to force 4.4+ but I need more testings regards, Bapt It looks like it actually need 4.7+: http://development.openoffice.org/releases/3.2.1.html But i may be wrong. I just don't get if they bundle own version of bdb47. I forget to note that i come to this link from here :) http://listarchives.libreoffice.org/global/users/msg00988.html But i think it still relevant, since libreoffice was forked after OOo 3.2.1 if i recall correctly. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: libreoffice-3.4.3 fails to upgrade
There seems to be failures the installed version4.4, not sure about that yet. I'm pondering to modify the USE_BDB to force 4.4+ but I need more testings regards, Bapt I vote for removing --with-system-db if it adds complexity and be done with it. The extra time for testing and potential user pain doesn't worth it IMO. Regards, George ___ 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: sysutils/cfs
On 5 September 2011 22:46, Julian H. Stacey j...@berklix.com wrote: Matthias Andree mand...@freebsd.org wrote: So either Kostik, or you, or someone else steps up to maintain the port at least to the extent that the known security bugs and reported bugs get fixed, or to hell the port goes. Recent un-professional threats to throw out ports at un-necessarily short notice, with half baked assessments based on flakey challenged send-prs (viz eg all of procmail diskcheckd cfs) have been divisive, un-professional, get FreeBSD a bad name. I don't actually think they've been divisive -- it's been policy for years. The clumsy short notice threats to delete were not stopped by senior ports/ colleagues, so they're part culpable (= to blame (nod to plain English request on another thread :-)). I don't call four weeks for software with a security vulnerability short notice. We count a maintainer timeout as half that. Probably other people are afraid to criticise the ports masters especially when a ports leader accused an innocent of whining, when he (Mikhail) was just observing tech merits. For clarification, I am neither a ports master nor a leader, just a developer. Mikail is in fact a developer just like me, and in no way is he afraid of me-- we have discussed and fixed similar issues in the past, where he has kindly stepped up and worked with upstream to find a new maintainer. My problem with 'whining' (perhaps a less emotional response from me would have been better) was the sheer number of people stepping up and refusing to provide any fixes, just criticising me for wanting to remove something. It's just not constructive. FreeBSD ports is not the personal toy of the leadership, but held in trust on behalf of those who send in code fixes. Mature professionalism peer control is required. Time heads[s] rolled. Julian, you have sent some excellent patches to me in the past. You have the skills, please use them to repair the problems, or suggest an alternative bit of software. Patches gratefully received (this is a volunteer effort after all) 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
Re: libreoffice-3.4.3 fails to upgrade
On Tue, Sep 06, 2011 at 03:51:06PM +0300, George Liaskos wrote: There seems to be failures the installed version4.4, not sure about that yet. I'm pondering to modify the USE_BDB to force 4.4+ but I need more testings regards, Bapt I vote for removing --with-system-db if it adds complexity and be done with it. The extra time for testing and potential user pain doesn't worth it IMO. Regards, George Why not, no opinion on this, btw there is still bugs with icons and .desktop (wanting libreoffice34). regards, Bapt pgpR08pO2xb1f.pgp Description: PGP signature
Re: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 07:32 AM, Pietro Cerutti wrote: On 2011-Sep-06, 07:28, Stephen Montgomery-Smith wrote: On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H Yes, that is correct. Can you commit this change at the same time as you commit the fltk update? It will be easier for you to get the timing correct than it will for me. Also, gmsh and vis5d+ (other ports that I maintain) seemed to build just fine. octave also built just fine, but that's maho's port, so I will let him have the final word. Stephen ___ 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: HEADS UP --- Update to x11-toolkits/fltk coming
On 2011-Sep-06, 08:28, Stephen Montgomery-Smith wrote: On 09/06/2011 07:32 AM, Pietro Cerutti wrote: On 2011-Sep-06, 07:28, Stephen Montgomery-Smith wrote: On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H Yes, that is correct. Can you commit this change at the same time as you commit the fltk update? It will be easier for you to get the timing correct than it will for me. Sure, I will keep that patch and commit it when I update fltk. Also, gmsh and vis5d+ (other ports that I maintain) seemed to build just fine. octave also built just fine, but that's maho's port, so I will let him have the final word. Thank you very much for looking at that! -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpC6lcVGYdcS.pgp Description: PGP signature
OpenCASCADE port outdated
Hello. Port is at 6.3, but 6.5.1 is out. Is upgrading under way or planned? bye Thanks av. ___ 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: libreoffice-3.4.3 fails to upgrade
checking for dbopen in -ldb4... no checking for __db185_open in -ldb4... no configure: error: db not installed or functional === Script configure failed unexpectedly. Please report the problem to off...@freebsd.org [maintainer] and attach the /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/editors/libreoffice. *** Error code 1 Stop in /usr/ports/editors/libreoffice. === make failed for editors/libreoffice === Aborting update === Update for editors/libreoffice failed === Aborting update /Leslie This should be fixed now, thanks for reporting Bapt pgpQSo0Mnyh3m.pgp Description: PGP signature
Re: Community's opinion (Re: Re: sysutils/cfs_
Am 05.09.2011 23:43, schrieb Mikhail T.: On -10.01.-28163 14:59, Doug Barton wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. We understand that this is your perspective, however the community in general has a different idea. Well, several committers are on (recent) record agreeing with Julian and myself. Yet, the community, supposedly, feels different. Can we ask, just what that nameless community is, and how do we know its opinion? Has there been a vote? What were the results? Were they overwhelming to one side, or close? And what, exactly, are our bylaws and procedures for when there is no consensus? Thanks! Yours, If you want anyone to accept the answers, you need those who make decisions based on those answers, agree on the questions first, so that they are unbiassed, offer alternatives, and are non-interdependent. ___ 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: libreoffice-3.4.3 fails to upgrade
Baptiste Daroussin skrev 2011-09-06 17:18: This should be fixed now, thanks for reporting Bapt You're welcome :-) The upgrade was successful now. Thanks /Leslie ___ 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
HEADS UP: ca_root_nss seems to trip up OpenSSL on FreeBSD 7.3
Greetings, apparently the new /etc/ssl/cert.pem file installed by security/ca_root_nss trips up the OpenSSL 0.9.8e in the 7.3-RELEASE base system. I haven't tested 7.4, 8.1 or 8.2, 8-STABLE is unaffected by the problem. The symptom is that some certificate chains that validate properly on OpenSSL under FreeBSD 8-STABLE, fail to validate on 7.3. OpenSSL claims that the root certificate weren't trusted. Manually editing the cert.pem file to reorder Entrust certificates up front in reverse order helps according to Doug's findings, but chances are that this breaks recognition of other root certificates in exchange. This is also extremely hard to test because we can't possibly find enough sites to cover for all 150+ trust anchors that the ca_root_nss ports provides. Doug and I have been trying to debug this earlier today, to no avail yet. The current suspicion is bug in OpenSSL when reading certificate bundles, and that bug got fixed between 0.9.8e and 0.9.8q (possibly 0.9.8n) -- note though that the order of certificates in a bundle file is not supposed to make any difference. If someone has any insights, that will be much appreciated. (Doug feel free to polish this text and re-post if it turned out to be incomprehensible. ;-)) Best regards, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Yar Tikhiy yar.tik...@gmail.com wrote: By the way, the Debian folks invested certain effort in keeping cfs up to date. Their git repo is still available at http://smarden.org/git/cfs.git/ . In particular, the DoS fix can be easily obtained from the repo and placed under files/ in the port. So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and _do_ that. ___ 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: sysutils/cfs
Doug Barton do...@freebsd.org wrote: Better to deprecate such non urgent ports, wait a while after next release is rolled, to give release users a warning some time to volunteer ... That's an interesting idea, but incredibly unlikely to happen. It _certainly_ won't happen if those in charge refuse to try it! My point was that the idea is impractical. I was trying to be polite. How is it impractical to, as a rule, set an expiration date based on an anticipated future release date rather than only a month or two out from when the decision is made? (Note that this is in no way exclusive with setting FORBIDDEN, and/or making an entry in the portaudit database, immediately upon discovering a vulnerability.) My *guess* is that the largest percentage of our users are what Julian calls release users -- those who install a release and corresponding ports, and don't touch it subsequently until they become aware of a problem. They _may_ follow the security branch for their base release, but that won't make them aware of issues that have turned up in ports. For security issues we have portaudit to handle this. Provided it is installed and activated. Perhaps it should be made into a part of the ports infrastructure, or even moved into the base, so as to be present on any machine having packages installed? ___ 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: sysutils/cfs
On Wed, Sep 7, 2011 at 5:09 PM, per...@pluto.rain.com wrote: Yar Tikhiy yar.tik...@gmail.com wrote: By the way, the Debian folks invested certain effort in keeping cfs up to date. Their git repo is still available at http://smarden.org/git/cfs.git/ . In particular, the DoS fix can be easily obtained from the repo and placed under files/ in the port. So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and _do_ that. You are absolutely right mate, that will be a natural step for me to take next. I just need to ensure first that I will have long-term access to an environment to test the code in. I can't help believing that reckless commitments are no better than hasty port removals. Yar ___ 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
LDFLAGS support for bsd.port.mk and CPPFLAGS/LDFLAGS cleanup
Hi!
As CPPFLAGS support was recently added to ports ([1]) I've proposed to
add support for LDFLAGS as well ([2]). That is quite logical in terms of
consistence, and also may be useful for other purposes such as passing
LTO flags to the linker.
Since many ports set LDFLAGS via CONFIGURE_ENV, e.g.
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include LDFLAGS=-L${LOCALBASE}/lib
which will override ${LDFLAGS}, it's also required to get rid of these.
The same thing should also be done with CPPFLAGS leftovers.
For now, I've processed about 10% of ports which set CONFIGURE_ENV and I
want the community to skim through this partial patch and check if
there are any errors or something should be done differently/should
not be done. See http://people.freebsd.org/~amdmi3/ldflags.patch
Currently, changes are:
* Move CPPFLAGS/LDFLAGS overrides out of CONFIGURE_ENV:
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
appends is processed correctly, e.g.
-CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS} -I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
* Drop simple passing of CPPFLAGS/LDFLAGS to configure (since it's now
done by ports framework):
-CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS}
* Change CPPFLAGS/LDFLAGS assignments to append (to allow user to tune
these and to be consistent with CFLAGS/CXXFLAGS):
-CPPFLAGS= -I${LOCALBASE}/include
+CPPFLAGS+= -I${LOCALBASE}/include
There are also some other changes made by hand, such as moving CFLAGS
out of CONFIGURE_ENV and tuning MAKE_ENV in the same manner as
CONFIGURE_ENV, but I guess I'll do these automatically as well.
The changes are processed by a perl script, which applies fixes to
each port and then shows a diff for me to check and accept or fix
manually.
I also plan to do an additional pass to fix some other errors such
as using += in CONFIGURE_ENV (e.g. CONFIGURE_ENV=CPPFLAGS+=-I...),
which is illegal and maybe other error I run into before submitting
final version of a patch for an exp-run.
[1]
http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r1=1.673;r2=1.674
[2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/157936
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
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: sysutils/cfs
On 09/07/2011 00:07, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: Better to deprecate such non urgent ports, wait a while after next release is rolled, to give release users a warning some time to volunteer ... That's an interesting idea, but incredibly unlikely to happen. It _certainly_ won't happen if those in charge refuse to try it! My point was that the idea is impractical. I was trying to be polite. How is it impractical to, as a rule, set an expiration date based on an anticipated future release date rather than only a month or two out from when the decision is made? As has repeatedly been explained to you, you're asking the wrong question. The question is, how does it benefit the users to leave it in when we know that we're going to delete it? Either way the user will discover that the port is not easily available for installation when they update their ports tree. The difference is that in the meantime people doing work on the ports tree don't have to work around the old port (that's going to be removed anyway). The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. To answer your question more directly, start thinking through all the possible permutations of having 4 completely separate branches of FreeBSD active and supported at the same time, with releases happening several times a year. Now consider how to handle EOL branches. Then consider that FreeBSD has _never_ supported a release-branched ports tree, precisely because it's a huge amount of additional work that we don't have person-hours for. I realize that what you're proposing sounds attractive from a purely theoretical standpoint. The problem is that it increases the maintenance burden a non-trivial amount without providing any substantive benefit. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On 07.09.2011 03:09, per...@pluto.rain.com wrote: So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and_do_ that. The main topic here -- despite the subject line -- is not about the particular part, but about the conflicting opinions on when to remove ports from the tree. The fate of sysutils/cfs or any other individual port is, really, secondary to that discussion... Yar, myself, as well as other folks, who object to the on-going deprecations/removals of ports for the slightest of offenses, can fix /any/ port currently on the death-row, but we can not fix /all/ of them. Still, we would like them to remain in the tree -- unless they flat-out do not build. Yours, -mi ___ 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
