Re: XPI infrastructure needs some love
Doug Barton wrote: If we have maintainers who are willing to keep these things up to date and people agree that this is an acceptable [way] Well, I'm not so sure about the ones I don't use, but the ones I do use are usualyl well maintained (either that or they get a PR form me), but there's also the fact that updating them is usually a no-brainer (in most cases it could well be automated, as Andrew Pantyukhin has suggested); it seems to me that a maintainer is not the most scarce resource in updating an XPI port, committer time seems to be a scarcer resource to me (but that's of course the point of view of a maintainer). I'm particularly concerned about the situation where we have them in the tree but they are not up to date. That's not only a waste of resources it makes us look bad. Especially so because system-wide packages are then more difficult to update for the single user; I don't remember at the moment if a stale system package can be Disabled *and* installed locally by the user or not (as I usually update the port first without trying to update as user), but that (if it is the case that it's impossible) would be a strong additional reason to be sure to have latest version in the ports. But I'm not really sure about this, I will double check next time an extension I do use is outdated (before updating the port). -- Lapo Luchini - http://lapo.it/ “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” (Edsger W. Dijkstra) ___ 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: XPI infrastructure needs some love
On 08/09/2010 07:00, Rob Farmer wrote: On Tue, Sep 7, 2010 at 21:32, Doug Barton do...@freebsd.org wrote: On 09/07/2010 09:09 PM, Rob Farmer wrote: Around 6 months ago, a similar thing was proposed for a number of eclipse plugins - they can all be installed and updated via the builtin update manager and nothing is built for FreeBSD - they are just Java stuff that can be binary downloaded and run anywhere. Are these eclipse plugins similar to mozilla plugins in that the user has to take an additional step after the FreeBSD package is added, or if the package is on the system then it's available to all the users immediately? If the latter, then I can understand why having FreeBSD packages of them would be valuable. If they are similar to mozilla plugins then I'm curious what the value-add is. I'm not quite sure what you mean by take an additional step after the FreeBSD package is added. I've never used either the xpi ports or the eclipse plugins. Do users have to run some command to import the plugins into their ~/.mozilla profiles after root installs them or is it automatic? Skimming a couple makefiles, neither the xpi nor eclipse plugin ports indicate this type of thing in a pkg-message or similar that I can see. No, it's not necessary. Only the enigmail ports are exceptions, but I'm repeating what a lot of people said before. I don't really have much of an opinion on this - I can see the pros (easier administration) and cons (more ports to be maintained, possiblity of lagging behind what's available upstream) to having the ports. I just recall the discussion and mentioned it because I thought it might be relevant if there was already some precedent for this type of thing (it seems the eclispe ports were kept). I'm a supporter of the keep it in ports idea. All these auto-updating mechanisms are workarounds for operating systems that lack a centralized update mechanism (Windows, OS-X). I dread the day when I update all my ports and still have to update my Firefox, Thunderbird, Eclipse, ... plugins afterwards. I pitty the sysadmin who updates a system and sends a mail to every account owner from first-level support to CEO, to please update all their plugins for all their software, because the infrastructure to do it all in one go is gone. I understand, FreeBSD is rarely used in this fashion (as a server with thin-clients), but by removing these kinds of ports we cut off any growth potential in this direction and I very much want FreeBSD to prosper and grow. This OS has a lot of faults and there is a lot of catching up to do in many areas. There's lack of manpower for a lot of the ungrateful jobs like 3D support (where frankly no one will be ever satisfied, because it will still run better under Windows). But, this system has so much potential and makes my life so much more easy, because there's a lot of stuff that FreeBSD _does_ better than other systems and there is a spirit of pragmatism that makes this community deal with stuff and move on to the next problem. So what I am trying to say - FreeBSD is worth all the effort we do and can give it. Because this is the place where people come up with /better/ solutions. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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 Port: squid-3.1.7
Hi, I'm trying to run more than one instance of squid on a system. Due to this, in the rc.conf I'm trying configure each instance to use a different squid.conf file using squid_conf=/usr/local/etc/squid/squid_wireless.conf. It appears that this option is ignored, because on boot squid still tries to load squid.conf Any assistance would be appreciated. Thanks Paul. ___ 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
request. Sogo
I am looking for a mail solution, with shared agenda and contacts, and came across Sogo. http://www.sogo.nu/english.html We tried several solutions, but Sogo fits our needs more than the other solutions like horde and so on. I tried it on a ubuntu box, and i really like it. The thing is, i can not get it working on FreeBSD. I am no programmer in any way, and do not understand all of the configure needs. I would like to know if anyone is working on it, because it is THE solution for us. Thanks, Regards, Johan Hendriks ___ 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: FreeBSD Port: squid-3.1.7
* Paul Gabriel (paul...@me.com):
Hi, I'm trying to run more than one instance of squid on a system. Due
to this, in the rc.conf I'm trying configure each instance to use a
different squid.conf file using
squid_conf=/usr/local/etc/squid/squid_wireless.conf. It appears that
this option is ignored, because on boot squid still tries to load
squid.conf
Paul, thank you for your mail.
It looks like it's my fault: I refactored the rc script a while
back and obviously broke this feature.
Could you try this patch?
Index: files/squid.in
===
--- files/squid.in (Revision 1875)
+++ files/squid.in (Arbeitskopie)
@@ -77,6 +77,7 @@
squid_conf=${squid_conf:-%%PREFIX%%/etc/squid/squid.conf}
squid_enable=${squid_enable:-NO}
squid_fib=${squid_fib:-NONE}
+squid_flags=-f ${squid_conf} ${squid_flags}
squid_pidfile=${squid_pidfile:-/var/run/squid/squid.pid}
squid_user=${squid_user:-%%SQUID_UID%%}
___
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: request. Sogo
On 09/08/10 08:37, Johan Hendriks wrote: I am no programmer in any way, and do not understand all of the configure needs. I would like to know if anyone is working on it, because it is THE solution for us. Seconded on that. Unfortunately, I don't have much time to burn on this and GNUStep is a mess. I was able to past the configure (whether or not I did right is another story) If anyone familiar with GNUStep wants to throw us a bone: [smca...@smcafee ~/sogo/SOGo-1.3.1]$ sudo ./configure --gsmake=/usr/local/GNUstep/System/Makefiles/ Password: gnustep-config: not found GNUstep environment: system: /usr/local/GNUstep/System local: /usr/local/GNUstep/Local user: /root/GNUstep path: /usr/local/GNUstep/System:/usr/local/GNUstep/Network:/usr/local/GNUstep/Local:/root/GNUstep flat: yes arch: amd64-portbld-freebsd8.1 combo: gnu-gnu-gnu Note: will install in GNUSTEP_LOCAL_ROOT: /usr/local/GNUstep/Local Configuration: debug: yes strip: no ldap-based configuration: no prefix: /usr/local/GNUstep/Local gstep: /usr/local/GNUstep/System/Makefiles/ config: /home/smcafee/sogo/SOGo-1.3.1/config.make script: /usr/local/GNUstep/System/Makefiles//GNUstep.sh creating: /home/smcafee/sogo/SOGo-1.3.1/config.make [r...@smcafee /home/smcafee/sogo/SOGo-1.3.1]# gmake This is gnustep-make 2.4.0. Type 'gmake print-gnustep-make-help' for help. Making all in SOPE/NGCards ... Making all for library libNGCards... Compiling file CardGroup.m ... CardGroup.m:27:33: warning: SaxObjC/SaxXMLReader.h: No such file or directory CardGroup.m:28:40: warning: SaxObjC/SaxXMLReaderFactory.h: No such file or directory In file included from CardGroup.m:30: NGCardsSaxHandler.h:25:39: warning: SaxObjC/SaxDefaultHandler.h: No such file or directory In file included from CardGroup.m:30: NGCardsSaxHandler.h:41: error: cannot find interface declaration for 'SaxDefaultHandler', superclass of 'NGCardsSaxHandler' CardGroup.m:35: error: cannot find protocol declaration for 'SaxXMLReader' CardGroup.m:40: error: cannot find protocol declaration for 'SaxXMLReader' CardGroup.m: In function '+[CardGroup cardParser]': CardGroup.m:43: warning: 'NGCardsSaxHandler' may not respond to '+new' CardGroup.m:43: warning: (Messages without a matching method signature CardGroup.m:43: warning: will be assumed to return 'id' and accept CardGroup.m:43: warning: '...' as arguments.) CardGroup.m:48: error: 'SaxXMLReaderFactory' undeclared (first use in this function) CardGroup.m:48: error: (Each undeclared identifier is reported only once CardGroup.m:48: error: for each function it appears in.) CardGroup.m:58: warning: '-setContentHandler:' not found in protocol(s) CardGroup.m:58: warning: no '-setContentHandler:' method found CardGroup.m:59: warning: '-setErrorHandler:' not found in protocol(s) CardGroup.m:59: warning: no '-setErrorHandler:' method found CardGroup.m: In function '+[CardGroup parseFromSource:]': CardGroup.m:71: error: cannot find protocol declaration for 'SaxXMLReader' CardGroup.m:83: warning: '-parseFromSource:' not found in protocol(s) gmake[4]: *** [obj/libNGCards.obj/CardGroup.m.o] Error 1 gmake[3]: *** [internal-library-all_] Error 2 gmake[2]: *** [libNGCards.all.library.variables] Error 2 gmake[1]: *** [internal-all] Error 2 gmake: *** [internal-all] Error 2 -- Sean McAfee Senior Systems Engineer ___ 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: request. Sogo
Sean McAfee schrieb: On 09/08/10 08:37, Johan Hendriks wrote: I am no programmer in any way, and do not understand all of the configure needs. I would like to know if anyone is working on it, because it is THE solution for us. Seconded on that. Unfortunately, I don't have much time to burn on this and GNUStep is a mess. [...] I gave it a quick shot, and was able to build and install SOGo and SOPE in a clean 8.1/amd64 jail, with NOPORTDOCS=yes as the only flag in /etc/make.conf. The jails ports tree was last csuped yesterday. $ denotes an unprivileged user account, # denotes root. # cd /usr/ports/ports-mgmt/portmaster make install clean # portmaster lang/gnustep-base # portmaster databases/mysql51-server # portmaster net/openldap24-server # portmaster mail/dovecot # portmaster mail/postfix # portmaster devel/monotone # portmaster shells/bash # portmaster databases/libmemcached Grab sources: $ mkdir ~/tmp $ cd ~/tmp $ mtn db init --db=~/db.mtn $ mtn --db=~/db.mtn pull inverse.ca ca.inverse.sope $ mtn --db=~/db.mtn checkout --branch ca.inverse.sope SOPE $ mtn --db=~/db.mtn pull inverse.ca ca.inverse.sogo $ mtn --db=~/db.mtn checkout --branch ca.inverse.sogo SOGo Build: bash $ cd ~/tmp/SOPE bash $ . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash $ ./configure --with-gnustep --enable-debug --disable-strip bash $ gmake bash # . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash # gmake install bash $ cd ~/tmp/SOGo bash $ . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash $ ./configure --enable-debug --disable-strip bash $ gmake The build stops at a missing library named libOGoContentStore.so.0.9 bash $ cd OGoContentStore gmake gmake install cd .. While you're at it, fix cp in SOPE/NGCards/GNUmakefile.postamble, by replacing -dpR with -a. bash $ gmake bash # . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash # gmake install The mere fact, that it gets through the build and install phase of course doesn't mean the resulting files will be able to actually do anything useful for us, but it might be a start, at least. Since I just had a very quick look at the documentation of SOGO, I'm not able to supply any more hints at this time. Seeing Funambol being mentioned raised my interesst, though. MfG CoCo ___ 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: portmanager endlessly looping in x11
On 08/26/10 01:17, jhell wrote: On 08/25/2010 21:27, Chuck Robey wrote: I have an interesting thing here: I seem to have found an endless loop in portmanager. It's *entirely* possible that I'm myself causing this, so I'll explain, and if you can come up with any hints, I'll be happy to test them, because I really do like using portmanager. CC:The maintainer of ports-mgmt/portmanager is a good start. Maybe He/She can give you some insight of the working of portmanager. I am not sure how portmanager keeps the package database up to date but sometimes dependencies can get messed up in the database that can cause a loop and if not handled correctly by the upgrade process can cause a lot of grief. In portmaster you could be using --check-depends and in portupgrade you could use -Ffu but you don't seem to be using any of the suggested ports-mgmt upgrade utilities so good luck. ``emphasis on portmaster'' -- written by dougb@, so you know it works!. The problem I saw, I'm pretty sure is caused by a discrepancy (in portmanager) between how deeply it looks for dependencies versus how deeply it looks it looks to decide to actually rebuild those discovered dependencies. Merely noting the need to rebuild seems not to be the same thing as actually doing it. It found things maybe 3 levels deep, but if it's less than 2 levels down, it won't rebuild it, it'll merely realize that it *should* do it. I switched to using portmaster (this looks alike, I'm making no mistake tho, moved from portmanager to portmaster) which doesn't seem to have this uneveness, so while it takes a whole lot longer to work than portmanager (it uses slow but sure shell utils for it's databases) it really does a far more reliable job of things. You could get to rely on it. It sure took me a good while to track down the reasons that portmanager was fixing on, in deciding that something was out of date, and the frustration was sufficient to cause me to forgive the way that portmaster is much more slow. One really big irritation was how portmanager would rebuild something completely successfully 3 times, but since it would fail its dependency scans, it never would recognize that any of those looping apps had been rebuilt. Very puzzling, until I realized about the dependency problems. ___ 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: portmanager endlessly looping in x11
On Wed, 08 Sep 2010 17:41:32 -0400 Chuck Robey chu...@telenix.org articulated: On 08/26/10 01:17, jhell wrote: On 08/25/2010 21:27, Chuck Robey wrote: I have an interesting thing here: I seem to have found an endless loop in portmanager. It's *entirely* possible that I'm myself causing this, so I'll explain, and if you can come up with any hints, I'll be happy to test them, because I really do like using portmanager. CC:The maintainer of ports-mgmt/portmanager is a good start. Maybe He/She can give you some insight of the working of portmanager. I am not sure how portmanager keeps the package database up to date but sometimes dependencies can get messed up in the database that can cause a loop and if not handled correctly by the upgrade process can cause a lot of grief. In portmaster you could be using --check-depends and in portupgrade you could use -Ffu but you don't seem to be using any of the suggested ports-mgmt upgrade utilities so good luck. ``emphasis on portmaster'' -- written by dougb@, so you know it works!. The problem I saw, I'm pretty sure is caused by a discrepancy (in portmanager) between how deeply it looks for dependencies versus how deeply it looks it looks to decide to actually rebuild those discovered dependencies. Merely noting the need to rebuild seems not to be the same thing as actually doing it. It found things maybe 3 levels deep, but if it's less than 2 levels down, it won't rebuild it, it'll merely realize that it *should* do it. I switched to using portmaster (this looks alike, I'm making no mistake tho, moved from portmanager to portmaster) which doesn't seem to have this uneveness, so while it takes a whole lot longer to work than portmanager (it uses slow but sure shell utils for it's databases) it really does a far more reliable job of things. You could get to rely on it. It sure took me a good while to track down the reasons that portmanager was fixing on, in deciding that something was out of date, and the frustration was sufficient to cause me to forgive the way that portmaster is much more slow. One really big irritation was how portmanager would rebuild something completely successfully 3 times, but since it would fail its dependency scans, it never would recognize that any of those looping apps had been rebuilt. Very puzzling, until I realized about the dependency problems. ___ 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 Portmanager did have a nasty bug that involved looping. It was fixed ages ago though. Are you running the latest version; i.e., 0.4.1_9 on your system? Run portmanager -v to confirm. Without the '-p' option, portmanager only looks 1 level deep. with the '-p' option, it will search the entire dependency chain. I always use the '-p' option and never experience any problems described by you. -- Jerry ✌ freebsd-ports.u...@seibercom.net 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: portmanager endlessly looping in x11
On 09/08/10 18:15, Jerry wrote: Portmanager did have a nasty bug that involved looping. It was fixed ages ago though. Are you running the latest version; i.e., 0.4.1_9 on your system? Run portmanager -v to confirm. Without the '-p' option, portmanager only looks 1 level deep. with the '-p' option, it will search the entire dependency chain. I always use the '-p' option and never experience any problems described by you. Not sure if the -p does that or not, but I *did* read (more than just a few times) about the -p (meaning pristine) option, and from the reading, it doesn't tell me that it might affect looping, and I didn't see anything about it in the man page. I didn't just try it and immediately mail, I tried to DTRT. Doesn't matter too much to me now, because I really love the fact that I did 4 *very* large (meaning lengthy dependency lists) ports, with 100% 1st-time accuracy, which means I will stay with portmaster for sure now. Also, because those ports are now all installed, and I don't want to take a few days to rebuild everything all over again. It looks like, in the default case, portmanager detects more problems than it deals with, which is not a desirable default action. It's probably a needed default action for some use case ... do you happen to know what that is? ___ 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: portmanager endlessly looping in x11
On Wed, 08 Sep 2010 17:41:32 -0400 Chuck Robey chu...@telenix.org wrote: I'm making no mistake tho, moved from portmanager to portmaster) which doesn't seem to have this uneveness, so while it takes a whole lot longer to work than portmanager (it uses slow but sure shell utils for it's databases) I don't know why people think portmanager is fast. It may be written in C, but in most upgrades it builds *many* more ports than portmaster or portupgrade would do. The point of a portmanager is to upgrade correctly with as little human intervention as is possible; and it sacrifices a lot of cpu cycles to that end. it really does a far more reliable job of things. Something it does, sometimes it doesn't. portmanager will handle a lot upgrades correctly even when instructions in UPDATING that are required for portmaster are ignored. With portupgrade I've had a few problems where the UPDATING entry was made after I updated the ports. These have been much more serious than harmless looping. One really big irritation was how portmanager would rebuild something completely successfully 3 times, but since it would fail its dependency scans, it never would recognize that any of those looping apps had been rebuilt. Very puzzling, until I realized about the dependency problems. I didn't follow what you were were saying, but portmanager has at least two features that can lead to looping. One is that it can rebuild ports when it detects a dynamic change in port dependencies. The other is when it tries to resolve conflicts by package deletion and iterative rebuilding. There are probably more. AFAIK it shouldn't actually loop endlessly because of its three-strikes database. In my experience portmanager goes through good and bad patches as the installed ports change and their dependencies evolve. Even when it's not completing successfully by it's own criteria, it usually does the job without leaving any real problems of its own making. ___ 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
