From rhurlin at gwdg.de Fri Oct 1 06:17:34 2010 From: rhurlin at gwdg.de (Rainer Hurling) Date: Fri Oct 1 06:17:38 2010 Subject: package generation on FreeBSD ftp server Message-ID: <4CA57D11.3020406@gwdg.de> I have a question about packages at ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/ . They are automatically generated from time to time. I understand that this depends on computing capacities on the server farm etc. So some packages are relatively new, some are older and some are missing... For example, for math/saga there had been a package saga-2.0.4_4.tbz for some time. After updating SAGA GIS to version 2.0.5 there is no package any more. There was an error on building math/saga in first half of september, see http://portsmon.freebsd.org/portoverview.py?portname=saga This was corected and the new SAGA GIS version has to differentiate between i386 and amd64 because of dependency libiodbc (patch problem). Does this prevent from automatic package generation? I would be happy if someone could give an explaination on this. Thanks in advance, Rainer Hurling From freebsd at jdc.parodius.com Fri Oct 1 06:28:34 2010 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Fri Oct 1 06:28:38 2010 Subject: package generation on FreeBSD ftp server In-Reply-To: <4CA57D11.3020406@gwdg.de> References: <4CA57D11.3020406@gwdg.de> Message-ID: <20101001062832.GA37936@icarus.home.lan> On Fri, Oct 01, 2010 at 08:17:53AM +0200, Rainer Hurling wrote: > I have a question about packages at > ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/ . > > They are automatically generated from time to time. I understand > that this depends on computing capacities on the server farm etc. So > some packages are relatively new, some are older and some are > missing... > > For example, for math/saga there had been a package saga-2.0.4_4.tbz > for some time. After updating SAGA GIS to version 2.0.5 there is no > package any more. > > There was an error on building math/saga in first half of september, see > http://portsmon.freebsd.org/portoverview.py?portname=saga > > This was corected and the new SAGA GIS version has to differentiate > between i386 and amd64 because of dependency libiodbc (patch > problem). > > Does this prevent from automatic package generation? > > I would be happy if someone could give an explaination on this. My impression has always been that the packages **are not** updated automatically, and are done manually + updated manually by someone. This is confirmed by the high amount of variance in timestamps on all the symlinks in the All/ directory (see for yourself). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kamikaze at bsdforen.de Fri Oct 1 06:59:35 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri Oct 1 06:59:38 2010 Subject: Using portmaster with different PYTHON_VERSION In-Reply-To: <4CA5176B.7080706@FreeBSD.org> References: <4CA256B6.5090908@FreeBSD.org> <4CA5176B.7080706@FreeBSD.org> Message-ID: <4CA586D4.8090903@bsdforen.de> On 01/10/2010 01:04, Doug Barton wrote: > On 9/29/2010 1:57 PM, Dmitry Pryanishnikov wrote: >> Hello! >> >> 2010/9/28 Doug Barton: >>> >>> I would also argue that there is a fundamental assumption in the ports >>> infrastructure that what you're doing here (installing both versions >>> on the >>> same system) is not supported. The ability to make the version of things >>> like python or perl variable is a great feature of the ports >>> infrastructure, >>> but my understanding has always been that this would be a system-wide >>> option, and that installing different versions of the same language >>> on the >>> same system is not supported. >> >> What problems (besides no support in portmaster) can arise due to >> parallel use of Python 2 and Python 3 in the same FreeBSD system? > > I'm not an expert on python so I'll let someone more knowledgeable > comment on that. There may not even be any problems. I'd assume this is a correct assumption. I wouldn't expect any problems. > My point was simply > that historically the assumption has been that there would only be one > version of a given interpreted language (like perl or python, and to > some extent php, and others) on a system at a time. Your post eloquently > stated the case for why that assumption might no longer be true. If > that's the case, then the way we do some things might have to change. I've been thinking whether I could abandon the assumption that there is only one package per origin in pkg_upgrade. I decided against it, because the change would be too fundamental. If the assumption was scrapped, there would no longer be a unique identifier for packages across versions and this would introduce guesswork into every layer of code. There is already tons of guesswork in reading the command line parameters, there are 13 different things that can go wrong with packages specified on the command line. Because they can go wrong in different situations (e.g. regular reinstall request or -o), the code currently produces 19 different kinds of error messages just for specified package names. There are another 38 error messages for redundant and conflicting options/flags. Imagine to introduce this degree of error handling into every layer of a package management tool. As far as I am concerned the correct solution would be to create py- slave ports for every major branch, i.e. py2-* and py3-* ports. This way you could have one python version from every major branch, which I'd expect to suffice for most use cases. An alternative would be to have the py-* packages depend on lang/python and make that depend on more than one version of python. I.e. it should allow to select all desired python versions through the OPTIONS framework. The py-* ports then would have to be changed to install themselves for all available python versions they support (this should be possible with a little Makefile magic and dynamic plists). I expect this approach would also work well with the build systems pointyhat and tinderbox. If the ports tree introduced a new unique identifier that crossed version boundaries, was present in INDEX files, +CONTENTS files and of course could be produced by the Makefile, it would be far less trouble to get rid of the origin 1-1 package relation assumption. It would be a lot of work, because the assumption is so heavily relied on, but it would not be very difficult. Regards, Dominic -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From christer.solskogen at gmail.com Fri Oct 1 07:24:43 2010 From: christer.solskogen at gmail.com (Christer Solskogen) Date: Fri Oct 1 07:24:49 2010 Subject: some problem with portsnap servers? In-Reply-To: <4CA4EA8A.9000809@yandex.ru> References: <4CA4E3CF.4040304@yandex.ru> <20100930193843.GC3929@libertas.local.camdensoftware.com> <4CA4EA8A.9000809@yandex.ru> Message-ID: On Thu, Sep 30, 2010 at 9:52 PM, Ruslan Mahmatkhanov wrote: > 30.09.2010 23:38, Chip Camden ?????: >> >> Quoth Ruslan Mahmatkhanov on Thursday, 30 September 2010: >>> >>> Hi! >>> >>> I have not have any updates from aprox 2010/09/30 14:00 +0400. portsnap >>> says that ports tree is up to date all the time. It's just me or anybody >>> have this problem right now? >>> >> >> Same here -- but I just assumed there haven't been any commits. >> > > No, there is. Check freshports.org. > IIRC the servers for portsnap is on a move. Hang in there! -- chs, From axelbsd at ymail.com Fri Oct 1 08:18:47 2010 From: axelbsd at ymail.com (Alexandre) Date: Fri Oct 1 08:18:50 2010 Subject: some problem with portsnap servers? In-Reply-To: <4CA4E3CF.4040304@yandex.ru> References: <4CA4E3CF.4040304@yandex.ru> Message-ID: Portsnap builds were temporarily offiline pending a move to new hardware, but portsnap builds are back online. Thanks Colin for these informations. On Thu, Sep 30, 2010 at 9:23 PM, Ruslan Mahmatkhanov wrote: > Hi! > > I have not have any updates from aprox 2010/09/30 14:00 +0400. portsnap > says that ports tree is up to date all the time. It's just me or anybody > have this problem right now? > > -- > Regards, > Ruslan > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From ml at netfence.it Fri Oct 1 09:10:59 2010 From: ml at netfence.it (Andrea Venturoli) Date: Fri Oct 1 09:11:02 2010 Subject: mod_auth_pam does not install mod_auth_sys_group.so Message-ID: <4CA5A59F.4020405@netfence.it> As per subject: _ the original port's Makefile contemplates mod_auth_sys_group; _ it used to be installed in the past; _ however, after a 7.2->7.3 upgrade, I did a "portupgrade -a" and that file is not there anymore. Why? bye & Thanks av. From amdmi3 at amdmi3.ru Fri Oct 1 11:05:42 2010 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri Oct 1 11:05:46 2010 Subject: FreeBSD Port: gnash-0.8.7_4 In-Reply-To: <4CA36014.6040201@cineca.it> References: <4CA36014.6040201@cineca.it> Message-ID: <20101001110539.GD11112@hades.panopticon> * Marco Alberoni (m.alberoni@cineca.it) wrote: > Good morning, is there a plan to upgrade the FreeBSD Gnash port to the > latest version (0.8.8)? Gnash port was updated, sorry for delay and thanks for waiting! -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From avg at icyb.net.ua Fri Oct 1 14:37:38 2010 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Oct 1 14:37:42 2010 Subject: FreeBSD Port: gnash-0.8.7_4 In-Reply-To: <20101001110539.GD11112@hades.panopticon> References: <4CA36014.6040201@cineca.it> <20101001110539.GD11112@hades.panopticon> Message-ID: <4CA5EF31.9020403@icyb.net.ua> on 01/10/2010 14:05 Dmitry Marakasov said the following: > * Marco Alberoni (m.alberoni@cineca.it) wrote: > >> Good morning, is there a plan to upgrade the FreeBSD Gnash port to the >> latest version (0.8.8)? > > Gnash port was updated, sorry for delay and thanks for waiting! The following patch is required for compilation with gcc44+. It's definitely an upstream issue: --- libbase/tu_file.h.orig 2010-10-01 16:39:16.419334667 +0300 +++ libbase/tu_file.h 2010-10-01 16:39:55.565197173 +0300 @@ -12,6 +12,7 @@ #include "dsodefs.h" // DSOEXPORT #include "utility.h" #include "IOChannel.h" // for inheritance +#include namespace gnash { -- Andriy Gapon From dougb at FreeBSD.org Fri Oct 1 20:36:51 2010 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Oct 1 20:36:55 2010 Subject: Using portmaster with different PYTHON_VERSION In-Reply-To: <4CA586D4.8090903@bsdforen.de> References: <4CA256B6.5090908@FreeBSD.org> <4CA5176B.7080706@FreeBSD.org> <4CA586D4.8090903@bsdforen.de> Message-ID: <4CA64661.5090806@FreeBSD.org> On 9/30/2010 11:59 PM, Dominic Fandrey wrote: > > I've been thinking whether I could abandon the assumption that there > is only one package per origin in pkg_upgrade. I decided against it, > because the change would be too fundamental. If the assumption was > scrapped, there would no longer be a unique identifier for packages > across versions and this would introduce guesswork into every layer > of code. FWIW, I agree with you that this is a fundamental assumption and that it cannot be challenged without great peril. :) > As far as I am concerned the correct solution would be to create > py- slave ports for every major branch, i.e. py2-* and py3-* ports. > This way you could have one python version from every major branch, > which I'd expect to suffice for most use cases. I agree with you that this is likely the best solution, and while I'm not a python person I would use this approach if a similar situation presented itself with my perl ports. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From obrien at freebsd.org Sat Oct 2 00:26:06 2010 From: obrien at freebsd.org (David O'Brien) Date: Sat Oct 2 00:26:09 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> Message-ID: <20101002002605.GA8018@dragon.NUXI.org> On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote: > What is "sufficiently clean" ? I wonder what is not clean in the > options framework, so please tell me then we still can clean it? When the Ports Collection was invented, ports maintainers were to choose a reasonable set of configuration for the FreeBSD community and have the port build that way. Today we have ports that seem to expose every single option to GNU configure and giving the user a puzzling choice of too many things. Often the explanations are nothing more than restating the option name and the user is left wondering what is X? What does Y mean? How do I know if I really want Z or not? Why is threading so often an OPTION and not just the default? Why do I have to go read the packages README and INSTALLING to figure out the caveats of say enabling threading? Or what the other list of things are and their caveats? 1. One should not have to deal with the OPTIONS dialog just to 'make extract' if one wants to check the license or otherwise investigate a port before deciding to install it. 2. With the way OPTIONS handling is done, there isn't a way for me to query if I built with the defaults or not. Thus leading to every port I manually install looking like it was customized just because /var/db/ports/${PORTNAME} exists. Thus implying I can no longer install the pre-build package. 3. OPTIONS are limited to only checkbox YES/NO settings. Why can I not set PREFIX thru the OPTIONS framework and have it come from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? Even the boolean NOPORTDOCS isn't available thru OPTIONS. Thus it is an inconsistent way to configure a port. 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in /etc/make.conf, why does the OPTIONS dialog offer me "[X] NLS Enable gettext support" instead of defaulting the dialog to unchecked? 5. One cannot opt-out of OPTIONS. WITHOUT_OPTIONS does not work to just get the defaults while skipping the OPTIONS dialog. Note, setting BATCH does a lot more than just make OPTIONS non-interactive (for some ports it stops other non-OPTIONS interaction with the user that one should see). Thus there is no way to get an uninterrupted default build of something. 6. One cannot opt-in/opt-out on a per-port basis. WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS should be supported to control the OPTIONS dialog just when building ${PORTNAME}. 7. Setting ${PORTNAME}_WITH[OUT]_ (or WITH[OUT]_${PORTNAME}_) should set WITH[OUT]_ just when building ${PORTNAME}. So that folks who don't want to be interrupted with OPTIONS every time there is an update to the list can hardcode their choices in /etc/make.conf. 8. OPTIONS make a mess in the typescript file from 'script typescript make', and the choices are totally unreadable vs. 'script typescript make -DWITH_FOO -WITHOUT_BAR'. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From obrien at NUXI.org Sat Oct 2 06:02:02 2010 From: obrien at NUXI.org (David O'Brien) Date: Sat Oct 2 06:02:06 2010 Subject: editors/vim installs to / In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> Message-ID: <20101002060201.GA8287@dragon.NUXI.org> On Fri, Sep 17, 2010 at 05:38:21PM -0700, Rob Farmer wrote: > However, I still think it would benefit everyone if the maintainer > could provide an explanation for some of the current behavior and > would at least be open to discussion about changing it. The biggest > problem here, IMHO, is not the OPTIONS issue, but rather the use of > GTK 1 as the default. I have commented on GTK2 (explained) in the past. It is the kitchen sink that gtk2 brings in vs. gtk1. On my desktop gtk2 requires 64 other packages. gtk1 requires 20. I guess its time to take another survey. Is Vim one of the few last gtk1 consumers? For gtk1, I have 13 packages that require it. For gtk2, I have 49 packages that require it. So I agree their are significantly more ports that depend on gtk2 -- and thus little way to avoid having it installed on one's system. > I think either defaulting to GTK 2 or just making vim a > console application would eliminate most of these complaints. Index: Makefile =================================================================== RCS file: /home/pcvs/ports/editors/vim/Makefile,v retrieving revision 1.362 diff -u -p -u -1 -r1.362 Makefile --- Makefile 2 Oct 2010 01:55:08 -0000 1.362 +++ Makefile 2 Oct 2010 06:00:34 -0000 @@ -40,3 +43,3 @@ SLAVEDIRS= editors/vim-lite -CONFLICTS= vim6* vim*-lite +CONFLICTS= vim6* vim*-lite vim*-gtk1 vim*-gnome MAKE_JOBS_SAFE= yes @@ -126,4 +129,4 @@ MAKE_ARGS+= CONF_OPT_TCL="--enable-tclin # for now default the GUI to the GTK+ one -. if !defined(WITH_X11_ONLY) && !defined(WITH_ATHENA) && !defined(WITH_MOTIF) && !defined(WITH_GNOME) && !defined(WITH_GTK) && !defined(WITH_GTK2) -WITH_GTK= yes +. if !defined(WITH_X11_ONLY) && !defined(WITH_ATHENA) && !defined(WITH_MOTIF) && !defined(WITH_GNOME) && !defined(WITH_GTK1) && !defined(WITH_GTK2) +WITH_GTK2= yes . endif @@ -132,3 +135,3 @@ WITH_GTK= yes MAKE_ARGS+= CONF_OPT_GUI="--enable-gui=athena" ${I18N} -. elif defined(WITH_GTK) +. elif defined(WITH_GTK1) USE_GNOME= gtk12 @@ -137,5 +140,5 @@ MAKE_ARGS+= X_LIBS="$(X_LIBS) -lXt" USE_XORG+= xt +PKGNAMESUFFIX= -gtk1 . elif defined(WITH_GTK2) USE_GNOME= gtk20 -PKGNAMESUFFIX= -gtk2 MAKE_ARGS+= CONF_OPT_GUI="--enable-gui=gtk2 --with-gtk-prefix=${LOCALBASE}" ${I18N} @@ -257,2 +260,8 @@ show-options: +.if defined(WITH_GTK) +.BEGIN: + @${ECHO_CMD} "WITH_GTK has been renamed WITH_GTK1." + @exit 1 +.endif + cklatest: Thoughts? -- -- David (obrien@NUXI.org) From obrien at freebsd.org Sat Oct 2 06:33:13 2010 From: obrien at freebsd.org (David O'Brien) Date: Sat Oct 2 06:33:17 2010 Subject: editors/vim installs to / In-Reply-To: <20101002060201.GA8287@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> Message-ID: <20101002063312.GA53750@dragon.NUXI.org> On Fri, Oct 01, 2010 at 11:02:01PM -0700, David O'Brien wrote: > On Fri, Sep 17, 2010 at 05:38:21PM -0700, Rob Farmer wrote: > > However, I still think it would benefit everyone if the maintainer > > could provide an explanation for some of the current behavior and > > would at least be open to discussion about changing it. The biggest > > problem here, IMHO, is not the OPTIONS issue, but rather the use of > > GTK 1 as the default. > > I have commented on GTK2 (explained) in the past. Oh, I forgot to mention that I don't find the Vim gtk2 icons near as intuitive as the gtk1 ones. And I really take the mswin'ifcation of UNIX (gtk2 refers to "folder", where gtk1 calls the things "directory") And most of all I totally cannot stand the GNOME dumbass reversal of umpteen years of UNIX ordering of [OK] vs. [Cancel] boxes. The GNOME folks have now created major inconstancy in the ordering of the various applications I run depending on if it is a basic Motif, KDE, or GNOME toolkit consumer. The ordering inconstancy has caused my muscle memory to choose the wrong thing (loosing data). -- -- David (obrien@FreeBSD.org) From ade at FreeBSD.org Sat Oct 2 06:50:11 2010 From: ade at FreeBSD.org (Ade Lovett) Date: Sat Oct 2 06:50:15 2010 Subject: editors/vim installs to / In-Reply-To: <20101002060201.GA8287@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> Message-ID: <32055F40-C8F9-4A65-9985-B1FA4AE11A38@FreeBSD.org> On Oct 02, 2010, at 01:02 , David O'Brien wrote: > I guess its time to take another survey. Is Vim one of the few last > gtk1 consumers? Without touching on any of the other issues, yes, indeed, (a) gtk v1 is abandonware and (b) vim-with-defaults is one of the last major consumers of gtk1. If I may be so bold, allow me to offer up an alternative. editors/vim -- fully functional console-only (no X11) editors/vim-lite -- stripped down version (again, no X11, perhaps even linked static for use within embedded systems) editors/vim-gui -- take your pick. X11 is implied. athena/motif widgets are pretty much dead, so unless there's a QT version floating around, GTK2. vim is the MASTER, vim-lite slave strips stuff out of vim, vim-gui adds stuff to vim. Might even be able to avoid the whole OPTIONS issue (which I'm purposefully not touching on here) with this kind of setup. -aDe From chetan.shukla at aricent.com Sat Oct 2 07:05:18 2010 From: chetan.shukla at aricent.com (Chetan Shukla) Date: Sat Oct 2 07:05:21 2010 Subject: porting: Linux to Freebsd Message-ID: Hi, Could someone please outline the steps needed in porting a general application from Linux to FreeBSD. Thanks & Regards, Chetan ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." From m.seaman at infracaninophile.co.uk Sat Oct 2 07:29:11 2010 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sat Oct 2 07:29:13 2010 Subject: porting: Linux to Freebsd In-Reply-To: References: Message-ID: <4CA6DF34.5080301@infracaninophile.co.uk> On 02/10/2010 07:42:30, Chetan Shukla wrote: > Could someone please outline the steps needed in porting a general application from > Linux to FreeBSD. Step 1) Spend time (probably several years) achieving a reasonable level of expertise in the languages and concepts involved. Step 2) During the same time, become intimately familiar with the applicable bits of API and the general operating environment available under FreeBSD. Step 3) Copy distfile tarballs onto FreeBSD box, or otherwise obtain the source code. Step 4) Try to configure and compile the software, or otherwise do what is needed to get the software into a usable state. Step 5) Test it Step 6) If it works, stop the compile/test cycle here and publish your results, preferably by writing a new port and submitting it as described in the Porter's handbook. Step 7) Else generate fixes for any apparent problems. Step 8) Goto step 4. Perhaps you might ask a more narrowly specified question? The answers will likely be a lot more useful to you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101002/4714ef82/signature.pgp From rfarmer at predatorlabs.net Sat Oct 2 11:38:36 2010 From: rfarmer at predatorlabs.net (Rob Farmer) Date: Sat Oct 2 11:38:39 2010 Subject: editors/vim installs to / In-Reply-To: <20101002060201.GA8287@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> Message-ID: On Fri, Oct 1, 2010 at 23:02, David O'Brien wrote: > For gtk1, I have 13 packages that require it. ?For gtk2, I have 49 > packages that require it. ?So I agree their are significantly more ports > that depend on gtk2 -- and thus little way to avoid having it installed > on one's system. > > Thoughts? In my experience, unless you choose one of the minimalist window managers and are very selective about what you install, GTK 2 might as well be part of X. x11/xorg, with default options, pulls in 90% of GTK 2 dependencies via sysutils/hal and avoiding the rest means no firefox, which alone is probably a dealbreaker for most people. I personally like Ade's suggestion, since it makes a gui opt-in for an application that functions perfectly well without one. -- Rob Farmer From tingox at gmail.com Sat Oct 2 12:27:00 2010 From: tingox at gmail.com (Torfinn Ingolfsen) Date: Sat Oct 2 12:27:03 2010 Subject: porting: Linux to Freebsd In-Reply-To: <4CA6DF34.5080301@infracaninophile.co.uk> References: <4CA6DF34.5080301@infracaninophile.co.uk> Message-ID: Or you could simply start at step 3, then for every problem you have in step 4, Google it. For the problems you cannot fix that way, ask (smart) questions on the appropriate FreeBSD mailing lists, until the application compiles. Then continue to step 5. Note: the learning curve will be steep, take the time needed to make it. On Sat, Oct 2, 2010 at 9:28 AM, Matthew Seaman < m.seaman@infracaninophile.co.uk> wrote: > On 02/10/2010 07:42:30, Chetan Shukla wrote: > > > Could someone please outline the steps needed in porting a general > application from > > Linux to FreeBSD. > > Step 1) Spend time (probably several years) achieving a reasonable level > of expertise in the languages and concepts involved. > > Step 2) During the same time, become intimately familiar with the > applicable bits of API and the general operating environment available > under FreeBSD. > > Step 3) Copy distfile tarballs onto FreeBSD box, or otherwise obtain the > source code. > > Step 4) Try to configure and compile the software, or otherwise do what > is needed to get the software into a usable state. > > Step 5) Test it > > Step 6) If it works, stop the compile/test cycle here and publish your > results, preferably by writing a new port and submitting it as described > in the Porter's handbook. > > Step 7) Else generate fixes for any apparent problems. > > Step 8) Goto step 4. > > Perhaps you might ask a more narrowly specified question? The answers > will likely be a lot more useful to you. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matthew@infracaninophile.co.uk Kent, CT11 9PW > > -- mvh Torfinn From jhs at berklix.com Sat Oct 2 12:46:29 2010 From: jhs at berklix.com (Julian H. Stacey) Date: Sat Oct 2 12:46:32 2010 Subject: porting: Linux to Freebsd In-Reply-To: Your message "Sat, 02 Oct 2010 08:28:52 BST." <4CA6DF34.5080301@infracaninophile.co.uk> Message-ID: <201010021208.o92C8VCv088633@fire.js.berklix.net> > On 02/10/2010 07:42:30, Chetan Shukla wrote: > > > Could someone please outline the steps needed in porting a general appl= > ication from > > Linux to FreeBSD. > > Step 1) Spend time (probably several years) achieving a reasonable level > of expertise in the languages and concepts involved. .... > Step 8) Goto step 4. > > Perhaps you might ask a more narrowly specified question? The answers > will likely be a lot more useful to you. Right :-) Chetan, First check if the port already exists http://www.freebsd.org/ports/ If no money: - A few years academic study helps - Obtain source code, check licence. - Read sources. - Read relevant FreeBSD manuals & documentation - Work. - If stuck, post exact questions to lists specific to whatever aspect. - Feed code extensions back to generic source owner. - Use send-pr to give us a working ports/ wrapper. If you have money but want details confidential, Hire a professional consultant. Here's a geographicly indexed list: http://berklix.com/consultants/ PS more consultants welcome to add their details, see page for format. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not HTML, quoted-printable & base 64 spam formats. Avoid top posting, It cripples itemised cumulative responses. From kamikaze at bsdforen.de Sat Oct 2 14:01:32 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sat Oct 2 14:01:36 2010 Subject: porting: Linux to Freebsd In-Reply-To: References: Message-ID: <4CA73B39.5030604@bsdforen.de> On 02/10/2010 08:42, Chetan Shukla wrote: > Hi, > Could someone please outline the steps needed in porting a general application from > Linux to FreeBSD. If the thing is not tightly coupled to the kernel, the general compile guide to the software you try to compile will suffice most of the time. Regards From lists at eitanadler.com Sat Oct 2 14:21:41 2010 From: lists at eitanadler.com (Eitan Adler) Date: Sat Oct 2 14:21:44 2010 Subject: porting: Linux to Freebsd In-Reply-To: References: Message-ID: On Sat, Oct 2, 2010 at 2:42 AM, Chetan Shukla wrote: > Hi, > Could someone please outline the steps needed in porting a general application from > Linux to FreeBSD. > > > Thanks & Regards, > Chetan You may want to have a look at http://wiki.freebsd.org/AvoidingLinuxisms If you ask a more specific question you will probably get more specific answers. -- Eitan Adler From scf at FreeBSD.org Sat Oct 2 15:28:39 2010 From: scf at FreeBSD.org (Sean C. Farley) Date: Sat Oct 2 15:28:43 2010 Subject: editors/vim installs to / In-Reply-To: <20101002060201.GA8287@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> Message-ID: On Fri, 1 Oct 2010, David O'Brien wrote: > On Fri, Sep 17, 2010 at 05:38:21PM -0700, Rob Farmer wrote: >> However, I still think it would benefit everyone if the maintainer >> could provide an explanation for some of the current behavior and >> would at least be open to discussion about changing it. The biggest >> problem here, IMHO, is not the OPTIONS issue, but rather the use of >> GTK 1 as the default. > > I have commented on GTK2 (explained) in the past. > It is the kitchen sink that gtk2 brings in vs. gtk1. On my desktop > gtk2 requires 64 other packages. gtk1 requires 20. > > I guess its time to take another survey. Is Vim one of the few last > gtk1 consumers? It probably is. Nothing I have installed uses GTK1. Actually, this includes Vim since I have it using Athena widgets. :) BTW, I just noticed by chance that Vim compiled with Athena widgets for the GUI has no dependency on libXaw. This is all the dependencies on my Vim install with a working gvim: Dependency: python26-2.6.6 Dependency: cscope-15.7a Dependency: libiconv-1.13.1_1 Sean -- scf@FreeBSD.org From norman at khine.net Sat Oct 2 17:00:00 2010 From: norman at khine.net (Norman Khine) Date: Sat Oct 2 17:00:04 2010 Subject: py-matplotlib issues Message-ID: hello, i am trying to build py-matplotlib, but get this error # cd /usr/ports/math/py-matplotlib # make install clean http://pastie.org/1195467 any pointers much appreciated. norman -- ?u?op ?p?sdn p,u?n? p??o? ??? ??s no? '?u???? s???? ??? pu? '?u??uo? ?q s,??? ??? %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] ) From cvs-src at yandex.ru Sat Oct 2 17:39:27 2010 From: cvs-src at yandex.ru (Ruslan Mahmatkhanov) Date: Sat Oct 2 17:39:31 2010 Subject: py-matplotlib issues In-Reply-To: References: Message-ID: <4CA76DD2.7050104@yandex.ru> 02.10.2010 20:36, Norman Khine ?????: > hello, i am trying to build py-matplotlib, but get this error > > # cd /usr/ports/math/py-matplotlib > # make install clean > > http://pastie.org/1195467 > > any pointers much appreciated. > > norman > Am i right that you trying to build matplotlib with TKAGGBACKEND switched to off? -- Regards, Ruslan From Gabor at Zahemszky.HU Sat Oct 2 17:39:35 2010 From: Gabor at Zahemszky.HU (Zahemszky =?ISO-8859-2?Q?G=E1bor?=) Date: Sat Oct 2 17:39:39 2010 Subject: FreeBSD mencoder port problem Message-ID: <20101002182128.7d3a96e9@Picasso.Zahemszky.HU> Hi! I've just found that libmpcdec has been deprecated in FreeBSD port. Because of it, there was an mplayer modification. The only problem is that mencoder has the same libmpcdec dependency, so it should be updated, too. Thanks, Zahy < Gabor at Zahemszky dot UH > -- #!/bin/ksh # # See my GPG key at http://www.Zahemszky.HU # Z='21N16I25C25E30, 40M30E33E25T15U!'; IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break; [[ $i = ??? ]]&&j=$i&&i=${i%?}; typeset -i40 i=8#$i;print -n ${i#???}; [[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;}; IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2; [[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" From norman at khine.net Sat Oct 2 17:58:58 2010 From: norman at khine.net (Norman Khine) Date: Sat Oct 2 17:59:03 2010 Subject: py-matplotlib issues In-Reply-To: <4CA76DD2.7050104@yandex.ru> References: <4CA76DD2.7050104@yandex.ru> Message-ID: hi On Sat, Oct 2, 2010 at 7:37 PM, Ruslan Mahmatkhanov wrote: > 02.10.2010 20:36, Norman Khine ?????: >> >> hello, i am trying to build py-matplotlib, but get this error >> >> # cd /usr/ports/math/py-matplotlib >> # make install clean >> >> http://pastie.org/1195467 >> >> any pointers much appreciated. >> >> norman >> > > Am i right that you trying to build matplotlib with TKAGGBACKEND switched to > off? i only used the GTKBACKEND, and this works. thanks for the reply. > -- > Regards, > Ruslan > -- ?u?op ?p?sdn p,u?n? p??o? ??? ??s no? '?u???? s???? ??? pu? '?u??uo? ?q s,??? ??? %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] ) From sfourman at gmail.com Sat Oct 2 22:59:50 2010 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Sat Oct 2 22:59:56 2010 Subject: libtool22 Message-ID: hello, Latley every time I run portupgrade -ar any random port will try to install libtool22... then it is already installed.. so if I deinstall libtool22.. then then reinstall the original port I was trying to install.. everything works.. how do I fix libtool22 for good so that all ports know that it is installed? Sample of the problem trying to install /usr/ports/audio/rhythmbox. ibtool: link: (cd libltdl/.libs/libltdlc.lax/dlopen.a && ar x "/usr/ports/devel/libtool22/work/libtool-2.2.10/libltdl/.libs/dlopen.a") libtool: link: ar cru libltdl/.libs/libltdlc.a libltdl/loaders/.libs/libltdl_libltdlc_la-preopen.o libltdl/.libs/libltdl_libltdlc_la-lt__alloc.o libltdl/.libs/libltdl_libltdlc_la-lt_dlloader.o libltdl/.libs/libltdl_libltdlc_la-lt_error.o libltdl/.libs/libltdl_libltdlc_la-ltdl.o libltdl/.libs/libltdl_libltdlc_la-slist.o libltdl/.libs/argz.o libltdl/.libs/libltdlcS.o libltdl/.libs/libltdlc.lax/dlopen.a/dlopen.o libtool: link: ranlib libltdl/.libs/libltdlc.a libtool: link: rm -fr libltdl/.libs/libltdlc.lax libtool: link: ( cd "libltdl/.libs" && rm -f "libltdlc.la" && ln -s "../libltdlc.la" "libltdlc.la" ) ===> Installing for libtool-2.2.10 ===> Generating temporary packing list ===> Checking if devel/libtool22 already installed ===> libtool-2.2.10 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of devel/libtool22 without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. *** Error code 1 Stop in /usr/ports/devel/libtool22. *** Error code 1 Stop in /usr/ports/audio/rhythmbox. *** Error code 1 Stop in /usr/ports/audio/rhythmbox. Sam# -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From pilot at monkey.org Sat Oct 2 23:28:32 2010 From: pilot at monkey.org (pilot) Date: Sat Oct 2 23:28:36 2010 Subject: update for security/arirang v2.00 Message-ID: <20101002232831.GA30796@l.monkey.org> hi arirang 2.00 released at today. so, security/arirang/ need to update. i havn't freebsd systems at the moment, but security/arirang/Makefile can modify like below Makefile) -PORTVERSION= 1.95 +PORTVERSION= 2.00 also require update distinfo and pkg-plist file. please update security/arirang ports. thanks From demelier.david at gmail.com Sun Oct 3 08:22:48 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 08:22:54 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: <20101002002605.GA8018@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> Message-ID: 2010/10/2 David O'Brien : > On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote: >> What is "sufficiently clean" ? I wonder what is not clean in the >> options framework, so please tell me then we still can clean it? > > When the Ports Collection was invented, ports maintainers were to > choose a reasonable set of configuration for the FreeBSD community > and have the port build that way. > > Today we have ports that seem to expose every single option to GNU > configure and giving the user a puzzling choice of too many things. > Often the explanations are nothing more than restating the option > name and the user is left wondering what is X? ?What does Y mean? > How do I know if I really want Z or not? ?Why is threading so often > an OPTION and not just the default? ?Why do I have to go read the > packages README and INSTALLING to figure out the caveats of say > enabling threading? ?Or what the other list of things are and their > caveats? > > 1. One should not have to deal with the OPTIONS dialog just to > 'make extract' if one wants to check the license or otherwise > investigate a port before deciding to install it. > > 2. With the way OPTIONS handling is done, there isn't a way for me > to query if I built with the defaults or not. > Thus leading to every port I manually install looking like it was > customized just because /var/db/ports/${PORTNAME} exists. ?Thus > implying I can no longer install the pre-build package. > make rmconfig ? > 3. OPTIONS are limited to only checkbox YES/NO settings. > Why can I not set PREFIX thru the OPTIONS framework and have it come > from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? > Even the boolean NOPORTDOCS isn't available thru OPTIONS. > Thus it is an inconsistent way to configure a port. > I agree. As I said in 4, OPTIONS should follow the defined knob in make.conf. But for not boolean knobs there is something we can also do, spawn a little textbox to define an option with a string. Example : [X] WITH_X foo bar [ ] WITH_Y foo bar baz [fr_FR en_GB] LANGS to be build Here pressing enter on LANGS would spawn a little textbox that can be fulfilled by the user. The little problem is how to tell to OPTIONS that it's not a boolean entry. > 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in > /etc/make.conf, why does the OPTIONS dialog offer me > "[X] NLS Enable gettext support" instead of defaulting the > dialog to unchecked? > I agree with this inconsistency, I think with a little of work OPTIONS framework should be to follow KNOB to enable an option if it's already defined by the user. This would be great for people that use WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it. pkgsrc do it with PKG_DEFAULT_OPTIONS= setting. > 5. One cannot opt-out of OPTIONS. > WITHOUT_OPTIONS does not work to just get the defaults while skipping > the OPTIONS dialog. ?Note, setting BATCH does a lot more than just > make OPTIONS non-interactive (for some ports it stops other > non-OPTIONS interaction with the user that one should see). ?Thus > there is no way to get an uninterrupted default build of something. > > 6. One cannot opt-in/opt-out on a per-port basis. > WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS > should be supported to control the OPTIONS dialog just when > building ${PORTNAME}. > > 7. Setting ${PORTNAME}_WITH[OUT]_ (or > WITH[OUT]_${PORTNAME}_) should set > WITH[OUT]_ just when building ${PORTNAME}. > So that folks who don't want to be interrupted with OPTIONS every > time there is an update to the list can hardcode their choices in > /etc/make.conf. > Yes, check my answer at 4. > 8. OPTIONS make a mess in the typescript file from > 'script typescript make', and the choices are totally unreadable vs. > 'script typescript make -DWITH_FOO -WITHOUT_BAR'. > There is a disadvantages with knobs here, you must define knob each time you install/upgrade a port. Of course you can do it with the make.conf or the portconf system. OPTIONS also prints -DSOMETHING when compiling. Definitely, I like knobs and I like options. But mixing the both is painful. You should check by typing make config or sometime lsknobs or even reading the makefile. The best thing to do is switch totally to a way to configure a port and remove the other one. I think we should try to upgrade the options framework with what I said at 4. and 3. It's possible but we need some work. Kind regards, -- Demelier David From m.seaman at infracaninophile.co.uk Sun Oct 3 08:55:13 2010 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun Oct 3 08:55:16 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> Message-ID: <4CA844E5.7060303@infracaninophile.co.uk> On 03/10/2010 09:22:46, David DEMELIER wrote: >> 3. OPTIONS are limited to only checkbox YES/NO settings. >> > Why can I not set PREFIX thru the OPTIONS framework and have it come >> > from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? >> > Even the boolean NOPORTDOCS isn't available thru OPTIONS. >> > Thus it is an inconsistent way to configure a port. >> > > I agree. As I said in 4, OPTIONS should follow the defined knob in > make.conf. But for not boolean knobs there is something we can also > do, spawn a little textbox to define an option with a string. Example > : > > [X] WITH_X foo bar > [ ] WITH_Y foo bar baz > [fr_FR en_GB] LANGS to be build > > Here pressing enter on LANGS would spawn a little textbox that can be > fulfilled by the user. The little problem is how to tell to OPTIONS > that it's not a boolean entry. > And the rest? Pursuing this idea through to its logical conclusion, you'ld end up implementing radio buttons, text entry boxes, drop down lists -- all the normal bits used in html forms. In fact, you might just as well write a small HTML form, display it using lynx or w3c or some other text mode browser[*], and then have the form action feed into a CGI program that outputs a small Makefile with appropriate variable definitions in it. Hmmm... doesn't address David's point about options dialogs not showing pre-existing options settings, but it should be simple enough to have a 'Use default settings' check box. Cheers, Matthew [*] Or FF if you really must. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101003/d7670991/signature.pgp From norman at khine.net Sun Oct 3 09:23:56 2010 From: norman at khine.net (Norman Khine) Date: Sun Oct 3 09:24:00 2010 Subject: swftools and Python Message-ID: hello, i have built the swftools port but from the make/install configure it does not seem to find Python.h so when i run: $ python -c 'import gfx' Traceback (most recent call last): File "", line 1, in ImportError: No module named gfx how do i enable this? thanks norman -- ?u?op ?p?sdn p,u?n? p??o? ??? ??s no? '?u???? s???? ??? pu? '?u??uo? ?q s,??? ??? %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] ) From demelier.david at gmail.com Sun Oct 3 09:45:03 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 09:45:07 2010 Subject: OPTIONS In-Reply-To: <4CA844E5.7060303@infracaninophile.co.uk> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> Message-ID: 2010/10/3 Matthew Seaman : > On 03/10/2010 09:22:46, David DEMELIER wrote: >>> 3. OPTIONS are limited to only checkbox YES/NO settings. >>> > Why can I not set PREFIX thru the OPTIONS framework and have it come >>> > from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? >>> > Even the boolean NOPORTDOCS isn't available thru OPTIONS. >>> > Thus it is an inconsistent way to configure a port. >>> > >> I agree. As I said in 4, OPTIONS should follow the defined knob in >> make.conf. But for not boolean knobs there is something we can also >> do, spawn a little textbox to define an option with a string. Example >> : >> >> [X] WITH_X foo bar >> [ ] WITH_Y foo bar baz >> [fr_FR en_GB] LANGS to be build >> >> Here pressing enter on LANGS would spawn a little textbox that can be >> fulfilled by the user. The little problem is how to tell to OPTIONS >> that it's not a boolean entry. >> > > And the rest? ?Pursuing this idea through to its logical conclusion, > you'ld end up implementing radio buttons, text entry boxes, drop down > lists -- all the normal bits used in html forms. > Don't you like this? sysinstall was made with dialog. And radiobuttons could be used to choose a group of options yes, for example when you only need to choose one option in three available choices, then BROKEN lines could be removed :-) > In fact, you might just as well write a small HTML form, display it > using lynx or w3c or some other text mode browser[*], and then have the > form action feed into a CGI program that outputs a small Makefile with > appropriate variable definitions in it. > I don't want something complex, checkbox, textbox, radiobuttons is enough. > Hmmm... doesn't address David's point about options dialogs not showing > pre-existing options settings, but it should be simple enough to have a > 'Use default settings' check box. > > ? ? ? ?Cheers, > > ? ? ? ?Matthew > > [*] Or FF if you really must. > > -- > Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate > JID: matthew@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW > > -- Demelier David From kamikaze at bsdforen.de Sun Oct 3 10:08:25 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Oct 3 10:08:27 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> Message-ID: <4CA85617.7060503@bsdforen.de> On 03/10/2010 11:45, David DEMELIER wrote: > 2010/10/3 Matthew Seaman : > I don't want something complex, checkbox, textbox, radiobuttons is enough. Textbox is _very_ complex. Think of all the code you'd have to add to ports to check what was entered by the user. At the very least you have to verify that whatever was provided is valid. For the feature not to become annoying you'd have to be a lot more fuzzy and complex, though. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From demelier.david at gmail.com Sun Oct 3 10:29:11 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 10:29:15 2010 Subject: OPTIONS In-Reply-To: <4CA85617.7060503@bsdforen.de> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> Message-ID: 2010/10/3 Dominic Fandrey : > On 03/10/2010 11:45, David DEMELIER wrote: >> 2010/10/3 Matthew Seaman : >> I don't want something complex, checkbox, textbox, radiobuttons is enough. > > Textbox is _very_ complex. Think of all the code you'd have to > add to ports to check what was entered by the user. > At the very least you have to verify that whatever was provided > is valid. For the feature not to become annoying you'd have to > be a lot more fuzzy and complex, though. > What do you mean by valid? In the way that the user can't insert any no alpha-numeric characters or an entry that is only valid to the application ? -- Demelier David From kamikaze at bsdforen.de Sun Oct 3 10:40:21 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Oct 3 10:40:25 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> Message-ID: <4CA85D92.8070500@bsdforen.de> On 03/10/2010 12:29, David DEMELIER wrote: > 2010/10/3 Dominic Fandrey : >> On 03/10/2010 11:45, David DEMELIER wrote: >>> 2010/10/3 Matthew Seaman : >>> I don't want something complex, checkbox, textbox, radiobuttons is enough. >> >> Textbox is _very_ complex. Think of all the code you'd have to >> add to ports to check what was entered by the user. >> At the very least you have to verify that whatever was provided >> is valid. For the feature not to become annoying you'd have to >> be a lot more fuzzy and complex, though. >> > > What do you mean by valid? In the way that the user can't insert any > no alpha-numeric characters or an entry that is only valid to the > application ? > Text fields are arbitrary and you'd probably want to limit it to a specific purpose, like a list of languages. So is de_* an acceptable language? Do you delimit with space, pipe or semicolon? Do people really want to be bothered with learning the specific syntax of your ports text input fields? -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From demelier.david at gmail.com Sun Oct 3 10:40:35 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 10:40:39 2010 Subject: openoffice.org-3 does not build anymore Message-ID: Hi, I can't build openoffice.org-3 anymore, readlicense_oo need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /usr/obj/usr/ports/editors/openoffice.o rg-3/work/OOO320_m19/readlicense_oo/ Attention: if you build and deliver the above module(s) you may prolongue your t he build issuing command "build --from readlicense_oo" rmdir /tmp/aTcGY4w2lp *** Error code 1 Stop in /usr/ports/editors/openoffice.org-3. Cheers, -- Demelier David From demelier.david at gmail.com Sun Oct 3 10:48:42 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 10:48:45 2010 Subject: OPTIONS In-Reply-To: <4CA85D92.8070500@bsdforen.de> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> <4CA85D92.8070500@bsdforen.de> Message-ID: 2010/10/3 Dominic Fandrey : > On 03/10/2010 12:29, David DEMELIER wrote: >> 2010/10/3 Dominic Fandrey : >>> On 03/10/2010 11:45, David DEMELIER wrote: >>>> 2010/10/3 Matthew Seaman : >>>> I don't want something complex, checkbox, textbox, radiobuttons is enough. >>> >>> Textbox is _very_ complex. Think of all the code you'd have to >>> add to ports to check what was entered by the user. >>> At the very least you have to verify that whatever was provided >>> is valid. For the feature not to become annoying you'd have to >>> be a lot more fuzzy and complex, though. >>> >> >> What do you mean by valid? In the way that the user can't insert any >> no alpha-numeric characters or an entry that is only valid to the >> application ? >> > > Text fields are arbitrary and you'd probably want to limit it to > a specific purpose, like a list of languages. > > So is de_* an acceptable language? Do you delimit with space, pipe > or semicolon? Do people really want to be bothered with learning > the specific syntax of your ports text input fields? > In the openoffice ports you have LOCALIZED_LANG knob, I needed to check which kind of delimiters was needed and it's a space, so delimit by space is enough. -- Demelier David From 000.fbsd at quip.cz Sun Oct 3 11:10:38 2010 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sun Oct 3 11:10:43 2010 Subject: OPTIONS In-Reply-To: <4CA85617.7060503@bsdforen.de> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> Message-ID: <4CA860E2.2080402@quip.cz> Dominic Fandrey wrote: > On 03/10/2010 11:45, David DEMELIER wrote: >> 2010/10/3 Matthew Seaman: >> I don't want something complex, checkbox, textbox, radiobuttons is enough. > > Textbox is _very_ complex. Think of all the code you'd have to > add to ports to check what was entered by the user. > At the very least you have to verify that whatever was provided > is valid. For the feature not to become annoying you'd have to > be a lot more fuzzy and complex, though. You don't need to. It is the same as if user put something wrong in to make.conf, ports.conf or even if somebody do: cd /usr/ports/databases/mysql51-server make WITH_CHARSET=UTF13 WITH_XCHARSET=1 WITH_COLLATION=true All of them are invalid and not checked by ports framework, so if somebody implements textbox in to OPTIONS framework, the situation will not be worse! Situation will be better for those users not familiar with WITH_XXXX knobs. Miroslav Lachman From rde at tavi.co.uk Sun Oct 3 11:18:49 2010 From: rde at tavi.co.uk (Bob Eager) Date: Sun Oct 3 11:18:53 2010 Subject: openoffice.org-3 does not build anymore In-Reply-To: References: Message-ID: <20101003121845.5b707d94@raksha.tavi.co.uk> On Sun, 3 Oct 2010 12:40:33 +0200 David DEMELIER wrote: > Hi, > > I can't build openoffice.org-3 anymore, > > readlicense_oo > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while > making /usr/obj/usr/ports/editors/openoffice.o > rg-3/work/OOO320_m19/readlicense_oo/ > > Attention: if you build and deliver the above module(s) you may > prolongue your t he build issuing command "build --from > readlicense_oo" > > rmdir /tmp/aTcGY4w2lp > *** Error code 1 > > Stop in /usr/ports/editors/openoffice.org-3. Quite often caused by running out of swap space. Or possibly actual disk space. From cmt at burggraben.net Sun Oct 3 11:22:15 2010 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Sun Oct 3 11:22:18 2010 Subject: openoffice.org-3 does not build anymore In-Reply-To: References: Message-ID: <20101003110602.GA1995@elch.exwg.net> ## David DEMELIER (demelier.david@gmail.com): > I can't build openoffice.org-3 anymore, > > readlicense_oo > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while making /usr/obj/usr/ports/editors/openoffice.o > rg-3/work/OOO320_m19/readlicense_oo/ I've not yet seen errors in readlicense_oo, but... OpenOffice ships a lot of libraries in their source tarball and installs them in it's build environment. When compiling and linking the actual OpenOffice modules, this results in conflicts with those versions of these libraries which are already installed on your system. Right now, I believe the surest way to build OpenOffice is to set up a jail for compiling OpenOffice only. Have you tried that (it worked for me a few weeks ago)? Regards, Christoph -- Spare Space From m.seaman at infracaninophile.co.uk Sun Oct 3 11:36:52 2010 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun Oct 3 11:36:55 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> Message-ID: <4CA86AC8.9080108@infracaninophile.co.uk> On 03/10/2010 10:45:01, David DEMELIER wrote: > 2010/10/3 Matthew Seaman : >> On 03/10/2010 09:22:46, David DEMELIER wrote: >>>> 3. OPTIONS are limited to only checkbox YES/NO settings. >>>>> Why can I not set PREFIX thru the OPTIONS framework and have it come >>>>> from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? >>>>> Even the boolean NOPORTDOCS isn't available thru OPTIONS. >>>>> Thus it is an inconsistent way to configure a port. >>>>> >>> I agree. As I said in 4, OPTIONS should follow the defined knob in >>> make.conf. But for not boolean knobs there is something we can also >>> do, spawn a little textbox to define an option with a string. Example >>> : >>> >>> [X] WITH_X foo bar >>> [ ] WITH_Y foo bar baz >>> [fr_FR en_GB] LANGS to be build >>> >>> Here pressing enter on LANGS would spawn a little textbox that can be >>> fulfilled by the user. The little problem is how to tell to OPTIONS >>> that it's not a boolean entry. >>> >> >> And the rest? Pursuing this idea through to its logical conclusion, >> you'ld end up implementing radio buttons, text entry boxes, drop down >> lists -- all the normal bits used in html forms. >> > > Don't you like this? sysinstall was made with dialog. And radiobuttons > could be used to choose a group of options yes, for example when you > only need to choose one option in three available choices, then BROKEN > lines could be removed :-) Don't get me wrong -- I think the current OPTIONS processing is at once too limited and too intrusive, and that it is ripe for some serious improvement. I'm all for your idea; I just don't think you've gone far enough. Now, personally, I quite like the idea of simply sticking entries into /etc/make.conf to control port compilation settings. Which would be fine for me managing my small number of home machines, but certainly not suitable for all users. There is also the problem of knowing what controls are available and having some reasonable idea of what they do, without the necessity of being a make(1) guru or grovelling through the guts of dozens of ports. Giving OPTIONS processing a lot more flexibility, and the capability to display help text etc. (yes -- I know there have been attempts in this direction already) plus pushing some of the logic up from the Makefile into the OPTIONS dialogue[*] would certainly improve the user experience. Something with the capabilities of sysinstall would be a step in the right direction, but I think most would agree, sysinstall is a bit clunky and confusing to new users. An alternative that behaves like a web form is going to be a lot more accessible to J. Random User. But that is really beyond the limits of what I have any idea about coding. I can see how to prototype it readily enough as a web app, but having to fire up an instance of apache or something just to install a few ports just ain't right. Cheers, Matthew [*] Ever had the experience of clicking on OPTIONS settings and then finding the port won't accept that combination of OPTIONS? That's frustrating, especially when combined with the use of eg. portmaster(8) where choosing OPTIONS can happen quite a while before attempting to build the port. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101003/cb206676/signature.pgp From demelier.david at gmail.com Sun Oct 3 11:39:55 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 11:39:59 2010 Subject: OPTIONS In-Reply-To: <4CA86AC8.9080108@infracaninophile.co.uk> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA86AC8.9080108@infracaninophile.co.uk> Message-ID: 2010/10/3 Matthew Seaman : > On 03/10/2010 10:45:01, David DEMELIER wrote: >> 2010/10/3 Matthew Seaman : >>> On 03/10/2010 09:22:46, David DEMELIER wrote: >>>>> 3. OPTIONS are limited to only checkbox YES/NO settings. >>>>>> Why can I not set PREFIX thru the OPTIONS framework and have it come >>>>>> from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? >>>>>> Even the boolean NOPORTDOCS isn't available thru OPTIONS. >>>>>> Thus it is an inconsistent way to configure a port. >>>>>> >>>> I agree. As I said in 4, OPTIONS should follow the defined knob in >>>> make.conf. But for not boolean knobs there is something we can also >>>> do, spawn a little textbox to define an option with a string. Example >>>> : >>>> >>>> [X] WITH_X foo bar >>>> [ ] WITH_Y foo bar baz >>>> [fr_FR en_GB] LANGS to be build >>>> >>>> Here pressing enter on LANGS would spawn a little textbox that can be >>>> fulfilled by the user. The little problem is how to tell to OPTIONS >>>> that it's not a boolean entry. >>>> >>> >>> And the rest? ?Pursuing this idea through to its logical conclusion, >>> you'ld end up implementing radio buttons, text entry boxes, drop down >>> lists -- all the normal bits used in html forms. >>> >> >> Don't you like this? sysinstall was made with dialog. And radiobuttons >> could be used to choose a group of options yes, for example when you >> only need to choose one option in three available choices, then BROKEN >> lines could be removed :-) > > Don't get me wrong -- I think the current OPTIONS processing is at once > too limited and too intrusive, and that it is ripe for some serious > improvement. ?I'm all for your idea; I just don't think you've gone far > enough. > > Now, personally, I quite like the idea of simply sticking entries into > /etc/make.conf to control port compilation settings. ?Which would be > fine for me managing my small number of home machines, but certainly not > suitable for all users. ?There is also the problem of knowing what > controls are available and having some reasonable idea of what they do, > without the necessity of being a make(1) guru or grovelling through the > guts of dozens of ports. > Yes that's why I would like that OPTIONS must read make.conf to set default ports options and only after make a individual change for it. > Giving OPTIONS processing a lot more flexibility, and the capability to > display help text etc. (yes -- I know there have been attempts in this > direction already) plus pushing some of the logic up from the Makefile > into the OPTIONS dialogue[*] would certainly improve the user experience. > > Something with the capabilities of sysinstall would be a step in the > right direction, but I think most would agree, sysinstall is a bit > clunky and confusing to new users. ?An alternative that behaves like a > web form is going to be a lot more accessible to J. Random User. > > But that is really beyond the limits of what I have any idea about > coding. ?I can see how to prototype it readily enough as a web app, but > having to fire up an instance of apache or something just to install a > few ports just ain't right. > > ? ? ? ?Cheers, > > ? ? ? ?Matthew > > [*] Ever had the experience of clicking on OPTIONS settings and then > finding the port won't accept that combination of OPTIONS? ?That's > frustrating, especially when combined with the use of eg. portmaster(8) > where choosing OPTIONS can happen quite a while before attempting to > build the port. > > -- > Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate > JID: matthew@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW > > -- Demelier David From lumiwa at gmail.com Sun Oct 3 11:40:22 2010 From: lumiwa at gmail.com (ajtiM) Date: Sun Oct 3 11:40:24 2010 Subject: openoffice.org-3 does not build anymore In-Reply-To: References: Message-ID: <201010030640.13676.lumiwa@gmail.com> On Sunday 03 October 2010 05:40:33 David DEMELIER wrote: > Hi, > > I can't build openoffice.org-3 anymore, > > readlicense_oo > need(s) to be rebuilt > > Reason(s): > > ERROR: error 65280 occurred while making > /usr/obj/usr/ports/editors/openoffice.o > rg-3/work/OOO320_m19/readlicense_oo/ > > Attention: if you build and deliver the above module(s) you may prolongue > your t he build issuing command "build --from readlicense_oo" > > rmdir /tmp/aTcGY4w2lp > *** Error code 1 > > Stop in /usr/ports/editors/openoffice.org-3. > > Cheers, I didn't have problem with RC-3 and it works very good (started yesterday about eight in the evening and it is done). Mitja -------- http://starikarp.redbubble.com From demelier.david at gmail.com Sun Oct 3 11:46:58 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Sun Oct 3 11:47:01 2010 Subject: openoffice.org-3 does not build anymore In-Reply-To: <201010030640.13676.lumiwa@gmail.com> References: <201010030640.13676.lumiwa@gmail.com> Message-ID: 2010/10/3 ajtiM : > On Sunday 03 October 2010 05:40:33 David DEMELIER wrote: >> Hi, >> >> I can't build openoffice.org-3 anymore, >> >> ? ? ? ? readlicense_oo >> need(s) to be rebuilt >> >> Reason(s): >> >> ERROR: error 65280 occurred while making >> /usr/obj/usr/ports/editors/openoffice.o >> rg-3/work/OOO320_m19/readlicense_oo/ >> >> Attention: if you build and deliver the above module(s) you may prolongue >> your t he build issuing command "build --from readlicense_oo" >> >> rmdir /tmp/aTcGY4w2lp >> *** Error code 1 >> >> Stop in /usr/ports/editors/openoffice.org-3. >> >> Cheers, > > I didn't have problem with RC-3 and it works very good (started yesterday > about eight in the evening and it is done). > > Mitja > -------- > http://starikarp.redbubble.com > So I don't understand. -- Demelier David From kamikaze at bsdforen.de Sun Oct 3 12:09:21 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Oct 3 12:09:24 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> <4CA85D92.8070500@bsdforen.de> Message-ID: <4CA8726F.6030105@bsdforen.de> On 03/10/2010 12:48, David DEMELIER wrote: > 2010/10/3 Dominic Fandrey : >> On 03/10/2010 12:29, David DEMELIER wrote: >>> 2010/10/3 Dominic Fandrey : >>>> On 03/10/2010 11:45, David DEMELIER wrote: >>>>> 2010/10/3 Matthew Seaman : >>>>> I don't want something complex, checkbox, textbox, radiobuttons is enough. >>>> >>>> Textbox is _very_ complex. Think of all the code you'd have to >>>> add to ports to check what was entered by the user. >>>> At the very least you have to verify that whatever was provided >>>> is valid. For the feature not to become annoying you'd have to >>>> be a lot more fuzzy and complex, though. >>>> >>> >>> What do you mean by valid? In the way that the user can't insert any >>> no alpha-numeric characters or an entry that is only valid to the >>> application ? >>> >> >> Text fields are arbitrary and you'd probably want to limit it to >> a specific purpose, like a list of languages. >> >> So is de_* an acceptable language? Do you delimit with space, pipe >> or semicolon? Do people really want to be bothered with learning >> the specific syntax of your ports text input fields? >> > > In the openoffice ports you have LOCALIZED_LANG knob, I needed to > check which kind of delimiters was needed and it's a space, so delimit > by space is enough. > I have set LOCALIZED_LANG wrongly before. An excellent example, why text input boxes are /very dangerous/. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From kamikaze at bsdforen.de Sun Oct 3 12:19:55 2010 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Oct 3 12:19:59 2010 Subject: OPTIONS In-Reply-To: <4CA860E2.2080402@quip.cz> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <4CA85617.7060503@bsdforen.de> <4CA860E2.2080402@quip.cz> Message-ID: <4CA874E9.2070807@bsdforen.de> On 03/10/2010 12:54, Miroslav Lachman wrote: > Dominic Fandrey wrote: >> On 03/10/2010 11:45, David DEMELIER wrote: >>> 2010/10/3 Matthew Seaman: >>> I don't want something complex, checkbox, textbox, radiobuttons is >>> enough. >> >> Textbox is _very_ complex. Think of all the code you'd have to >> add to ports to check what was entered by the user. >> At the very least you have to verify that whatever was provided >> is valid. For the feature not to become annoying you'd have to >> be a lot more fuzzy and complex, though. > > You don't need to. It is the same as if user put something wrong in to > make.conf, ports.conf or even if somebody do: > > cd /usr/ports/databases/mysql51-server > make WITH_CHARSET=UTF13 WITH_XCHARSET=1 WITH_COLLATION=true No, it's technically the same, but from a usability standpoint this is entirely different. In your examples a user makes an educated and competent change, the user acted on his own behalf. When you pop up a dialogue and ask the user for something you better have a) a good reason, b) good defaults, c) give thorough guidance and explanation and d) offer a way to roll back the changes made. Or you can kiss your users good bye. > All of them are invalid and not checked by ports framework, so if > somebody implements textbox in to OPTIONS framework, the situation will > not be worse! Situation will be better for those users not familiar with > WITH_XXXX knobs. You're mistaking a usability issue with a technical one. Jef Raskin's Humane Interface is a good starting point. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From amdmi3 at amdmi3.ru Sun Oct 3 13:45:11 2010 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Sun Oct 3 13:45:15 2010 Subject: FreeBSD Port: gnash-0.8.7_4 In-Reply-To: <4CA5EF31.9020403@icyb.net.ua> References: <4CA36014.6040201@cineca.it> <20101001110539.GD11112@hades.panopticon> <4CA5EF31.9020403@icyb.net.ua> Message-ID: <20101003134507.GF11112@hades.panopticon> * Andriy Gapon (avg@icyb.net.ua) wrote: > > Gnash port was updated, sorry for delay and thanks for waiting! > > The following patch is required for compilation with gcc44+. > It's definitely an upstream issue: > --- libbase/tu_file.h.orig 2010-10-01 16:39:16.419334667 +0300 > +++ libbase/tu_file.h 2010-10-01 16:39:55.565197173 +0300 > @@ -12,6 +12,7 @@ > #include "dsodefs.h" // DSOEXPORT > #include "utility.h" > #include "IOChannel.h" // for inheritance > +#include Added, thanks. I will submit it upstream when I find time for it, along with other ports patches. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From jhell at DataIX.net Sun Oct 3 22:27:25 2010 From: jhell at DataIX.net (jhell) Date: Sun Oct 3 22:27:29 2010 Subject: editors/vim installs to / In-Reply-To: <32055F40-C8F9-4A65-9985-B1FA4AE11A38@FreeBSD.org> References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> <32055F40-C8F9-4A65-9985-B1FA4AE11A38@FreeBSD.org> Message-ID: <4CA90347.3020207@DataIX.net> On 10/02/2010 02:49, Ade Lovett wrote: > editors/vim -- fully functional console-only (no X11) > editors/vim-lite -- stripped down version (again, no X11, perhaps even linked static for use within embedded systems) > editors/vim-gui -- take your pick. X11 is implied. athena/motif widgets are pretty much dead, so unless there's a QT version floating around, GTK2. editors/vim editors/vim-lite editors/gvim editors/gvim-lite ? Makes sense does it not ? -- jhell,v From m.seaman at infracaninophile.co.uk Sun Oct 3 22:29:03 2010 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun Oct 3 22:29:06 2010 Subject: databases/postgresql90-{client, server, contrib} not hooked up to ports Message-ID: <4CA9039A.3080407@infracaninophile.co.uk> Is there any reason why the 3 postgresql90 ports aren't mentioned in ${PORTSDIR}/databases/Makefile ? They seem to work perfectly well for installing postgresql-9.0.0 Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101003/583f919e/signature.pgp From girgen at FreeBSD.org Sun Oct 3 22:56:00 2010 From: girgen at FreeBSD.org (Palle Girgensohn) Date: Sun Oct 3 22:56:33 2010 Subject: databases/postgresql90-{client, server, contrib} not hooked up to ports In-Reply-To: <4CA9039A.3080407@infracaninophile.co.uk> References: <4CA9039A.3080407@infracaninophile.co.uk> Message-ID: <8A35D5B08AE8B3E0BDF5C1AE@girgBook.local> Nope, no reason, my mistake! Thanks, I will fix that. PAlle --On 3 oktober 2010 23.28.42 +0100 Matthew Seaman wrote: > > Is there any reason why the 3 postgresql90 ports aren't mentioned in > ${PORTSDIR}/databases/Makefile ? They seem to work perfectly well for > installing postgresql-9.0.0 > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matthew@infracaninophile.co.uk Kent, CT11 9PW > From dougb at FreeBSD.org Sun Oct 3 22:58:03 2010 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 3 22:58:06 2010 Subject: ident strings in pkg-plist In-Reply-To: <19625.2146.758021.796409@gossamer.timing.com> References: <19625.2146.758021.796409@gossamer.timing.com> Message-ID: <4CA90A78.5010806@FreeBSD.org> Changing the list to have a real discussion about this. On 10/3/2010 3:49 PM, John Hein wrote: > I'll mention that > it has come in handy for me in the past. I put it into the category > of ident strings in binaries. It has a similar utility. > > Because I find it useful in maintaining and using a port/package, > I've been one that has added it to pkg-plist in the past. I'm curious about what your use case for the information is. You can always know if you have the latest version of the plist via cvs, c[v]sup, portsnap, etc. Other than knowing that you have the latest version, what utility does the $Id string in the file itself have? Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From jhein at symmetricom.com Sun Oct 3 23:50:56 2010 From: jhein at symmetricom.com (John Hein) Date: Sun Oct 3 23:50:58 2010 Subject: ident strings in pkg-plist In-Reply-To: <4CA90A78.5010806@FreeBSD.org> References: <19625.2146.758021.796409@gossamer.timing.com> <4CA90A78.5010806@FreeBSD.org> Message-ID: <19625.5094.895017.729445@gossamer.timing.com> Doug Barton wrote at 15:58 -0700 on Oct 3, 2010: > Changing the list to have a real discussion about this. > > On 10/3/2010 3:49 PM, John Hein wrote: > > I'll mention that > > it has come in handy for me in the past. I put it into the category > > of ident strings in binaries. It has a similar utility. > > > > Because I find it useful in maintaining and using a port/package, > > I've been one that has added it to pkg-plist in the past. > > I'm curious about what your use case for the information is. You can > always know if you have the latest version of the plist via cvs, > c[v]sup, portsnap, etc. Other than knowing that you have the latest > version, what utility does the $Id string in the file itself have? Mostly convenience (one less level of indirection). For identifying sub-changes between PORTVERSION/PORTREVISION bumps. For keeping track of heritage when using a local mirror of FreeBSD ports, but slightly divergent, for local products. Mainstream FreeBSD users don't care about this one, but people who use FreeBSD and add value might. For instance, PC-BSD might fall into this category (not trying to put words in their mouth - just guessing). $work users might. Just one specific use case here - we have to maintain some older 4.x based products and have to have our own branch of the ports tree. For aberrant maintenance issues where I have had local screwups. These, of course, are _extremely_ rare personally ;) Anyway this is quite a weak entry on the use case list. Just like for ident strings in binaries where you can generally get close enough by knowing uname, you can (as you mention) generally get close enough to the plist source version from PORTVERSION/PORTREVISION and cvs, et. al. Removal doesn't bother me that much, but I found it useful on occasion over the years. From corky1951 at comcast.net Mon Oct 4 00:47:55 2010 From: corky1951 at comcast.net (Charlie Kester) Date: Mon Oct 4 00:47:57 2010 Subject: porting: Linux to Freebsd In-Reply-To: References: Message-ID: <20101004004751.GA74984@comcast.net> On Fri 01 Oct 2010 at 23:42:30 PDT Chetan Shukla wrote: >Hi, >Could someone please outline the steps needed in porting a general >application from Linux to FreeBSD. As others have already pointed out, there are no shortcuts to the righthand side of the learning curve. For most apps, the usual "configure; make; make install" works. It's when it doesn't that you need to be able to draw on the kind of experience that puts you on the righthand side of the curve. In some cases, you really do need to be able to debug and write some code yourself. Apps written in Python or Perl tend to port fairly easily, because the folks who have ported the languages and their main libraries have already done most of the hard work. C and C++ apps, on the other hand, are more likely to surface differences in the Linux and FreeBSD API's. If you're porting one of those, you need to be willing and able to dig in and research those APIs. For a good grounding in the UNIX API's, I'd recommend the Stevens/Rago book "Advanced Programming in the UNIX Environment". The Avoiding Linuxisms article also has a lot of useful information. The Porter's Handbook contains most of what you'll need to know once you've got the app built and running OK and you want to add it to the portstree. (I say "most" because you'll still need to have some profiency with BSD makefiles, and the Handbook doesn't teach you that.) From dereckson at gmail.com Mon Oct 4 01:11:47 2010 From: dereckson at gmail.com (Dereckson) Date: Mon Oct 4 01:11:49 2010 Subject: pokerTH In-Reply-To: <201009291623.11001.lumiwa@gmail.com> References: <201009291623.11001.lumiwa@gmail.com> Message-ID: Good evening, I contacted the port maintainer Thursday evening. All is fine, he already submitted an update the Tuesday. See http://www.freebsd.org/cgi/query-pr.cgi?pr=151020 -- S?bastien Santoro aka Dereckson http://www.dereckson.be/ ---------- Forwarded message ---------- From: Guido Falsi Date: Sun, Oct 3, 2010 at 11:11 PM Subject: Re: Fwd: pokerTH To: S?bastien Santoro On 09/30/10 04:52, S?bastien Santoro wrote: > > Good evening, > > There is a request on the FreeBSD ports mailing list from an user who > wish to know if you could update your port. Hi! Thank you for the information. I already answered this request I think. I filed a PR for this update: http://www.freebsd.org/cgi/query-pr.cgi?pr=151020 it should be committed in a few days. -- Guido Falsi From snasonov at bcc.ru Mon Oct 4 08:07:07 2010 From: snasonov at bcc.ru (Sergey G Nasonov) Date: Mon Oct 4 08:07:12 2010 Subject: FreeBSD Port: xf86-video-ati-6.13.0 update to 6.13.2? In-Reply-To: <4CA3E322.9050501@gmail.com> References: <4CA3E322.9050501@gmail.com> Message-ID: <201010041142.58737.snasonov@bcc.ru> On Thursday 30 September 2010 05:08:50 Jimmie James wrote: > >>>> Now i'm running with 6.13.2, but my graphical errors are the same. > >>>> I have a screenshot make of my errors. > >>> > >>> Please don't send image attachments to the mailing lists. Having said > >>> that, it looks bad. > >>> > >>> Comparing your xorg.conf to the sample at > >>> http://www.wonkity.com/~wblock/radeon/x1650/xorg.conf might reveal > >>> something useful. > >>> > >> Have compared it and some settings tested, but doesn't help. > > > Well, there are the standard tricks. Disable composite, maybe disable acceleration even though it should work. > > > > The card works in other operating systems, right? > > I also have the same issue, and updated this ati driver. > > pciconf: > ATI RADEON X300/X550/X1050 Series (RV370) > dmesg |grep vga: > vgapci0: port 0x9800-0x98ff mem > 0xd8000000-0xdfffffff,0xffa20000-0xffa2ffff irq 16 at device 0.0 on pci1 > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > vgapci1: mem 0xffa30000-0xffa3ffff at device > 0.1 on pci1 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > http://pastebin.com/pvgj9NLt xorg.conf (with ati commented out, using > vesa at the moment) > http://pastebin.com/ZpJgbLpi Xorg.log.0 > http://i.imgur.com/S1aCb.png screen and font corruption while using the > ATI driver, which happens at all resolutions and depths. > > The previous version of Xorg worked perfectly with this card/setup. and > there's no evidence using any liveCD with an ATI driver. > > P.S Sorry if I missed anyone on the C.C. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > At home I have PC with FBSD 8 Stable. Video card is ATI HD 5750. This card worked fine only with vesa driver. After release ATI driver 6.13.2 I tried this and get screen corruption. For me it was some progress because older version ati drivers (6.13.0. and 6.13.1) led to lockup at X start. These screen corruptions was resolved after mesa upgrade to version 7.8.2. Currently mesa version in ports is 7.4.4. So maybe there is benefit for upgrade mesa version in ports to latest. All whats need for upgrade mesa is just modify Makefiles. I am tested only this card (HD 5750) and dont know how latest mesa verison will work with another video cards. PS Sorry for my english. Thanks. -- Best Regards, Nasonov Sergey From bugmaster at FreeBSD.org Mon Oct 4 11:06:08 2010 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 4 11:06:30 2010 Subject: Current unassigned ports problem reports Message-ID: <201010041106.o94B67Jj065108@freefall.freebsd.org> (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/151197 [sysutils/monitorix] Fixed URL for fetch o ports/151196 [NEW PORT] games/inform7: Inform 7 programming languag o ports/151195 Update ports: japanese/yc.el o ports/151193 [MAINTAINER] deskutils/q4wine: update to 0.120 o ports/151192 [mail/horde-imp] Upgrade o ports/151191 [www/horde-base] Upgrade o ports/151190 wine needs prelink o ports/151188 Maintainer update: lang/s9fes o ports/151182 Port munin-node creates wrong newsyslog.conf entry f ports/151175 [PATCH] sysutils/xfce4-cpugraph-plugin to 1.0.0, chang f ports/151174 [UPDATE] sysutils/xfce4-cpugraph-plugin to 1.0.0 o ports/151172 [ports] graphics/mesa-demos marked as broken with WITH o ports/151171 Update port: print/latex-etoolbox update to 2.0a o ports/151165 php 5.3.3_2 has undocumented version dependence on pcr o ports/151163 [MAINTAINER] net-im/centerim-devel: Update to 4.22.9.3 o ports/151162 sysutils/gdisk needs to be updated to 0.6.11 o ports/151161 [PATCH] textproc/rst.el: update to 6390 o ports/151157 [PATCH] graphics/sane-backends: link with pthread o ports/151156 Update port: databases/ocaml-pgocaml f ports/151154 audio/amarok-kde4 crashes on network activity if ports f ports/151153 Update of cad/linux-eagle5 to the most recent version o ports/151140 USE_PERL5_BUILD in lang/gcc* ports fails to compile o ports/151126 deskutils/fet: Software update f ports/151118 net-mgmt/pnp: bump version to 0.6.7 o ports/151113 www/py-django-registration - fix breakage o ports/151110 mysqlbackup 2.4 incompatability with mysql Ver 14.14 D o ports/151087 sysutils/pcpustat: Update Makefile to be compatible wi o ports/151077 NEW port devel/gdb72 o ports/151062 New port: www/trac-OhlohWidgetsMacro Trac macro to emb o ports/151060 Update ports: japanese/yc.el o ports/151058 New port: devel/py-pycerberus Highly flexible, no magi o ports/151005 New port: www/peraperaprv, a pure java twitter client o ports/151001 Update port net/ipa_ip6fw to 1.0.2 version o ports/150974 www/cybercalendar : port fix / deprecate o ports/150973 [NEW PORT] games/inform7: Inform 7 programming languag o ports/150937 [REPOCOPY] www/typo3 --> www/typo343 o ports/150900 net-p2p/gift-fasttrack: deprecate umaintained gift-plu o ports/150896 [PATCH] Unbreak, restore editors/xml2rfc-xxe4.6.1 and o ports/150895 astro/stellarium and games/viruskiller [Segmentation f f ports/150883 Ports games/openastromenace won't compile on 64 bit o ports/150881 [patch] sysutils/backuppc: remove %%RC_SUBR%%, etc. o ports/150879 [NEW PORT] sysutils/downtimed: System downtime monitor o ports/150863 Update port: www/piwigo (former phpwebgallery) update o ports/150790 New port: mail/dovecot20-pigeonhole o ports/150789 New port: mail/dovecot20 f ports/150783 mail/qpopper: fails to configure ocasionally f ports/150770 [patch] devel/geany v0.19 o ports/150765 [Maintainer Update] Give sysutils/radmind its own UID/ f ports/150757 [patch] update astro/merkaartor to 0.16.3 o ports/150743 New port: graphics/commons-utilities o ports/150728 [PATCH] sysutils/duplicity-devel: update to 0.6.10 o ports/150698 [patch] graphics/mupdf: restore some vendor CFLAGS o ports/150683 New port: devel/dragon, Combined C++ scanner/parser ge o ports/150653 OGG/Vorbis playback with multimedia/mplayer is broken o ports/150608 Mk/bsd.license.mk Add OWL license o ports/150605 [PATCH] audio/liblastfm: Fix build with alternate LOCA o ports/150592 AX_BOOST_FILESYSTEM macro from devel/autoconf-archive o ports/150574 [PATCH] mail/dkimproxy: Simplify the rc scripts o ports/150563 bugfix for /usr/ports/lang/p5-JavaScript-SpiderMonkey f ports/150542 [new port] createrepo - creates rpm metadata for yum o ports/150541 [new port] sysutils/yum - Installer/updater for rpm o ports/150493 Update for: security/openssh-portable port from 5.2p1 o ports/150489 [NEW PORT] devel/d-feet: D-Feet is a D-Bus debugger wr o ports/150446 New port: lang/rexx-regutil o ports/150425 www/squid31: rc.d/squid's squid_fib setting ineffectiv f ports/150423 [PATCH] Upgrade www/p5-Mojo to devel/p5-Mojolicious (v f ports/150376 port net-mgmt/zabbix-server 1.8.3 fails to build on 8. o ports/150361 [patch] provide script to bind with nautilus for multi o ports/150333 x11/lxpanel: forced dependency with WITH_ALSA o ports/150316 new port: net/neatx f ports/150294 news/hellanzb fails to run due to string compare bug f ports/150283 security/l5 produces wrong output on amd64 o ports/150266 New port: x11/tabbed Simple generic tabbed fronted to f ports/150235 sysutils/smartmontools build system bug f ports/150233 conky 1.8 broken (sysutils/conky) o ports/150208 [new port] databases/jasperserver: Open Source Java Re f ports/150194 There is no startup script for databases/cassandra f ports/150169 www/havp: Assertion failed: file llvm/lib/System/Mutex f ports/150146 [PATCH] net/igmpproxy: fix rc script o ports/150145 [patch] ftp/smbftpd port rewrite configuration files o o ports/150086 [NEW PORT] net-im/tkabber-plugins-devel: External Plug f ports/150047 net/ipv6socket_scrub: Makefile contains incorrect URL f ports/149963 chinese/ibus-chewing: Refine FETCH_ARGS o ports/149947 [NEW PORT] devel/smartCVS, a powerful graphical CVS cl o ports/149928 New port: textproc/iText iText, a JAVA-PDF library by o ports/149892 [NEW PORT] textproc/weka-devel: Data Mining Software i o ports/149849 New Port : print/scribus-devel - Scribus is a desktop o ports/149817 ports-mgmt/portupgrade: portinstall -p option doesn't f ports/149816 devel/icu4: install forget to install the lib libicute o ports/149725 [patch] devel/cdk: Errors in examples of cdk_display(3 o ports/149682 New port:net/gogonet_c gogoCLIENT offers IPv6 connecti o ports/149674 [patch] sysutils/fusefs-kmod: ftruncate() sycall on FU f ports/149616 [PATCH] textproc/ibus: update to 1.3.7 o ports/149601 New port: games/gargoyle - a multiplatform interacti f ports/149565 Update port: converters/igbinary o ports/149564 patch for various games/ adding appropriate LICENSEs t f ports/149547 [PATCH] net/igmpproxy: prevent deletion of configfile f ports/149507 security/libprelude missing configure option o ports/149348 New port: net/wowzamediaserver o ports/149305 Small security fix and transcoding profile fix to net/ o ports/149196 [PATCH] chinese/zh-ibus-chewing: update to 1.3.6.20100 f ports/149127 [PATCH] net/beacon: allow compilation on non-i386 arch o ports/149069 new port: sysutils/hfsexplorer HFSExplorer read Mac-fo f ports/149020 sysutils/dvdisaster Inappropriate ioctl for device wit f ports/148919 graphics/mapnik not longer broken o misc/148871 bad packages: p5-XML-Parser-2.36_1 p5-XML-SAX-Expat-0. o ports/148605 security/ipsec-tools rc.d/racoon startup script fails f ports/148519 New port: devel/pear-PHP_Debug Port for the PEAR PHP_D f ports/148462 [New port] www/wordpress-themes: wordpress featured th f ports/148454 games/freebsd-carddeck-kde4: freebsd's kde card deck d o ports/148415 new port: devel/libsysinfo, GNU libc's sysinfo port fo o ports/148411 New port: audio/madfufw M-Audio DFU Firmware for USB s o ports/148398 [NEW PORT] net/omcmd: CLI utility for performing OMAPI f ports/148316 net/quagga 0.99.16 - OSPF broken o ports/148234 pkg_install fails for some math/octave-forge ports o ports/148090 [PATCH] security/ike: update to 2.1.5 o ports/147944 [NEW PORT] net/gogoc: GogoCLIENT, which is needed to c o ports/147943 New port: net/radsecproxy Radsecproxy is a generic RAD s ports/147829 Improved net/ucarp startup script: multiple VHID and F f ports/147669 science/gramps fails to start o ports/147660 new port: net-im/pidgin-mra, Mail.ru Agent protocol pl s ports/147457 Update port: devel/ptlib26 o ports/147242 ports-mgmt/portupgrade incorrectly remove old port whe o ports/146934 [NEW PORT] japanese/unzip NLS patched unzip. import fr o ports/146913 ports/databases/skytools failed to make package if Pos o ports/146895 [NEW PORT] emulators/linux-libusb -- linux(4)-friendly o ports/146880 [MAINTAINER] korean/ko.TeX : update to 0.2.0.20100511 o ports/146879 [MAINTAINER] korean/ko.TeX-fonts-extra : update to 0.2 o ports/146858 [patch] ports-mgmt/portupgrade-devel: respect LOCALBAS o ports/146830 multimedia/pvr_xxx does not compile on FreeBSD 8.* and o ports/146818 [update] games/openarena latest release f ports/146801 can't build graphics/py-opengl because math/py-numpy f o ports/146713 [patch] net-mgmt/argus-monitor update o ports/146641 [MAINTAINER] sysutils/gosa: update to 2.6.10 o ports/146392 [NEW PORT] devel/php5-thrift: PHP interface to Thrift f ports/145966 port devel/pwlib fails to build: cast error: patch att o ports/145704 [patch] Update-request: audio/xmms2-scrobbler o ports/145076 I could not build devel/pwlib o ports/144993 databases/postgresql-odbc: contents of numeric fields o ports/144857 [patch] audio/abraca: update to 0.4.3 o ports/144849 [new port] java/eclipse-eclemma code coverage for ecli o ports/144821 [patch] audio/xmms2 : update to version 0.7 DrNo. o ports/144769 [PATCH] ports-mgmt/portupgrade should have a configura o ports/144605 [PATCH] Get ports-mgmt/portupgrade to build under Ruby o ports/144597 security/openssh-portable fails to compile with KERBER o ports/144555 graphics/mesagl: glutMainLoop() crashes when using VBO o ports/144412 Update port: mail/tkrat2 (Use latest tcl/tk versions) o ports/144248 net/asterisk16 conflicts with linuxthreads o ports/143938 [NEW PORTS] textproc/linux-f10-ibus-qt et al.: Linux v o ports/143566 sysutils/diskcheckd runs constantly when using gmirror o ports/142824 [patch] security/openssh-portable: add VersionAddendum f ports/141103 net/stone strange behavior on 8.0-RELEASE o ports/141001 net/ssltunnel-server/ depends on /sbin/pppd o ports/140880 ports-mgmt/portupgrade: portversion confused with ezm3 f ports/140867 net-mgmt/nagios-plugins: check_icmp default packets si o ports/140364 ports-mgmt/portupgrade-devel: #! line substitution is s ports/140303 net-mgmt/docsis can not compile filters under amd64 pl o ports/140273 ports-mgmt/portupgrade-devel chokes on bsdpan pkgs o ports/140008 ports-mgmt/portupgrade: many papercut omissions on por o ports/139867 mail/isoqlog catch segmentation fault under AMD64 f ports/139203 sysutils/freebsd-snapshot more careful patch not depen o ports/138929 [PATCH] security/heimdal update to 1.2.1 o ports/138602 audio/sphinxbase port update o ports/137958 ports-mgmt/portupgrade fails with recursive dependency o ports/137708 ports-mgmt/portupgrade: portupgrade -cRn is broken o ports/137378 Advisory locks fail with ports/security/cfs on FreeBSD o ports/135691 ports-mgmt/portupgrade Wrong example in man page of pk o ports/134714 ports-mgmt/portupgrade deletes user data without quest o ports/134182 ports-mgmt/portupgrade incorrectly handles manual reje a ports/133773 net/keepalived port update request o ports/133723 net/asterisk16: asterisk-1.6.0.9 crash when load chan_ o ports/133563 security/cfs rc script needs "mntudp" option on 8-CURR o ports/131111 ports-mgmt/portupgrade-devel: completely removes packa o ports/129930 ports-mgmt/portupgrade - portinstall tries to install o ports/129891 ports-mgmt/portupgrade fails to recognize variations o o ports/128952 [NEW PORT] java/javadb: Sun's supported distribution o o ports/128881 ports-mgmt/portupgrade backtrace o ports/127889 ports-mgmt/portupgrade detects spurious failures and s o ports/127321 japanese/kon2-16dot: buffer overflow and mouse bugs s ports/127087 mail/bincimap port does not include an rc.d file o ports/127019 ports-mgmt/portupgrade does not recognize fail conditi o ports/126140 ports-mgmt/portupgrade runtime error o ports/125936 ports-mgmt/portupgrade -R fails if BUILD_DEP's are not s ports/125324 editors/the (3.2) looses cursor when compiled with PDC o ports/123068 sysutils/bubblemon2 bubblemon-dockapp: error extractin o ports/121259 New port: net/openamq OpenAMQ is a complete AMQP messa o ports/118716 security/heimhal - shared library conflict with heimda o ports/114611 [NEW PORT] net-p2p/freenet05: An anonymous censorship- o ports/112818 ports-mgmt/portupgrade -a fails with database error o ports/107816 [patch] The IPv6 patch breaks the location feature of o ports/82634 security/heimdal port conflict with base heimdal o ports/80111 patch to make WITH_KERBEROS4 working for security/cyru s ports/57498 HEIMDAL_HOME should be defined in src or ports Makefil 193 problems total. From Alexander at Leidinger.net Mon Oct 4 11:33:51 2010 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Oct 4 11:33:55 2010 Subject: ident strings in pkg-plist In-Reply-To: <4CA90A78.5010806@FreeBSD.org> References: <19625.2146.758021.796409@gossamer.timing.com> <4CA90A78.5010806@FreeBSD.org> Message-ID: <20101004131504.790553t2r4kpcpwk@webmail.leidinger.net> Quoting Doug Barton (from Sun, 03 Oct 2010 15:58:00 -0700): > Changing the list to have a real discussion about this. > > On 10/3/2010 3:49 PM, John Hein wrote: >> I'll mention that >> it has come in handy for me in the past. I put it into the category >> of ident strings in binaries. It has a similar utility. >> >> Because I find it useful in maintaining and using a port/package, >> I've been one that has added it to pkg-plist in the past. > > I'm curious about what your use case for the information is. You can > always know if you have the latest version of the plist via cvs, > c[v]sup, portsnap, etc. Other than knowing that you have the latest > version, what utility does the $Id string in the file itself have? I see a value in this if: - you use a port with non-default options which change the plist and - a change is made to the plist which affects your use case, but the revision of the port is not changed (because the change only affects the non-default options and as such do not change the default package) Normally you can not detect after a while if the plist in the port is what is used in /var/db/pkg or not (the dates in /var/db/pkg may change when portupgrade is used). If this matters and rectifies a new rule to include an ident string into the plist or not... personally I wouldn't object if it is added. Bye, Alexander. -- This is the sort of English up with which I will not put. -- Winston Churchill http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From frivoal at gmail.com Mon Oct 4 16:15:32 2010 From: frivoal at gmail.com (Florian Rivoal) Date: Mon Oct 4 16:15:36 2010 Subject: FreeBSD Port: xfce4-cpugraph-plugin-0.3.0_14 Message-ID: Hi, I just released a new version (1.0.0) of xfce4-cpugraph-plugin. Compared to the 0.3.0 you currently have, it fixes many bugs and introduces a fair amount of features, and the code has been significantly clean up. Unlike the previous 0.4.0, support for FreeBSD has been added back in 1.0.0. It is targeted at xfce4.6, rather than the upcoming 4.7/4.8, so there is no particular reason to wait before upgrading it. Also, I don't really plan to make more releases targeting 4.6, and the following ones will be focused on 4.7/4.8. I don't know when the next version of FreeBSD will ship, nor when xfce 4.7 will turn into 4.8, but if FreeBSD was to ship with xfce4.6, I'd strongly recommend using version 1.0.0 of cpugraph instead of the 0.3.0 that you currently have. tarball: http://archive.xfce.org/src/panel-plugins/xfce4-cpugraph-plugin/1.0/ homepage: http://goodies.xfce.org/projects/panel-plugins/xfce4-cpugraph-plugin If FreeBSD or FreeBSD users have any issue with xfce4-cpugraph-plugin, please report them in xfce's bug tracker. This project was unmaintained for a while, but I now took over, and I'll try to be responsive. Best regards, Florian From fbsd at opal.com Mon Oct 4 17:29:06 2010 From: fbsd at opal.com (J.R. Oldroyd) Date: Mon Oct 4 17:29:38 2010 Subject: FreeBSD Port: xfce4-cpugraph-plugin-0.3.0_14 In-Reply-To: References: Message-ID: <20101004125758.01203660@shibato.opal.com> On Tue, 05 Oct 2010 00:49:29 +0900, "Florian Rivoal" wrote: > > Hi, > > I just released a new version (1.0.0) of xfce4-cpugraph-plugin. Compared > to the 0.3.0 you currently have, it fixes many bugs and introduces a fair > amount of features, and the code has been significantly clean up. > > Best regards, > > Florian Portupdate already in progress. See PR ports/151175. -jr From dougb at FreeBSD.org Mon Oct 4 18:57:12 2010 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 4 18:57:15 2010 Subject: ident strings in pkg-plist In-Reply-To: <20101004131504.790553t2r4kpcpwk@webmail.leidinger.net> References: <19625.2146.758021.796409@gossamer.timing.com> <4CA90A78.5010806@FreeBSD.org> <20101004131504.790553t2r4kpcpwk@webmail.leidinger.net> Message-ID: <4CAA2388.2050308@FreeBSD.org> On 10/4/2010 4:15 AM, Alexander Leidinger wrote: > Quoting Doug Barton (from Sun, 03 Oct 2010 15:58:00 > -0700): > >> Changing the list to have a real discussion about this. >> >> On 10/3/2010 3:49 PM, John Hein wrote: >>> I'll mention that >>> it has come in handy for me in the past. I put it into the category >>> of ident strings in binaries. It has a similar utility. >>> >>> Because I find it useful in maintaining and using a port/package, >>> I've been one that has added it to pkg-plist in the past. >> >> I'm curious about what your use case for the information is. You can >> always know if you have the latest version of the plist via cvs, >> c[v]sup, portsnap, etc. Other than knowing that you have the latest >> version, what utility does the $Id string in the file itself have? > > I see a value in this if: > - you use a port with non-default options which change the plist > and > - a change is made to the plist which affects your use case, > but the revision of the port is not changed (because the change > only affects the non-default options and as such do not change > the default package) > > Normally you can not detect after a while if the plist in the port is > what is used in /var/db/pkg or not (the dates in /var/db/pkg may change > when portupgrade is used). > > If this matters and rectifies a new rule to include an ident string into > the plist or not... personally I wouldn't object if it is added. I think I understand what you're describing here, and if so you could probably count the number of people it would apply to on one hand. :) I'm not sure justifies adding it to all ports. In fact, my vote would be to remove it from all ports where it exists currently, but I really don't want to push that rock up hill. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From jumper99 at gmx.de Mon Oct 4 19:00:07 2010 From: jumper99 at gmx.de (Helmut Schneider) Date: Mon Oct 4 19:00:41 2010 Subject: How long does a repocopy take? Message-ID: Hi, sorry for my impatience but I asked for a repocopy about one week ago and now I'm wondering how long normally a repocopy takes. http://www.freebsd.org/cgi/query-pr.cgi?pr=150937 Thanks, Helmut -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn From ml at netfence.it Mon Oct 4 20:01:05 2010 From: ml at netfence.it (Andrea Venturoli) Date: Mon Oct 4 20:01:08 2010 Subject: Upgrading Samba In-Reply-To: <20100922225856.0891aee7@raksha.tavi.co.uk> References: <4C9A6F48.6000107@netfence.it> <20100922225856.0891aee7@raksha.tavi.co.uk> Message-ID: <4CAA325A.6060506@netfence.it> On 09/22/10 23:58, Bob Eager wrote: Thanks for your answer. > My logbook says that it wanted to use /var/run/samba34 (a directory) > instead of the previous default. That was easy. In fact, yes, I too had to copy some files around, but that was more than easy. > Probably wasn't necessary, but I moved smbusers > to /usr/local/etc/samba34, and updated smb.conf. I did the same with smbpasswd. > Also that smbd wouldn't start because it needed the avahi-app package > (and dependencies) but this presumably wasn't listed as a dependency > because I had to install it by hand. No need for that in my case, but I didn't choose avahi in "make config". > I had to re-add the user rights for some reason - YMMV - this may be > the use of different directories for 3.4. Not sure what you mean. In any case, I had samba34 working in a little more than a few minutes, with users still accessing shares, XP machines still doing domain logons and the new W7 box integrated at first try. So far so good, it seemed, but it was not so. First, I noticed profiles could not be copied back on the server at logoff: a quick search pointed to full_audit being buggy and in fact removing it turned out to be the correct workaround. What I find strange is that it is deamed as not working in 3.4.7, but corrected in 3.4.8; this is evidently not true. Later I upgraded to 3.4.9, but had no time to test it again. I will ASAP and eventually report on the Samba newsgroup. The second problem is harder: pam_smb stopped working, so I had domain logons and file sharing ok, but any other service rejecting users. I could not come to any solution to this; I even tried pam_smbpass and setting up winbindd, but to no avail. Time was not on my side, so I ended up putting every password into the UNIX database and forget about PAM for the moment. However I'll have to fix this soon, so I'm in search of any hint on how to debug this. I tried putting "debug" next to pam_smb_auth.so in /etc/pam.d/*, but this didn't help much. Using Postgres (as an example) I get in my logs: xxxxxx pamsmbd[93053]: cache_check: no entry xxxxxx pamsmbd[93053]: server: remote auth user unix:yyyyy nt:yyyyy NTDOM:ZZZZZZ PDC:XXXXXX BDC:XXXXXX xxxxxx postgres[16385]: pamsmbd: Got something back... 3 xxxxxx pamsmbd[93053]: cache_check: no entry xxxxxx pamsmbd[93053]: server: remote auth user unix:yyyyy nt:yyyyy NTDOM:ZZZZZZ PDC:XXXXXX BDC:XXXXXX xxxxxx postgres[16387]: pamsmbd: Got something back... 3 but then: psql: FATAL: PAM authentication failed for user "yyyyy" FATAL: PAM authentication failed for user "yyyyy" In the meantime, I get absolutely nothing in /var/log/samba34/log.smbd. Any hint? bye & Thanks av. From martymac at FreeBSD.org Tue Oct 5 06:21:56 2010 From: martymac at FreeBSD.org (Ganael LAPLANCHE) Date: Tue Oct 5 06:22:36 2010 Subject: FreeBSD mencoder port problem In-Reply-To: <20101002182128.7d3a96e9@Picasso.Zahemszky.HU> References: <20101002182128.7d3a96e9@Picasso.Zahemszky.HU> Message-ID: <20101005055958.M59376@martymac.org> On Sat, 2 Oct 2010 18:21:28 +0200, Zahemszky G?bor wrote Hi, > I've just found that libmpcdec has been deprecated in FreeBSD > port. Because of it, there was an mplayer modification. The > only problem is that mencoder has the same libmpcdec > dependency, so it should be updated, too. Yes, you're right ! mencoder had missed libmpcdec removal. This is fixed now. Thanks for your report ! Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From makc at issp.ac.ru Tue Oct 5 07:39:17 2010 From: makc at issp.ac.ru (Max Brazhnikov) Date: Tue Oct 5 07:39:21 2010 Subject: How long does a repocopy take? In-Reply-To: References: Message-ID: <201010051139.15066.makc@issp.ac.ru> On Mon, 4 Oct 2010 18:57:35 +0000 (UTC), Helmut Schneider wrote: > Hi, > > sorry for my impatience but I asked for a repocopy about one week ago > and now I'm wondering how long normally a repocopy takes. Submit patch vs existing port ask for repocopy. Commiter will request repocopy from portmgr@ From mickael.maillot at gmail.com Tue Oct 5 11:05:05 2010 From: mickael.maillot at gmail.com (=?ISO-8859-1?Q?Micka=EBl_Maillot?=) Date: Tue Oct 5 11:05:09 2010 Subject: XBMC port Message-ID: hi, you can test my pre version of xbmc port some infos: - i host xbmc files because i can't find a recent tar.gz - internal video player crash on my intel graphic, you can use mplayer as external video player ex: http://fneufn.eu/freebsd/xbmc/playercorefactory.xml in ~/.xbmc/userdata/ - vdpau works fine - skin aeon65 crash xbmc - only python 2.4, 2.5 and 2.6 are supported - with pulse, i can choose /dev/dsp audio output - good luck with custom alsa output (ex: alsa:surround51 works) - if you want correct utf8, start xbmc with: LANG=fr_FR.UTF-8 /usr/local/bin/xbmc/xbmc.sh - xbmc.bin need XBMC_BIN_HOME and XBMC_HOME defined to start defaults are (already added in xbmc.sh): XBMC_BIN_HOME=/usr/local/lib/xbmc XBMC_HOME=/usr/local/share/xbmc - timezone doesn't work - plist without: faac, hal, nonfree or avahi option can be wrong The port can be downloaded from: http://fneufn.eu/freebsd/xbmc/xbmc.shar From rodrigo at bebik.net Tue Oct 5 11:27:59 2010 From: rodrigo at bebik.net (Rodrigo OSORIO (ros)) Date: Tue Oct 5 11:28:03 2010 Subject: Apache20 in amd64 Message-ID: <20101005111228.GH4550@hodja.bebik.net> Hi, I found a compiler error building www/apache20 in the amd64 arch. The error is located in the mod_ssl code where the 'STACK' structure seems to be unknown. 'STACK' is a basic data type defined in the native ssl api and the problem seems to be related to the struct visibility. Maybe a DEFINE problem . The error message says : ssl_engine_init.c: In function 'ssl_init_ctx_verify': ssl_engine_init.c:534: error: 'STACK' undeclared (first use in this function) The most crappy workaround was to add the following line into the work/httpd-2.0.63/modules/ssl/mod_ssl.h file. typedef struct stack_st STACK; Before going deeper in my investigations I want to know if someone faces the same problems with this port. Regards Rodrigo From chetan.shukla at aricent.com Tue Oct 5 11:32:16 2010 From: chetan.shukla at aricent.com (Chetan Shukla) Date: Tue Oct 5 11:32:19 2010 Subject: Issues in installing Gmake and Gcc on FreeBSD Message-ID: Hi, I am trying to install GCC and Gmake on FreeBSd machine and faced following issues: GCC: Steps: 1)At directory gcc-3.3.2 I ran ./configure -enable-obsolete 2)error returned: Please update *-*-freebsd* in gcc/config.gcc Configure in /usr/home/iptk/gcc-3.3.2/gcc failed, exiting. 3)I have included this string in gcc/config.gcc with architecture string as i386 but still facing same issue. The configuration and version details: Machine arch:i386 FreeBSD version: FreeBSD 8.0-RELEASE #0: GCC version :gcc-3.3.2 Gmake: Steps: 1)I have un tarred the gmake-3.79.1.tgz but it did not create any gmake-3.79.1 directory. 2)Hence I am unable to run ./configure and make and make install. The hardware details remain same. The system is not connected to Internet so I cannot use pkg-add. To give backdrop all this is needed to port linux code to FreeBSD. Please let me know your inputs on the above, Also please excuse me if it is wrong mailing list and please redirect it to the correct one. Thanks & Regards, Chetan ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." From freebsd at jdc.parodius.com Tue Oct 5 11:43:27 2010 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Tue Oct 5 11:43:31 2010 Subject: Issues in installing Gmake and Gcc on FreeBSD In-Reply-To: References: Message-ID: <20101005114326.GA31432@icarus.home.lan> On Tue, Oct 05, 2010 at 05:02:08PM +0530, Chetan Shukla wrote: > I am trying to install GCC and Gmake on FreeBSd machine and faced following issues: > GCC: > > Steps: > 1)At directory gcc-3.3.2 I ran ./configure -enable-obsolete > 2)error returned: > Please update *-*-freebsd* in gcc/config.gcc > Configure in /usr/home/iptk/gcc-3.3.2/gcc failed, exiting. > > 3)I have included this string in gcc/config.gcc with architecture string as i386 but still facing same issue. > > The configuration and version details: > Machine arch:i386 > FreeBSD version: FreeBSD 8.0-RELEASE #0: > GCC version :gcc-3.3.2 > > Gmake: > > Steps: > 1)I have un tarred the gmake-3.79.1.tgz but it did not create any gmake-3.79.1 directory. > 2)Hence I am unable to run ./configure and make and make install. > > The hardware details remain same. > The system is not connected to Internet so I cannot use pkg-add. > > To give backdrop all this is needed to port linux code to FreeBSD. > > Please let me know your inputs on the above, > Also please excuse me if it is wrong mailing list and please redirect it > to the correct one. GCC on FreeBSD is "special" in the sense that you should either use the version that's included in the base system (4.2.1 as of 8.0-RELEASE), or if you need an older/different version, install it from ports/packages. The same goes for gmake. You managed to get the source code to both gcc and gmake on a system which isn't connected to the Internet, so surely you could download the binary versions of the FreeBSD packages and install those...? Take a peek in: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/ Look for gcc* and gmake*. These are probably what you want: -rw-r--r-- 1 110 1002 351139 Oct 20 2009 gmake-3.81_3.tbz -rw-r--r-- 1 110 1002 14269507 Oct 20 2009 gcc-3.4.6_3,1.tbz If you download these packages, you can get them onto the machine however possible and simply pkg_add the files (literally: "pkg_add xxx.tbz"). You might have to download some dependency packages, but pkg_add should tell you what those are if needed. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From chetan.shukla at aricent.com Tue Oct 5 12:06:45 2010 From: chetan.shukla at aricent.com (Chetan Shukla) Date: Tue Oct 5 12:06:49 2010 Subject: Issues in installing Gmake and Gcc on FreeBSD In-Reply-To: <20101005114326.GA31432@icarus.home.lan> References: <20101005114326.GA31432@icarus.home.lan> Message-ID: Thanks Jeremy, Started work on ur guidance :) Regards, Chetan -----Original Message----- From: Jeremy Chadwick [mailto:freebsd@jdc.parodius.com] Sent: Tuesday, October 05, 2010 5:13 PM To: Chetan Shukla Cc: freebsd-ports@freebsd.org Subject: Re: Issues in installing Gmake and Gcc on FreeBSD On Tue, Oct 05, 2010 at 05:02:08PM +0530, Chetan Shukla wrote: > I am trying to install GCC and Gmake on FreeBSd machine and faced following issues: > GCC: > > Steps: > 1)At directory gcc-3.3.2 I ran ./configure -enable-obsolete > 2)error returned: > Please update *-*-freebsd* in gcc/config.gcc > Configure in /usr/home/iptk/gcc-3.3.2/gcc failed, exiting. > > 3)I have included this string in gcc/config.gcc with architecture string as i386 but still facing same issue. > > The configuration and version details: > Machine arch:i386 > FreeBSD version: FreeBSD 8.0-RELEASE #0: > GCC version :gcc-3.3.2 > > Gmake: > > Steps: > 1)I have un tarred the gmake-3.79.1.tgz but it did not create any gmake-3.79.1 directory. > 2)Hence I am unable to run ./configure and make and make install. > > The hardware details remain same. > The system is not connected to Internet so I cannot use pkg-add. > > To give backdrop all this is needed to port linux code to FreeBSD. > > Please let me know your inputs on the above, > Also please excuse me if it is wrong mailing list and please redirect it > to the correct one. GCC on FreeBSD is "special" in the sense that you should either use the version that's included in the base system (4.2.1 as of 8.0-RELEASE), or if you need an older/different version, install it from ports/packages. The same goes for gmake. You managed to get the source code to both gcc and gmake on a system which isn't connected to the Internet, so surely you could download the binary versions of the FreeBSD packages and install those...? Take a peek in: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/ Look for gcc* and gmake*. These are probably what you want: -rw-r--r-- 1 110 1002 351139 Oct 20 2009 gmake-3.81_3.tbz -rw-r--r-- 1 110 1002 14269507 Oct 20 2009 gcc-3.4.6_3,1.tbz If you download these packages, you can get them onto the machine however possible and simply pkg_add the files (literally: "pkg_add xxx.tbz"). You might have to download some dependency packages, but pkg_add should tell you what those are if needed. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." From decke at FreeBSD.org Tue Oct 5 13:21:47 2010 From: decke at FreeBSD.org (Bernhard Froehlich) Date: Tue Oct 5 13:21:50 2010 Subject: XBMC port In-Reply-To: References: Message-ID: On Tue, 5 Oct 2010 12:37:19 +0200, Micka?l Maillot wrote: > hi, > > you can test my pre version of xbmc port > > some infos: > - i host xbmc files because i can't find a recent tar.gz > - internal video player crash on my intel graphic, you can use mplayer > as external video player > ex: http://fneufn.eu/freebsd/xbmc/playercorefactory.xml in ~/.xbmc/userdata/ > - vdpau works fine > - skin aeon65 crash xbmc > - only python 2.4, 2.5 and 2.6 are supported > - with pulse, i can choose /dev/dsp audio output > - good luck with custom alsa output (ex: alsa:surround51 works) > - if you want correct utf8, start xbmc with: > LANG=fr_FR.UTF-8 /usr/local/bin/xbmc/xbmc.sh > - xbmc.bin need XBMC_BIN_HOME and XBMC_HOME defined to start > defaults are (already added in xbmc.sh): > XBMC_BIN_HOME=/usr/local/lib/xbmc > XBMC_HOME=/usr/local/share/xbmc > - timezone doesn't work > - plist without: faac, hal, nonfree or avahi option can be wrong > > > The port can be downloaded from: > http://fneufn.eu/freebsd/xbmc/xbmc.shar Thank you very much for your work! Port and patches look already quite good so I will give it some testing over the next few days in Karlsruhe. Have you already compiled it on amd64 and i386? -- Bernhard Froehlich http://www.bluelife.at/ From jhell at DataIX.net Tue Oct 5 14:47:07 2010 From: jhell at DataIX.net (jhell) Date: Tue Oct 5 14:47:11 2010 Subject: devel/p4d/Makefile Message-ID: <4CAB3A64.4080709@DataIX.net> Hi Gordon, I have just upgraded my p4d install and have found the following inconsistency in the Makefile: ${CAT} pkg-message pkg-message at this point cannot be found and it would be better if this referred to the ports directory and the portname /pkg-message instead. I might also suggest that instead of using touch(1) chown(1) chmod(1) to create entries in the filesystem for the p4d.log that you use install(1) instead as that allows you to achieve all three steps listed above in one command like so. install -S -o p4admin -g p4admin -m 640 /dev/null /var/log/p4d.log And of course this might need/involve some checking to see if the users log file already exists as we would not want to overwrite that by the above command but nor do we want to blindly chmod(1) the file either which is also done in the Makefile already. Regards, -- jhell,v From obrien at freebsd.org Tue Oct 5 18:15:23 2010 From: obrien at freebsd.org (David O'Brien) Date: Tue Oct 5 18:15:27 2010 Subject: editors/vim installs to / In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100917205404.GA66620@atarininja.org> <20100917232437.GC67059@atarininja.org> <20101002060201.GA8287@dragon.NUXI.org> Message-ID: <20101005181522.GD7829@dragon.NUXI.org> On Sat, Oct 02, 2010 at 04:38:34AM -0700, Rob Farmer wrote: > On Fri, Oct 1, 2010 at 23:02, David O'Brien wrote: > > For gtk1, I have 13 packages that require it.  For gtk2, I have 49 > > packages that require it.  So I agree their are significantly more ports > > that depend on gtk2 -- and thus little way to avoid having it installed > > on one's system. > > > > Thoughts? > > In my experience, unless you choose one of the minimalist window > managers and are very selective about what you install, GTK 2 might as > well be part of X. Ok, I've gone ahead and changed the default GUI to gtk2. > I personally like Ade's suggestion, since it makes a gui opt-in for an > application that functions perfectly well without one. This may be a good approach to take -- but I didn't see a need to not change the default GUI for now. -- -- David (obrien@FreeBSD.org) From obrien at freebsd.org Tue Oct 5 18:24:08 2010 From: obrien at freebsd.org (David O'Brien) Date: Tue Oct 5 18:24:11 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> Message-ID: <20101005182407.GE7829@dragon.NUXI.org> On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote: > 2010/10/2 David O'Brien : > > 2. With the way OPTIONS handling is done, there isn't a way for me > > to query if I built with the defaults or not. > > Thus leading to every port I manually install looking like it was > > customized just because /var/db/ports/${PORTNAME} exists.  Thus > > implying I can no longer install the pre-build package. > > make rmconfig ? I think you've missed my point. That does not tell me if I, in the past, made a decision that did not like the maintainer's defaults, or if I just wanted to extract the sources so I could read the license or figure out what the OPTIONS knobs were about, etc.. > The best thing to do is switch totally to a way to configure a port > and remove the other one. Only if folks agree on what the best way to configure a port is. I spoke with some co-workers last week, and OPTIONS weren't very popular with them. They also stated some of the the issues I listed. > I think we should try to upgrade the options > framework with what I said at 4. and 3. It's possible but we need some > work. Even without forcing all ports to go in one direction for configuration, this would be a Good Thing to do. Hopefully someone with interest will submit some patches. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From obrien at freebsd.org Tue Oct 5 18:34:54 2010 From: obrien at freebsd.org (David O'Brien) Date: Tue Oct 5 18:34:57 2010 Subject: OPTIONS In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> Message-ID: <20101005183452.GF7829@dragon.NUXI.org> On Sun, Oct 03, 2010 at 11:45:01AM +0200, David DEMELIER wrote: > 2010/10/3 Matthew Seaman : > > On 03/10/2010 09:22:46, David DEMELIER wrote: > >> I agree. As I said in 4, OPTIONS should follow the defined knob in > >> make.conf. But for not boolean knobs there is something we can also > >> do, spawn a little textbox to define an option with a string. > >> [X] WITH_X foo bar > >> [ ] WITH_Y foo bar baz > >> [fr_FR en_GB] LANGS to be build > >> > >> Here pressing enter on LANGS would spawn a little textbox that can be > >> fulfilled by the user. The little problem is how to tell to OPTIONS > >> that it's not a boolean entry. > > > > And the rest?  Pursuing this idea through to its logical conclusion, > > you'ld end up implementing radio buttons, text entry boxes, drop down > > lists -- all the normal bits used in html forms. > > Don't you like this? sysinstall was made with dialog. And folks hate that. jkh wanted to move the TurboC text-GUI library, but we never did. Accelerators are one of the things that dialog seems to not handle very well. In fact our OPTIONS suggest they are supported, but hitting "N" when building ports/misc/mc-light does not deselect NLS. > > In fact, you might just as well write a small HTML form, display it > > using lynx or w3c or some other text mode browser[*], and then have the > > form action feed into a CGI program that outputs a small Makefile with > > appropriate variable definitions in it. I like this statement -- as it shows just how complex this will get when taken to its natural conclusion. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From swell.k at gmail.com Tue Oct 5 18:44:49 2010 From: swell.k at gmail.com (Anonymous) Date: Tue Oct 5 18:44:51 2010 Subject: OPTIONS In-Reply-To: (David DEMELIER's message of "Sun, 3 Oct 2010 10:22:46 +0200") References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> Message-ID: <864od08oqg.fsf@gmail.com> David DEMELIER writes: > 2010/10/2 David O'Brien : >> 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in >> /etc/make.conf, why does the OPTIONS dialog offer me >> "[X] NLS Enable gettext support" instead of defaulting the >> dialog to unchecked? >> > > I agree with this inconsistency, I think with a little of work OPTIONS > framework should be to follow KNOB to enable an option if it's already > defined by the user. This would be great for people that use > WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it. I think Chris solved this one in the thread http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200 From jake at avenue22.net Tue Oct 5 21:05:26 2010 From: jake at avenue22.net (Jake Smith) Date: Tue Oct 5 21:05:29 2010 Subject: FreeBSD Port: ossec-hids-server-2.4.1 Message-ID: <4CAB8EF4.1020807@avenue22.net> Hi, When can we expect security/ossec-hids-* port to be updated from v2.4.1 to v2.5 released 2010-09-28. Many thanks! Regards Jake From nox at jelal.kn-bremen.de Tue Oct 5 21:49:55 2010 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue Oct 5 21:49:59 2010 Subject: XBMC port In-Reply-To: Message-ID: <201010052129.o95LTvtV095032@triton8.kn-bremen.de> In article you write: >hi, Hi! > >you can test my pre version of xbmc port > >some infos: >- i host xbmc files because i can't find a recent tar.gz Is this the head branch (trunk)? I'm not sure but its possible the pvr-testing2 branch is more popular, http://xbmc.svn.sourceforge.net/viewvc/xbmc/branches/pvr-testing2/ because it adds pvr (live tv, dvb...) support so you can use xbmc with e.g. mythtv(?) or vdr (actually I was looking forward to test it with my preliminary vdr ports, http://people.freebsd.org/~nox/dvb/ because for example xbmc is supposed to be faster at switching channels - only to discover you ported the `wrong' branch. :) >- internal video player crash on my intel graphic, you can use mplayer >as external video player >ex: http://fneufn.eu/freebsd/xbmc/playercorefactory.xml in ~/.xbmc/userdata/ >- vdpau works fine >- skin aeon65 crash xbmc >- only python 2.4, 2.5 and 2.6 are supported >- with pulse, i can choose /dev/dsp audio output >- good luck with custom alsa output (ex: alsa:surround51 works) >- if you want correct utf8, start xbmc with: >LANG=fr_FR.UTF-8 /usr/local/bin/xbmc/xbmc.sh >- xbmc.bin need XBMC_BIN_HOME and XBMC_HOME defined to start >defaults are (already added in xbmc.sh): >XBMC_BIN_HOME=/usr/local/lib/xbmc >XBMC_HOME=/usr/local/share/xbmc >- timezone doesn't work >- plist without: faac, hal, nonfree or avahi option can be wrong Anyway, I use RV730 PRO [Radeon HD 4650] graphics on a PhenomII box here and got playback working (including 1080i dvb-s2 h264 recordings from vdr), but first I had to disable tvout in xorg.conf (Option "ATOMTvOut") because with it xbmc kept turning off my lcd even after I told it to keep it on, and I found no option to ignore tvout or select the lcd as main display. Thanx, :) Juergen From pgollucci at p6m7g8.com Wed Oct 6 02:06:02 2010 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Wed Oct 6 02:06:06 2010 Subject: Apache20 in amd64 In-Reply-To: <20101005111228.GH4550@hodja.bebik.net> References: <20101005111228.GH4550@hodja.bebik.net> Message-ID: <4CABD983.2010606@p6m7g8.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/10 11:12, Rodrigo OSORIO (ros) wrote: > Hi, > > I found a compiler error building www/apache20 in the > amd64 arch. The error is located in the mod_ssl code where > the 'STACK' structure seems to be unknown. > 'STACK' is a basic data type defined in the native ssl api > and the problem seems to be related to the struct visibility. > Maybe a DEFINE problem . > > The error message says : > > ssl_engine_init.c: In function > 'ssl_init_ctx_verify': > ssl_engine_init.c:534: error: 'STACK' > undeclared (first use in this function) > > The most crappy workaround was to add the following line > into the work/httpd-2.0.63/modules/ssl/mod_ssl.h file. > > typedef struct stack_st STACK; > No, you have a conflict with the security/openssl port and your /etc/make.conf settings. - -- - ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFMq9mDdbiP+9ubjBwRAhPoAJ9B41gETAj2RRN3OUheneplJVgRXACfVaVR t7LpF9bJHz3nVgFwQKUw3CM= =OGkw -----END PGP SIGNATURE----- From jhell at DataIX.net Wed Oct 6 03:46:24 2010 From: jhell at DataIX.net (jhell) Date: Wed Oct 6 03:46:28 2010 Subject: ftp/ncftp3 stale patch no recorded checksums Message-ID: <4CABF10A.9070700@DataIX.net> After the recent update of ftp/ncftp3 there seems to be a stale v6 patch file left hanging around that no longer applies to the 3.2.4 source code for ncftp3. The following patch comments out the section in question but it also seems as there is "no native support for v6 in ncftp3 ?" at this time. Does anyone know of a v6 patch for the new (3.2.4) source ? Regards, -- jhell,v -------------- next part -------------- --- Makefile.orig 2010-10-05 23:26:16.738633363 -0400 +++ Makefile 2010-10-05 23:25:14.727629085 -0400 @@ -14,11 +14,11 @@ ftp://ftp.mirrorservice.org/sites/ftp.ncftp.com/ncftp/ DISTNAME= ncftp-${PORTVERSION}-src -.if !defined(WITHOUT_NCFTP_IPV6) && !defined(WITHOUT_IPV6) -PATCH_SITES= ftp://ftp.kame.net/pub/kame/misc/ -PATCHFILES= ncftp-323-v6-20091109.diff.gz -PATCH_DIST_STRIP= -p1 -.endif +#.if !defined(WITHOUT_NCFTP_IPV6) && !defined(WITHOUT_IPV6) +#PATCH_SITES= ftp://ftp.kame.net/pub/kame/misc/ +#PATCHFILES= ncftp-323-v6-20091109.diff.gz +#PATCH_DIST_STRIP= -p1 +#.endif MAINTAINER= obrien@FreeBSD.org COMMENT= ftp replacement with advanced user interface From obrien at FreeBSD.org Wed Oct 6 06:17:43 2010 From: obrien at FreeBSD.org (David O'Brien) Date: Wed Oct 6 06:17:47 2010 Subject: OPTIONS In-Reply-To: <864od08oqg.fsf@gmail.com> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <864od08oqg.fsf@gmail.com> Message-ID: <20101006053807.GD41180@dragon.NUXI.org> On Tue, Oct 05, 2010 at 10:43:19PM +0400, Anonymous wrote: > David DEMELIER writes: > > I agree with this inconsistency, I think with a little of work OPTIONS > > framework should be to follow KNOB to enable an option if it's already > > defined by the user. This would be great for people that use > > WITHOUT_GNOME, WITHOUT_X11 and so on. I think it's possible to do it. > > I think Chris solved this one in the thread > http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200 Unless this was also submitted as a PR -- I doubt it will ever get in. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From obrien at freebsd.org Wed Oct 6 08:40:42 2010 From: obrien at freebsd.org (David O'Brien) Date: Wed Oct 6 08:40:45 2010 Subject: OPTIONS In-Reply-To: <20101005183452.GF7829@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <20101005183452.GF7829@dragon.NUXI.org> Message-ID: <20101006084040.GA53569@dragon.NUXI.org> On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: > > 2010/10/3 Matthew Seaman : > > > In fact, you might just as well write a small HTML form, display it > > > using lynx or w3c or some other text mode browser[*], and then have the > > > form action feed into a CGI program that outputs a small Makefile with > > > appropriate variable definitions in it. > > I like this statement -- as it shows just how complex this will get when > taken to its natural conclusion. This is also how ridiculous things can get: curl 7.21.1 now offers me: [X] WERROR Treat compilation warnings as errors Can the port maintainer really not decide if that should just be turned off or turned on for FreeBSD?!? Do *I* really need to think about this one? But of course it doesn't offer me turning on NOPORTDOCS or NOPORTEXAMPLES, which would be useful. [I don't think any ports do...] cscope 15.7a offers me: [ ] XCSCOPE Install (X)Emacs package Do we really need to be bothered with OPTIONS to avoid installing an 87K .el file?!? -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From andrew.w.nosenko at gmail.com Wed Oct 6 09:33:35 2010 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Wed Oct 6 09:33:37 2010 Subject: OPTIONS In-Reply-To: <20101006084040.GA53569@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <20101005183452.GF7829@dragon.NUXI.org> <20101006084040.GA53569@dragon.NUXI.org> Message-ID: On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote: > On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: >> > 2010/10/3 Matthew Seaman : >> > > In fact, you might just as well write a small HTML form, display it >> > > using lynx or w3c or some other text mode browser[*], and then have the >> > > form action feed into a CGI program that outputs a small Makefile with >> > > appropriate variable definitions in it. >> >> I like this statement -- as it shows just how complex this will get when >> taken to its natural conclusion. > > This is also how ridiculous things can get: > > curl 7.21.1 now offers me: > ? ?[X] WERROR ? ? ? Treat compilation warnings as errors > > ? ?Can the port maintainer really not decide if that should just be > ? ?turned off or turned on for FreeBSD?!? I wonder why -Werror even ever considered to be turned "on" at all. > > ? ?Do *I* really need to think about this one? > > ? ?But of course it doesn't offer me turning on NOPORTDOCS or > ? ?NOPORTEXAMPLES, which would be useful. > ? ?[I don't think any ports do...] > > > cscope 15.7a offers me: > ? ?[ ] XCSCOPE ?Install (X)Emacs package > > ? ?Do we really need to be bothered with OPTIONS to avoid installing an > ? ?87K .el file?!? Yes. I'm, as everyday cscope and emacs user, would be very frustrated if xcscope.el would be installed by ports overriding my patched version and forcing me to patch it again and again. Why xcscope.el didn't splinted out into separate port/package -- it's another question... -- Andrew W. Nosenko From demelier.david at gmail.com Wed Oct 6 12:12:19 2010 From: demelier.david at gmail.com (David DEMELIER) Date: Wed Oct 6 12:12:22 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: <20101005182407.GE7829@dragon.NUXI.org> References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <20101005182407.GE7829@dragon.NUXI.org> Message-ID: 2010/10/5 David O'Brien : > On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote: >> 2010/10/2 David O'Brien : >> > 2. With the way OPTIONS handling is done, there isn't a way for me >> > to query if I built with the defaults or not. >> > Thus leading to every port I manually install looking like it was >> > customized just because /var/db/ports/${PORTNAME} exists. ?Thus >> > implying I can no longer install the pre-build package. >> >> make rmconfig ? > > I think you've missed my point. > > That does not tell me if I, in the past, made a decision that did not > like the maintainer's defaults, or if I just wanted to extract the > sources so I could read the license or figure out what the OPTIONS knobs > were about, etc.. > I understood, you prefere a file like make.conf or ports.conf to see which options/knob is defined, isn't it ? >> The best thing to do is switch totally to a way to configure a port >> and remove the other one. > > Only if folks agree on what the best way to configure a port is. > I spoke with some co-workers last week, and OPTIONS weren't very > popular with them. ?They also stated some of the the issues I listed. > > >> I think we should try to upgrade the options >> framework with what I said at 4. and 3. It's possible but we need some >> work. > > Even without forcing all ports to go in one direction for configuration, > this would be a Good Thing to do. ?Hopefully someone with interest will > submit some patches. > I will try to do it, I think a replacement of ports.conf with a make syntax would be better. I will try to do something in the end of week. > -- > -- David ?(obrien@FreeBSD.org) > Q: Because it reverses the logical flow of conversation. > A: Why is top-posting (putting a reply at the top of the message) frowned upon? > Let's not play "Jeopardy-style quoting" > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > Kind regards, -- Demelier David From bf1783 at googlemail.com Wed Oct 6 12:42:31 2010 From: bf1783 at googlemail.com (b. f.) Date: Wed Oct 6 12:42:34 2010 Subject: OPTIONS In-Reply-To: References: Message-ID: David O'Brien wrote: > On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote: > > What is "sufficiently clean" ? I wonder what is not clean in the > > options framework, so please tell me then we still can clean it? > > When the Ports Collection was invented, ports maintainers were to > choose a reasonable set of configuration for the FreeBSD community > and have the port build that way. > > Today we have ports that seem to expose every single option to GNU > configure and giving the user a puzzling choice of too many things. > Often the explanations are nothing more than restating the option > name and the user is left wondering what is X? What does Y mean? > How do I know if I really want Z or not? Why is threading so often > an OPTION and not just the default? Why do I have to go read the > packages README and INSTALLING to figure out the caveats of say > enabling threading? Or what the other list of things are and their > caveats? If you mean that some of the defaults are inconsistent, and could be changed; and that succinct comments could be added in some places to save time for the user, then I agree with you. But if you think that comments could obviate the need for learning about the software; or that the solution is to do away with OPTIONS altogether, and hard-code everything, I don't. You are a very experienced programmer, and you can appreciate that there is a lot of software out there that works in a lot of different ways. Also, there are a lot of users with different needs. To take your example, it may be that threading may be disabled for one port, and enabled for another, because of some inconsequential decision by a port maintainer. But it may also be because that port doesn't implement threading properly for some FreeBSD platforms. Or because enabling it brings benefits for some users, but disadvantages for others. We may be able to clean up some things, but we can't make the situation simpler than it is. > 1. One should not have to deal with the OPTIONS dialog just to > 'make extract' if one wants to check the license or otherwise > investigate a port before deciding to install it. That may be annoying, but some OPTIONS affect what is fetched and extracted, and how, so there isn't an easy way around this. If you just wanted to examine the default distfiles, you could set BATCH. The new license framework may help in the other case, after more LICENSE entries are added to ports. > 2. With the way OPTIONS handling is done, there isn't a way for me > to query if I built with the defaults or not. > Thus leading to every port I manually install looking like it was > customized just because /var/db/ports/${PORTNAME} exists. Thus > implying I can no longer install the pre-build package. This is partly an administrative issue, and I don't think that it can be dealt with entirely within Ports. Even if we changed the OPTIONSFILE handling to: (a) add a PORTS_DBDIR cookie, or an OPTIONSFILE entry, to indicate if an OPTIONSFILE corresponded to the default OPTIONS ; and (b) include all knobs that may affect the port build, and not just those now in OPTIONS -- both of which would add some complexity, and another potential source of error -- the information in PORTS_DBDIR may not correspond to the packages that are actually installed. Are you suggesting that all knobs used to build a package should be recorded in the package, and hence in PKG_DBDIR? That might be useful, although not easy to implement for knobs that weren't in OPTIONS. However, it seems to me that this kind of thing is best handled by updating tools, like pkg-mgmt/portupgrade[-devel], which has the per-port USE_PKGS[_ONLY] settings in pkgtool.conf. > 3. OPTIONS are limited to only checkbox YES/NO settings. > Why can I not set PREFIX thru the OPTIONS framework and have it come > from /var/db/ports/${PORTNAME}/options on the 2nd and later builds? > Even the boolean NOPORTDOCS isn't available thru OPTIONS. > Thus it is an inconsistent way to configure a port. > > 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in > /etc/make.conf, why does the OPTIONS dialog offer me > "[X] NLS Enable gettext support" instead of defaulting the > dialog to unchecked? You can set those knobs via the command line, or via Makefile.{inc, ${ARCH}*, ${OPSYS}, local}, or via make.conf, where you can limit the scope based on the .CURDIR, etc. Although we do have a problem, as you note in (4), with knobs that are OPTIONS, but are defined somewhere other than OPTIONSFILE. I hadn't seen: http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200 until swell.k pointed it out (thanks). I think that it does some good things, but it does have some problems: --I don't think the priority is right: the "environment" settings ought to override the PORTS_DBDIR entries. This is because they will do so anyway in some circumstances (because of recursion, or the use of make -e/-E, or because you can't .undef some "environment" variables), but also because users may want to perform a test build with knobs defined in the "environment", without having to alter their settings in PORTS_DBDIR. --The parsing of the config files needs to be changed, so that _OPTION_SRC_${OPT} isn't set to "config" when it should be "environment" (see above). Also, the entries in OPTIONSFILE.local ought to override anything in OPTIONSFILE, without regard to precedence of WITHOUT_*. --There needs to be a final sanity-check, that fails with an appropriate error message if both WITH_* and WITHOUT_* are defined, because the .undefs are not sufficient to guarantee mutual exclusivity. > 5. One cannot opt-out of OPTIONS. > WITHOUT_OPTIONS does not work to just get the defaults while skipping > the OPTIONS dialog. Note, setting BATCH does a lot more than just > make OPTIONS non-interactive (for some ports it stops other > non-OPTIONS interaction with the user that one should see). Thus > there is no way to get an uninterrupted default build of something. We could add a DEFAULT_OPTIONS knob, that used default values without querying the user or overwriting an existing OPTIONSFILE. > 6. One cannot opt-in/opt-out on a per-port basis. > WITH[OUT]_${PORTNAME}_OPTIONS and ${PORTNAME}_WITH[OUT]_OPTIONS > should be supported to control the OPTIONS dialog just when > building ${PORTNAME}. If you have (5), you can opt-in/opt-out, just as you can set knobs, on a per-port basis. It seems to me that little is gained, but something is lost, by defining and parsing many per-port variables. > 7. Setting ${PORTNAME}_WITH[OUT]_ (or > WITH[OUT]_${PORTNAME}_) should set > WITH[OUT]_ just when building ${PORTNAME}. > So that folks who don't want to be interrupted with OPTIONS every > time there is an update to the list can hardcode their choices in > /etc/make.conf. Again, I wouldn't want to have to define and parse scores of such variables. You mean that, if a DEFAULT_OPTIONS knob were implemented as in (5), you would want to use default options for any new options, but a select set of pre-defined values for the others? A reasonable implementation of DEFAULT_OPTIONS and a solution to the problem of (4) would allow you to do this as above, with the knobs, or via OPTIONSFILE.local. > 8. OPTIONS make a mess in the typescript file from > 'script typescript make', and the choices are totally unreadable vs. > 'script typescript make -DWITH_FOO -WITHOUT_BAR'. We could print the OPTIONS settings used during a build, by default. b. From roberthuff at rcn.com Wed Oct 6 12:48:12 2010 From: roberthuff at rcn.com (Robert Huff) Date: Wed Oct 6 12:48:15 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <20101005182407.GE7829@dragon.NUXI.org> Message-ID: <19628.26937.51650.986554@jerusalem.litteratus.org> David DEMELIER writes: > I will try to do it, I think a replacement of ports.conf with a > make syntax would be better. I will try to do something in the > end of week. For informational purposes only: if you are not aware of it, portupgrade has "pkgtools.conf". Robert Huff From cforgeron at acsi.ca Wed Oct 6 15:15:05 2010 From: cforgeron at acsi.ca (Chris Forgeron) Date: Wed Oct 6 15:15:08 2010 Subject: Volunteering for maintaining ICC port Message-ID: I'd like to step up and offer to modernize and maintain the ICC port for FreeBSD. I may be crazy, specially as 9 is going towards Clang/LLVM. With that move, there may be a lot of very talented people modifying the build/make environment to work in a way that is even further removed from ICC's working. Time will tell if this is viable or not. What I'm looking for is the previous port maintainer's email address. I ran across it someplace, but can't find it now. He mentioned having some contacts at Intel, as well as info on the basic process and tips for the next person who may want to maintain. I'm very interested in HPC, and I believe step one on this long road for FreeBSD is an option to use a more optimized complier for Intel platforms (which is all we use anyway). Thanks. From dennylin93 at hs.ntnu.edu.tw Wed Oct 6 15:24:41 2010 From: dennylin93 at hs.ntnu.edu.tw (Denny Lin) Date: Wed Oct 6 15:24:44 2010 Subject: Volunteering for maintaining ICC port In-Reply-To: References: Message-ID: <20101006152438.GA84591@mail.hs.ntnu.edu.tw> On Wed, Oct 06, 2010 at 11:45:03AM -0300, Chris Forgeron wrote: > What I'm looking for is the previous port maintainer's email address. I ran across it someplace, but can't find it now. He mentioned having some contacts at Intel, as well as info on the basic process and tips for the next person who may want to maintain. The maintainer used to be netchild@FreeBSD.org. Info can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/icc/Makefile#rev1.94 -- Denny Lin From cforgeron at acsi.ca Wed Oct 6 15:26:50 2010 From: cforgeron at acsi.ca (Chris Forgeron) Date: Wed Oct 6 15:26:53 2010 Subject: Volunteering for maintaining ICC port In-Reply-To: <20101006152438.GA84591@mail.hs.ntnu.edu.tw> References: <20101006152438.GA84591@mail.hs.ntnu.edu.tw> Message-ID: Ah, perfect - That's the page I was looking for. Thanks, now begins the feasibility study. :-) -----Original Message----- From: owner-freebsd-ports@freebsd.org [mailto:owner-freebsd-ports@freebsd.org] On Behalf Of Denny Lin Sent: October-06-10 12:25 PM To: Chris Forgeron Cc: 'freebsd-ports@freebsd.org' Subject: Re: Volunteering for maintaining ICC port On Wed, Oct 06, 2010 at 11:45:03AM -0300, Chris Forgeron wrote: > What I'm looking for is the previous port maintainer's email address. I ran across it someplace, but can't find it now. He mentioned having some contacts at Intel, as well as info on the basic process and tips for the next person who may want to maintain. The maintainer used to be netchild@FreeBSD.org. Info can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/icc/Makefile#rev1.94 -- Denny Lin _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From andimayer82 at gmail.com Wed Oct 6 16:22:39 2010 From: andimayer82 at gmail.com (Andreas Mayer) Date: Wed Oct 6 16:22:44 2010 Subject: teamspeak_client/teamspeak_server ports Message-ID: hi, I just wanted to notify you that there are TeamSpeak 3 binaries available for FreeBSD x86 and AMD64 now. Got them up and running without problems, maybe you find some time and update the ports... just let me know if I can help (but I don't have experience with ports). daemon -u teamspeak ./ts3server_minimal_runscript.sh works for me, when permissions are set to teamspeak user for the whole directory Best regards Andreas From jumper99 at gmx.de Wed Oct 6 17:12:12 2010 From: jumper99 at gmx.de (Helmut Schneider) Date: Wed Oct 6 17:12:16 2010 Subject: How long does a repocopy take? References: <201010051139.15066.makc@issp.ac.ru> Message-ID: Max Brazhnikov wrote: > On Mon, 4 Oct 2010 18:57:35 +0000 (UTC), Helmut Schneider wrote: > > sorry for my impatience but I asked for a repocopy about one week > > ago and now I'm wondering how long normally a repocopy takes. > > Submit patch vs existing port ask for repocopy. Commiter will request > repocopy from portmgr@ Did so. Thanks, Helmut From bf1783 at googlemail.com Wed Oct 6 17:31:06 2010 From: bf1783 at googlemail.com (b. f.) Date: Wed Oct 6 17:31:09 2010 Subject: Volunteering for maintaining ICC port Message-ID: >The maintainer used to be netchild at FreeBSD.org. He wrote this not long ago: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019208.html b. From bf1783 at googlemail.com Wed Oct 6 17:35:32 2010 From: bf1783 at googlemail.com (b. f.) Date: Wed Oct 6 17:35:36 2010 Subject: Volunteering for maintaining ICC port Message-ID: >The maintainer used to be netchild at FreeBSD.org. He wrote this not long ago: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019208.html b. From obrien at freebsd.org Wed Oct 6 17:51:06 2010 From: obrien at freebsd.org (David O'Brien) Date: Wed Oct 6 17:51:09 2010 Subject: OPTIONS (was: editors/vim installs to /) In-Reply-To: References: <4C93AA31.5080202@DataIX.net> <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <20101005182407.GE7829@dragon.NUXI.org> Message-ID: <20101006175105.GA81751@dragon.NUXI.org> On Wed, Oct 06, 2010 at 02:12:18PM +0200, David DEMELIER wrote: > 2010/10/5 David O'Brien : > > On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote: > >> 2010/10/2 David O'Brien : > >> > 2. With the way OPTIONS handling is done, there isn't a way for me > >> > to query if I built with the defaults or not. > >> > Thus leading to every port I manually install looking like it was > >> > customized just because /var/db/ports/${PORTNAME} exists.  Thus > >> > implying I can no longer install the pre-build package. > >> > >> make rmconfig ? > > > > I think you've missed my point. > > > > That does not tell me if I, in the past, made a decision that did not > > like the maintainer's defaults, or if I just wanted to extract the > > sources so I could read the license or figure out what the OPTIONS knobs > > were about, etc.. > > I understood, you prefere a file like make.conf or ports.conf to see > which options/knob is defined, isn't it ? That is true - but doesn't isn't really what's behind #2 above. In this case, I really want to now which packages are OK to upgrade using 'portupgrade -PP' (or portmaster) -- to quickly do upgrades using the pre-built packages Portmgr spends a lot of time making available to us. I use a script that looks for a non-zero byte /var/db/ports/$PKG/options or any $PKG knobs in /etc/make.conf. If either is found, then 'portupgrade -PP', else just 'portupgrade'. This is where things like 'make extract' cause a problem - since one cannot even extract without going thru OPTIONS dialog. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From obrien at freebsd.org Wed Oct 6 17:55:14 2010 From: obrien at freebsd.org (David O'Brien) Date: Wed Oct 6 17:55:18 2010 Subject: OPTIONS In-Reply-To: References: <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <20101005183452.GF7829@dragon.NUXI.org> <20101006084040.GA53569@dragon.NUXI.org> Message-ID: <20101006175513.GB81751@dragon.NUXI.org> On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote: > On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote: > > On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: > >> > 2010/10/3 Matthew Seaman : > >> > > In fact, you might just as well write a small HTML form, display it > >> > > using lynx or w3c or some other text mode browser[*], and then have the > >> > > form action feed into a CGI program that outputs a small Makefile with > >> > > appropriate variable definitions in it. > >> > >> I like this statement -- as it shows just how complex this will get when > >> taken to its natural conclusion. > > > > This is also how ridiculous things can get: > > > > curl 7.21.1 now offers me: > >    [X] WERROR       Treat compilation warnings as errors > > > >    Can the port maintainer really not decide if that should just be > >    turned off or turned on for FreeBSD?!? > > I wonder why -Werror even ever considered to be turned "on" at all. \AOL{me too} I mean building with "-Werror" sounds like goodness -- of course I want it. But why is the maintainer offering me a choice? What is the likelihood of the port not building with -Werror? Does he know of versions of FreeBSD where the port will not build with -Werror? Hum.. maybe I don't want -Werror. But then why didn't the the maintainer just decide we would all not build with -Werror? Given we are just building and installing Curl, what do we expect users to do choose WERROR and get a build break with -Werror? They aren't developing the next version of Curl. Can they submit a FreeBSD PR and expect the maintainer will quickly add a patch to the port to fix the warning(s)? Or will the response be "Well, don't do that."? In which case just turning off -Werror for all seems a better thing to do. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From severe.grind at gmail.com Wed Oct 6 19:57:47 2010 From: severe.grind at gmail.com (Severe Grind) Date: Wed Oct 6 19:57:51 2010 Subject: several question about ports In-Reply-To: References: Message-ID: Hello, I have several questions concerning creating Makefile I don't understand in what sequence USE_* flags in Makefile are processed Is it possible to do: In pre-fetch stage USE_AUTOTOOLS USE_JAVA USE_APACHE after that execute script, pre-configure which will make firebird-2.1 from sorce, then make PHP via USE flag? From severe.grind at gmail.com Wed Oct 6 20:17:37 2010 From: severe.grind at gmail.com (Severe Grind) Date: Wed Oct 6 20:46:08 2010 Subject: several question about ports Message-ID: Hello I have several question about create Makefile ???? ???? ???????? ?? ?????? ???????? Makefile I'm not understand in what sequence processed USE_* flags in Makefile ?? ??????? ? ????? ?????????????????? ?????????????? USE_* ????? ? ???? ????? Is it possible the following: ???????? ?? ????????? ?? pre-fetch USE_AUTOTOOLS USE_JAVA USE_APACHE pre-fetch ?????? ???????????? USE_AUTOTOOLS USE_JAVA USE_APACHE after that execute script, pre-configure who maked firebird-2.1 from sorce, then make PHP via USE flag? ????? ????????? ??????, pre-configure ??????? ??????? firebird-2.1, ? ????? ??????? PHP ????? USE ????. From paul_hohberg at fsd.k12.ca.us Wed Oct 6 21:00:20 2010 From: paul_hohberg at fsd.k12.ca.us (paul_hohberg) Date: Wed Oct 6 21:00:22 2010 Subject: FreeBSD Port: ntop-3.3.10_7 Message-ID: Any plans on adding ntop 4.1 to the FreeBSD ports collection? Thanks, Paul Hohberg System Administrator Fullerton School District 1401 W. Valencia Drive Fullerton, CA 92833 714-447-7483 From swell.k at gmail.com Thu Oct 7 02:46:47 2010 From: swell.k at gmail.com (Anonymous) Date: Thu Oct 7 02:46:50 2010 Subject: irc/weechat*: cmake/Find(Python|Ruby|etc).cmake don't respect version from bsd.(python|ruby|etc).mk Message-ID: <86y6aau3e6.fsf@gmail.com> The port blindly assumes the first version of python|ruby|etc it finds as the one user wants weechat plugin built against. Example for python $ export PYTHON_DEFAULT_VERSION=python2.7 $ make install deinstall WITH_PYTHON= ... ===> Deinstalling weechat-0.3.3_1 pkg_delete: file '/usr/local/lib/weechat/plugins/python.so' doesn't exist And excerpt from CMakeCache.txt //Path to a program. PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python //Path to a file. PYTHON_INCLUDE_PATH:PATH=/usr/local/include/python2.5 //Path to a library. PYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython2.6.so //Dependencies for the target python_LIB_DEPENDS:STATIC=general;/usr/local/lib/libpython2.6.so;general;weechat_scripts; I guess FindPython.cmake doesn't respect LOCALBASE, too. %% Index: irc/weechat/Makefile =================================================================== RCS file: /a/.cvsup/ports/irc/weechat/Makefile,v retrieving revision 1.49 diff -u -p -r1.49 Makefile --- irc/weechat/Makefile 30 Sep 2010 04:14:36 -0000 1.49 +++ irc/weechat/Makefile 7 Oct 2010 02:44:32 -0000 @@ -64,6 +64,8 @@ PLIST_SUB+= ASPELL="@comment " .if defined(WITH_PYTHON) USE_PYTHON= yes +CMAKE_ARGS+= -DPYTHON_VERSION=${PYTHON_VERSION} \ + -DPYTHON_CMD=${PYTHON_CMD} PLIST_SUB+= PYTHON="" .else CMAKE_ARGS+= -DDISABLE_PYTHON=yes Index: irc/weechat/files/patch-cmake-FindPython.cmake =================================================================== RCS file: irc/weechat/files/patch-cmake-FindPython.cmake diff -N irc/weechat/files/patch-cmake-FindPython.cmake --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ irc/weechat/files/patch-cmake-FindPython.cmake 7 Oct 2010 01:59:44 -0000 @@ -0,0 +1,21 @@ +--- cmake/FindPython.cmake~ 2010-09-28 13:09:52.000000000 +0400 ++++ cmake/FindPython.cmake 2010-10-07 05:37:43.709648725 +0400 +@@ -34,8 +34,7 @@ IF(PYTHON_FOUND) + ENDIF(PYTHON_FOUND) + + FIND_PROGRAM(PYTHON_EXECUTABLE +- NAMES python python2.6 python2.5 python2.4 python2.3 python2.2 +- PATHS /usr/bin /usr/local/bin /usr/pkg/bin ++ NAMES ${PYTHON_CMD} + ) + + IF(PYTHON_EXECUTABLE) +@@ -65,7 +64,7 @@ IF(PYTHON_EXECUTABLE) + ) + + FIND_LIBRARY(PYTHON_LIBRARY +- NAMES python python2.6 python2.5 python2.4 python2.3 python2.2 ++ NAMES ${PYTHON_VERSION} + PATHS ${PYTHON_POSSIBLE_LIB_PATH} + ) + %% From swell.k at gmail.com Thu Oct 7 02:54:24 2010 From: swell.k at gmail.com (Anonymous) Date: Thu Oct 7 02:54:27 2010 Subject: irc/weechat*: cmake/Find(Python|Ruby|etc).cmake don't respect version from bsd.(python|ruby|etc).mk In-Reply-To: <86y6aau3e6.fsf@gmail.com> (Anonymous's message of "Thu, 07 Oct 2010 06:45:37 +0400") References: <86y6aau3e6.fsf@gmail.com> Message-ID: <86hbgyu318.fsf@gmail.com> Anonymous writes: > $ export PYTHON_DEFAULT_VERSION=python2.7 > $ make install deinstall WITH_PYTHON= > ... > ===> Deinstalling weechat-0.3.3_1 > pkg_delete: file '/usr/local/lib/weechat/plugins/python.so' doesn't exist > > And excerpt from CMakeCache.txt Oops, read as And excerpt from CMakeCache.txt when several version of python installed while retaining python2.7 as the default > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python > > //Path to a file. > PYTHON_INCLUDE_PATH:PATH=/usr/local/include/python2.5 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython2.6.so > > //Dependencies for the target > python_LIB_DEPENDS:STATIC=general;/usr/local/lib/libpython2.6.so;general;weechat_scripts; As for the case when only python2.7 is installed the contents are //Path to a program. PYTHON_EXECUTABLE:FILEPATH=PYTHON_EXECUTABLE-NOTFOUND From chrcoluk at gmail.com Thu Oct 7 03:05:09 2010 From: chrcoluk at gmail.com (Chris) Date: Thu Oct 7 03:05:42 2010 Subject: security/openssh-portable maintainer Message-ID: Hi, I see this port has no maintainer now and is now out of date. I have attempted myself to update the port but have hit a number of problems. 1 - some of the contrib patches dont exist for the new version of the app. I assume support would need to be dropped t least emporarily on an update. 2 - one of the freebsd patches in the files dir fails to patch, the rest are reported as syccessful however when checking the files in the work dir they are not patched. 3 - the hpn patch on the dev website is gzipped, the ports system seems to assume a patch must be uncompressed when downloading? 4 - the hpn patch initially on the old version is just in the files dir however I couldnt find a way to use -p1 with it, so I set it to download as a dist patch but because of problem #3 I used my own webspace to download a uncompressed patch. What I am asking is, can someone please take over this port, my skill set is not high enough to do it at least without some help. Failing that can someone help me with the freebed patches in the files dir to patch ok on openssh 5.6p1. Chris From jhell at DataIX.net Thu Oct 7 03:22:44 2010 From: jhell at DataIX.net (jhell) Date: Thu Oct 7 03:22:47 2010 Subject: OPTIONS In-Reply-To: <20101006175513.GB81751@dragon.NUXI.org> References: <20100918223933.GB85995@dragon.NUXI.org> <20101002002605.GA8018@dragon.NUXI.org> <4CA844E5.7060303@infracaninophile.co.uk> <20101005183452.GF7829@dragon.NUXI.org> <20101006084040.GA53569@dragon.NUXI.org> <20101006175513.GB81751@dragon.NUXI.org> Message-ID: <4CAD3CFE.8030700@DataIX.net> On 10/06/2010 13:55, David O'Brien wrote: > On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote: >> On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote: >>> On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: >>>>> 2010/10/3 Matthew Seaman : >>>>>> In fact, you might just as well write a small HTML form, display it >>>>>> using lynx or w3c or some other text mode browser[*], and then have the >>>>>> form action feed into a CGI program that outputs a small Makefile with >>>>>> appropriate variable definitions in it. >>>> >>>> I like this statement -- as it shows just how complex this will get when >>>> taken to its natural conclusion. >>> >>> This is also how ridiculous things can get: >>> >>> curl 7.21.1 now offers me: >>> ? ?[X] WERROR ? ? ? Treat compilation warnings as errors >>> >>> ? ?Can the port maintainer really not decide if that should just be >>> ? ?turned off or turned on for FreeBSD?!? >> >> I wonder why -Werror even ever considered to be turned "on" at all. > > \AOL{me too} > > I mean building with "-Werror" sounds like goodness -- of course I > want it. > > But why is the maintainer offering me a choice? > What is the likelihood of the port not building with -Werror? > Does he know of versions of FreeBSD where the port will not build > with -Werror? Hum.. maybe I don't want -Werror. But then why didn't > the the maintainer just decide we would all not build with -Werror? > > Given we are just building and installing Curl, what do we expect > users to do choose WERROR and get a build break with -Werror? > They aren't developing the next version of Curl. Can they submit a > FreeBSD PR and expect the maintainer will quickly add a patch to the > port to fix the warning(s)? Or will the response be > "Well, don't do that."? In which case just turning off -Werror for > all seems a better thing to do. > IMHO If I may, The OPTIONS framework is a UI(User Interface) to useful options that a 'User' would be interested in turning on. This would be things that a user, not a 'developer' could use or would find helpful. With the above said, if it was the developers intent to add options in order to make debugging the port easier for them, then I feel that is the wrong approach as these are options that are more appropriately handled by CFLAGS CXXFLAGS LDFLAGS and such since they are developer centric and mean very little to the majority of the community. Now with both of the above stated, it may be useful if specific developer options were wrapped in a statement that would check to see if a MAINTAINER_MODE has been defined allowing those options to be dynamically added to the list of existing option. Personally I feel that because of the loose guidelines that we already have in the Porters Handbook that when frameworks like this present problems as the options framework has already shown, that a better defined standard should be developed & agreed upon so that every developer and user knows exactly what to expect out of every port and what is expected to be presented to the user. A ports tree of this size and not having a clear and set-forth standard as to what can be expected is fairly hazardous IMO. If I had missed an area 'one area' where this is already defined then please excuse me and reference me a clear link. Regards, -- jhell,v From linimon at FreeBSD.org Thu Oct 7 06:28:33 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:28:38 2010 Subject: FreeBSD unmaintained ports which are currently marked broken Message-ID: <20101007062832.70F2A1CC22@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/festvox-aec broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=festvox-aec portname: audio/gtkguitune broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gtkguitune portname: audio/gxmms2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gxmms2 portname: biology/tinker broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=tinker portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: databases/p5-sqlrelay broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=p5-sqlrelay portname: deskutils/gnotime broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gnotime portname: devel/ace+tao broken because: Does not compile on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ace%2Btao portname: devel/fampp broken because: FAM system mismatch: gamin is installed, while desired FAM system is fam build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fampp portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linuxthreads portname: devel/ngpt broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ngpt portname: dns/fourcdns broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=fourcdns portname: emulators/cpmtools2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=cpmtools2 portname: emulators/win4bsd broken because: does not fetch build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: finance/gfp broken because: fails during build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=finance&portname=gfp portname: ftp/ftpq broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=ftpq portname: games/hlstats broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=hlstats portname: games/kanatest broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=kanatest portname: games/kbilliards broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=kbilliards portname: games/whichwayisup broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=whichwayisup portname: games/xblast broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=xblast portname: graphics/libvisual-plugins broken because: Broken objformat handling build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=libvisual-plugins portname: graphics/mesa-demos broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=mesa-demos portname: graphics/ophoto broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=ophoto portname: graphics/paintlib broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/paintlib-2.6.2_5.log.bz2 (_Sep_20_05:12:48_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=paintlib portname: graphics/plasma-kmod broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=plasma-kmod portname: graphics/ray++ broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=ray%2B%2B portname: graphics/seom broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=seom portname: graphics/snx101util broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=snx101util portname: graphics/white_dune broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=white_dune portname: graphics/wildmagic broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=wildmagic portname: japanese/oleo broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=oleo portname: japanese/tkstep80 broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=tkstep80 portname: java/tya broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=java&portname=tya portname: korean/unzip broken because: does not patch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=korean&portname=unzip portname: lang/bigloo broken because: is not compiled with Emacs 23 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=bigloo portname: lang/scriba broken because: Does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=scriba portname: lang/u++ broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=u%2B%2B portname: mail/kiltdown broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/kiltdown-0.8.045_14.log.bz2 (_Sep_21_18:49:36_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=kiltdown portname: math/kaskade broken because: Fails to compile with GCC 4.3 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=kaskade portname: math/rascal broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=rascal portname: misc/fep broken because: Does not compile without sgtty build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=fep portname: misc/splitvt broken because: does not compile: /usr/include/sys/ioctl_compat.h:42:2: Definitions not available without TTY ioctl compat build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=splitvt portname: multimedia/jahshaka broken because: does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=jahshaka portname: multimedia/netshow broken because: does not fetch build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.20101005222306/netshow-2.00.251_2.log (_May_12_05:28:15_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=netshow portname: net-mgmt/net-snmp4 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=net-snmp4 portname: net-mgmt/nipper broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=nipper portname: net-mgmt/wide-dhcp broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=wide-dhcp portname: net-p2p/trackerbt broken because: does not compile with new Sockets build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/trackerbt-0.1.3.log.bz2 (_Jul_27_00:48:52_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=trackerbt portname: net/cap broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=cap portname: net/pimdd broken because: does not compile: error: IGMP_HOST_MEMBERSHIP_REPORT undeclared build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=pimdd portname: net/pppoa broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=pppoa portname: news/ija broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=news&portname=ija portname: palm/uppc-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=palm&portname=uppc-kmod portname: ports-mgmt/barry broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=barry portname: print/py-reportlab broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=py-reportlab portname: security/fressh broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=fressh portname: security/lasso broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=lasso portname: security/newpki-lib broken because: does not compile with OpenSSL 0.9.8b build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=newpki-lib portname: security/newpki-server broken because: does not compile with OpenSSL 0.9.8b build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=newpki-server portname: security/nsm-console broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=nsm-console portname: security/prelude-lml broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=prelude-lml portname: security/vscan broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=vscan portname: security/xmlsec broken because: Does not compile on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=xmlsec portname: security/xyssl broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=xyssl portname: sysutils/checkservice broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=checkservice portname: textproc/htmlize.el broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=htmlize.el portname: textproc/opensched broken because: Does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=opensched portname: textproc/openvanilla-modules broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/openvanilla-modules-0.7.2.20070514_3.log (_Oct__5_06:21:59_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=openvanilla-modules portname: textproc/skim broken because: Doesn't build with python2.6 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=skim portname: www/bk_edit broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=bk_edit portname: www/bricolage broken because: missing dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=bricolage portname: www/wb0 broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=wb0 portname: www/xist broken because: bad plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=xist portname: x11-clocks/xtu broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-clocks&portname=xtu portname: x11-toolkits/p5-Tcl-Tk broken because: something segfaults during build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=p5-Tcl-Tk portname: x11-toolkits/xscoop broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=xscoop From linimon at FreeBSD.org Thu Oct 7 06:29:09 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:29:13 2010 Subject: FreeBSD ports which are currently marked broken Message-ID: <20101007062907.5E6A71CC22@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/aureal-kmod broken because: doesn't build on RELENG_8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=aureal-kmod portname: audio/baudline broken because: no longer available (website now have 1.08) build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/linux-baudline-1.07.log.bz2 (_Jul_27_00:43:34_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=baudline portname: audio/ecawave broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=ecawave portname: audio/emu10kx broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=emu10kx portname: audio/festvox-aec broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=festvox-aec portname: audio/gmpc-mserver broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gmpc-mserver portname: audio/gtkguitune broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gtkguitune portname: audio/gxmms2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gxmms2 portname: benchmarks/polygraph broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph-3.0.6_1.log (_Mar_21_01:42:24_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph portname: benchmarks/polygraph31 broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph31-3.1.5_1.log (_Mar_21_01:42:25_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph31 portname: biology/tinker broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=tinker portname: cad/tclspice broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=tclspice portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: comms/hcfmdm broken because: Does not compile at 7.x or higher build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=hcfmdm portname: comms/hso-kmod broken because: does not build with USB2, please try comms/uhso-kmod instead build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=hso-kmod portname: comms/ib-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=ib-kmod portname: comms/uticom broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=uticom portname: converters/mimelib broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=converters&portname=mimelib portname: databases/erserver broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=erserver portname: databases/gauche-gdbm broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=gauche-gdbm portname: databases/mysql-gui-tools broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100922072848/mysql-gui-tools-5.0r14_4.log.bz2 (_Sep_26_03:18:48_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mysql-gui-tools portname: databases/mysqlcc broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mysqlcc portname: databases/p5-sqlrelay broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=p5-sqlrelay portname: deskutils/gnotime broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gnotime portname: devel/ace+tao broken because: Does not compile on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ace%2Btao portname: devel/bullet broken because: Does not work with autoconf>=2.64 - upstream 2.76 has switched to cmake. build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/bullet-2.75.log.bz2 (_Mar_18_02:13:41_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=bullet portname: devel/cocktail broken because: Segfault during build on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=cocktail portname: devel/djgpp-gcc broken because: Does not work with autoconf>=2.64 - no upstream fix. build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=djgpp-gcc portname: devel/fampp broken because: FAM system mismatch: gamin is installed, while desired FAM system is fam build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fampp portname: devel/gauche-sdl broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gauche-sdl portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gcvs portname: devel/gdb53-act broken because: Does not compile with GCC 4.2 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.20090822221417/gdb-act-5.3_2,1.log (_Aug_23_08:39:54_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gdb53-act portname: devel/lamson broken because: leaves behind files on deinstall build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=lamson portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linuxthreads portname: devel/msp430-gdb broken because: Does not compile with GCC 4.2 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.20090822221417/msp430-gdb-5.1.1.20030909_1.log (_Aug_23_08:40:49_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=msp430-gdb portname: devel/ngpt broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ngpt portname: devel/p5-P4-Client broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-P4-Client portname: devel/php-dbg2 broken because: does not compile with PHP 5.3.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=php-dbg2 portname: devel/root broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=root portname: devel/ruby-rjudy broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ruby-rjudy portname: devel/rubygem-newgem broken because: Depends on broken devel/rubygem-rubigen build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-newgem portname: devel/rubygem-rubigen broken because: Depends on exact vesion of activesupport 2.3.5 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-rubigen portname: devel/xfc broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=xfc portname: dns/fourcdns broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=fourcdns portname: editors/zed broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editors&portname=zed portname: emulators/cpmtools2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=cpmtools2 portname: emulators/fmsx broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=fmsx portname: emulators/linux_base-gentoo-stage3 broken because: unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_base-gentoo-stage3 portname: emulators/linux_dist-gentoo-stage3 broken because: unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_dist-gentoo-stage3 portname: emulators/mupen64plus-rice broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=mupen64plus-rice portname: emulators/pearpc broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=pearpc portname: emulators/win4bsd broken because: does not fetch build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: finance/gfp broken because: fails during build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=finance&portname=gfp portname: ftp/ftpq broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=ftpq portname: ftp/wxdfast broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=wxdfast portname: games/aqbubble broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=aqbubble portname: games/egl broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=egl portname: games/hlstats broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=hlstats portname: games/kanatest broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=kanatest portname: games/kbilliards broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=kbilliards portname: games/whichwayisup broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=whichwayisup portname: games/xblast broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=xblast portname: graphics/crystalspace broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=crystalspace portname: graphics/exact-image broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/exact-image-0.8.1.log.bz2 (_Sep_19_14:26:01_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=exact-image portname: graphics/libvisual-plugins broken because: Broken objformat handling build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=libvisual-plugins portname: graphics/linux-ac3d broken because: does not fetch build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/linux-ac3d-6.528.log.bz2 (_Sep_16_11:39:25_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=linux-ac3d portname: graphics/luxrender broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/luxrender-0.6.1_1.log.bz2 (_Sep_20_01:26:08_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=luxrender portname: graphics/mapnik broken because: Does not build with boost-1.41 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=mapnik portname: graphics/mesa-demos broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=mesa-demos portname: graphics/ophoto broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=ophoto portname: graphics/paintlib broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/paintlib-2.6.2_5.log.bz2 (_Sep_20_05:12:48_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=paintlib portname: graphics/phpsview broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=phpsview portname: graphics/plasma-kmod broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=plasma-kmod portname: graphics/qcamview broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=qcamview portname: graphics/ray++ broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=ray%2B%2B portname: graphics/seom broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=seom portname: graphics/snx101util broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=snx101util portname: graphics/spcaview broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=spcaview portname: graphics/vid broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=vid portname: graphics/white_dune broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=white_dune portname: graphics/wildmagic broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=wildmagic portname: japanese/oleo broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=oleo portname: japanese/roundcube broken because: bad distinfo build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=roundcube portname: japanese/tkstep80 broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=tkstep80 portname: japanese/yc.el broken because: Does not support emacs23.x or later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=yc.el portname: java/eclipse-cdt broken because: bad dependency object for java/eclipse build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=java&portname=eclipse-cdt portname: java/jakarta-commons-dbcp broken because: does not build unless jakarta-commons-collections is compiled with jdk15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=java&portname=jakarta-commons-dbcp portname: java/jdk14 broken because: Does not compile with GCC 4.2 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.20090822221417/jdk-1.4.2p8_15.log (_Aug_23_08:38:49_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=java&portname=jdk14 portname: java/tya broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=java&portname=tya portname: korean/unzip broken because: does not patch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=korean&portname=unzip portname: lang/bigloo broken because: is not compiled with Emacs 23 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=bigloo portname: lang/dylan broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=dylan portname: lang/etoile-languagekit broken because: needs llvm <= 2.6.r71086 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=etoile-languagekit portname: lang/gnat-gcc42 broken because: does not support FreeBSD 8.x build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=gnat-gcc42 portname: lang/mozart broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=mozart portname: lang/nqc broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=nqc portname: lang/ocamlduce broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=ocamlduce portname: lang/pugs broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=pugs portname: lang/scriba broken because: Does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=scriba portname: lang/u++ broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=u%2B%2B portname: mail/evolution-sharp broken because: Doesn't accept current evolution version build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=evolution-sharp portname: mail/kiltdown broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/kiltdown-0.8.045_14.log.bz2 (_Sep_21_18:49:36_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=kiltdown portname: math/R-cran-igraph broken because: Does not build with R-2.11.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=R-cran-igraph portname: math/asir2000 broken because: Only builds with now-nonexistant automake15 build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/asir-20070806_4.log.bz2 (_Sep_22_07:31:06_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=asir2000 portname: math/dislin broken because: size mismatch build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/dislin-10.0.log.bz2 (_Apr__5_09:13:46_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=dislin portname: math/kaskade broken because: Fails to compile with GCC 4.3 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=kaskade portname: math/linalg broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=linalg portname: math/rascal broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=rascal portname: math/scilab-toolbox-sivp broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=scilab-toolbox-sivp portname: misc/fep broken because: Does not compile without sgtty build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=fep portname: misc/ftree broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=ftree portname: misc/splitvt broken because: does not compile: /usr/include/sys/ioctl_compat.h:42:2: Definitions not available without TTY ioctl compat build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=splitvt portname: misc/usbrh broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=usbrh portname: multimedia/bangarang broken because: does not compile build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100922072848/bangarang-1.0.1.log.bz2 (_Sep__7_04:00:35_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=bangarang portname: multimedia/banshee-mirage broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=banshee-mirage portname: multimedia/jahshaka broken because: does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=jahshaka portname: multimedia/katchtv broken because: does not work with new kaffeine build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=katchtv portname: multimedia/libomxil-bellagio broken because: bad plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=libomxil-bellagio portname: multimedia/netshow broken because: does not fetch build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.20101005222306/netshow-2.00.251_2.log (_May_12_05:28:15_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=netshow portname: net-im/trix broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-im&portname=trix portname: net-mgmt/nagios-check_memcached_paranoid broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.6.20100927082744/check_memcached_paranoid-0.20091016_1.log (_Sep_25_20:27:28_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=nagios-check_memcached_paranoid portname: net-mgmt/net-snmp4 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=net-snmp4 portname: net-mgmt/nipper broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=nipper portname: net-mgmt/wide-dhcp broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=wide-dhcp portname: net-p2p/trackerbt broken because: does not compile with new Sockets build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/trackerbt-0.1.3.log.bz2 (_Jul_27_00:48:52_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=trackerbt portname: net/atmsupport broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=atmsupport portname: net/b2bua broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=b2bua portname: net/cap broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=cap portname: net/ggsd broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=ggsd portname: net/ipex broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=ipex portname: net/penguintv broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=penguintv portname: net/pimdd broken because: does not compile: error: IGMP_HOST_MEMBERSHIP_REPORT undeclared build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=pimdd portname: net/pppoa broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=pppoa portname: net/skype broken because: This is the last version of skype that works on FreeBSD, but the distfile is no longer available from the vendor, and won't be in the future. We are working on alternative solutions. build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=skype portname: net/xbone-gui broken because: bad plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=xbone-gui portname: net/ztelnet broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=ztelnet portname: news/ija broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=news&portname=ija portname: news/newsstar broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=news&portname=newsstar portname: news/openftd broken because: does not configure build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.6.20090312033320/openftd-1.1.0_2.log (Wed Mar 18 11:52:03 UTC 2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=news&portname=openftd portname: palm/barry broken because: does not configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=palm&portname=barry portname: palm/romeo broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=palm&portname=romeo portname: palm/uppc-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=palm&portname=uppc-kmod portname: ports-mgmt/barry broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=barry portname: print/kaspaliste broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=kaspaliste portname: print/py-reportlab broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=print&portname=py-reportlab portname: science/elmer-fem broken because: fails to compile with gcc4.4 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=science&portname=elmer-fem portname: science/pcp broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=science&portname=pcp portname: security/dazuko broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=dazuko portname: security/f-protd broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=f-protd portname: security/fressh broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=fressh portname: security/lasso broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=lasso portname: security/newpki-lib broken because: does not compile with OpenSSL 0.9.8b build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=newpki-lib portname: security/newpki-server broken because: does not compile with OpenSSL 0.9.8b build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=newpki-server portname: security/nsm-console broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=nsm-console portname: security/prelude-lml broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=prelude-lml portname: security/sfs broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=sfs portname: security/vscan broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=vscan portname: security/xmlsec broken because: Does not compile on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=xmlsec portname: security/xyssl broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=xyssl portname: sysutils/busybox broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=busybox portname: sysutils/checkservice broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=checkservice portname: sysutils/dtc broken because: bad dependency object build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100922072848/dtc-0.32.0.1.log.bz2 (_Sep_26_03:35:27_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=dtc portname: sysutils/perf broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=perf portname: sysutils/udesc_dump broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=udesc_dump portname: sysutils/xwlans broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=xwlans portname: textproc/htmlize.el broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=htmlize.el portname: textproc/opensched broken because: Does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=opensched portname: textproc/openvanilla-modules broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.8.20100815051156/openvanilla-modules-0.7.2.20070514_3.log (_Oct__5_06:21:59_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=openvanilla-modules portname: textproc/skim broken because: Doesn't build with python2.6 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textproc&portname=skim portname: vietnamese/vnelvis broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=vietnamese&portname=vnelvis portname: vietnamese/vnterm broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=vietnamese&portname=vnterm portname: www/bk_edit broken because: Broken with gcc 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=bk_edit portname: www/bricolage broken because: missing dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=bricolage portname: www/cacheboy15-devel broken because: does not compile with Heimdal 1.1 in 8.0-CURRENT build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=cacheboy15-devel portname: www/mod_dtcl broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=mod_dtcl portname: www/p5-Apache2-Scoreboard broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=p5-Apache2-Scoreboard portname: www/p5-Plack-Server-ServerSimple broken because: installs same files as its dependency build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/p5-Plack-Server-ServerSimple-0.03.log (_Mar_21_01:51:37_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=p5-Plack-Server-ServerSimple portname: www/p5-RTx-Statistics broken because: bad plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=p5-RTx-Statistics portname: www/py-jswebkit broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20100917074150/py26-jswebkit-0.0.2.log.bz2 (_Sep_21_12:28:17_UTC_2010) http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/py26-jswebkit-0.0.2.log.bz2 (_Jul_27_00:43:11_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=py-jswebkit portname: www/wb0 broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=wb0 portname: www/wyvern broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=wyvern portname: www/xist broken because: bad plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=xist portname: x11-clocks/xtu broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-clocks&portname=xtu portname: x11-drivers/xf86-input-citron broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-drivers&portname=xf86-input-citron portname: x11-drivers/xf86-input-elographics broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-drivers&portname=xf86-input-elographics portname: x11-drivers/xf86-input-fpit broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-drivers&portname=xf86-input-fpit portname: x11-drivers/xf86-video-rdc broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-drivers&portname=xf86-video-rdc portname: x11-toolkits/efltk broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=efltk portname: x11-toolkits/gambas2-gb-qt broken because: fails to build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.20090822221417/gambas2-gb-qt-2.15.2.log (_Aug_23_08:37:22_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=gambas2-gb-qt portname: x11-toolkits/gauche-gtk broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=gauche-gtk portname: x11-toolkits/p5-Tcl-Tk broken because: something segfaults during build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=p5-Tcl-Tk portname: x11-toolkits/php-gtk2 broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=php-gtk2 portname: x11-toolkits/xscoop broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=xscoop portname: x11/metisse broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11&portname=metisse From linimon at FreeBSD.org Thu Oct 7 06:29:22 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:29:25 2010 Subject: FreeBSD unmaintained ports which are currently scheduled for deletion Message-ID: <20101007062921.DDE051CC47@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/bmp-musepack description: Musepack decoder for beep-media-player maintainer: ports@FreeBSD.org deprecated because: does not build with audio/musepack expiration date: 2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=bmp-musepack portname: audio/py-musepack description: Python module that provides the Musepack decoding interface maintainer: ports@FreeBSD.org deprecated because: does not build with audio/musepack expiration date: 2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=py-musepack portname: chinese/chinput3 description: Chinese GB2312,BIG5 code input server maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: emulators/win4bsd description: Win4BSD Virtual Machine for Windows under BSD maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased and distfile is no longer available expiration date: 2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: french/mozilla-flp description: seamonkey French Language Pack (FLP) maintainer: ports@FreeBSD.org deprecated because: www/seamonkey port is deprecated. Consider using the www/firefox-i18n. expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=mozilla-flp portname: french/xtel description: An emulator for the french Minitel maintainer: ports@FreeBSD.org deprecated because: Minitel services will be discontinued at the end of 2010. expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=xtel portname: ftp/kwebget description: A KDE frontend to wget maintainer: ports@FreeBSD.org deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=kwebget portname: misc/compat3x description: A convenience package to install the compat3x libraries maintainer: ports@FreeBSD.org status: FORBIDDEN deprecated because: Only FreeBSD 6.4+ are supported in ports expiration date: 2010-10-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x portname: multimedia/clive-utils description: Passwords, RSS parsing, and link extraction for clive maintainer: ports@FreeBSD.org status: IGNORE deprecated because: development has ceased; use multimedia/umph instead expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=clive-utils portname: net-mgmt/net-snmp4 description: An extendable SNMP implementation maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Use net-mgmt/net-snmp port instead expiration date: 2009-07-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=net-snmp4 portname: net-p2p/btpeer description: Client functionality of bittorrent protocol, network only environment maintainer: ports@FreeBSD.org deprecated because: Does not build with net/Sockets and is unmaintained. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=btpeer portname: net/Sockets-devel description: A C++ wrapper for BSD-style sockets maintainer: ports@FreeBSD.org deprecated because: Older than net/Sockets and unmaintained. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=Sockets-devel portname: net/gkrellm_snmp description: A gkrellm SNMP Monitor maintainer: ports@FreeBSD.org deprecated because: Depends of net-snmp4, that is deprecated also and will be removed soon. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=gkrellm_snmp portname: ports-mgmt/barry description: A nice KDE frontend to the ports system maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=barry portname: www/flock description: Web browser based on the browser portion of Mozilla maintainer: ports@FreeBSD.org deprecated because: Flock 3 moves from Firefox to Chromium expiration date: 2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/flock-2.5_2.log.bz2 (_Apr_11_20:29:16_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=flock portname: www/linux-flock description: The social web browser maintainer: ports@FreeBSD.org deprecated because: Flock 3 moves from Firefox to Chromium expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=linux-flock portname: www/wb0 description: Web browser for svgalib which can show pictures maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=wb0 From linimon at FreeBSD.org Thu Oct 7 06:29:29 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:29:31 2010 Subject: FreeBSD ports which are currently scheduled for deletion Message-ID: <20101007062928.5BD591CC47@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/bmp-musepack description: Musepack decoder for beep-media-player maintainer: ports@FreeBSD.org deprecated because: does not build with audio/musepack expiration date: 2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=bmp-musepack portname: audio/libmpcdec description: High quality audio compression format maintainer: multimedia@FreeBSD.org deprecated because: superseded by audio/musepack expiration date: 2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=libmpcdec portname: audio/py-musepack description: Python module that provides the Musepack decoding interface maintainer: ports@FreeBSD.org deprecated because: does not build with audio/musepack expiration date: 2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=py-musepack portname: chinese/chinput3 description: Chinese GB2312,BIG5 code input server maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: devel/p5-P4 description: P4 - Perl friendly OO interface to the Perforce SCM System maintainer: tobez@FreeBSD.org deprecated because: Depends of p5-P4-Client, which is DEPRECATED. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-P4 portname: devel/p5-P4-Client description: P4::Client - Perl extension for the Perforce API maintainer: tobez@FreeBSD.org status: BROKEN deprecated because: has been broken for 11 months expiration date: 2010-01-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-P4-Client portname: emulators/win4bsd description: Win4BSD Virtual Machine for Windows under BSD maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased and distfile is no longer available expiration date: 2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: french/mozilla-flp description: seamonkey French Language Pack (FLP) maintainer: ports@FreeBSD.org deprecated because: www/seamonkey port is deprecated. Consider using the www/firefox-i18n. expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=mozilla-flp portname: french/xtel description: An emulator for the french Minitel maintainer: ports@FreeBSD.org deprecated because: Minitel services will be discontinued at the end of 2010. expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=xtel portname: ftp/kwebget description: A KDE frontend to wget maintainer: ports@FreeBSD.org deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=kwebget portname: japanese/samba3 description: Japanese Samba maintainer: kuriyama@FreeBSD.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date: 2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=samba3 portname: misc/compat3x description: A convenience package to install the compat3x libraries maintainer: ports@FreeBSD.org status: FORBIDDEN deprecated because: Only FreeBSD 6.4+ are supported in ports expiration date: 2010-10-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x portname: multimedia/clive-utils description: Passwords, RSS parsing, and link extraction for clive maintainer: ports@FreeBSD.org status: IGNORE deprecated because: development has ceased; use multimedia/umph instead expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=clive-utils portname: net-mgmt/net-snmp4 description: An extendable SNMP implementation maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Use net-mgmt/net-snmp port instead expiration date: 2009-07-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=net-snmp4 portname: net-p2p/btpeer description: Client functionality of bittorrent protocol, network only environment maintainer: ports@FreeBSD.org deprecated because: Does not build with net/Sockets and is unmaintained. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=btpeer portname: net-p2p/pyslsk description: Client for SoulSeek filesharing system maintainer: shoesoft@gmx.net deprecated because: unmantaind upstream, use net-p2p/nicotine-plus expiration date: 2010-11-24 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2p&portname=pyslsk portname: net/Sockets-devel description: A C++ wrapper for BSD-style sockets maintainer: ports@FreeBSD.org deprecated because: Older than net/Sockets and unmaintained. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=Sockets-devel portname: net/gkrellm_snmp description: A gkrellm SNMP Monitor maintainer: ports@FreeBSD.org deprecated because: Depends of net-snmp4, that is deprecated also and will be removed soon. expiration date: 2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=gkrellm_snmp portname: net/py-samba description: Python bindings for Samba maintainer: timur@FreeBSD.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date: 2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=py-samba portname: net/samba3 description: A free SMB and CIFS client and server for UNIX maintainer: timur@FreeBSD.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date: 2010-09-01 build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/samba-3.0.37,1.log.bz2 (_Mar_17_00:31:04_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=samba3 portname: net/samba32 description: A free SMB and CIFS client and server for UNIX maintainer: timur@FreeBSD.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date: 2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=samba32 portname: net/samba33 description: A free SMB and CIFS client and server for UNIX maintainer: timur@FreeBSD.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date: 2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=samba33 portname: ports-mgmt/barry description: A nice KDE frontend to the ports system maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=barry portname: security/phpmyid description: A single user Identity Provider for the OpenID framework maintainer: dan@langille.org deprecated because: Development has ceased. expiration date: 2011-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=phpmyid portname: security/ssh2 description: Secure shell client and server for V.2 SSH protocol maintainer: marius@FreeBSD.org deprecated because: abandoned upstream expiration date: 2010-10-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=ssh2 portname: security/ssh2-nox11 description: Secure shell client and server for V.2 SSH protocol maintainer: marius@FreeBSD.org deprecated because: abandoned upstream expiration date: 2010-10-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=ssh2-nox11 portname: sysutils/sfdisk description: Standalone sysinstall's fdisk maintainer: spam@rm-rf.kiev.ua deprecated because: All supported freebsd versions now have sade, sfdisk 0.2 is outdated expiration date: 2010-10-27 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutils&portname=sfdisk portname: www/flock description: Web browser based on the browser portion of Mozilla maintainer: ports@FreeBSD.org deprecated because: Flock 3 moves from Firefox to Chromium expiration date: 2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/flock-2.5_2.log.bz2 (_Apr_11_20:29:16_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=flock portname: www/linux-flock description: The social web browser maintainer: ports@FreeBSD.org deprecated because: Flock 3 moves from Firefox to Chromium expiration date: 2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=linux-flock portname: www/trac-multirepos description: Multiple repositories Trac version maintainer: alexey@renatasystems.org deprecated because: Multiple repositories support has been merged in trunk, please use Trac 0.12+ (www/trac) instead expiration date: 2010-10-10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=trac-multirepos portname: www/wb0 description: Web browser for svgalib which can show pictures maintainer: ports@FreeBSD.org status: BROKEN deprecated because: Development has ceased. expiration date: 2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=wb0 From linimon at FreeBSD.org Thu Oct 7 06:29:34 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:29:37 2010 Subject: FreeBSD unmaintained ports which are currently marked forbidden Message-ID: <20101007062933.1D7991CC61@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as "forbidden" in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x From linimon at FreeBSD.org Thu Oct 7 06:29:34 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Oct 7 06:29:38 2010 Subject: FreeBSD ports which are currently marked forbidden Message-ID: <20101007062933.522CC1CC69@mail.droso.net> As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as "forbidden" in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: databases/gnats forbidden because: Security issues build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=gnats portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x From Alexander at Leidinger.net Thu Oct 7 07:41:52 2010 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Oct 7 07:41:55 2010 Subject: Volunteering for maintaining ICC port In-Reply-To: References: Message-ID: <20101007094138.973859ejkm7m4vc4@webmail.leidinger.net> Quoting Chris Forgeron (from Wed, 06 Oct 2010 11:45:03 -0300): > I'd like to step up and offer to modernize and maintain the ICC port > for FreeBSD. > > I may be crazy, specially as 9 is going towards Clang/LLVM. With > that move, there may be a lot of very talented people modifying the > build/make environment to work in a way that is even further removed > from ICC's working. Time will tell if this is viable or not. Today I see more value in getting ICC to run for the HPC community than for the kernel/world. When I modified the kernel build infrastructure to be able to use icc, this was more to get more warning/error messages from the compiler, than for performance reasons. The warning/error messages part should now be covered by clang and coverity, so I do not see very much value in using icc for the kernel/world anymore. > What I'm looking for is the previous port maintainer's email > address. I ran across it someplace, but can't find it now. He > mentioned having some contacts at Intel, as well as info on the > basic process and tips for the next person who may want to maintain. My contact at Intel was specific to get an commercial icc license for FreeBSD. He did not had access to the icc sources or similar. I did feature requests via the normal support channel. > I'm very interested in HPC, and I believe step one on this long road > for FreeBSD is an option to use a more optimized complier for Intel > platforms (which is all we use anyway). When icc is done, the fortran compiler is not far away (at least there where people in the past which took the work for icc and applied it to the fortran compiler)... Bye, Alexander. -- There is always something new out of Africa. -- Gaius Plinius Secundus http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From severe.grind at gmail.com Thu Oct 7 07:55:33 2010 From: severe.grind at gmail.com (Severe Grind) Date: Thu Oct 7 11:40:46 2010 Subject: questions about ports Message-ID: Hello, I have several questions concerning creating Makefile I don't understand in what sequence USE_* flags in Makefile are processed, for example - in archives/jzlib/Makefile add USE_APACHE=22, before USE_JAVA= yes USE_JAVA= 1.4+ but when i execute make install, first install JAVA. Is it possible through the Makefile to make the following: In pre-fetch stage makes dependences on flags: USE_AUTOTOOLS USE_JAVA USE_APACHE after that execute script, pre-configure which will make firebird-2.1 from sorce, then make PHP via USE? Or, it can be done by FETCH_DEPENDENDS etc.? From alp at rsu.ru Thu Oct 7 12:52:35 2010 From: alp at rsu.ru (Alexander Pyhalov) Date: Thu Oct 7 12:52:38 2010 Subject: new version of postgresql port Message-ID: <4CADC28F.7000109@rsu.ru> Hello. I've seen interesting commit message in postgresql90-server port: "Also, try to break the previous 1:1 relation between FreeBSD system and PostgreSQL versions installed. Use different PREFIX:es to install different versions on the same system." I've fetched new version of ports and tried to install postgresql84 from ports with default prefix and later - postgresql90 with non-default prefix. I managed to install postgresql90-client and postgresql84-{server,client}. However, while building postgresql90-server I received pgtest# make PREFIX=/usr/local/postgresql/9.0 install ===> postgresql-server-9.0.1 cannot install: the port wants postgresql90-client but you have postgresql84-client installed. *** Error code 1 Stop in /usr/ports/databases/postgresql90-server. The problem comes from 186 line of /usr/ports/Mk/bsd.database.mk. It must be modified to allow such things. Also, it seems that PREFIX modification is not sufficient: we should have some specific postgresql files in /usr/local/etc/periodic and several startup scripts in /usr/local/etc/rc.d. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University From girgen at FreeBSD.org Thu Oct 7 13:06:40 2010 From: girgen at FreeBSD.org (Palle Girgensohn) Date: Thu Oct 7 13:07:15 2010 Subject: new version of postgresql port In-Reply-To: <4CADC28F.7000109@rsu.ru> References: <4CADC28F.7000109@rsu.ru> Message-ID: <65236C3B101A160F514BEB2D@girgBook.local> Hi, True, it is a first shot at breaking the 1:1 relationship, it is not a solution. I think that if you install all PostgreSQL:s in different PREFIXes, it will work to install them. As you say, they should opimtally install in their own non-conflicting places without changing prefix. Lets see this as a work in progress. Cheers, Palle --On 7 oktober 2010 16.52.31 +0400 Alexander Pyhalov wrote: > Hello. > I've seen interesting commit message in postgresql90-server port: "Also, > try to break the previous 1:1 relation between FreeBSD system and > PostgreSQL versions installed. Use different PREFIX:es to install > different versions on the same system." > > I've fetched new version of ports and tried to install postgresql84 from > ports with default prefix and later - postgresql90 with non-default > prefix. > > I managed to install postgresql90-client and > postgresql84-{server,client}. However, while building postgresql90-server > I received > > pgtest# make PREFIX=/usr/local/postgresql/9.0 install > ===> postgresql-server-9.0.1 cannot install: the port wants > postgresql90-client but you have postgresql84-client installed. > *** Error code 1 > > Stop in /usr/ports/databases/postgresql90-server. > > The problem comes from 186 line of /usr/ports/Mk/bsd.database.mk. It must > be modified to allow such things. > Also, it seems that PREFIX modification is not sufficient: we should have > some specific postgresql files in /usr/local/etc/periodic and several > startup scripts in /usr/local/etc/rc.d. > > -- > Best regards, > Alexander Pyhalov, > system administrator of Computer Center of South Federal University From girgen at FreeBSD.org Thu Oct 7 13:10:54 2010 From: girgen at FreeBSD.org (Palle Girgensohn) Date: Thu Oct 7 13:11:00 2010 Subject: new version of postgresql port In-Reply-To: <65236C3B101A160F514BEB2D@girgBook.local> References: <4CADC28F.7000109@rsu.ru> <65236C3B101A160F514BEB2D@girgBook.local> Message-ID: --On 7 oktober 2010 15.06.37 +0200 Palle Girgensohn wrote: > Hi, > > True, it is a first shot at breaking the 1:1 relationship, it is not a > solution. I think that if you install all PostgreSQL:s in different > PREFIXes, it will work to install them. or if you install in prefix first... or manually install the client... > > As you say, they should optimally install in their own non-conflicting > places without changing prefix. > > Lets see this as a work in progress. > > Cheers, > Palle > > > --On 7 oktober 2010 16.52.31 +0400 Alexander Pyhalov wrote: > >> Hello. >> I've seen interesting commit message in postgresql90-server port: "Also, >> try to break the previous 1:1 relation between FreeBSD system and >> PostgreSQL versions installed. Use different PREFIX:es to install >> different versions on the same system." >> >> I've fetched new version of ports and tried to install postgresql84 from >> ports with default prefix and later - postgresql90 with non-default >> prefix. >> >> I managed to install postgresql90-client and >> postgresql84-{server,client}. However, while building postgresql90-server >> I received >> >> pgtest# make PREFIX=/usr/local/postgresql/9.0 install >> ===> postgresql-server-9.0.1 cannot install: the port wants >> postgresql90-client but you have postgresql84-client installed. >> *** Error code 1 >> >> Stop in /usr/ports/databases/postgresql90-server. >> >> The problem comes from 186 line of /usr/ports/Mk/bsd.database.mk. It must >> be modified to allow such things. >> Also, it seems that PREFIX modification is not sufficient: we should have >> some specific postgresql files in /usr/local/etc/periodic and several >> startup scripts in /usr/local/etc/rc.d. >> >> -- >> Best regards, >> Alexander Pyhalov, >> system administrator of Computer Center of South Federal University > > > From alp at rsu.ru Thu Oct 7 13:17:41 2010 From: alp at rsu.ru (Alexander Pyhalov) Date: Thu Oct 7 13:17:50 2010 Subject: new version of postgresql port In-Reply-To: <65236C3B101A160F514BEB2D@girgBook.local> References: <4CADC28F.7000109@rsu.ru> <65236C3B101A160F514BEB2D@girgBook.local> Message-ID: <4CADC872.4020905@rsu.ru> Hello. Just a notice. It seems it will not work to install different postgresql versions in different PREFIX'es at least because of bsd.databases.mk: lines 181 - 186: if we look at postgresql version in $LOCALBASE, it will be different from one from $PREFIX. Palle Girgensohn wrote: > True, it is a first shot at breaking the 1:1 relationship, it is not a > solution. I think that if you install all PostgreSQL:s in different > PREFIXes, it will work to install them. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University From linimon at lonesome.com Thu Oct 7 13:30:39 2010 From: linimon at lonesome.com (Mark Linimon) Date: Thu Oct 7 13:30:43 2010 Subject: security/openssh-portable maintainer In-Reply-To: References: Message-ID: <20101007133039.GE20270@lonesome.com> Please see ports/150493 for someone who seems to be looking at it. mcl From bob at immure.com Thu Oct 7 13:41:43 2010 From: bob at immure.com (Bob Willcox) Date: Thu Oct 7 13:41:47 2010 Subject: New mutt-devel problems with text/html processing Message-ID: <20101007132209.GA47648@rancor.immure.com> The new version of mutt-devel nolonger honors my mailcap entry to invoke lynx when it encounters a text/html file type. Instead it simply displays the raw html text. According to their UPDATING file, they say: "all text/* parts can be displayed inline without mailcap" Which is suspiciously in the realm of the problem I'm seeing. Perhaps there's now some other way of displaying text/html files w/o mailcap and an external program that I'm missing? Thanks, Bob -- Bob Willcox A great many people think they are thinking bob@immure.com when they are merely rearranging their prejudices. Austin, TX -- William James From freebsd at jdc.parodius.com Thu Oct 7 13:51:42 2010 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Thu Oct 7 13:51:50 2010 Subject: New mutt-devel problems with text/html processing In-Reply-To: <20101007132209.GA47648@rancor.immure.com> References: <20101007132209.GA47648@rancor.immure.com> Message-ID: <20101007135138.GA81306@icarus.home.lan> On Thu, Oct 07, 2010 at 08:22:09AM -0500, Bob Willcox wrote: > The new version of mutt-devel nolonger honors my mailcap entry to invoke lynx > when it encounters a text/html file type. Instead it simply displays the raw > html text. According to their UPDATING file, they say: > > "all text/* parts can be displayed inline without mailcap" > > Which is suspiciously in the realm of the problem I'm seeing. > > Perhaps there's now some other way of displaying text/html files w/o mailcap > and an external program that I'm missing? Looks relevant, with a response from Michael Elkins explaining the change: http://marc.info/?t=128477093300004&r=1&w=2 Basically, it appears that as of 1.5.21, mutt only displays text/* MIME types using its own internal engine. If you want the old behaviour, when selecting the attachment/entry, press "m". Personally I don't like this change, but I'll deal with it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From john.bayly at tipstrade.net Thu Oct 7 14:47:20 2010 From: john.bayly at tipstrade.net (John Bayly) Date: Thu Oct 7 14:47:23 2010 Subject: FreeBSD Port: py26-fail2ban-0.8.4 Message-ID: <4CADDA88.6080505@tipstrade.net> Chris Jones posted a pf action for fail2ban over a year ago with the suggestion that it should be added to the official port. I've attached a patch to include in the port which provides the bsd-pf action out of the box. Can this be included into the fail2ban port? Regards -- John Bayly Systems Administrator ------------------ TipsTrade Ltd. 16 Wornal Park, Menmarsh Road, Worminghall, Bucks. HP18 9JX T: +44 (0)1844 337 326 (Direct) M: +44 (0)7787 727 934 F: +44 (0)1844 337 337 E: john.bayly@tipstrade.net E-Mail Disclaimer Whilst TipsTrade Ltd. believes that the information is correct at the date of this e-mail, no warranty or representation is given to this effect and no responsibility can be accepted by TipsTrade Ltd. to any end users for any action taken on the basis of the information. The information contained in this electronic transmission is strictly confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on this is prohibited and may be unlawful. Please treat our information in confidence, as you would expect us to treat yours. E-mail is an inherently insecure form of communication and we do not accept liability for any unintentional damage caused to a recipient's system by this e-mail message and/or its attachments or for any unauthorised access to or interference with this e-mail that may occur. If you have received this e-mail in error, please notify the Systems Manager: mailman@tipstrade.net -------------- next part -------------- --- /dev/null 2010-10-07 16:20:29.000000000 +0100 +++ ./config/action.d/bsd-pf.conf 2010-10-07 16:20:22.000000000 +0100 @@ -0,0 +1,65 @@ +# Fail2Ban action file for use with the FreeBSD packet filter +# +# Author: Chris Jones +# Modified by: John Bayly +# + +[Definition] + +# Option: actionstart +# Notes.: command executed once at the start of Fail2Ban. +# Values: CMD +# +actionstart = + + +# Option: actionstop +# Notes.: command executed once at the end of Fail2Ban +# Values: CMD +# +actionstop = + + +# Option: actioncheck +# Notes.: command executed once before each actionban command +# Values: CMD +# +actioncheck = + + +# Option: actionban +# Notes.: command executed when banning an IP. Take care that the +# command is executed with Fail2Ban user rights. +# Tags: IP address +# number of failures +#