Orphaning ports
Hi, Unfortunately, I'm no longer able to maintain my ports. How do I orphan the following? - databases/akonadi-googledata - deskutils/libgcal - graphics/ipe - science/avogadro Thanks in advance! Med venlig hilsen/Best regards Troels Kofoed Jacobsen ___ 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
devel/subversion, Sponsored by
Hi, I think freebsd template is 'broken' after r314983. I haven't ORGANIZATION defined on /etc/make.conf in this case string 'Sponsored by: ' should not be displayed, right? but I have it: quote r1242 | tiger | 2013-04-11 11:19:18 +0300 (чт, 11 апр 2013) | 4 lines Import lua-libs Sponsored by: /quote -- wbr, tiger ___ 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
problems with half installed ports
Hi, Sometimes, while compiling all my ports, I encounter the following problem: Say, we are installing ports/A which depends on ports/B; the Makefile detects the dependency and goes to install ports/B; if now during the final installation process, some files are already delivered to /usr/local, some files not, the system goes down (by intention because it's time to go out), before the installation of ports/B is fully done and registered to /var/db/pkg, next time when you restart installing ports/A it often sees, because the file referenced in the Makefile was allready installed (while others not), it thinks that ports/B was installed fine and proceeds with ports/A which later (or even in some other area) gives an error due to missing files of ports/B; I think, the only solution is that the dependency is not only based on some (random) file of B, but on the fact if B was *fully* installed and registered in /var/db/pkg; comments? Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: problems with half installed ports
On 11 April 2013 11:19, Matthias Apitz g...@unixarea.de wrote: Hi, Sometimes, while compiling all my ports, I encounter the following problem: Say, we are installing ports/A which depends on ports/B; the Makefile detects the dependency and goes to install ports/B; if now during the final installation process, some files are already delivered to /usr/local, some files not, the system goes down (by intention because it's time to go out), before the installation of ports/B is fully done and registered to /var/db/pkg, next time when you restart installing ports/A it often sees, because the file referenced in the Makefile was allready installed (while others not), it thinks that ports/B was installed fine and proceeds with ports/A which later (or even in some other area) gives an error due to missing files of ports/B; I think, the only solution is that the dependency is not only based on some (random) file of B, but on the fact if B was *fully* installed and registered in /var/db/pkg; comments? Installing a port isn't atomic by definition; the larger ones have loads of files that need installed. If I read your description carefully, your solution is to simply avoid interrupting during the installation phase. 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: Orphaning ports
On 11-04-2013 08:12, Troels Kofoed Jacobsen wrote: Hi, Unfortunately, I'm no longer able to maintain my ports. How do I orphan the following? - databases/akonadi-googledata - deskutils/libgcal - graphics/ipe - science/avogadro One way is to write a mail like this one, but you might consider using send-pr (either as utility or at http://www.freebsd.org/send-pr.html ) for better archiving. I'll handle the ports. René ___ 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: problems with half installed ports
On Thu, 11 Apr 2013 11:36:54 +0100 Chris Rees articulated: Installing a port isn't atomic by definition; the larger ones have loads of files that need installed. If I read your description carefully, your solution is to simply avoid interrupting during the installation phase. Unless you happen to suffer from a catastrophic power failure and don't have a functional UPS installed. In that case, you will probably have to do a forcible uninstall of all of the affected ports and start over. pkg_delete -dfv port works for me. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: problems with half installed ports
Matthias Apitz wrote: Say, we are installing ports/A which depends on ports/B; the Makefile detects the dependency and goes to install ports/B; if now during the final installation process, some files are already delivered to /usr/local, some files not, the system goes down (by intention because it's time to go out), before the installation of ports/B is fully done and registered to /var/db/pkg, next time when you restart installing ports/A it often sees, because the file referenced in the Makefile was allready installed (while others not), it thinks that ports/B was installed fine and proceeds with ports/A which later (or even in some other area) gives an error due to missing files of ports/B; I think, the only solution is that the dependency is not only based on some (random) file of B, but on the fact if B was *fully* installed and registered in /var/db/pkg; There is a case where this will break: if multiple ports install the same file, and you don't care which of them installed it, then you need to depend on the file, not on a specific port. For example, both www/node and www/node-devel install the same binary, and dependent ports will work with either of them. Now, it's true that using files as a proxy for interchangeable ports isn't ideal, and we could do better... Anyway, the problem you're describing allows for another fix. If ports/A depends of file-B, port system could check not only that file-B exists, but if there is also a package that installed it (via 'pkg which'), and if not, install ports/B. This will of course slow down ports operations somewhat. ___ 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-freebsd] kopete-kde4 fails to build
On Wed, 10 Apr 2013 15:44 -0400 Jerry wrote: On Wed, 10 Apr 2013 11:41:03 -0700 (PDT) Anthony Jenkins articulated: Looks like the QT4-QT3 incompatibility - try uninstalling x11-toolkits/qt33 and rebuilding, then reinstalling qt33. I don't have that installed. As far as I can tell, I don't have any QT3\* ports installed. The closest I can find is qt4-qt3support-4.8.4 It is shown as a dependency of kopete-4.9.5 and a crap load of other programs. What happens if I just delete kopete-4.9.5 and then try to build the updated version? From your build log: /usr/local/include/qt4/QtCore/qbytearray.h:79: error: redefinition of 'uint qstrlen(const char*)' /usr/local/include/qcstring.h:57: error: 'uint qstrlen(const char*)' previously defined here include/qcstring.h is installed by x11-toolkits/qt33. Either you have qt3 package installed or your system polluted with leftovers. Max ___ 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-freebsd] kopete-kde4 fails to build
On Thu, 11 Apr 2013 12:22:22 + Max Brazhnikov articulated: From your build log: /usr/local/include/qt4/QtCore/qbytearray.h:79: error: redefinition of 'uint qstrlen(const char*)' /usr/local/include/qcstring.h:57: error: 'uint qstrlen(const char*)' previously defined here include/qcstring.h is installed by x11-toolkits/qt33. Either you have qt3 package installed or your system polluted with leftovers. I would vote for a seriously polluted system. When FreeBSD 10-STABLE is released, I plan to dump the entire system, reformat it from scratch and start over clean. It isn't worth the effort it takes to keep it running anymore. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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-freebsd] kopete-kde4 fails to build
El día Thursday, April 11, 2013 a las 09:02:23AM -0400, Jerry escribió: On Thu, 11 Apr 2013 12:22:22 + Max Brazhnikov articulated: From your build log: /usr/local/include/qt4/QtCore/qbytearray.h:79: error: redefinition of 'uint qstrlen(const char*)' /usr/local/include/qcstring.h:57: error: 'uint qstrlen(const char*)' previously defined here include/qcstring.h is installed by x11-toolkits/qt33. Either you have qt3 package installed or your system polluted with leftovers. I would vote for a seriously polluted system. When FreeBSD 10-STABLE is released, I plan to dump the entire system, reformat it from scratch and start over clean. It isn't worth the effort it takes to keep it running anymore. All ports installed files will go away by # rm -rf /usr/local/* # rm -rf /var/db/pkg/* # rm -rf /compat/linux/* I just did this three days ago to compile after SVN updating /usr/ports matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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-freebsd] kopete-kde4 fails to build
Date: Thu, 11 Apr 2013 09:02:23 -0400 From: Jerry je...@seibercom.net To: freebsd-ports@freebsd.org Subject: Re: [kde-freebsd] kopete-kde4 fails to build On Thu, 11 Apr 2013 12:22:22 + Max Brazhnikov articulated: From your build log: /usr/local/include/qt4/QtCore/qbytearray.h:79: error: redefinition of 'uint qstrlen(const char*)' /usr/local/include/qcstring.h:57: error: 'uint qstrlen(const char*)' previously defined here include/qcstring.h is installed by x11-toolkits/qt33. Either you have qt3 package installed or your system polluted with leftovers. I would vote for a seriously polluted system. When FreeBSD 10-STABLE is released, I plan to dump the entire system, reformat it from scratch and start over clean. It isn't worth the effort it takes to keep it running anymore. That is unacceptable in many cases. There are enough tools in the ports tree to fix such problems, such as various portmaster diagnostics, pkgng diagnostics, perl-after-upgrade, and many more. One of the major strengths of If reformatting is easier than fixing then something is seriously wrong. I don't think I ever had to reinstall the OS because of the ports problems. Anton ___ 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: problems with half installed ports
Earlier I wrote:
Anyway, the problem you're describing allows for another fix. If ports/A
depends of file-B, port system could check not only that file-B exists,
but if there is also a package that installed it (via 'pkg which'), and
if not, install ports/B. This will of course slow down ports operations
somewhat.
Here's a patch to that effect.
(Only tested with PKGNG; should work with old pkg tools, but some
tweaking may be required).
Matthias, can you try to reproduce the situation you described, and see
if it will be resolved after applying this patch?
diff -ruN Mk.orig/bsd.commands.mk Mk/bsd.commands.mk
--- Mk.orig/bsd.commands.mk 2013-03-19 11:27:52.0 +0200
+++ Mk/bsd.commands.mk 2013-04-11 14:15:49.0 +0300
@@ -128,6 +128,7 @@
PKG_CREATE?= ${PKG_BIN} create
PKG_ADD?= ${PKG_BIN} add
PKG_QUERY?=${PKG_BIN} query
+PKG_WHICH?=${PKG_BIN} which
.else
.if exists(${LOCALBASE}/sbin/pkg_info)
PKG_CMD?= ${LOCALBASE}/sbin/pkg_create
@@ -135,12 +136,14 @@
PKG_DELETE?= ${LOCALBASE}/sbin/pkg_delete
PKG_INFO?= ${LOCALBASE}/sbin/pkg_info
PKG_VERSION?= ${LOCALBASE}/sbin/pkg_version
+PKG_WHICH?=${LOCALBASE}/sbin/pkg_info -W
.else
PKG_CMD?= /usr/sbin/pkg_create
PKG_ADD?= /usr/sbin/pkg_add
PKG_DELETE?= /usr/sbin/pkg_delete
PKG_INFO?= /usr/sbin/pkg_info
PKG_VERSION?= /usr/sbin/pkg_version
+PKG_WHICH?=/usr/sbin/pkg_info -W
.endif
.endif
diff -ruN Mk.orig/bsd.port.mk Mk/bsd.port.mk
--- Mk.orig/bsd.port.mk 2013-03-30 07:31:29.0 +0200
+++ Mk/bsd.port.mk 2013-04-11 16:35:42.0 +0300
@@ -5063,6 +5063,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but
building it anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} $$prog
/dev/null; then \
+ ${ECHO_MSG}(but not
installed by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5104,6 +5107,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building it
anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} `${WHICH} $$prog`
/dev/null; then \
+ ${ECHO_MSG}(but not installed
by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5141,11 +5147,19 @@
dir=$${dir%%:*}; \
fi; \
${ECHO_MSG} -n === ${PKGNAME} depends on shared library:
$$lib; \
- if ${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR} | ${GREP} -qwE -e -l$$pattern; then \
+ libs=`${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR}`; \
+ if ${ECHO_CMD} $$libs | ${GREP} -qwE -e -l$$pattern; then \
${ECHO_MSG} - found; \
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building it anyway); \
notfound=1; \
+ elif ${ECHO_CMD} $$libs | ${GREP} -wE -e
-l$$pattern | ${SED} 's/.*= //' | \
+ while read lib; do \
+ if ${PKG_WHICH} $$lib /dev/null;
then return 1; fi; \
+ done; \
+ then \
+ ${ECHO_MSG}(but not installed by any
package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/subversion, Sponsored by
On 2013/04/11, at 1:54, Sergey V. Dyatko sergey.dya...@gmail.com wrote: Hi, I think freebsd template is 'broken' after r314983. I haven't ORGANIZATION defined on /etc/make.conf in this case string 'Sponsored by: ' should not be displayed, right? but I have it: It will be displayed but it wasn't getting removed automatically. I fixed it in r315775. Regards, -- Rui Paulo ___ 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: problems with half installed ports
On 11 Apr 2013 14:48, Vitaly Magerya vmage...@gmail.com wrote:
Earlier I wrote:
Anyway, the problem you're describing allows for another fix. If ports/A
depends of file-B, port system could check not only that file-B exists,
but if there is also a package that installed it (via 'pkg which'), and
if not, install ports/B. This will of course slow down ports operations
somewhat.
Here's a patch to that effect.
(Only tested with PKGNG; should work with old pkg tools, but some
tweaking may be required).
Matthias, can you try to reproduce the situation you described, and see
if it will be resolved after applying this patch?
diff -ruN Mk.orig/bsd.commands.mk Mk/bsd.commands.mk
--- Mk.orig/bsd.commands.mk 2013-03-19 11:27:52.0 +0200
+++ Mk/bsd.commands.mk 2013-04-11 14:15:49.0 +0300
@@ -128,6 +128,7 @@
PKG_CREATE?= ${PKG_BIN} create
PKG_ADD?= ${PKG_BIN} add
PKG_QUERY?=${PKG_BIN} query
+PKG_WHICH?=${PKG_BIN} which
.else
.if exists(${LOCALBASE}/sbin/pkg_info)
PKG_CMD?= ${LOCALBASE}/sbin/pkg_create
@@ -135,12 +136,14 @@
PKG_DELETE?= ${LOCALBASE}/sbin/pkg_delete
PKG_INFO?= ${LOCALBASE}/sbin/pkg_info
PKG_VERSION?= ${LOCALBASE}/sbin/pkg_version
+PKG_WHICH?=${LOCALBASE}/sbin/pkg_info -W
.else
PKG_CMD?= /usr/sbin/pkg_create
PKG_ADD?= /usr/sbin/pkg_add
PKG_DELETE?= /usr/sbin/pkg_delete
PKG_INFO?= /usr/sbin/pkg_info
PKG_VERSION?= /usr/sbin/pkg_version
+PKG_WHICH?=/usr/sbin/pkg_info -W
.endif
.endif
diff -ruN Mk.orig/bsd.port.mk Mk/bsd.port.mk
--- Mk.orig/bsd.port.mk 2013-03-30 07:31:29.0 +0200
+++ Mk/bsd.port.mk 2013-04-11 16:35:42.0 +0300
@@ -5063,6 +5063,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ];
then \
${ECHO_MSG}(but
building it anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} $$prog
/dev/null; then \
+ ${ECHO_MSG}(but
not installed by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5104,6 +5107,9 @@
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building
it anyway); \
notfound=1; \
+ elif ! ${PKG_WHICH} `${WHICH} $$prog`
/dev/null; then \
+ ${ECHO_MSG}(but not
installed by any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
@@ -5141,11 +5147,19 @@
dir=$${dir%%:*}; \
fi; \
${ECHO_MSG} -n === ${PKGNAME} depends on shared
library: $$lib; \
- if ${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR} | ${GREP} -qwE -e -l$$pattern; then \
+ libs=`${LDCONFIG} ${_LDCONFIG_FLAGS} -r | ${GREP} -vwF -e
${PKGCOMPATDIR}`; \
+ if ${ECHO_CMD} $$libs | ${GREP} -qwE -e -l$$pattern;
then \
${ECHO_MSG} - found; \
if [ ${_DEPEND_ALWAYS} = 1 ]; then \
${ECHO_MSG}(but building it
anyway); \
notfound=1; \
+ elif ${ECHO_CMD} $$libs | ${GREP} -wE -e
-l$$pattern | ${SED} 's/.*= //' | \
+ while read lib; do \
+ if ${PKG_WHICH} $$lib
/dev/null; then return 1; fi; \
+ done; \
+ then \
+ ${ECHO_MSG}(but not installed by
any package); \
+ notfound=1; \
else \
notfound=0; \
fi; \
No thanks.
Ports should be happy to use files whether they're installed by ports or
not.
Just don't interrupt installs, and you'll be OK!
Stagedir will fix this problem correctly once it's implemented.
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
FTP packages missing CHECKSUM.MD5
Noticed that at least ports/i386/packages-9-stable is missing its CHECKSUM.MD5 file. Of course people shouldn't use it for what they think it's for, because it's not signed and uses a broken hash function. Hopefully that will be updated to signed sha1/256/3 before long. However it does make for a good 'TIMESTAMP' file to detect when new packages appear. Ftp's internal or external 'ls -tT' can't be counted on for this across mirrors because such options to ls are mirror dependant. And there's no simple way to locally sort the ftp list output by date without rigging in perl, etc. And an overwrite of the same file may not stamp the parent directory, which also doesn't appear reliably '.' while in the current directory. In short, I'd suggest making a formal TIMESTAMP file for when package updates are pushed out so people can key off that instead. ___ 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
patching lang/lua52 to honor Mk/bsd.lua.mk
Hi, I've made a slightly big set of patch[0] across several ports. I think that submitting PR's for individual ports obscure the overview. I want someone to coordinate this. Thanks in advance. The patch consists of five parts: - modify lang/lua52 and Mk/bsd.lua.mk to make use of ``USE_LUA=5.2''. The rest part of the patch is a trial to make components available. - check build against lua52 and add extra-patches when required; devel/lua-alien, devel/lua-gettext, devel/lua-pty, and net/luasocket. Slave ports prefixed with ``lua52-'' may be needed. - add new port devel/luaposix[1], which the author of devel/lua-posix says to be the successor[2]. - update lang/tolua to the version said to work with lua 5.2, and name it lang/tolua52[3]. - bring back lang/ruby-lua with patch to make it build with ruby 1.9, because it still remains in Mk/bsd.lua.mk. The patch is against r277024[4], but created a shell archive[5], too. [0] https://gist.github.com/5365055#file-lua52-patch [1] https://gist.github.com/5365055#file-devel_luaposix-shar [2] http://luaforge.net/projects/lposix/ [3] https://gist.github.com/5365055#file-lang_tolua52-shar [4] http://svnweb.freebsd.org/ports/head/lang/ruby-lua/?pathrev=277024 [5] https://gist.github.com/5365055#file-lang_ruby-lua-shar Regards, -- end Hirohisa Yamaguchi umq@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FTP packages missing CHECKSUM.MD5
Hey, Thanks for your report I will take care of that. On Apr 12, 2013, at 2:15 AM, grarpamp grarp...@gmail.com wrote: Noticed that at least ports/i386/packages-9-stable is missing its CHECKSUM.MD5 file. Of course people shouldn't use it for what they think it's for, because it's not signed and uses a broken hash function. Hopefully that will be updated to signed sha1/256/3 before long. However it does make for a good 'TIMESTAMP' file to detect when new packages appear. Ftp's internal or external 'ls -tT' can't be counted on for this across mirrors because such options to ls are mirror dependant. And there's no simple way to locally sort the ftp list output by date without rigging in perl, etc. And an overwrite of the same file may not stamp the parent directory, which also doesn't appear reliably '.' while in the current directory. In short, I'd suggest making a formal TIMESTAMP file for when package updates are pushed out so people can key off that instead. ___ 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 +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest ___ 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
