Re: XPI infrastructure needs some love
--- Original message --- From: Lapo Luchini l...@lapo.it To: po...@freebsd.org Cc: infofar...@freebsd.org, m...@freebsd.org, s...@freebsd.org Sent: 7.9.'10, 20:39 Dear port committers, I understand that infofarmer@ and miwi@ have no more enough free time to be hyper-active about those and other ports (and btw, thanks very much for the huge work you did in the past!), but is out there anyone else out there with both a commit bit and some time on hand to give a bit of love to the XPI ports? Hey Lapo and all, nice to hear from you! XPI stuff is one of those things that's crying to get 95% automated (along with CPAN, pypy, etc, but *not* along with generic ports). I would estimate it is about a week of work for a reasonably seasoned ports committer. At the moment, I could provide input for anyone with enough time to undertake it, but can not implement it myself. ___ 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: pkg_delete: package 'libvorbis-1.2.0,3' doesn't have a prefix
On Tue, May 27, 2008 at 10:23:51PM -0400, Dan Langille wrote: Can you tell me why this portupgrade fails? creating seeking_example Making all in vq --- Backing up the old version tar: +COMMENT: Cannot stat: No such file or directory tar: +DESC: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. Because you lost a couple of files in /var/db/pkg? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_delete: package 'libvorbis-1.2.0,3' doesn't have a prefix
On Wed, May 28, 2008 at 07:46:05AM -0400, Dan Langille wrote:
On May 28, 2008, at 6:10 AM, Andrew Pantyukhin wrote:
On Tue, May 27, 2008 at 10:23:51PM -0400, Dan Langille wrote:
Can you tell me why this portupgrade fails?
creating seeking_example
Making all in vq
--- Backing up the old version
tar: +COMMENT: Cannot stat: No such file or directory
tar: +DESC: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
Because you lost a couple of files in /var/db/pkg?
A poor question on my part.
How can I make this portupgrade succeed?
timtowtdi:
1. pkg_delete -af
2. rm -rf /var/db/pkg
3. touch /var/db/pkg/*/+{COMMENT,DESC}
4. pkg_delete -x failing package
5. ln -sf /usr/bin/true /usr/local/sbin/portupgrade
There is no right way. Portupgrade is a great tool which just
likes to really screw up once in a while. I guess it's a fair
payment for all the headaches it solves.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Unicode plane 1 in rxft-unicode
I wonder if anyone succeeded in getting subj working. The simplest way to test it is: - install a plane one font (e.g. I've just committed code2001) - verify it's working in firefox (after a restart) - add something like 'xft:Code2001:size=19,xft:' to 'URxvt*font:' in .Xresources, and merge it with xrdb -merge .Xresources - restart rxvt and try to view a text file with the symbols A good test case is this: http://www.code2000.net/oneplane.htm Wikipedia title page (with languages) also contains some plane one symbols. My rxvt is compiled with --enable-everything (which includes --enable-unicode3) and with all encodings. Ctrl+Shift+Click shows code point fffd for plane one characters, but then I've never seen it show codes over 16 bits. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lzma: invalid option -- s
On Sat, Apr 26, 2008 at 07:33:35PM +0200, Hans Lambermont wrote: This might be interesting to multiple ports: 7.0-R, fresh portsnap. # portmaster -bad ... === Gathering dependency list for graphics/ImageMagick from ports === Starting dependency check === The dependency for archivers/lzma seems to be handled by lzmautils-4.32.5 Deinstall lzmautils and try again. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Mon, Apr 21, 2008 at 02:42:24PM -0500, Brooks Davis wrote: That's well hidden (DOC/lzam.txt in the tarball). Someone should produce some sort of lzma-lite distribution that only does the basics. Then this could be a practical option. Unfortunately, a closer look dispelled the hope. The public-domained files only show how to use the GPL'ed ones. I had a conversation with the author, who is worried about incompatible formats being spawned if he releases lzma from under LGPL. He might change his mind in the future, though. So I guess we'll have to stick to using lzma from ports for now. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Tue, Apr 22, 2008 at 08:57:08AM -0500, Brooks Davis wrote: On Tue, Apr 22, 2008 at 02:34:39PM +0400, Andrew Pantyukhin wrote: On Mon, Apr 21, 2008 at 02:42:24PM -0500, Brooks Davis wrote: That's well hidden (DOC/lzam.txt in the tarball). Someone should produce some sort of lzma-lite distribution that only does the basics. Then this could be a practical option. Unfortunately, a closer look dispelled the hope. The public-domained files only show how to use the GPL'ed ones. I had a conversation with the author, who is worried about incompatible formats being spawned if he releases lzma from under LGPL. He might change his mind in the future, though. Too bad. :( FWIW, I don't see any significant, incompatible competitors to bzip2 or ogg vorbis (for example). It seems that GPL infects not only software, but minds also, with pure FUD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Tue, Apr 22, 2008 at 10:21:45AM -0400, Mikhail Teterin wrote: вівторок 22 квітень 2008 06:34 до, Andrew Pantyukhin Ви написали: So I guess we'll have to stick to using lzma from ports for now. Well, we lived with bzip2 from ports for quite a while... The real problem with lzma right now is that lzmautils (already marked as incompatible with lzma) installs its own lzma executable, with incompatible command-line arguments :-( Maybe, instead of marking the ports as mutually incompatible, one of them could be modified to install executables under different names?.. We had a talk with naddy about it, but since there are people using archivers/lzma with whatever syntax it has, in scripted environments, I'm inclined not to surprise them very much. I think a wrapper can be added to lzmautils for full backwards-compatibility, I may look at it later. Also, the lzmautils website claims it's of alpha-quality, so I'm also hesitant to rely on it completely. At any rate, I think having a reference implementation of lzma util in ports is a good thing. OTOH, changing lzmautils' lzma to another name would probably confuse gtar (I'm not sure though). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Operation not permitted after Updating ports
On Mon, Apr 21, 2008 at 12:15:09PM +0200, Johan Hendriks wrote: I have a small question After the update of a compat port i get the following errors after installing a port! Updating the pkgdb ... Operation not permitted - /usr/local/lib/compat/pkg/libc.so.5 Try something like chflags -R noschg /usr/local/lib/compat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lzma (Re: HEADS UP: upgrading ImageMagick to 6.4.0-6)
On Tue, Apr 15, 2008 at 10:07:54PM -0500, Brooks Davis wrote: On Tue, Apr 15, 2008 at 10:35:30PM -0400, Mikhail Teterin wrote: 15 ??? 2008 10:21 ??, Brooks Davis ?? : Sadly, the author's licensing terms will limit the adoption of lzma. The BSD license is well established as the most restrictive acceptable license for successful, widely adopted compression schemes. I wouldn't necessicairly be opposed to seeing support for tar.lzma files in bsd.port.mk, but I don't think lzma has a signficant future if the licensing policy remains as is (i.e. complex and not clearly defined in the source files). == qouth lzma.txt == SPECIAL EXCEPTION #3: Igor Pavlov, as the author of this code, expressly permits you to use code of the following files: BranchTypes.h, LzmaTypes.h, LzmaTest.c, LzmaStateTest.c, LzmaAlone.cpp, LzmaAlone.cs, LzmaAlone.java as public domain code. Without a more careful look, it sounds like enough to integrate lzma in libarchive. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Utility for safe updating of ports in base system
On Sat, Apr 12, 2008 at 07:01:15PM +0200, clemens fischer wrote: On Fri, 21 Mar 2008 17:21:10 +1100 Peter Jeremy wrote: Note that UFS is a database: If I've understood you correctly, the main problem is that there is no appropriate index to map a port directory to an installed package name. This could be fixed... sorry to be late. how about creating a special directory holding symlinks from package names to port directories? The other way around. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: results of ports re-engineering survey
On Wed, Dec 12, 2007 at 04:38:39AM -0500, Aryeh M. Friedman wrote: I have used FreeBSD since '95 and except for jerks like you have really enjoyed it. Are you quite sure it would be there to enjoy if not for jerks like us? :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFC/P] Port System Re-Engineering
On Sun, Dec 02, 2007 at 05:01:35AM -0500, Aryeh M. Friedman wrote: As has been hashed out in -ports@ over the last few days there is at least a need to examine weither or not the current ports system should remain as is or potentially be re-engineered in the future (estimates if and when needed vary from ASAP to 10-15 years). I have volunteered to undertake a feasibility/pilot project to examine what changes (if any) are needed in the system (for the purposes of this thread I will not venture any of my own suggestions). I have the following broad questions for people: You would have saved the community a couple of expensive bikesheds (and more to come, as usual) if you had cared to do some research. All of the questions you ask have already been answered hundreds of times on mailing lists over the years. By starting the cycle anew, I'm afraid, you're only contributing to the problem. There are heaps of papers on package management out there. Look for answers there and you will find them. Most of us have our own engineering demons, who breed Napoleonic plans in our heads - to solve every problem in a perfect way. The sooner we learn to control them, the better. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to distinguish direct/indirect requirements?
On Fri, Nov 23, 2007 at 11:00:32PM +0100, Alex Dupre wrote: Andrew Pantyukhin wrote: You can cd some/port/make depends One way only. It would be more useful to know which installed ports directly depend on a specific port. As an obvious working (but not nearly correct) example: pkg_direct_req pkg name or regexp #!/bin/sh indirect_reqs=`pkg_info -Rx $1|egrep -v '(:|^$)'` pkg_origin=`pkg_info -ox $1|grep -m1 /` for i in $indirect_reqs;do req_origin=`pkg_info -o $i|grep /` depdirs=`cd /usr/ports/$req_origin;make -V _DEPEND_DIRS` if echo $depdirs|grep -qw $pkg_origin;then echo $i is a direct req fi done ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to distinguish direct/indirect requirements?
On Fri, Nov 23, 2007 at 10:49:35AM +0100, Lapo Luchini wrote: Is there a way to discriminate direct dependencies fro indirect ones, except from reading every single Makefile? (and knowing to full extent what USE_GNOME and similar lines really do take in as deps) You can cd some/port/make depends, but personally, I've also always thought that the difference between direct and indirect dependencies should be embedded in the package system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Package Building in the Large
On Thu, Nov 22, 2007 at 07:13:04AM -0800, Jason C. Wells wrote: ... Not all dependencies had a package built for them. For my list of 31 ports that I actually desired to build there was a dependency list (make all-depends-list) of 758 ports. Of those 758 ports there were 427 packages built. I also ended up with shared a library version problem in at least one port (grip) in spite of having started my build with a completely vacant /usr/local. ... I would also like the portmanagers to know that I think they do a bang-up job. I just have my ultra narrow fussy roll your own way of doing things. I am looking for the right method _for me_. All of the above is no criticism. I usually just use pkg_create -b within simple shell scripts. It's as simple as it gets and works every time. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/117266: New port: www/linux-netscape-navigator The All-New Netscape Navigator 9.0
On Fri, Nov 16, 2007 at 03:32:44PM +0100, Pietro Cerutti wrote: The browser-prefs.js file indeed isn't part of the tarball, but gets anyway installed on my system: pkg_info -W /usr/local/lib/linux-netscape-navigator/defaults/pref/browser-prefs.js /usr/local/lib/linux-netscape-navigator/defaults/pref/browser-prefs.js was installed by package linux-netscape-navigator-9.0.0.3 The port uses the infrastructure provided by /usr/ports/www/linux-seamonkey/Makefile.common, as all other linux-gecko ports do. I think the cause is to be searched inside that file. Yep, look at the post-patch target. I can't say if that should be disabled for netscape until I examine the browser a bit deeper, but I will. In the meantime, could you please provide a complete shar or tarball of the latest version in any form. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can we have FireFox updated to 2.0.0.9 ?
On Mon, Nov 05, 2007 at 03:22:35PM -0800, Xin LI wrote: Martin Nilsson wrote: I know that we have a ports freeze but FF 2.0.0.8 have some very serious rendering bugs affecting most modern page layouts so it is not suitable to ship with any release. Yes, I think the change is trivial. Here is a patch that updates it, but I would like to hear from ahze@ and portmgr@ first (we are in a ports freeze). plugYou're welcome to try linux-firefox in the meanwhile/plug :-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NOPORTDOCS and man/info pages
On Fri, Oct 12, 2007 at 09:54:36AM -0400, Chess Griffin wrote: Hello- I am working on some small cleanup patches to a couple port Makefiles and had a few questions on how to handle man/info pages. I have come across a couple Makefiles that have something like this in post-install: .if defined(NOPORTDOCS) ... .else MAN1= portname.1 INFO= portname .endif It's my understanding after reading 5.9, 5.10, and 5.14.4 of the Porter's Handbook that the man and info page variables should be listed in the first part of the Makefile, before the .include bsd.port.pre.mk or .include bsd.port.mk for example. It also states in 5.14.4 that Note: NOPORTDOCS only controls additional documentation installed in DOCSDIR. It does not apply to standard man page and info pages. This statement seems to indicate that the above snippet would still install the man/info pages even if NOPORTDOCS was set. I have also seen where the manpage and info page are then also listed in pkg-plist, which I gather should not be the case according to 5.9 of the Porter's Handbook. So, my questions are: Is the above handling of the man and info pages correct? It seems the answer is no, but just thought I would check. Not really, but I guess there may be some special cases that warrant the handling (e.g. megabytes of manpages, etc.) How does one choose not to install man and info pages if NOPORTDOCS does not apply to them? I seem to recall that there is a NO_INSTALL_MANPAGES knob but am not sure if that's the answer or if there is a NO_INSTALL_INFOPAGES. Some people tried to respect some knobs, but in general we just always install manpages. As for infopages, we usually only install them when there are no manpages or if the manpages are insufficient. Is is correct procedure to never include man and info pages in the pkg-plist like Porter's Handbook states? Sometimes it's necessary to list manpages in plist. E.g. when there are different sets of manpages for different languages. MANLANG and MAN# can only handle one set across all languages. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea: static builds
On Thu, Oct 04, 2007 at 11:03:04PM +0400, Dmitry Marakasov wrote: Hi! I just have an idea that may be useful: static port builds. This can help produce packages without any depends, which may be useful sometimes. What I'd like to see first is some quantitative research on the benefits of it. Static builds are a lot more headache than one could imagine from a number points of view. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea: static builds
On Sat, Oct 06, 2007 at 09:20:24PM +0300, Diomidis Spinellis wrote: Andrew Pantyukhin wrote: On Thu, Oct 04, 2007 at 11:03:04PM +0400, Dmitry Marakasov wrote: Hi! I just have an idea that may be useful: static port builds. This can help produce packages without any depends, which may be useful sometimes. What I'd like to see first is some quantitative research on the benefits of it. Static builds are a lot more headache than one could imagine from a number points of view. I can give you quantitative data on the benefits of shared objects. On a web server running FreeBSD 6.2 I found 98 shared objects sharing 16,790,901 bytes of memory through 1,002 mappings. Without shared libraries the corresponding binaries would require 198,815,270 bytes - an order of magnitude more. On freefall I found 58 shared objects sharing 11,285,262 bytes of memory through 2,127 mappings. Without shared libraries the corresponding binaries would require 515,107,268 bytes - 50 times more. These are not just memory savings, but, more importantly on a modern system, they contribute to improved locality in the code cache. I've put the Perl script I used for obtaining these figures at http://www.spinellis.gr/blog/20071006/ Cool :) Here's what I get on our hosting server (lots of PHP FastCGI processes): 115 shared objects sharing 23242679 of memory with 11800 mappings. Without shared libraries 4806500943 bytes would be needed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: configure editors/vim
On Fri, Sep 14, 2007 at 07:07:46PM -0700, David E. O'Brien wrote: Brownie ports for someone that can explain why this always happens for me with ports that have OPTIONS: bash$ make cd /usr/ports/editors/vim make config; === Switching to root credentials to create /var/db/ports/vim Password: === Returning to user credentials [3]+ Stopped WITH_OPTIONS=1 make /var/db/ports/*/options, the place where options are kept, is only accessible to root. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: configure editors/vim
On Thu, Sep 13, 2007 at 02:01:22PM +0200, Gergely Sánta wrote: Hi! I'm a developer using gvim with it's tagging through exctags (somehow ctags never worked for me). As vim port have no configuration options, it can't be configured easyly through 'make config'. I'm too lazy for digging Makefile for options every time I compile new version of vim, I added configuration options to Makefile. I'm new to FreeBSD, also to it's Ports, so maybe I don't see the reasons, these options aren't in the Makefile, but maybe they should be there. Anyway, I attach my change, maybe it will be acceptable to have it's way to ports. And if not, maybe it will help for someone else too :) It's interesting to hear that from a vim (power?) user :) Personally I resent dialog(1) because it's so much faster, more hassle-free and convenient to edit make.conf(5) with vim. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
vim-script ports
On Wed, Oct 18, 2006 at 10:29:05AM +0400, Andrew Pantyukhin wrote: Any particular reason for no vim scripts in ports? I'm gonna make some, if there's no secret taboo. Better late than never :-) For the past two days I've been playing with some vim scripts. Here's a pre-alpha version of bsd.vim-scripts.mk and a tiny sample port: http://people.freebsd.org/~sat/diffs/vim-markdown.tar.bz2 The infrastructure has a separate server side, a simple shell script running on a server box which retrieves vim scripts from vim.sf.net, jumps through a couple of hoops and makes tar.bz2 distfiles out of them. I'll publish it later, along with make hooks for maintainer convenience. It's all very simple so far and I'll try to keep it that way. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.port.options.mk status
On Wed, Sep 12, 2007 at 01:18:31PM +0100, Shaun Amott wrote: On Tue, Sep 11, 2007 at 02:00:14AM +0400, Andrew Pantyukhin wrote: So am I missing something or is it as trivial as using these four lines instead of one: USEOPTIONSMK= yes INOPTIONSMK=yes .include bsd.port.mk .undef INOPTIONSMK This is even uglier than our existing work-around solutions. :-) You snipped the question I was trying to answer, which was is it possible? Now IMHO the current way of handling options is ugly as a whole. We're trying to use paradigms from other languages in make. A make solution would look more like this: SOMELIST= FOO BAR BAZ WITH_FOO_CONFIGURE_ARGS= --with-foo WITHOUT_BAZ_PLIST_SUB+=BAZ=@comment other BSD's have used this approach for some time now and it looks a lot cleaner than all the hacks we have, at least to my eyes. The reason I'm not rallying for cosmetics like that is that I fail to see make(1) as a future-proof base for ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.port.options.mk status
On Mon, Sep 10, 2007 at 06:58:34PM +0200, Pav Lucistnik wrote: Dmitry Marakasov píše v po 10. 09. 2007 v 19:26 +0400: * Pav Lucistnik ([EMAIL PROTECTED]) wrote: It's possible to use this feature, but only on -CURRENT and -STABLE FreeBSD systems newer than certain date. No existing release supports it - it will be supported in upcoming 6.3 and 7.0. Erm, isn't ports code (more or less) release-independent? What's missing in existing FreeBSD versions that's needed to support options.mk? The make only looks into /usr/share/mk for includes, until told otherwise. bsd.port.options.mk is included before bsd.port.pre.mk, so it can't be found. Base system was modified to install stub of the same name into /usr/share/mk to workaround this problem. Understood. Then we really have to wait till 5.5 and 6.2 EOL to use options.mk... That's a bit strange to wait multiple years for an useful feature, aren't there any workaround planned? The question is, are there any workarounds possible? So am I missing something or is it as trivial as using these four lines instead of one: USEOPTIONSMK= yes INOPTIONSMK=yes .include bsd.port.mk .undef INOPTIONSMK ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to squid-2.6.15 is not recommended.
On Mon, Sep 10, 2007 at 12:04:29PM +0400, Sergey Matveychuk wrote: Thomas-Martin Seck wrote: * RW [EMAIL PROTECTED] [gmane.os.freebsd.devel.ports]: The squid site is recommending that people skip 2.6.15 and go straight to 2.6.16 The Squid maintainer can not resist to recommend that people look at what the FreeBSD port of Squid-2.6.STABLE15 actually delivers. :-) I'd like to thank Thomas-Martin Seck for maintaining squid ports. It's the one of little numbers ports those I'm sure work and stable after upgrade. Really great work! Same here. Squid is one of those ports I'm always proud to show off to my Linux-stuck friends. That said, I'm very grateful to hundreds of other maintainers. This is just a convenient moment to say that tmseck really does a great job. Thanks, man! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADSUP] bsd.perl.mk import coming soon
On Tue, Sep 11, 2007 at 09:12:26AM +1000, Edwin Groothuis wrote: On Tue, Sep 11, 2007 at 01:50:39AM +0400, Andrew Pantyukhin wrote: On Sun, Sep 09, 2007 at 10:57:50AM +1000, Edwin Groothuis wrote: On Sat, Sep 08, 2007 at 06:40:23PM +0200, Erwin Lansing wrote: On Sat, Sep 08, 2007 at 10:30:51AM +0200, Henrik Brix Andersen wrote: On Fri, Sep 07, 2007 at 11:33:42PM +, Mark Linimon wrote: The main feature of the change will be to allow USE_PERL5= 5.8.0+ (and similarly for USE_PERL5_RUN, USE_PERL5_BUILD, PERL_CONFIGURE and PERL_MODBUILD). As a side-effect, the remaining few stragglers that attempt to keep perl5.003 going will be dropped. (Other committers have also been removing that code). Great! A big thank you to all who helped get this work done :) Let me chime in and thank everyone, especially Gabor for writing and Mark for testing this. This was a long needed feature that gets rid of a huge number of cumbersome workarounds. Thanks a lot! An idea for next summer: PERL_RUN_DEPENDS=Foo::Bar (I know I've done by best for this one, and it failed here and there) That would really be a killer feature. Applicable to other areas like CPAN-like repos (rubygems, pypi, pear/pecl, etc.) See http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/87318. It came into bsd.port.mk once, but it was removed after people complained too much. What I am thinking about is not having to specify which port to install from. A module name should be enough. Some kind of (CPAN-based?) registry is needed for this to work. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: rsyslog-1.17.4
On 8/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Trying to install rsyslog from ports and getting the following error: net.h:72: warning: struct sockaddr_storage declared inside parameter list net.h:72: warning: its scope is only this definition or declaration, which is probably not what you want omfwd.c: In function `doAction': omfwd.c:571: error: `AI_NUMERICSERV' undeclared (first use in this function) omfwd.c:571: error: (Each undeclared identifier is reported only once omfwd.c:571: error: for each function it appears in.) omfwd.c: In function `parseSelectorAct': omfwd.c:854: error: `AI_NUMERICSERV' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/sysutils/rsyslog/work/rsyslog-1.17.6. *** Error code 1 Stop in /usr/ports/sysutils/rsyslog/work/rsyslog-1.17.6. *** Error code 1 Stop in /usr/ports/sysutils/rsyslog. System is FreeBSD 5.x STABLE, here is uname: FreeBSD rjclark1.mdacc.tmc.edu 5.5-STABLE FreeBSD 5.5-STABLE #0: Fri Jul 20 10:08:31 CDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MDACC1 i386 Is there an issue with my system, or is something broken in the code? I'm afraid 5.x may have differences from 6.x substantial enough to break rsyslog. I'll wait for our package-building cluster and see if it can reproduce the error, but if it does, I'll probably just mark rsyslog broken on 5.x. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mail/horde
On 7/20/07, Jonathan Horne [EMAIL PROTECTED] wrote: On Friday 20 July 2007 08:36:38 Jonathan Horne wrote: i am trying to setup mail/horde on a test box, but so far i am not having much success. can anyone direct me to a place where i might find tips or documentation for setting up the *current* port version of horde? sorry, i meant to say www/horde-meta. Why don't you try to contact its maintainer (cc'ed)? Good luck! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: lzma-4.48
On 7/6/07, Eric Kingston [EMAIL PROTECTED] wrote: There is a bug in LZMA running on amd64. LZMA, an archiver port, segmentation faults on files 1-5 GB in size. I've tested this on three different xeon dual multi-core processor servers. In each case, lzma core dumps in the exact same spot and the resulting file size for each is exactly the same. Files less than 1 GB seem to work ok. LZMA seems to work on any size file without a problem on the FreeBSD i386 platform. When I spoke with a friend of mine, he says that he compresses 160GB files daily without a problem, on his i386 systems. P.S. Here is my machine info.. FreeBSD elrond.esreco.net 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #0: Sun Jun 17 13:37:57 MDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELROND amd64 Thanks for your report! To achieve the best/quickest possible result, could you also: 1. Try a previous version 2. File your bug report with the 7zip project 3. Get a gdb backtrace out of the coredump I'm sorry but I don't have time to do it all right now. I will look into it at the first opportunity, though. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jdk - broken dependency on compat6x
On 6/28/07, Greg Lewis [EMAIL PROTECTED] wrote: On Thu, Jun 28, 2007 at 08:58:22PM +0400, Andrew Pantyukhin wrote: The c.6 dependency does not work if you have linux base installed (thanks to /compat/linux/lib/libc.6) How about depending on z.3 instead? How about LIB_DEPENDS only checks native shared libraries for a native port? This seems like it could easily affect a whole variety of ports once linux base is installed. switching to ports@ Yes, sounds like a sane idea. Actually, to simplify it, we can always ignore libs in linuxbase. Linux ports only use run_depends anyway. So it boils down to an extra grep -v in lib_depends processing in bsd.port.mk. Still, it will probably take no less than a month to get it committed, so how about changing the java ports now and saving many users a headache? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compat6x
On 6/6/07, Kris Kennaway [EMAIL PROTECTED] wrote: Is anyone working on a compat6x port? mnag is ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More speed increases for make-ing ports
On 5/24/07, Mark Linimon [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 05:34:32PM +0400, Andrew Pantyukhin wrote: A seemingly better way may be to make these system vars available in make by default. Doesn't help anyone who runs -RELEASE, so a non-starter. You can go ahead and say that about almost every commit to src. They don't help release-runners immediately, but we're not in a hurry, are we. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discontinued projects
On 5/24/07, Thierry Thomas [EMAIL PROTECTED] wrote: Le Jeu 24 mai 07 à 12:16:26 +0200, Gabor Tjong A Hung [EMAIL PROTECTED] écrivait: What happens with discontinued projects? They seem to pollute our ports tree. http://tmsnc.sourceforge.net/ seems to indiacte that the project is discontinued. Shouldn't its port be removed from the ports tree then? I've noticed the same with several other ports. http://koti.mbnet.fi/jarmonik/MathPlanner.html aka editors/MathPlanner Well, if they are still usuable, why would we remove them? In the future, they might break for some reason (unfetchable, broken with a new compiler version, not compatible with some dependency, etc.): at this time, let's see if someone take time to fix them; if not, they will be marked as deprecated, and then removed. Moreover, many abandoned projects continue to live in OS-local repositories. Debian have dozens (hundreds?) of such packages, our ports also have some. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More speed increases for make-ing ports
On 5/22/07, Kris Kennaway [EMAIL PROTECTED] wrote:
On Tue, May 22, 2007 at 01:47:23AM -0500, Stephen Montgomery-Smith wrote:
This small modification cuts off about 25% off pkg_version on my system.
Basically bsd.gnome.mk recursively finds all the dependencies, but many
of them are listed many times. This makes make work extra hard when it
doesn't have to. I simply weed out the repeated entries.
--- bsd.gnome.mk-orig Tue May 22 01:29:08 2007
+++ bsd.gnome.mk Tue May 22 01:29:22 2007
@@ -655,6 +655,8 @@
_USE_GNOME+= ${${component}_USE_GNOME_IMPL} ${component}
. endfor
+_USE_GNOME!=(for i in ${_USE_GNOME}; do ${ECHO_CMD} $$i; done) | sort -u
+
# Setup the GTK+ API version for pixbuf loaders, input method modules,
# and theme engines.
PLIST_SUB+= GTK2_VERSION=${GTK2_VERSION}
Be careful, != assignments may add thousands of process invocations to
large targets like 'make index' and can slow it down dramatically.
Right, and uniqueness logic can be implemented in make.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More speed increases for make-ing ports
On 5/22/07, Alexander Leidinger [EMAIL PROTECTED] wrote:
Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Tue, 22 May
2007 11:55:39 +0400):
On 5/22/07, Kris Kennaway [EMAIL PROTECTED] wrote:
On Tue, May 22, 2007 at 01:47:23AM -0500, Stephen Montgomery-Smith wrote:
This small modification cuts off about 25% off pkg_version on my system.
Basically bsd.gnome.mk recursively finds all the dependencies, but many
of them are listed many times. This makes make work extra hard when it
doesn't have to. I simply weed out the repeated entries.
--- bsd.gnome.mk-orig Tue May 22 01:29:08 2007
+++ bsd.gnome.mk Tue May 22 01:29:22 2007
@@ -655,6 +655,8 @@
_USE_GNOME+= ${${component}_USE_GNOME_IMPL} ${component}
. endfor
+_USE_GNOME!=(for i in ${_USE_GNOME}; do ${ECHO_CMD} $$i; done) | sort -u
+
# Setup the GTK+ API version for pixbuf loaders, input method modules,
# and theme engines.
PLIST_SUB+= GTK2_VERSION=${GTK2_VERSION}
Be careful, != assignments may add thousands of process invocations to
large targets like 'make index' and can slow it down dramatically.
Right, and uniqueness logic can be implemented in make.
Be proactive and tell/point out how... :)
TMTOWTDI. There are several examples in bsd.*.mk. The
obvious one is flags (you set or unset flag vars
first, then traverse them and add what you need to
the list). In recent versions of our make you can
also use ${VAR:O:u}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More speed increases for make-ing ports
On 5/22/07, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote:
Andrew Pantyukhin wrote:
On 5/22/07, Alexander Leidinger [EMAIL PROTECTED] wrote:
Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Tue, 22 May
2007 11:55:39 +0400):
On 5/22/07, Kris Kennaway [EMAIL PROTECTED] wrote:
On Tue, May 22, 2007 at 01:47:23AM -0500, Stephen Montgomery-Smith
wrote:
This small modification cuts off about 25% off pkg_version on my
system.
Basically bsd.gnome.mk recursively finds all the dependencies, but
many
of them are listed many times. This makes make work extra hard
when it
doesn't have to. I simply weed out the repeated entries.
--- bsd.gnome.mk-orig Tue May 22 01:29:08 2007
+++ bsd.gnome.mk Tue May 22 01:29:22 2007
@@ -655,6 +655,8 @@
_USE_GNOME+= ${${component}_USE_GNOME_IMPL} ${component}
. endfor
+_USE_GNOME!=(for i in ${_USE_GNOME}; do ${ECHO_CMD} $$i; done) |
sort -u
+
# Setup the GTK+ API version for pixbuf loaders, input method
modules,
# and theme engines.
PLIST_SUB+= GTK2_VERSION=${GTK2_VERSION}
Be careful, != assignments may add thousands of process invocations to
large targets like 'make index' and can slow it down dramatically.
Right, and uniqueness logic can be implemented in make.
Be proactive and tell/point out how... :)
TMTOWTDI. There are several examples in bsd.*.mk. The
obvious one is flags (you set or unset flag vars
first, then traverse them and add what you need to
the list). In recent versions of our make you can
also use ${VAR:O:u}
I must admit I was looking for the :u. Definitely a good feature -
maybe it could be invoked in the make file conditional on an appropriate
value of OSVERSION.
Incidently if you want to save a few more != assignments, I notice that
setting the variables
ARCH=i386
OPSYS=FreeBSD
OSREL=6.2
OSVERSION=602110
in /etc/make.conf will do this for you.
A seemingly better way may be to make these system vars
available in make by default. They may even be compiled
in - to achieve virtually no performance impact (except
for a bit larger default var table).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Gstreamer80 is scheduled for removal in 9 days.
On 5/22/07, Michael Johnson [EMAIL PROTECTED] wrote: multimedia/gstreamer80 has been marked DEPRECATED and has an EXPIRATION_DATE of 2007-05-31. The following ports depend on gstreamer80 ... Please update your ports to use gstreamer 0.10. We will probably extend the removal since there are so many ports that depend on gstreamer80. Seems like many of those depend indirectly (through wxgtk or otherwise). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Gstreamer80 is scheduled for removal in 9 days.
On 5/22/07, Michael Johnson [EMAIL PROTECTED] wrote: On May 22, 2007, at 11:29 AM, Jona Joachim wrote: On Tue, 22 May 2007 19:18:57 +0400 Andrew Pantyukhin [EMAIL PROTECTED] wrote: On 5/22/07, Michael Johnson [EMAIL PROTECTED] wrote: multimedia/gstreamer80 has been marked DEPRECATED and has an EXPIRATION_DATE of 2007-05-31. The following ports depend on gstreamer80 ... Please update your ports to use gstreamer 0.10. We will probably extend the removal since there are so many ports that depend on gstreamer80. Seems like many of those depend indirectly (through wxgtk or otherwise). Yes, wxgtk26 depends on gstreamer80. Will wxgtk26 be updated to use gestreamer 0.10 or should those ports that depend on wxgtk26 be modified to use wxgtk28 instead? We're one of the only projects that still has wxgtk26 depending on gstreamer80 gentoo, fedora, debian, etc don't. I was about to say you're talking like you're not on the gnome team, but I see fjoe is maintainer, so we should all probably just blame Max :-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: minimizing downtime on upgrades? (for example: mysql 4.1 - 5.0 or php)
On 5/22/07, Olivier Mueller [EMAIL PROTECTED] wrote: Hello, Some freebsd-beginner questions about how to maintain a production server up to date day after day, with a practical example: now I have to update a 6.1-based server from mysql 4.1 to mysql 5.0, minimizing the downtime during the upgrade. In the past under other OS'es I would have taken the mysql source, compiled the whole, and then on upgrade time: - stopped the services (httpd, etc.) - mysqldump of all tables - stopped mysqld - removed the old version (+backup) - 'make install'ed the new one - started mysqld - imported the db and restarted the other services - 2-3 minutes downtime, depending on the size of the databases Now I can't really do that under FreeBSD: if I want to prepare (just make in the ports directory) the mysql50-server part, it answers: [EMAIL PROTECTED] /usr/ports/databases/mysql50-server]# make === mysql-server-5.0.41 cannot install: MySQL versions mismatch: mysql41-client is installed and wanted version is mysql50-client. *** Error code 1 Stop in /usr/ports/databases/mysql50-server. So I can only do that after the installation of mysql50-client, which means all the services will have to be stopped during the compilation of mysql50-server, which usually takes some time. Isn't there a better way? How do you handle such cases? Same questions for php upgrades: on php5 upgrade, all the other php5-* packages have to be compiled too, and keeping the webserver running during this time is probably not the best idea. You raise a very good question. Concurrent versions have been a major feature of some enterprise-class package management systems for years now. Through local hacks, FreeBSD ports only enable us to achieve that in a tiny amount of cases (e.g. you can have multiple [but fixed] versions of autoconf installed at the same time). To make the feature available on a larger scale, we'll need to rework much of our current infrastructure. E.g. most probably we'll have to install ports into dedicated directories. This springs has already reignited many talks about the ports system. Let's hope we'll see some substantial results by the end of the year. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X.org 7.2 ports merged into the FreeBSD Ports Tree
On 5/20/07, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Peter Jeremy [EMAIL PROTECTED] writes: That rates as the biggest commit I recall seeing: - Affecting 7868 files - Updating 6168 ports - Creating 255 new ports - 700KB, 14553 line commit message The commit message never showed up in my inbox... Freshports never saw it, either: http://www.freshports.org/x11/xorg/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
On 5/13/07, Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 01:11:15AM +0400, Andrew Pantyukhin wrote: On 5/13/07, Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 01:00:51AM +0400, Andrew Pantyukhin wrote: mergebase.sh failed, probably because my system is quite dirty. Even after I removed the conflicting files, it just failed. I've made the merge myself and been living happily ever since (so far). Hmm, would be nice to know why. I'll try to look closer at it on my laptop. Something tells me it'll fail there too, because it's my development system and it's as dirty as it gets. Running sh -x will help. It fails at line 81. The problem is when there are empty dirs in /usr/X11R6, they cause File exists errors, but don't get deleted. Reproducible this way: # rm -rf /usr/X11R6 # mkdir /usr/X11R6 # run mergebase ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [NEW PORT] ports-mgmt/pkg - smart tool for managing FreeBSD ports
On 5/12/07, Andy Kosela [EMAIL PROTECTED] wrote: Hi all, I would like to present to you the new utility to deal with the ports system. The main goal of this project is to provide one common tool for managing ports and packages instead of relying on many applications (pkg_add, pkg_delete, pkg_info, pkg_version etc.). Actually it is a smart wrapper written in /bin/sh to the previously mentioned applications. It also uses external tool portmaster written also in /bin/sh by Doug Barton to work with the ports compiled from source. Pkg tool automates upgrading installed packages, outputs valuable information about packages/ports and overall simplifies working with the FreeBSD Ports Collection. It uses no external databases like portupgrade, just simplicity and minimalism are its main goals. You can test the latest version by installing the package from here http://home.si.rr.com/pyn/pf/pkg-1.1.tbz I commited pkg-1.0 with send-pr to the ports tree a few days ago. It is awaiting approval... http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/112572 Feel free to send any suggestions, new ideas and of course bug reports... First of all, can you consider renaming it to something less ambitious? A tool named pkg is already present in some other systems (e.g. pkgjam in NetBSD). It would be a pity to see your tool, however marvelous it is, squatter the name just because it was the earliest one. That said, your tool is very welcome. P.S. You wanted to post your message to ports@, not [EMAIL PROTECTED] Cc fixed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
Reporting success on one of my desktops. It's a current/i386 box with a little over 1000 packages (after the upgrade). I used portupgrade-devel, but started with stale INDEX. For this reason or not, I stumbled upon the libXft quirk. Stopped the upgrade when I saw a few pkg_create's to take far too long because of dependency loop, rebuilt the INDEX with make index (portsdb -U didn't work for me), ran pkgdb -F and after that portupgrade -a finished without any major surprises. mergebase.sh failed, probably because my system is quite dirty. Even after I removed the conflicting files, it just failed. I've made the merge myself and been living happily ever since (so far). Waiting for portupgrade -a to finish on my laptop. Thanks, Kris and all of you guys for making this step as painless as possible - for me and everyone. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
On 5/13/07, Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 01:00:51AM +0400, Andrew Pantyukhin wrote: Reporting success on one of my desktops. It's a current/i386 box with a little over 1000 packages (after the upgrade). I used portupgrade-devel, but started with stale INDEX. For this reason or not, I stumbled upon the libXft quirk. Stopped the upgrade when I saw a few pkg_create's to take far too long because of dependency loop, rebuilt the INDEX with make index (portsdb -U didn't work for me), ran pkgdb -F and after that portupgrade -a finished without any major surprises. Can you confirm that you started by doing portupgrade -Rf libXft and it still gave the dependency loop? Nope, I actually misread UPDATING and thought portupgrade-devel didn't need it. [ try s/nor/not/ in the message :) ] mergebase.sh failed, probably because my system is quite dirty. Even after I removed the conflicting files, it just failed. I've made the merge myself and been living happily ever since (so far). Hmm, would be nice to know why. I'll try to look closer at it on my laptop. Something tells me it'll fail there too, because it's my development system and it's as dirty as it gets. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
On 5/11/07, Edwin Groothuis [EMAIL PROTECTED] wrote: On Thu, May 10, 2007 at 05:28:17PM -0400, Kris Kennaway wrote: Dear porters, We are now ready for xorg 7.2 testing! Over the past week we have done extensive tests of various upgrade scenarios, fixed many remaining bugs, and now the upgrade is looking good. Of course, we can't possibly test everything, so that's where you come in. What we need now is for everyone to download this tarball: http://people.freebsd.org/~kris/ports-xorg-7.2.tbz http://people.FreeBSD.org/~ade/ports-xorg-7.2-nogit.tar.bz2 is only 28Mb http://people.freebsd.org/~sat/diffs/ports.xorg72.diff.bz2 is only 461 Kb In fact, that's what we've been promised - a diff :-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: www/linux-firefox JavaScript Versions?
On 5/2/07, Jesse Scott [EMAIL PROTECTED] wrote: Why is www/linux-firefox version 2.0.0.3 built using JavaScript version 1.4? Check the link below to see the JavaScript version you are using: http://tychousa3.umuc.edu/sys/browserinfo.html linux-firefox uses the official binary from mozilla.com. AFAICT, the browser check is just bogus. (http://tychousa3.umuc.edu/js/browsercheck.js) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sudo insults
On 5/2/07, Dan Casey [EMAIL PROTECTED] wrote: I'm guilty of not reading the handbook.. I just assumed that revision had to be bumped up. Or perhaps the reason for bumping it up is to prevent systems from recompiling the port for no reason. Anyway, I have attached the fixed unified diff. Committed, thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xpi updates
On 3/30/07, Andrew Pantyukhin [EMAIL PROTECTED] wrote: Dear xpi-extensions maintainers, Some of you granted me an implicit approval for routine updates of your xpi ports. That was some time ago and now I ask you to renew the approval. If you want to, just reply to this mail (you don't need to include all the recipients, of course) to tell me it's okay. I would gladly send you patches for approval, but in most cases an update takes a few seconds, while the total time spent on patches and approvals can amount to minutes per update. It's just a question of efficiency. Dear Chin-San, Andrey and Stanislav! All other xpi-maintainers have already responded. Here's a short list of out-of-date extensions: xpi-unplug xpi-sessionmanager xpi-vimperator I'll be glad if you could grant me an implicit approval to update your xpi-ports for you whenever I perform version-bump sweeps of my own ports. Stanislav, welcome to our little xpi club :-) When dealing with others' ports I usually try to be as little intrusive as possible - performing only the very necessary/minor changes and keeping the style intact. Anyway, it's okay if all of you prefer to keep your ports to yourself, but I would appreciate a (negative) response anyway just to be sure it's not a matter of a lost e-mail. Thanks guys! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bundling Kwiki
On 4/23/07, Cheng-Lung Sung [EMAIL PROTECTED] wrote: Hi, Quote from http://search.cpan.org/src/INGY/Kwiki-0.39/README Kwiki is *really* simple to install now. _All_ the Perl dependencies come with Kwiki, and are /preinstalled/. This means you just need Perl 5.8.3 and a web server. Well actually we give you a web server too!... ... ... Eventually all this work will make it back to CPAN, but likely not for a while. The kwiki-trunk-*.tar.gz already do so (bundling almost every plugin) I think I'd better take off these plugins from ports tree before 'Ingy dot net' put them back. Just IMHO. :-) That *really* simple was directed to poor Linux/Solaris admins, who mostly have to install everything manually. Bundles are evil :-) It's your call, of course, and considering the devs aren't going to push the stuff back to CPAN for a while, it seems you've made the right choice. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Bundling Kwiki
First of all, thanks for taking up the initiative and updating Kwiki. It's a worthy project. Do we want to bundle Kwiki into a single port? In ports we usually consider bundling (of any software project) a harmful thing, as opposed to modularizing. I haven't looked at those new Kwiki snapshots, but is it too hard to update all those p5-Kwiki-* ports instead of merging them into the main one? Never mind if it's too much work... Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Warnings added to INDEX
On 4/20/07, Kris Kennaway [EMAIL PROTECTED] wrote: /a/portbuild/amd64/7/ports/deskutils/linux-sunbird/ ../../www/linux-seamonkey/Makefile.common, line 43: warning: duplicate script for target post-extract ignored Fixed, sorry. Thanks for a heads-up! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP error
On 4/9/07, Beech Rintoul [EMAIL PROTECTED] wrote: I have a port which calls php -m as a test from the makefile. Problem is if I do php -m I get the following: stargate# php -m /libexec/ld-elf.so.1: /usr/local/lib/php/20060613/imap.so: Undefined symbol ssl_onceonlyinit I tried rebuilding php the module involved, but no joy. Does anyone have a suggestion? I'm running the following: FreeBSD 7.0-CURRENT #113: Sun Apr 8 08:27:49 AKDT 2007 Apache-2.0.59 php5-5.2.1_3 php5-imap-5.2.1_3 This worked about a month ago. Did you follow UPDATING when upgrading ports? In particular, there's been a gettext and some other interesting updates. If all else fails, go the pkg_delete -a way. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Package A should replace Package B
On 4/9/07, Alagarsamy [EMAIL PROTECTED] wrote: I had package A and package B. Package A does all the functions of Package B and some more functions. So installing package A should replace package B. So i need to have a 'REPLACES' like directive in Makefile of Package A which says package A should replace package B. currently I can't find 'REPLACES' directive. Is there any otherway we can achieve this ? Not this time of year, and it's not as simple as you sound. Just tell the user he needs to remove some packages before installing this one, and/or just set CONFLICTS. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: gnono-1.9.1_1 failed on amd64 7]
On 4/4/07, Kris Kennaway [EMAIL PROTECTED] wrote: === cc1: warnings being treated as errors In file included from /usr/local/include/libgnome-2.0/libgnome/gnome-program.h:41, from /usr/local/include/libgnome-2.0/libgnome/gnome-init.h:30, from /usr/local/include/libgnome-2.0/libgnome/gnome-config.h:34, from game.c:31: /usr/local/include/popt.h:444: warning: type qualifiers ignored on function return type gmake[3]: *** [game.o] Error 1 gmake[3]: Leaving directory `/work/a/ports/games/gnono/work/gnono-1.9.1/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/work/a/ports/games/gnono/work/gnono-1.9.1/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/work/a/ports/games/gnono/work/gnono-1.9.1' gmake: *** [all] Error 2 *** Error code 2 === popt has a few places like this: const char *const poptStrerror(const int error)... I see the samba project patched this: http://lists.samba.org/archive/samba-cvs/2006-May/067499.html Should we do the same? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and NetBSD's pkgsrc: A strategic synergy for awesomeness
On 4/2/07, Bill Moran [EMAIL PROTECTED] wrote: OK. I have to know ... who took all the time to write that all up? Look into the headers and grep our mailing-list archives for peculiar ones, like bofh ;-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: twiki-4.1.0,1
On 3/30/07, David Christensen [EMAIL PROTECTED] wrote: Andrew: Thank you for your reply. Be sure to backup your data before every update if you use twiki from ports. It (the port) doesn't support updates, only the first time install. Personally, I maintain my twiki installation manually. Twiki is quite complicated to make a good port out of it. Okay. I'm trying to get a fresh install working. Should I download the current version, or will you be releasing an updated port? Either way, be sure to know that 4.1.0 (and maybe 4.1.1) has security holes in it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
xpi updates
Dear xpi-extensions maintainers, Some of you granted me an implicit approval for routine updates of your xpi ports. That was some time ago and now I ask you to renew the approval. If you want to, just reply to this mail (you don't need to include all the recipients, of course) to tell me it's okay. I would gladly send you patches for approval, but in most cases an update takes a few seconds, while the total time spent on patches and approvals can amount to minutes per update. It's just a question of efficiency. Here's a tentative list of outdated extensions: display qouta adblock plus cutemenus crystalsvg session manager stumbleupon unplug That's a small list and it means you're doing a great job! In other news, addons.mozilla.org engine has been updated. New releases are to be found in addons/ XPI_NUM subfolders (as opposed to extensions/ XPI_DISTNAME). So if you're updating/adding a recent release from addons.mozilla.org, you should notice the number in its URL (usually 3 or 4 digits) and set XPI_NUM=number in the port. The xpi infrastruc- ture will then seek the distfiles in the proper subfolder. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: twiki-4.1.0,1
On 3/29/07, David Christensen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: I recently made and installed TWiki 4.1.0, and have run into some issues. When I check the TWiki project site: http://twiki.org/cgi-bin/view/Codev/DownloadTWiki they have released a newer version. Should I download and install that, or will you be updating the FreeBSD port soon? Be sure to backup your data before every update if you use twiki from ports. It (the port) doesn't support updates, only the first time install. Personally, I maintain my twiki installation manually. Twiki is quite complicated to make a good port out of it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How many distfile downloads
On 3/24/07, Karel Miklav [EMAIL PROTECTED] wrote: I'm thinking about putting a larger distfile on my server and I'd like to know how it will affect the bandwidth. How many downloads can be expected from automated processes? Is there any statistics for port popularity or something? Could somebody please give me a number of downloads for his distfiles? I'm thinking about setting up an automated on-demand mirroring for BSD ports. Until that happens, I can deal with some requests manually. Tell me more about your distfile, if you want to. As for stats, my hoster password-protects them, I'll try to publish them though. You can get anywhere from 0 downloads to 100-200 a day depending on many things. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New port - please review
On 3/25/07, KillFill [EMAIL PROTECTED] wrote: Hello Marcin! actually the BSD# ports repo, already got gnome-subtitles! already as in 2 hours after Marcin's mail? It happens all the time - two people working on the same thing independently. I'm sure you both did a great job porting gnome-subtitles. Just be sure to mention each other when it gets committed. Cheers! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml)
On 3/21/07, Alexander Leidinger [EMAIL PROTECTED] wrote: When you need a program which needs a newer lib than installed on a production system, but you don't get a maintenance window to update all other programs which use this lib, then not having the old lib will hurt. When the reason for the library version bump also requires to change some parts in the source of the programs which make use of the lib, you have to update all programs at once. If some programs have bugs in more recent versions which you can't accept in production and when you need to install a program which needs the new lib version, you are busted when you don't have the old lib around. But don't you smell an architectural flaw here (of the ports system) and don't you feel that working around it in a tool in the base system might only mess things up even more?.. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml)
On 3/21/07, Pav Lucistnik [EMAIL PROTECTED] wrote: Andrew Pantyukhin píše v st 21. 03. 2007 v 11:31 +0300: On 3/21/07, Alexander Leidinger [EMAIL PROTECTED] wrote: When you need a program which needs a newer lib than installed on a production system, but you don't get a maintenance window to update all other programs which use this lib, then not having the old lib will hurt. When the reason for the library version bump also requires to change some parts in the source of the programs which make use of the lib, you have to update all programs at once. If some programs have bugs in more recent versions which you can't accept in production and when you need to install a program which needs the new lib version, you are busted when you don't have the old lib around. But don't you smell an architectural flaw here (of the ports system) and don't you feel that working around it in a tool in the base system might only mess things up even more?.. No I don't see a systematic flaw here. Or you suggest we reset all shmajors everywhere to zero? I would suggest that multiple versions of any port should be allowed to be installed simultaneously - and without the burden of introducing versioned ports. I do not volunteer just yet to propose an outline of a solution to make that possible, but workarounds have a tendency to be tolerated in the long run once introduced into the base system. objformat tool is a nice example of such a workaround. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml)
On 3/21/07, Pav Lucistnik [EMAIL PROTECTED] wrote: Andrew Pantyukhin píše v st 21. 03. 2007 v 13:55 +0300: On 3/21/07, Pav Lucistnik [EMAIL PROTECTED] wrote: Andrew Pantyukhin píše v st 21. 03. 2007 v 11:31 +0300: On 3/21/07, Alexander Leidinger [EMAIL PROTECTED] wrote: When you need a program which needs a newer lib than installed on a production system, but you don't get a maintenance window to update all other programs which use this lib, then not having the old lib will hurt. When the reason for the library version bump also requires to change some parts in the source of the programs which make use of the lib, you have to update all programs at once. If some programs have bugs in more recent versions which you can't accept in production and when you need to install a program which needs the new lib version, you are busted when you don't have the old lib around. But don't you smell an architectural flaw here (of the ports system) and don't you feel that working around it in a tool in the base system might only mess things up even more?.. No I don't see a systematic flaw here. Or you suggest we reset all shmajors everywhere to zero? I would suggest that multiple versions of any port should be allowed to be installed simultaneously - and without the burden of introducing versioned ports. How would that work? I'm curious. Several systems have such a feature. SEPP for one. I do not volunteer just yet to propose an outline of a solution to make that possible, but workarounds have a tendency to be tolerated in the long run once introduced into the base system. objformat tool is a nice example of such a workaround. Let's say I prefer a working system now than neatly designed system in 2014. Will you have figured out how to work around similar problems with all other dependency cases by 2014? There are libraries in interpreted languages, static libs, and just old programs that require old programs to function. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems running pkgdb -fF
On 3/19/07, Joe Marcus Clarke [EMAIL PROTECTED] wrote: Running pkgdb -Ff today gives me the following error: Just a me too here, and this problem appears during portupgrade runs, too. Also, portupgrade-devel has been almost unusable for me for some time now, on different machines. It's dependency harvesting is quite strange; portupgrade -a starts installing a lot of irrelevant packages. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems running pkgdb -fF
On 3/20/07, Sergey Matveychuk [EMAIL PROTECTED] wrote:
Andrew Pantyukhin wrote:
On 3/19/07, Joe Marcus Clarke [EMAIL PROTECTED] wrote:
Running pkgdb -Ff today gives me the following error:
Just a me too here, and this problem appears during
portupgrade runs, too.
Try the patch please. I could not find a box where I can reproduce the
error, so it's not tested. Just a obvious quick fix.
Index: pkgtools.rb
===
RCS file: /cvsroot/portupgrade/pkgtools/lib/pkgtools.rb,v
retrieving revision 1.16.2.4
diff -u -r1.16.2.4 pkgtools.rb
--- pkgtools.rb 27 Feb 2007 11:34:59 - 1.16.2.4
+++ pkgtools.rb 20 Mar 2007 17:18:35 -
@@ -790,8 +790,7 @@
contents_file = $pkgdb.pkg_contents(pkgname)
if grep_q_file(/[EMAIL PROTECTED] \t]+ORIGIN:/, contents_file)
-command = shelljoin('sed',
- s|^\\(@comment[ \t][
\t]*ORIGIN:\\).*$|\\1#{origin}|)
+command = sed s|^\\(@comment[ \t][ \t]*ORIGIN:\\).*$|\\1#{origin}|
else
command = (cat; echo '@comment ORIGIN:#{origin}')
end
Stale origin: 'x11-wm/fluxbox-devel': perhaps moved or obsoleted.
- The port 'x11-wm/fluxbox-devel' was moved to 'x11-wm/fluxbox' on
2007-03-19 because:
Merged into x11-wm/fluxbox
1x11-wm/fluxbox: not found
^(@comment[: not found
sed: 1: s: substitute pattern can not be delimited by newline or backslash
Fixed. (- x11-wm/fluxbox)
At least the error is shorter now. I can make my
/var/db/pkg available if you want.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port Makefiles and the MANPREFIX macro
On 9/15/06, Kris Kennaway [EMAIL PROTECTED] wrote:
On Fri, Sep 15, 2006 at 02:25:14AM -0400, Kris Kennaway wrote:
On Fri, Sep 15, 2006 at 07:22:15AM +0100, Matt Dawson wrote:
Hi all,
Currently doing battle with some port updates and I have come across a
strange problem. It's probably my fault, but some guidance would be
appreciated.
Three of the ports I maintain have decided that the man pages belong in
${PREFIX}/share/man/man(n). Now, reading the Porter's Handbook, it appears
this is exactly what the MAN[n]PREFIX macro is for, and sure enough after
removing the man page from pkg-plist and telling the Makefile about it, the
ports system compresses the resultant man page in its new location. So far
so
good.
However, on deinstall, if appeand two lots of ${PREFIX} when trying to
remove
the man page. For example, grig installs a man page
to /usr/local/share/man/man1/grig.1 (for a ${PREFIX} of /usr/local). The
deinstall routine trys to delete grig.1.gz
from /usr/local/share//usr/local/share/man/man1, which is just a little
crazy. Note the two slashes between the two iterations of the MANPREFIX.
Any clues, folks? I'd like to get these updates in before the ports tree is
frozen for 6.2 if at all possible.
Don't include MANPREFIX=${PREFIX}... since it's apparently being used
as ${PREFIX}${MANPREFIX}; you could confirm this by reading
bsd.port.mk.
Actually this appears to be incorrect, I'm not sure what is the cause.
There appears to be an obscure bug in make(1). This line:
__MANPAGES:= ${_MANPAGES:S%^${TARGETDIR}/%%}
ignores the substitution under some conditions (e.g.
non-standard MANPREFIX). I'm not aware of a solution
(and I don't feel like diving into make guts right now),
but a workaround is to s/:=/=/ (which needs a fix in
case of mancompressed).
Thoughts will be much appreciated, I have to jump through
hula hoops to work around the problem in some ports.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Porting a Linux application to FreeBSD
On 2/13/07, Tom McLaughlin [EMAIL PROTECTED] wrote:
On Mon, 2007-02-12 at 14:35 -0800, [EMAIL PROTECTED] wrote:
Hello,
I was referred here by some people in the hackers@ list because I
asked a porting related question and I should have asked it on this
list.
I was wondering steps people had used in the past for porting
linux applications, in particular applications that need libpng (i.e.
the differences between FreeBSD and Linux's libpng, if there are any).
I ran configure with no arguments and with the
--with-png=/usr/local/lib argument, but both sets of arguments fail
saying that they require png_read_png (just a C generated autoconf
test). The odd thing that I discovered too when I manually tried to
compile the autoconf generated C file is that it segfaulted when I
tried to execute the program (not sure if this behavior's intended or
not).
Linux does not have it's own libpng and neither do we. Most Linux
distros and us use libpng from libpng.org. I took a quick look at the
current libpng in the ports tree and it appears to have png_read_png().
With out seeing a Makefile for the ports system and some error output it
is hard to comment as to the specific reason stuff is failing for you.
Yes, but my money says
==
=CPPFLAGS= -I${LOCALBASE}/include
=LDFLAGS=-L${LOCALBASE}/lib
=GNU_CONFIGURE= yes
=CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS} LDFLAGS=${LDFLAGS}
===
will help, it always(x0.999) does :-) It's one
of those things everyone knows about but no one
commits into Mk/* because we enjoy routine so
much.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Warning added to index build
On 2/7/07, Kris Kennaway [EMAIL PROTECTED] wrote: Someone recently added the following warning to a port makefile, which shows up during e.g. index builds: Makefile, line 47: warning: duplicate script for target post-patch ignored Can someone please fix it? :) That's make's built-in warning when a target is redefined. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port Imgseek
On 2/8/07, Alfredo Perez [EMAIL PROTECTED] wrote: Hi Is it possible you can make me the maintainer for Imgseek port? Sure, but before you ask that question you really should preempt our why?, if you please. I mean all we know about you is that you have a horny email address and a name that yields 512k results in Google, and you maintain one port (assigned to you after a similar request). I mean I honestly believe you're a great guy, but please tell us a bit about yourself, what you're planning to do with imgseek and fluxconf and we'd very much like to see a patch or an idea of yours concerning the ports. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LIB_DEPENDS not really required for build?
On 2/4/07, Gerald Pfeifer [EMAIL PROTECTED] wrote: I always relied on LIB_DEPENDS applying both at install time as well as build time, and strictly so, but apparently I was confused? % cd $PORTSDIR/lang/gcc42 ; make : === gcc-4.2.0_20070131 depends on shared library: gmp.7 - not found ===Verifying install for gmp.7 in /home/gerald/ports//math/libgmp4 = No directory for gmp.7. Skipping.. === gcc-4.2.0_20070131 depends on shared library: mpfr.1 - not found ===Verifying install for mpfr.1 in /home/gerald/ports//math/mpfr = No directory for mpfr.1. Skipping.. === gcc-4.2.0_20070131 depends on shared library: iconv.3 - found And on it went to build the port, only dying later, at install time, wasting two hours. :-( Ignoring dependencies like this looks very, very bogus to me. IMnsHO the user explicitly should provide NO_DEPENDS to get this behavior, which may lead to build failures, wrong package lists, and run-time failures. Thoughts? You should take another look at the excerpt you posted. Looks like portsdir has been redefined. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LIB_DEPENDS not really required for build?
On 2/4/07, Gerald Pfeifer [EMAIL PROTECTED] wrote: On Sun, 4 Feb 2007, Andrew Pantyukhin wrote: You should take another look at the excerpt you posted. Looks like portsdir has been redefined. Yes, PORTSDIR has been redefined to point to where my ports reside. ;-) I fully understand that I am missing these dependencies. They simply do not exist on that system. My complaint is that the build should stop immediately, with a clear error message, instead of forging ahead and silently do the wrong thing or fail at a later stage, during build, installation, or run-time. It's been written in big red letters that partial/broken ports trees are not supported. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Package management on many hosts
On 1/31/07, Paul Chvostek [EMAIL PROTECTED] wrote: So ... on the topic of large-scale FreeBSD deployment ... How are people handling package version consistency in large groups of servers? If you have a web farm with 10 hosts, plus 3 hosts in a QA farm, and you want to make sure you're using the same version everywhere and upgrading production to the version you tested last week in QA, do you just do it manually, perhaps using portdowngrade on each host, or installing binary packages built on one host? Next, how are people dealing with portaudit info for groups of servers? Is the old standard of a cronjob for daily `portaudit -a` results still the best option? I'm putting together some tools to help with this stuff, but I'd hate to duplicate a perfectly functional wheel. The things you're talking about is what makes (some) enterprise proprietary Unix flavors competitive (e.g. HP-UX). Both BSD and Linux crowds would certainly like to have this kind of functionality, but it's currently in the planning phase. Enterprise Linux has been aiming there for years, but it's still clumsy at it. So I guess you're left with a bunch of hacks, and unless some magic collection of scripts surfaces, I'd say you have the right ideas. I'd stick with building packages on QA boxes and using portupgrade -PP or a similar solution on production ones. Good luck! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: REPLACES variable in Makefile ?
On 1/30/07, Alagarsamy [EMAIL PROTECTED] wrote: I want to know whether we are having REPLACES variable just like CONFLICTS variable in the Makefile ? I have two packages A and B. Package A is already installed. I want to install package B which should automatically replace the package A. In case, if there is no REPLACES variable, is there any other way to do this ? Your end-user desire is clear, but if you want to go a bit further and propose a solution you should probably examine systems where this already works (I'd start with debian). Currently in ports, you just have to bark at users to perform some actions manually. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc42 Build Error
On 1/28/07, Beech Rintoul [EMAIL PROTECTED] wrote: I'm getting the following updating gcc42: Maybe not enough memory? It's a one fat thing. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Non-daemon programs requiring kernel modules
On 1/29/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Sun, 28 Jan 2007 21:58:28 +0300): On 1/28/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Andrew Pantyukhin [EMAIL PROTECTED] (Sun, 28 Jan 2007 18:35:30 +0300): I'm porting a simple util requiring aio(4). My plan is to install a wrapper script which includes rc.subr(8) and uses its required_modules mechanism. If anyone has a better idea, please tell me. Just tell at port/package install time the requirement. Every linux program needs the linux module or the corresponding kernel option. If the code is not available at runtime, the user will get an error. Unix is not for dumb people, so I don't think we need this low-level hand-holding. That's one opinion. But Unix is also not about dumb developers. As a ports developer, my job is to make it easier for users to run third-party software and that's just what I'm trying to do to the extent of my skills and motivation... I agree, but if you are interested in a general solution, how do you want to apply it to the linux stuff? See my original message. grep /etc/rc.d for required_modules. Should we remove all that and just fail when needed modules are not present? The solution is not general, but it helps. I'm always more interested in a small step forward we make than a big leap we discuss. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg-plist question
On 1/28/07, makc [EMAIL PROTECTED] wrote:
Hi,
I'm going to update my port which lives in ${LOCALBASE}.
The new version offers to install qt-designer plugin to ${QT_PREFIX} --- to
${X11BASE} in other words.
Is there a way to handle this in pkg-plist?
You can use something like '@cwd %%X11BASE%%', but
consider it a last resort. Try stuffing the plugin
into LOCALBASE somehow, or create a separate port
installing the plugin.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Restricting (human) language and character set in /usr/ports
I'm not sure if there's a policy already, but it seems we have discussed this before. Can we limit /usr/ports (the whole ports collection) to English language and ASCII characters? This restriction should probably apply to all text data (with possible exception for patches). I know many of us would like to see i18n/l10n efforts in ports collection, but for now, in my opinion, we might need to focus on plain English. I'll start poking maintainers soon if there's no articulate objection. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xlockmore - serious security issue
On 6/14/06, Simon L. Nielsen [EMAIL PROTECTED] wrote: On 2006.06.13 18:51:48 +0400, Andrew Pantyukhin wrote: On 6/13/06, Anish Mistry [EMAIL PROTECTED] wrote: On Tuesday 13 June 2006 07:54, Andrew Pantyukhin wrote: On 6/13/06, Anton Berezin [EMAIL PROTECTED] wrote: On Tue, Jun 13, 2006 at 03:18:16PM +0400, Andrew Pantyukhin wrote: The problem is that xlockmore exits all by itself when left alone for a couple of days. It works all right overnight, but when left for the weekend, it almost certainly fails. I just come to work and see that my workstation is unlocked, what a surprise. [...] I just stick with a blank screen and works fine for several weeks at a time. I found some of the GL screensavers to cause problems. Ask me - we should mark this port forbidden and/or make and entry in vuxml until we resolve this issue. Let's make blank screen the default behavior or something. To leave this as is is unacceptable. FORBIDDEN and a VuXML entry seems in a way a bit overkill to me seems a bit overkill to me, since it's not really a vulnerability, but I'm open to input. As mentioned by others, xlockmore is fundamentally flawed wrt. guaranteeing that the screen stays locked in that the screensavers code can kill the lock, which it should not be able to happen. Has anyone contacted the xlockmore author for comment on this issue? One thing we could do right now is to add a message at install time warning that xlockmore might unlock the screen (a bit like the Pine warning). High time we settled on something. Now that we had this discussion, I only use the swarm mode and never had any problems with it. But what about those who still don't know about the issues? I've been in situations where accidental unlocking was unacceptable. In most cases unlocking implies immediate root access to the local machine (which is also possible, but more complicated, with plain physical access), but more importantly - decrypted auth info in RAM, such as ssh keys. This is a major security breach. IMHO, we can't overestimate it. I'm quite sure an ignorable/overlookable message is not enough. A user must fully understand all the implications of this software being used. If it's fundamentally flawed, let's forbid/remove it _until_ the author has a statement for us, not after that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restricting (human) language and character set in /usr/ports
On 1/13/07, Robert Huff [EMAIL PROTECTED] wrote: Andrew Pantyukhin writes: I'm not sure if there's a policy already, but it seems we have discussed this before. Can we limit /usr/ports (the whole ports collection) to English language and ASCII characters? This restriction should probably apply to all text data (with possible exception for patches). I don't follow this issue (much), so could you explain what's broken about the /status quo/? It depends on what you mean by /status quo/, but in short, when I look at COMMENT, pkg-descr, pkg-message, comments in Makefile and other such text data, I expect to see English language and ASCII characters. There are ports that don't follow this expectation and I'd like to change that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Restricting (human) language and character set in /usr/ports
On 1/14/07, Doug Barton [EMAIL PROTECTED] wrote: Andrew Pantyukhin wrote: On 1/13/07, Robert Huff [EMAIL PROTECTED] wrote: Andrew Pantyukhin writes: I'm not sure if there's a policy already, but it seems we have discussed this before. Can we limit /usr/ports (the whole ports collection) to English language and ASCII characters? This restriction should probably apply to all text data (with possible exception for patches). I don't follow this issue (much), so could you explain what's broken about the /status quo/? It depends on what you mean by /status quo/, but in short, when I look at COMMENT, pkg-descr, pkg-message, comments in Makefile and other such text data, I expect to see English language and ASCII characters. There are ports that don't follow this expectation and I'd like to change that. I'm not sure it's quite so cut and dry as that. For example, I think it's probably reasonable for the /usr/ports/language ports to have some non-ascii stuff to start with. I'm not against non-ascii, but there's no notion of character set in /usr/ports. I work in UTF-8 and it's visible to me, as it is to many other people working in many different charsets. There are several ways to deal with non-ascii characters, the two most effective being: (a) select a universal charset (I would love to see UTF-8 in that role) (b) introduce special markers, defining current charset I can not agree with people selecting random charsets and me having to guess them. Automated information brokers, like freshports, also have problems with this. As for the language, I expect everything within the FreeBSD project to be present at least in English. L10n overlaps with multiple charset support and without both concepts implemented one way or another (like they are in FDP), I think presenting content exclusively in English is the only solution. Is there a problem you're trying to solve here, or is this just a matter of tidying things up a bit? To me it looks like a matter of consistency and usability. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linux-mozilla, linux-firefox and linux-realplayer
On 1/8/07, Stevan Tiefert [EMAIL PROTECTED] wrote: Hello, I hope that this is the right mailinglist. If not say it! freebsd-ports would probably be more correct. (Cc'ing there) I had to visit a web-site with realplayer-contents and that was the reason to install the port linux-realplayer. It seems that linux-realplayer wants to copy his plugins into /usr/X11R6/lib/linux-mozilla/plugins/nphelix.so Then I have to install the port linux-mozilla port before the linux-realplayer. But the security-database didn't allow me to install linux-mozilla, EVEN I updated my ports-tree like the error-message recommends! OK, then I tried to install linux-firefox. That worked, but I couldn't see the contents. I had to copy by hand the files nphelix.so and nphelix.xpt into /usr/local/lib/linux-firefox/plugins I think that it is a problem, if I am not allowed to install linux-mozilla and the ports linux-realplayer and linux-firefox are not willing to work together. Maybe somebody can fix this small problem in these ports? This is not a small problem. Several approaches have been tried to fix the general problem you're talking about and none perfected yet. Please have patience or try to look into the issue and provide a patch. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DEPENDS -- is it time to remove it?
On 1/5/07, RW [EMAIL PROTECTED] wrote: Isn't DEPENDS still a sensible way of making one metaport depend on another. For example if someone wanted to create a personal desk- top metaport that depends on KDE, xorg etc. People need programs, not ports. It's more sensible to run_depend on files than just on ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PLIST_FILES question
On 1/3/07, Gabor Kovesdan [EMAIL PROTECTED] wrote:
Beech Rintoul schrieb:
Thanks to everyone who responded. I somehow missed that handbook section, but
I have it figured out now. What I needed to do is the following:
.if defined(WITH_MYSQL)
USE_MYSQL=yes
MODULES:=${MODULES}:mod_sql:mod_sql_mysql
INCLUDEDIRS:=${INCLUDEDIRS}:${LOCALBASE}/include
LIBDIRS:=${LIBDIRS}:${LOCALBASE}/lib/mysql
PLIST_FILES= include/proftpd/mod_sql.h
.endif
The extra header file is not copied to include unless that option is checked
and hard coding it in pkg-plist broke the pkg build. It didn't show up on
pointyhat because that option is off by default.
Oh, do you want to mix PLIST_FILES and pkg-plist, did
I catch it right? That should not be done.
Why not?
You can list that file in pkg-plist as
%%MYSQL%%include/proftpd/mod_sql.h and do the following in Makefile:
if defined(WITH_MYSQL)
PLIST_SUB+= MYSQL=
[...another things here...]
.else
PLIST_SUB+= MYSQL=@comment
.endif
Look at e.g. security/amavisd-new, I do something similar there.
PLIST_FILES is a bit simpler to use. Personal feelings
about the variable, or whether it smells well when mixed
with pkg-plist are interesting, but they are not quite
relevant if there's no technical problem.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
libvisual
I'm looking at libvisual 0.4. I have the base port ready and there's no major issue with -plugins. The developers went the versioned way so that the new version can safely coexist with 0.2, so it makes sense to me to repocopy libvisual to libvisual04. I'm also planning to split the -plugins the gstreamer way into 10-20+ separate libvisual- plugins-xxx04 ports. I don't want to move current libvisual to libvisual02 and make the new one just libvisual (at least right now), as it's pretty pointless with 0.6 coming along the way. Speak up now if you have anything to say. I guess I'll start with the base port and make plugins one by one starting soonish. Thanks! P.S. I had never touched libvisual before I started porting LiVES [1]. If there are willing experts, I'll be very glad to hear from them. [1] http://lives.sourceforge.net/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Detecting real python (perl/ruby/.so/...) dependencies
It's never clear what a program really needs. Ports solve this problem (mostly), but whenever you make an update or port something new, you face the same issue. Developers tend to maintain a list of dependencies, but you're in big luck if you find it up-to-date and accurate. It would be nice to verify anyway. So I need to find out what modules does a particu- lar python program require. I can grep for import, but many modules are present in our python bundle. Is there a way to see: 1) Which of the modules are present, and any single file for each of them, so we can map to installed packages 2) Which of the modules are not present Ideally, also 3) A hint as to where can I find a missing module, maybe from some CPAN-like repo 4) Whether the module is critical for the app, e.g. whether it's imported inside a try block I've seen something like this for Perl, but not for Python apps. If you successfully use an automa- ted way of detecting dependencies for Python (and maybe other languages like Perl, Tcl/Tk, Ruby, or maybe even C/C++, based on headers or something), please share. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP : security/gnupg will be upgraded to 2.0.1
On 12/12/06, Jun Kuriyama [EMAIL PROTECTED] wrote:
I just think security/gnupg should be used as what
you should choose for GnuPG. If new ports user
wants to install GnuPG, I hope there is
security/gnupg as recommended stable version.
An unversioned directory is the maintainer-designated
default version of a port. Unless its upgrades break
a whole bunch of ports (like python did), it's none
of our business when and why they happen. An advance
heads-up is nice, but redundant.
Doug, privately kept, but prompt versioning ways are
one of the ports {trade,hall}marks. Gentoo is broken
and Debian is stale, we're fighting somewhere in
between, thanks to sane decisions our contributors
make.
Shaun, whatever versioned dirs might seem to imply,
they don't imply (in)stability or (in)compatibility.
The unversioned one is the default one, that's it.
Hitting users with new versions, but leaving them
a chance to survive seems like a nice policy to me.
To conclude, I understand how Jun feels and think
that instead of bitching about his reasoning, we
should be insanely grateful for more than 8 years
of his impeccable gnupg maintainership.
THANKS, JUN!!!
This is all my humble 4:30AM opinion anyway :-)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
cups-pstoraster vs. ghostscript 8.15
It looks like both ports install some similar files into share/ghostscript/8.15, in particular share/ghostscript/8.15/lib/gs_init.ps. Frank, could you please look at it or should I mark the two ports as conflicting right away? Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SciTE // patch error
On 02 Dec 2006 19:37:19 +0100, vermaden [EMAIL PROTECTED] wrote: Hi, I can not install/built scite editor from ports, I got the following error message: [code] # make === Found saved configuration for scite-gtk2-1.71_1 = scite171.tgz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://heanet.dl.sourceforge.net/sourceforge/scintilla/. scite171.tgz 100% of 1269 kB 86 kBps 00m00s === Extracting for scite-gtk2-1.71_1 = MD5 Checksum OK for scite171.tgz. = SHA256 Checksum OK for scite171.tgz. === Patching for scite-gtk2-1.71_1 === Applying FreeBSD patches for scite-gtk2-1.71_1 tr: Illegal byte sequence *** Error code 1 Stop in /usr/ports/editors/scite. # [/code] Please try running make in another locale, like env LANG=C LC_ALL=C make or env LANG=en_US.ISO8859-1 LC_ALL=en_US.ISO8859-1 make ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apache + php + mysql startup order
On 11/30/06, Dmitry Pryanishnikov [EMAIL PROTECTED] wrote: Hello! I'm trying to write an automated rc.d-script that should check MySQL database before it's used by the Apache+PHP hosting. If I were you, I'd make my php scripts handle temporary db outages. Don't forget that most hosting providers have web and sql servers on separate machines. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New portmgr member: Pav Lucistnik
On 11/23/06, Erwin Lansing [EMAIL PROTECTED] wrote: Portmgr is pleased to announce that Pav Lucistnik has accepted the challenge of being a portmgr member. Terrific! We should now guess if it will be portmgr on steroids or pav on sedatives :-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with version numbers going backwards: www/eyeos
On 11/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ** The following ports have a version number that sorts before a previous one ** I think I fixed it: http://www.freshports.org/www/eyeos/ Sorry for not letting you know immediately and sorry for the mess. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firefox 2.0
On 10/26/06, Peter Jeremy [EMAIL PROTECTED] wrote: There are over 200 other ports that have Firefox listed as a dependency. Firefox 2.0 is presumably a major upgrade compared to Firefox 1.5 and it's highly likely that the upgrade would adversely impact at least one of those other ports - necessitating more last minute fixes. From what I see it's minor, 1.5 broke much more things, but portmgr/gnome are not yet fully recovered from the gnome update. As I see it, we'd better let eager users learn to install new Firefox from ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
zabbix update
I decided to try zabbix out and had to update the port: http://people.freebsd.org/~sat/diffs/zabbix113.diff There are still a few todo items, like pgsql 8.1 schema patch. It seems that Sergey has been inactive for quite a while, though he did surface this October. If neither he, nor anyone else knowledgeable of zabbix, wish to maintain it, I'll consider taking it. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: zabbix update
On 10/26/06, Sergey Matveychuk [EMAIL PROTECTED] wrote: Andrew Pantyukhin wrote: I decided to try zabbix out and had to update the port: http://people.freebsd.org/~sat/diffs/zabbix113.diff There are still a few todo items, like pgsql 8.1 schema patch. It seems that Sergey has been inactive for quite a while, though he did surface this October. If neither he, nor anyone else knowledgeable of zabbix, wish to maintain it, I'll consider taking it. Thanks! Personally I don't object for changing of inactive maintainers, but I think we should follow formal maintainer timeout rules described in TPH. You mean after 29 months of inactivity and a couple of time-outs, we should not be impertinent enough to reset the maintainer? You're probably right :-) Anyways, I'd be happy to hear from Sergey and even happier to have him maintain zabbix further. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with compiling firefox
On 10/23/06, Klaus Friis Østergaard [EMAIL PROTECTED] wrote: Hi, I have a amd64 box with freebsd 5.4, during upgrading with portupgrade I have a problem with Firefox. Could you please perform the gnome-related updated as described in /usr/ports/UPDATING Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gnome update
On 10/23/06, Ganbold [EMAIL PROTECTED] wrote: Hi, I'm trying to update gnome to 2.16 using portmaster for more than 3 days :( portmaster is good, but you really should use portupgrade if you're stumbling over and over again. 1. Every time after some error when I try to run portmaster -r pkg-config\* it starts from the beginning. Maybe there is some option to skip updated ports. How to tell portmaster to skip updated ports? No. Neither portmaster, nor portupgrade has this option, or any session management for that matter. 2. After upgrading some port it asks whether to delete the source file or not. I don't want to press button everytime. Is it possible to have option something like '[y][n][Allyes][allnO]'? -D switch disables distfile-cleaning functionality 3. While portmaster running, I manually updated libtheora port. When portmaster reaches libtheora, it stops with error. Is it possible for portmaster to give user some choices in this case like [Skip]...? IIRC, it's on Doug's todo list. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Vim scripts
Any particular reason for no vim scripts in ports? I'm gonna make some, if there's no secret taboo. Also, now that vim comes with a spellchecker, I'll start thinking about dictionaries. I already use /usr/share/dict/* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP Vulnerabilities and Suhosin
On 10/6/06, Alex Dupre [EMAIL PROTECTED] wrote: Andrew Pantyukhin ha scritto: I've noticed we have WITH_SUHOSIN option. It may alleviate some security issues. In particular, suhosin 0.9.6 fixes this latest issue. Can we somehow make this option influence PKGNAME (suffix, prefix, version or revision) so I can mark php+suhosin 0.9.6 safe in VuXML? No, because what fixes the problem is the suhosin extension (security/php-suhosin) and not the suhosin patch. I think we should mark suhosin 0.9.5 as vulnerable to encourage an upgrade (in the same advisory). What do you think? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
