Re: ports/158348: mail/thunderbird build error
Ruslan Mahmatkhanov wrote on 17.09.2011 10:02: Janos Dohanics wrote on 17.09.2011 03:57: 1 out of 1 hunks failed--saving rejects to mailnews/extensions/smime/build/Makefile.in.rej By the way, it looks like some stale patch file is a culprit: This file - patch-mailnews-extensions-smime-build-Makefile.in in /usr/ports/mail/thunderbird was removed some time ago, and it should be ^^^ in /usr/ports/mail/thunderbird/files. Sorry (. removed automatically when updating ports tree. How do you update your ports tree? You can try to manually remove this patch and try to build again. -- 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: ports/158348: mail/thunderbird build error
Janos Dohanics wrote on 17.09.2011 03:57: 1 out of 1 hunks failed--saving rejects to mailnews/extensions/smime/build/Makefile.in.rej By the way, it looks like some stale patch file is a culprit: This file - patch-mailnews-extensions-smime-build-Makefile.in in /usr/ports/mail/thunderbird was removed some time ago, and it should be removed automatically when updating ports tree. How do you update your ports tree? You can try to manually remove this patch and try to build again. -- 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: ports/158348: mail/thunderbird build error
Janos Dohanics wrote on 17.09.2011 03:57: On Fri, 09 Sep 2011 14:20:20 +0400 Ruslan Mahmatkhanov wrote: Hi Janos, does this bug report still valid? Are you able to reproduce this with current ports tree and current thunderbird versions in ports (6.0.2 and 3.1.14)? -- Regards, Ruslan Tinderboxing kills... the drives. Ruslan, my apologies for the belated reply - I thought I have unsubscribed myself from the ports mailing list. However, your message is really timely... Although I have been able to build thunderbird-5.0 some time ago, when I try to upgrade to thunderbird-6.0.2, I get this error: ---> Build of mail/thunderbird started at: Fri, 16 Sep 2011 07:26:52 -0400 ---> Building '/usr/ports/mail/thunderbird' ===> Cleaning for thunderbird-6.0.2 ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for thunderbird-6.0.2 ===> Extracting for thunderbird-6.0.2 => SHA256 Checksum OK for thunderbird-6.0.2.source.tar.bz2. ===>thunderbird-6.0.2 depends on file: /usr/local/bin/perl5.10.1 - found ===> Patching for thunderbird-6.0.2 ===>thunderbird-6.0.2 depends on file: /usr/local/bin/perl5.10.1 - found ===> Applying FreeBSD patches for thunderbird-6.0.2 1 out of 1 hunks failed--saving rejects to mailnews/extensions/smime/build/Makefile.in.rej => Patch patch-mailnews-extensions-smime-build-Makefile-in failed to apply cleanly. => Patch(es) patch-calendar-base-src-calDateTime.cpp patch-calendar-lightning-install.rdf patch-config-autoconf.mk.in patch-configure.in patch-ipc-chromium-src-base-atomicops_internals_mutex.cc patch-ipc-chromium-src-base-file_util.h patch-ipc-chromium-src-base-file_util_linux.cc patch-ipc-chromium-src-base-file_util_posix.cc patch-ipc-chromium-src-base-platform_file_posix.cc patch-ipc-chromium-src-base-platform_thread_posix.cc patch-ipc-chromium-src-base-third_party-nspr-prcpucfg.h patch-ipc-chromium-src-build-build_config.h patch-ldap-sdks-c-sdk-ldap-libraries-libldap-Makefile.in patch-ldap-sdks-c-sdk-ldap-libraries-libprldap-Makefile.in applied cleanly. *** Error code 1 Stop in /usr/ports/mail/thunderbird. *** Error code 1 Stop in /usr/ports/mail/thunderbird. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20110916-20994-g0kqdj-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=thunderbird-5.0 UPGRADE_PORT_VER=5.0 make ** Fix the problem and try again. Looking into Makefile.in.rej: *** *** 81,87 $(NULL) ifndef MOZ_STATIC_MAIL_BUILD - SHARED_LIBRARY_LIBS + = ../../../base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX) endif ifdef MOZILLA_INTERNAL_API --- 81,87 $(NULL) ifndef MOZ_STATIC_MAIL_BUILD + SHARED_LIBRARY_LIBS += ../../../base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX) endif ifdef MOZILLA_INTERNAL_API # uname -mrs FreeBSD 8.2-STABLE amd64 Thank you for keeping track of this, Good day, Janos. Please make sure that you have latest portstree. The last revision of mail/thunderbird Makefile is # $FreeBSD: ports/mail/thunderbird/Makefile,v 1.136 2011/09/06 20:15:18 flo Exp $ And it patches correctly for me. If the port is update, go to /usr/ports/mail/thunderbird and make `make clean`, then try to portupgrade this port again. Hope this helps. Please keep bug-follo...@freebsd.org in cc: when responding, so we can keep the current status of this problem in pr. Thanks. -- 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: Detecting dependencies
On 09/15/11 07:06, chukha...@mail.ru wrote: Hi, There have been a discussion about finding interdependencies of ports. I have a relatively simple Python script for that. There is a pr ports/160007 to add its early version. Unfortunately, I missed a reply to it, so there is an issue which I have not yet addressed... Since that time, I added reverse dependencies with full ports tree scanning (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually) to a file, so that rescanning all ports tree is not needed. See http://code.google.com/p/porttree/ If there will be interest, scanning packages interdependencies could also be added. On a related subtopic, we also need a tool that identifies implicit dependencies not captured in the ports Makefiles. I hacked the following together earlier this year to smooth over the updating process when key libraries get bumped (e.g. the gettext update at the time I wrote the script was a nightmare). There were a tonne of ports which needed to be updated even though they didn't explicitly record a dependency on gettext. https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh It's still quite rough and manually driven and is tied to portmaster at the moment, but I use it routinely after a "portmaster -ad" to check that no libs are missing dependencies. It works pretty well most of the time, but definitely needs more finessing. I share it mostly to prove the feasibility of the approach and in case anyone is curious. I haven't thought the following ideas through a great deal and welcome feedback, but I think the basic functionality/premise of this script could be integrated into the ports framework so that at package registration time, implicit deps are identified and marked in the package database. A warning could also be generated that the port is using deps not identified in the Makefile, and perhaps trigger a send-pr to the port maintainer to let them know. That way when we update ports using a tool like portmaster, it will know to update all the relevant ports and avoid leaving your system broken (yes, I'm aware of the -w switch, but I prefer not to use it as you can get into nasty situations if the compat and non-compat libs get mixed at run-time). A script like this could also be integrated/called somehow from a tool like portmaster during an update to ensure ports with implicit dependencies on another port which has been updated are identified and recompiled too so that we avoid the nasty problems that crop up with missing library dependencies. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/158348: mail/thunderbird build error
On Fri, 09 Sep 2011 14:20:20 +0400 Ruslan Mahmatkhanov wrote: > > Hi Janos, > > does this bug report still valid? Are you able to reproduce this with > current ports tree and current thunderbird versions in ports (6.0.2 > and 3.1.14)? > > -- > Regards, > Ruslan > > Tinderboxing kills... the drives. Ruslan, my apologies for the belated reply - I thought I have unsubscribed myself from the ports mailing list. However, your message is really timely... Although I have been able to build thunderbird-5.0 some time ago, when I try to upgrade to thunderbird-6.0.2, I get this error: ---> Build of mail/thunderbird started at: Fri, 16 Sep 2011 07:26:52 -0400 ---> Building '/usr/ports/mail/thunderbird' ===> Cleaning for thunderbird-6.0.2 ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for thunderbird-6.0.2 ===> Extracting for thunderbird-6.0.2 => SHA256 Checksum OK for thunderbird-6.0.2.source.tar.bz2. ===> thunderbird-6.0.2 depends on file: /usr/local/bin/perl5.10.1 - found ===> Patching for thunderbird-6.0.2 ===> thunderbird-6.0.2 depends on file: /usr/local/bin/perl5.10.1 - found ===> Applying FreeBSD patches for thunderbird-6.0.2 1 out of 1 hunks failed--saving rejects to mailnews/extensions/smime/build/Makefile.in.rej => Patch patch-mailnews-extensions-smime-build-Makefile-in failed to apply cleanly. => Patch(es) patch-calendar-base-src-calDateTime.cpp patch-calendar-lightning-install.rdf patch-config-autoconf.mk.in patch-configure.in patch-ipc-chromium-src-base-atomicops_internals_mutex.cc patch-ipc-chromium-src-base-file_util.h patch-ipc-chromium-src-base-file_util_linux.cc patch-ipc-chromium-src-base-file_util_posix.cc patch-ipc-chromium-src-base-platform_file_posix.cc patch-ipc-chromium-src-base-platform_thread_posix.cc patch-ipc-chromium-src-base-third_party-nspr-prcpucfg.h patch-ipc-chromium-src-build-build_config.h patch-ldap-sdks-c-sdk-ldap-libraries-libldap-Makefile.in patch-ldap-sdks-c-sdk-ldap-libraries-libprldap-Makefile.in applied cleanly. *** Error code 1 Stop in /usr/ports/mail/thunderbird. *** Error code 1 Stop in /usr/ports/mail/thunderbird. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20110916-20994-g0kqdj-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=thunderbird-5.0 UPGRADE_PORT_VER=5.0 make ** Fix the problem and try again. Looking into Makefile.in.rej: *** *** 81,87 $(NULL) ifndef MOZ_STATIC_MAIL_BUILD - SHARED_LIBRARY_LIBS + = ../../../base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX) endif ifdef MOZILLA_INTERNAL_API --- 81,87 $(NULL) ifndef MOZ_STATIC_MAIL_BUILD + SHARED_LIBRARY_LIBS += ../../../base/util/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX) endif ifdef MOZILLA_INTERNAL_API # uname -mrs FreeBSD 8.2-STABLE amd64 Thank you for keeping track of this, -- Janos Dohanics ___ 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: KDE4 - Hellhole of conflicts
On Fri, Sep 16, 2011 at 10:23 PM, Lars Eighner wrote: > Just saying. > > No really, what to do about the kdelibs4 kdebase4-runtime conflict? 1. can you please write to k...@freebsd.org? 2. can you please actually say something about the problem? -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla ___ 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: Re-starting daemons across upgrades?
On 16 Sep 2011 21:16, "Gabor Kovesdan" wrote: > > On 2011.09.16. 17:51, Matthias Andree wrote: >> >> Am 16.09.2011 11:51, schrieb Lev Serebryakov: >>> >>> Hello, Freebsd-ports. >>> You wrote 16 сентября 2011 г., 0:28:07: >>> > Really? I thought it was supposed to be standard behaviour- the @stopdaemon > line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. >>> >>> Yep, and even more annoyingly is that it is completely inconsistent: >>> some daemons are stopped, some not, etc. >> >> We do not currently have a standard procedure for that, nor do we record >> the necessary state -- perhaps we should just discuss, vote, and add a >> paragraph to the porter's handbook. >> >> We also need to bring the authors (or volunteers) for the de-facto >> standard upgrade tools into the loop. >> >> My thoughts: >> >> - give the user a choice to configure whether to restart services >> >> - optional: give the users a chance to configure this per-service >> >> - discuss whether we want/need to support this (a) in the framework that >> we currently use, (b) only in pkgng, (c) in portmaster and portupgrade >> where necessary. > > Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: > > #!/bin/sh > PID_FILE="/var/db/mysql/server.mypc.hu.pid" > PID=`cat $PID_FILE` > EXECUTABLE="/usr/local/etc/rc.d/mysql-server start" > > if test -r $PID_FILE ; then ># pidfile exist, is it correct? >if kill -CHLD $PID >/dev/null 2>&1; then ># ok, exit silently >exit 0 >fi >rm -f $PID_FILE > fi > echo "" > echo "Couldn't find the MySQL server running, retsarting.." > echo "" > $EXECUTABLE > I would prefer to parse the output of rc status, but I presume this script is more specialised. 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: Re-starting daemons across upgrades?
On 09/16/11 20:00, Gabor Kovesdan wrote: > #!/bin/sh > PID_FILE="/var/db/mysql/server.mypc.hu.pid" > PID=`cat $PID_FILE` > EXECUTABLE="/usr/local/etc/rc.d/mysql-server start" > > if test -r $PID_FILE ; then > # pidfile exist, is it correct? > if kill -CHLD $PID >/dev/null 2>&1; then > # ok, exit silently > exit 0 > fi > rm -f $PID_FILE > fi > echo "" > echo "Couldn't find the MySQL server running, retsarting.." > echo "" > $EXECUTABLE #!/bin/sh PIDS=$(/usr/bin/pgrep rsyslogd) if [ $? -eq 1 ]; then /usr/bin/killall rsyslogd 2>/dev/null /usr/local/etc/rc.d/rsyslogd start >/dev/null else exit 1 fi exit 0 -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Infrastructure,Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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"
KDE4 - Hellhole of conflicts
Just saying. No really, what to do about the kdelibs4 kdebase4-runtime conflict? -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ 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: Re-starting daemons across upgrades?
On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: #!/bin/sh PID_FILE="/var/db/mysql/server.mypc.hu.pid" PID=`cat $PID_FILE` EXECUTABLE="/usr/local/etc/rc.d/mysql-server start" if test -r $PID_FILE ; then # pidfile exist, is it correct? if kill -CHLD $PID >/dev/null 2>&1; then # ok, exit silently exit 0 fi rm -f $PID_FILE fi echo "" echo "Couldn't find the MySQL server running, retsarting.." echo "" $EXECUTABLE Gabor ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Lev Serebryakov wrote: Hello, Łukasz. You wrote 16 сентября 2011 г., 22:17:58: were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. I agree with that. It is not difficult to REstart service by hands. But stopping service is another story. Many ports/packages stop service on dinstall/pkg_delete, and as result, if port with service are upgraded in the middle of large upgrade session (and it is not always possible to upgrade services SEPARATELY, due to dependences), here is large window when old service is stopped, but new cannot be started yet. From my point of view, it is better to not stop the service by deinstall phase, if it is not started by install. If I do portmaster -a, deinstall of MySQL stops the mysql daemon and all dependent services are unavailable for a very long time - until all other packages are upgraded and administrator starts MySQL by hand. It can be hours. But I like the idea based on portupgrade AFTERINSTALL / (AFTERUPGRADE) - some kind of custom hooks, where user can define actions for specific packages / services. It can be restart in some cases, or write something to log, or send an e-mail, or print some user defined warning text about dependencies needed to be upgraded / restarted... and so on. Miroslav Lachman ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
W dniu 2011-09-16 20:25, Chris Rees pisze: > However, having services not restarted after an upgrade can leave you > with a) a vulnerable older service and b) a nasty shock when you > decide to reboot six months later and it breaks :) I know that I should restart service after update and I will do it, I promise :) But I like to do it when I'm prepared for it, not when monitoring system starts screaming about a down service ;) -- best regards, Lukasz Wasikowski ___ 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: Compilation impossible using TARGET_ARCH=i386
On 16 September 2011 13:47, Benjamin Stier wrote: > Hello everyone, > > I try to compile packages for older i386 on an amd64 machine. On the amd64 I > use a chroot into an i386-world. I then compile ports using > make ARCH=i386 TARGET_ARCH=i386 BATCH=yes install > > There are some ports where this doesn't work. Here's the list I found: > dns/adns > lang/lua > graphics/pho > graphics/xzgv > devel/cvsps > Drop the TARGET_ARCH. 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Hello, Łukasz. You wrote 16 сентября 2011 г., 22:17:58: > were not recompiled). Updating ports should never turn off or restart > service - thats my $0.02. I agree with that. It is not difficult to REstart service by hands. But stopping service is another story. Many ports/packages stop service on dinstall/pkg_delete, and as result, if port with service are upgraded in the middle of large upgrade session (and it is not always possible to upgrade services SEPARATELY, due to dependences), here is large window when old service is stopped, but new cannot be started yet. -- // Black Lion AKA Lev Serebryakov ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
2011/9/16 Łukasz Wąsikowski : > W dniu 2011-09-16 18:17, Eric pisze: > >> Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using >> AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. > > I'm using it for a long time on my personal box and it's not that great. > After some updates there is need to prepare the daemon - adjust > configuration for example. Automatic restart will do much harm in that > case. Another example: update when there's apache and php in new > versions, system has also eaccelerator and some pecl's installed. If php > was updated before apache, then apache restart via AFTERINSTALL will > leave you with not working www server (because eaccelerator and pecl's > were not recompiled). Updating ports should never turn off or restart > service - thats my $0.02. > I had a thought about implementing this in bsd.port.mk, but to tell the truth it would be better handled by your port manager of choice-- I can't find an option for portmaster, but I bet someone willing to send a working patch to dougb can earn themselves some brownie points. I would do it myself, but meh it doesn't upset me that much. However, having services not restarted after an upgrade can leave you with a) a vulnerable older service and b) a nasty shock when you decide to reboot six months later and it breaks :) 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
W dniu 2011-09-16 18:17, Eric pisze: > Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using > AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. I'm using it for a long time on my personal box and it's not that great. After some updates there is need to prepare the daemon - adjust configuration for example. Automatic restart will do much harm in that case. Another example: update when there's apache and php in new versions, system has also eaccelerator and some pecl's installed. If php was updated before apache, then apache restart via AFTERINSTALL will leave you with not working www server (because eaccelerator and pecl's were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. -- best regards, Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
> We do not currently have a standard procedure for that, nor do we record > the necessary state -- perhaps we should just discuss, vote, and add a > paragraph to the porter's handbook. > > We also need to bring the authors (or volunteers) for the de-facto > standard upgrade tools into the loop. > > My thoughts: > > - give the user a choice to configure whether to restart services > > - optional: give the users a chance to configure this per-service > > - discuss whether we want/need to support this (a) in the framework that > we currently use, (b) only in pkgng, (c) in portmaster and portupgrade > where necessary. Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. [1] http://wiki.freebsd.org/portupgrade ___ 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: freevrrpd
Yes, the interface needs an IP configured on it, and both boxes need to be on the same subnet. However, the "real" IP doesn't have to be a routable IP, nor does it even have to be in the same subnet as the virtual IP. The "real" IP is just used for sending out the VRRP broadcasts and pings and whatnot to determine which host is up, which is master, when a host fails, etc. On a test box, I've assigned all of the "real" IPs into 172.20.xxx.0/24 subnets (non-routable, RFC1918 addresses), where xxx is the same as the vlan tag for the interface (it's a vlan routing box). And then the "virtual"/shared IPs are live, routable IPs. So far, everything is working correctly. It's really no different from the 0.9 setup. On Fri, Sep 16, 2011 at 3:49 AM, etherforet wrote: > Hi,all. > > for OLD FreeVRRPd 0.9x,settings example. > -- > box1: / etc / rc.conf > ifconfig_em0 = "inet 192.168.0.2 netmask 255.255.255.0" > > box1: / usr / local / etc / freevrrpd.conf > [VRID] > serverid = 1 > interface = em0 > carriertimeout = 10 > spanningtreelatency = 0 > priority = 200 > addr = 192.168.0.1/24 > monitoredcircuits = yes > MCClearErrorsCount = 3600 > masterscript = / usr / local / bin / master_script.sh > backupscript = / usr / local / bin / backup_script.sh > password = vrid1 > > - > > box2: / etc / rc.conf > ifconfig_em0 = "inet 192.168.0.3 netmask 255.255.255.0" > > box2: / usr / local / etc / freevrrpd.conf > [VRID] > serverid = 1 > interface = em0 > carriertimeout = 10 > spanningtreelatency = 0 > priority = 100 > addr = 192.168.0.1/24 > monitoredcircuits = yes > MCClearErrorsCount = 3600 > masterscript = / usr / local / bin / master_script.sh > backupscript = / usr / local / bin / backup_script.sh > password = vrid1 > > -- > Can be set for the segment were the same. > > However, NEWer FreeVRRPd 1.0 is A real IP and you need to set up to > another segment. > # bug? > > For example, > IP assigned to the real card of real IP > / etc / rc.conf > ifconfig_em0 = "inet 192.168.0.1 netmask 255.255.255.0" > > Virtual IP assigned to the virtual card (assign ngether0: or n > / usr / local / etc / freevrrpd.conf > [VRID] > serverid = 1 > interface = em0 > carriertimeout = 10 > spanningtreelatency = 0 > priority = 200 > addr = 192.168.1.1/24 > monitoredcircuits = yes > MCClearErrorsCount = 3600 > masterscript = / usr / local / bin / master_script.sh > backupscript = / usr / local / bin / backup_script.sh > password = vrid1 > > Needs to be set like this. > When using a local router is not a problem, would be a little trouble > setting the scene for small segment of GLOBAL edge router. > # I need 0.9x ;) > > 2011/8/26 : > > Hello, my name is Mihail Suhorosov, Im from Russia and I use you port for > > FreeBSD freevrrpd.(My BSD version is 8.2) > > > > I have some problem. I can't start this programm. My config is: > > [VRID] > > serverid = 1 > > interface = re0 > > priority = 255 > > addr = 10.50.40.8/32 > > #masterscript = /usr/local/bin/master_script.sh > > #backupscript = /usr/local/bin/backup_script.sh > > #password = vrid1 > > > > After start I see in log: > > Aug 26 17:31:52 tim freevrrpd[1687]: launching daemon in background mode > > Aug 26 17:31:52 tim freevrrpd[1688]: initializing threads and all VRID > > Aug 26 17:31:52 tim freevrrpd[1688]: reading configuration file > > /usr/local/etc/freevrrpd.conf > > Aug 26 17:31:52 tim freevrrpd[1688]: cannot create a bridge device: No > such > > file or directory > > Aug 26 17:31:52 tim freevrrpd[1688]: aborting... > > > > So i think it cant connetct to interface. But why i dont know > > In my netcard i have alias 10.50.40.8 > > > > Please help my)) > > > > Bets whishes, > > Suhorosov Mihail. > > ___ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > -- Freddie Cash fjwc...@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: Detecting dependencies
Michel Talon wrote: > Oliver Fromme wrote: > > > > That's what a script of mine does (it's also in Python): > > > > http://www.secnetix.de/olli/scripts/pkg_dep_view > > Waooh! this is very cute. > > While we are in python i have something which draws > graphviz dependency graphs for ports here > http://www.lpthe.jussieu.fr/~talon/pkg_check.py Very nice! Your script seems to do several jobs at once, while I have separate scripts for those tasks. E.g. I have a separate script for checking origins and the consistency of dependencies. > Seeing things like your script, the perl script port-easy by des, etc. > i really wonder why people write stuff in C or worse shell for ports. > One could write ten times smarter and ten times shorter things in real > languages like python, lisp, etc. This argument of being "included in > base system" is so completely bogus ... I think "high-level" languages like Python are very well suited for managing data structures like dependency graphs. These structures are native to the language, so reading the +REQUIRED_BY files into a tree structure is absolutely trivial and requires just a few lines, wereas in C it gets a lot more complicated and a lot more error-prone. In Python you don't have to care about pointers and memory allocation (the same is true for Ruby, Perl and others, of course, but I think that Perl's syntax is horrible). As for "it's not in the base system": I don't care much. The Python port is easy enough to install, and in fact it's installed on most machines anyway because quite a lot of ports depend on it. Actually, some of my scripts that deal with package began as awk scripts, precisely for the reason that it's in the base system. But while awk supports dynamic arrays and associative arrays, it doesn't support nesting them, so you can't directly make a tree-like structure (well, you can, but it gets ugly very quickly). So I started porting them to my favourite scripting language, which is Python. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Being really good at C++ is like being really good at using rocks to sharpen sticks." -- Thant Tessman ___ 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: [CFT] Dolphin-emu preliminary port
On Thu, 25 Aug 2011 08:27:05 +0200 (CEST), Ganael LAPLANCHE wrote Hi everyone, > The port has been updated : Dolphin now builds and run on > amd64 (the MAP_FIXED hack now works). A new version of the port is available, following the integration of several patches into the main branch. I think the port has now reached enough quality to hit the tree : - NLS can be disabled - Options are provided tu enable/disable PortAudio and PulseAudio (OpenAL is used by default). You can try it here : http://contribs.martymac.org/FreeBSD-ports/sandbox/dolphin-emu-3.0.r20110912-port.tgz And follow the thread on Dolphin forums : http://forums.dolphin-emulator.com/showthread.php?tid=8254 > OpenGL still needs testing : does it work on your box ? I > would be happy to get comments on that. Yes, I'd be glad to get feedback on OpenGL rendering (for those who have support for the GL_EXT_framebufer_object, otherwise, it'll just crash). I've still only been able to test software rendering... Don't hesitate to contact me if you need more info or if you can test the software. Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Am 16.09.2011 11:51, schrieb Lev Serebryakov: > Hello, Freebsd-ports. > You wrote 16 сентября 2011 г., 0:28:07: > >>> Really? I thought it was supposed to be standard behaviour- the @stopdaemon >>> line in pkg-plist facilitates that. > >> While I totally understand why we do this, I have to say it's VERY >> VERY annoying behavior especially when one upgrading a remote system >> with multiple server daemon ports. One have to watch the whole >> process carefully and restart the daemon manually. > Yep, and even more annoyingly is that it is completely inconsistent: > some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. ___ 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: Detecting dependencies
Oliver Fromme wrote: That's what a script of mine does (it's also in Python): http://www.secnetix.de/olli/scripts/pkg_dep_view Waooh! this is very cute. While we are in python i have something which draws graphviz dependency graphs for ports here http://www.lpthe.jussieu.fr/~talon/pkg_check.py Unfortunately for many ports the diagram becomes completely unreadable. Your display is wonderful. Seeing things like your script, the perl script port-easy by des, etc. i really wonder why people write stuff in C or worse shell for ports. One could write ten times smarter and ten times shorter things in real languages like python, lisp, etc. This argument of being "included in base system" is so completely bogus ... -- Michel TALON ___ 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"
Compilation impossible using TARGET_ARCH=i386
Hello everyone, I try to compile packages for older i386 on an amd64 machine. On the amd64 I use a chroot into an i386-world. I then compile ports using make ARCH=i386 TARGET_ARCH=i386 BATCH=yes install There are some ports where this doesn't work. Here's the list I found: dns/adns lang/lua graphics/pho graphics/xzgv devel/cvsps They all exit with the same error: cc: i386: No such file or directory Is this behaviour intended? Kind regards, Benjamin ___ 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: editors/zim
Good day there. Maintainer timeout 2weeks has reached. Can please anybody commit this? http://bugs.freebsd.org/160385 Thanks in advance. Ruslan Mahmatkhanov wrote on 02.09.2011 12:18: Chris Whitehouse wrote on 01.09.2011 02:30: [skipping the details since original problem was solved] Now it builds and installs and is working fine, _and_ my original problem has gone away. thanks very much for your help. I'll drop the author a line to say it's been fixed. Chris Sorry for delay, i now added sqlite3 dependency and some optional dependencies for zim plugins (besides the gtkspell one, since the plugin needs python binding to gtkspell that we seems lacking in the ports tree). This pr was submitted: http://bugs.freebsd.org/160385. I also reupploaded port tarball and the diff. -- 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: freevrrpd
Hi,all. for OLD FreeVRRPd 0.9x,settings example. -- box1: / etc / rc.conf ifconfig_em0 = "inet 192.168.0.2 netmask 255.255.255.0" box1: / usr / local / etc / freevrrpd.conf [VRID] serverid = 1 interface = em0 carriertimeout = 10 spanningtreelatency = 0 priority = 200 addr = 192.168.0.1/24 monitoredcircuits = yes MCClearErrorsCount = 3600 masterscript = / usr / local / bin / master_script.sh backupscript = / usr / local / bin / backup_script.sh password = vrid1 - box2: / etc / rc.conf ifconfig_em0 = "inet 192.168.0.3 netmask 255.255.255.0" box2: / usr / local / etc / freevrrpd.conf [VRID] serverid = 1 interface = em0 carriertimeout = 10 spanningtreelatency = 0 priority = 100 addr = 192.168.0.1/24 monitoredcircuits = yes MCClearErrorsCount = 3600 masterscript = / usr / local / bin / master_script.sh backupscript = / usr / local / bin / backup_script.sh password = vrid1 -- Can be set for the segment were the same. However, NEWer FreeVRRPd 1.0 is A real IP and you need to set up to another segment. # bug? For example, IP assigned to the real card of real IP / etc / rc.conf ifconfig_em0 = "inet 192.168.0.1 netmask 255.255.255.0" Virtual IP assigned to the virtual card (assign ngether0: or n / usr / local / etc / freevrrpd.conf [VRID] serverid = 1 interface = em0 carriertimeout = 10 spanningtreelatency = 0 priority = 200 addr = 192.168.1.1/24 monitoredcircuits = yes MCClearErrorsCount = 3600 masterscript = / usr / local / bin / master_script.sh backupscript = / usr / local / bin / backup_script.sh password = vrid1 Needs to be set like this. When using a local router is not a problem, would be a little trouble setting the scene for small segment of GLOBAL edge router. # I need 0.9x ;) 2011/8/26 : > Hello, my name is Mihail Suhorosov, Im from Russia and I use you port for > FreeBSD freevrrpd.(My BSD version is 8.2) > > I have some problem. I can't start this programm. My config is: > [VRID] > serverid = 1 > interface = re0 > priority = 255 > addr = 10.50.40.8/32 > #masterscript = /usr/local/bin/master_script.sh > #backupscript = /usr/local/bin/backup_script.sh > #password = vrid1 > > After start I see in log: > Aug 26 17:31:52 tim freevrrpd[1687]: launching daemon in background mode > Aug 26 17:31:52 tim freevrrpd[1688]: initializing threads and all VRID > Aug 26 17:31:52 tim freevrrpd[1688]: reading configuration file > /usr/local/etc/freevrrpd.conf > Aug 26 17:31:52 tim freevrrpd[1688]: cannot create a bridge device: No such > file or directory > Aug 26 17:31:52 tim freevrrpd[1688]: aborting... > > So i think it cant connetct to interface. But why i dont know > In my netcard i have alias 10.50.40.8 > > Please help my)) > > Bets whishes, > Suhorosov Mihail. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: overlays
> Simplicity. [...] I've got ca. 70 Gentoo servers and I want my own > portage overlay. Thank you very much for that explanation! I was thinking in a different direction, as the number of machines I have is quite limited, each with very specific needs. As long as it is only about adding new ports, I would probably have /usr/ports/local a checkout of my personal repository with the rest of /usr/ports a checkout of the official repository (cvs allows this and cvs update will tacitly update each directory form the repository it belongs). But as I said, I have no practical experience with the same overlay on a bulk of machines. My thought was in the direction of tweaking a single machine to its very specific needs while keeping maintenance of the tweaked machine simple. So thanks for clarifying this and best regards, Klaus ___ 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: Thank you (for making the ports less boring).
Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: >> Really? I thought it was supposed to be standard behaviour- the @stopdaemon >> line in pkg-plist facilitates that. > While I totally understand why we do this, I have to say it's VERY > VERY annoying behavior especially when one upgrading a remote system > with multiple server daemon ports. One have to watch the whole > process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. -- // Black Lion AKA Lev Serebryakov ___ 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: overlays
W dniu 2011-09-16 08:24, Klaus T. Aehlig pisze: > Now I'm really curios what magic device gentoo has. Once thing I > most appreciate about FreeBSD is how flexible it is in precisely > this manner. [...] > Could you please elaborate, which additional features gentoo's overlay > system brings on top of that? Simplicity. I'm not familiar with FreeBSD's way of doing overlays, quick googling and quick testing may be not enough to say anything in that matter, so I'll just describe how I do it in Gentoo. I've got ca. 70 Gentoo servers and I want my own portage overlay. So I've set up svn server with my ports. Each of 70 servers has a script in /etc/portage/postsync.d which retrives my ports from svn server during the synchronization of portage tree. Each server have a line in /etc/make.conf: PORTDIR_OVERLAY=/some/local/directory Let's say I've wrote a new ebuild for a new category, for example: my-category/my-port/my-port-1.0.ebuild. Now I have to do prepare it for "shipping", so: cd my-category/my-port && ebuild my-port-1.0.ebuild digest && svn ci That's all, after next portage update (via emerge --sync) I'll end with up-to-date official portage tree and up-to-date my overlay. Ports from my overlay will work with emerge out of the box (checking for new USE flags, checking if port needs updating, etc.) Summarize: Enable overlay: - one simple script in postsync.d - one line in make.conf Prepare port for tree: - one command to make ebuild - one command to commit it to svn Sync and install/update: - one command to update portage tree on each server - one command to install/update port(s) How would it look like on FreeBSD? -- best regards Lukasz Wasikowski ___ 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: Detecting dependencies
Jason Hellenthal wrote: > On Thu, Sep 15, 2011 at 12:06:03AM +0300, chukha...@mail.ru wrote: > > There have been a discussion about finding interdependencies of ports. > > I have a relatively simple Python script for that. There is a pr > > ports/160007 > > to add its early version. Unfortunately, I missed a reply to it, so there > > is > > an issue which I have not yet addressed... > [...] > > 1. Would be cool if this would work on already installed ports or packages > too! just a thought. That's what a script of mine does (it's also in Python): http://www.secnetix.de/olli/scripts/pkg_dep_view > 2. If it would detect the presence of UTF-8 in the LANG or LC_ALL > environment vars and use the appropriate drawing method for each rather > than a default to UTF-8. "I am happy with it as is though" Maybe have a look at my script, it might help. It uses Python's curses module to display graphical line characters using the ACS feature (alternate character set). This is independent from the local (UTF-8, ISO8859, ASCII) and works very well with terminals that support line drawing characters, such as xterm, vt100 and so on. When there is no such support (dumb terminal, or not supported by termcap, or stdout is a pipe), normal ASCII characters are used instead. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe ___ 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: Remove dependency on xz - How?
On Fri, 2011-09-16 at 02:45 -0500, Lars Eighner wrote: > archivers/xz is mark IGNORE because xz is now in the base system (8.2) > > Numerous other ports won't build because they believe they depend on xz (or > on a port that depends on xz) > > I'd like to remove the dependencies on xz from the pkgs database. > > pkgdb -s /xz-5.0.0// won't work as the slash notation might suggest it would > because -s does not accept a 'empty argument' > > I am afraid to remove the xz package because it seems to me it would delete > the base system xz -- and I don't want to make world if I can avoid it. Try: $ ls -l /usr/bin/xz $ ls -l /usr/local/bin/xz $ pkg_which /usr/local/bin/xz In short: It won't. Ports generally do not install into base hier(7). Also, even if case such situation happened, you'd be much quicker with: # cd /usr/src/usr.bin/xz # make clean # make # make install [ # make clean ] > Is there some sensible way to do this? Force deinstall xz package, run pkgdb -Fuf, confirm deleting the unneeded dependency (if asked), and you're done. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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"
Remove dependency on xz - How?
archivers/xz is mark IGNORE because xz is now in the base system (8.2) Numerous other ports won't build because they believe they depend on xz (or on a port that depends on xz) I'd like to remove the dependencies on xz from the pkgs database. pkgdb -s /xz-5.0.0// won't work as the slash notation might suggest it would because -s does not accept a 'empty argument' I am afraid to remove the xz package because it seems to me it would delete the base system xz -- and I don't want to make world if I can avoid it. Is there some sensible way to do this? -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ 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"
