Re: mail/imaptools: port removal at Monday April 9th
On 8 April 2012 15:28, Mikhail Tsatsenko m.tsatse...@gmail.com wrote: You might have luck with a Debian mirror, and there's always inurl: I have tried it already, but had no luck. Currently I created a fork of 1.133 version (named imaputils to avoid name collision with original software). Can anybody having ports commit bit import it in the ports tree, please. In case if somebody will provide most recent free version of imaptools I'll submit an update. New port added, with minor changes. Thanks! Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
New port added, with minor changes. Thanks! Chris Thank you There is a PR 166757 which may be closed now. -- Mikhail ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
On 9 April 2012 08:16, Mikhail Tsatsenko m.tsatse...@gmail.com wrote: New port added, with minor changes. Thanks! Chris Thank you There is a PR 166757 which may be closed now. Closed, thanks. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: BUILD_DEPENDS and libraries -- how to express build-time-only dependency on library?
On 1 April 2012 17:27, Lev Serebryakov l...@freebsd.org wrote:
Hello, Chris.
You wrote 1 апреля 2012 г., 21:22:36:
Is it possible to express build-time-only dependency on library?
BUILD_DEPENDS=${LOCALBASE}/lib/libfoo.a:${PORTSDIR}/foo/libfoo ?
It works, but here are other problem: if iconv or gettext or
something like this are used, they added after all libs anyway :(
Well, don't iconv and gettext require it? In that case it needs
registering. Otherwise iconv and gettext should have their deps
fixed
My port builds with static linkage. After port is built and
installed, it doesn't need any other ports in system. But if I use
USE_ICONV, and, later do something like this:
OLD_LIB_DEPENDS:=
${LIB_DEPENDS:S!^!${LOCALBASE}/lib/lib!:C!(\.[0-9]+)?:!.a:!}
BUILD_DEPENDS+= ${OLD_LIB_DEPENDS}
LIB_DEPENDS=
I have proper BUILD_DEPENDS which is built from MY libraries, but
iconv, gettext Ko are in LIB_DEPENDS anyway :(
USE_GETTEXT could be set to build but not USE_ICONV and USE_BDB.
And all my manipulations with *_DEPENDS goes before effect of these
options :(
I suppose bsd.port.pre.mk doesn't help here, does it?
USE_ICONV= yes
USE_BDB= yes
.include bsd.port.pre.mk
# mess with dependencies
.include bsd.port.post.mk
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Current unassigned ports problem reports
(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/166782[MAINTAINER] databases/sqlite3: update to 3.7.11 o ports/166778revise port: lang/urweb f ports/166777some warnings with net-mgmt/mrtg o ports/166776update net-mgmt/mrtg f ports/166768[maintainer update] math/ess 5.12.8 - 12.04.00 o ports/166756[PATCH] databases/cassandra: update to 1.0.9 o ports/166754[maintainer] [patch] lang/harbour: update to 3.0.0 and f ports/166752mail/imapsync: update to 1.487 f ports/166749[PATCH]deskutils/cairo-dock-plugins 2.3.0~3_2 AlsaMixe f ports/166748[PATCH]deskutils/cairo-dock 2.3.0~3 not sound(Resend) f ports/166747[PATCH]deskutils/cairo-dock-plugins 2.3.0~3_2 GMenu er o ports/166745[UPDATE] graphics/mupdf to 1.0rc1 o ports/166743[UPDATE] x11-fonts/hanazono-fonts-ttf to 20120202 f ports/166733Update and adopt port: sysutils/condor o ports/166728New port: science/fvcom-mpi o ports/166726New port: science/fvcom o ports/166725New port: science/dlpoly-classic o ports/166722graphics/ufraw: port fails to build if GTK option is o ports/166716New ports: chinese/fcitx-libpinyin chinese/libpinyin o ports/166711New port: japanese/fcitx-mozc - Mozc Japanese input me o ports/166689[UPDATE] chinese/fcitx and its addons to 4.2.1 o ports/166680Maintainer update: sysutils/desktop-installer o ports/166670New Port :converter/libb64 Base64 Encoding/Decoding Ro o ports/19[PATCH] mail/roundcube-sieverules: update to 1.16 f ports/16sysutils/qjail update -b removes uglyperlhack o ports/15java/jboss-as: JBoss 7.1 new port o ports/12www/asterisk-stat - pgsql select substring() problem o ports/11maintainer update: devel/pysvn o ports/166658audio/rplay: rplayd crashes on amd64 o ports/166645emulators/virtio-kmod: rxcsum breaks checksum for loca f ports/166607[PATCH]deskutils/cairo-dock-plugins 2.3.0~3_2 AlsaMixe f ports/166606[PATCH]deskutils/cairo-dock 2.3.0~3 not sound o ports/166593[MAINTAINER] ports-mgmt/porttools: CVS expansion of $F o ports/166587Maintainer update: sysutils/radmind o ports/166572New port: deskutils/devd-notifier - a simple daemon f ports/166534finance/openerp-server, finance/openerp-web: OpenERP m o ports/166522lang/f77: Fortran 77 compiler always exits with error o ports/166506www/py-prewikka bug using [auth cgi] o ports/166504security/prelude-pflogger fails to compile o ports/166438New port: devel/libarms: library for developing SMFv2/ o ports/166435Update devel/libedit with local patches f ports/166388security/libgcrypt is broken o ports/166341devel/valgrind crash on binaries built with gcc46 f ports/166313please, update net-mgmt/zabbix-server to 1.8.11 o ports/166275[new port] sysutils/automount devd(8) based automounte o ports/166248sendmail dies of signal 11 on freebsd in a virtualbox o ports/166244[maintainer update] databases/powerarchitect version u o ports/166243New port databases/jdbc-oracle10g: JDBD driver for Ora o ports/166237New port: devel/arduino-glcd: A Graphical LCD library o ports/166209[PATCH] cad/verilog-mode.el port update f ports/166204Update port: print/reportlab2 Fix fonts search path f ports/166136[patch] databases/freetds-devel properly link tds modu o ports/166117add knobs in math/grace to make features selectable an o ports/166058New port sysutils/py-XenAPI f ports/166055[patch] x11/fireflies does not build with x11-toolkits o ports/166006Problem with mail/postfix and mail/mailman integration f ports/166004www/squid31 3.1.19 crashes on first request o ports/165926[patch] deskutils/cairo-dock-plugins fix many bugs o ports/165925[patch] deskutils/cairo-dock fix many bugs f ports/165918unable to build net-mgmt/zenoss with subversion o ports/165900[new port] emulators/linux_base-c6 f ports/165899devel/wand-libconfig and devel/libconfig conflict (sam f ports/165898deskutils/cairo-dock-plugins 2.3.0~3_2 (The icon effec o ports/165865
Re: mail/imaptools: port removal at Monday April 9th
From: Chris Rees cr...@freebsd.org Well, whatever he says, he can't revoke the license of what's already been distributed. # Copyright (c) 2008 Rick Sanders rfs9...@earthlink.net # # # # Permission to use, copy, modify, and distribute this software for any# # purpose with or without fee is hereby granted, provided that the above # # copyright notice and this permission notice appear in all copies.# ... Exactly ! From: Mark Linimon lini...@lonesome.com portmgr's policy is to honor removal requests, no matter the circumstances. Irresponsible. Real 'Managers' shoulder responsibility. So ... In /usr/ports/Mk/bsd.port.mk, define a warning variable after NO_CDROM, NO_PACKAGE, [ RESTRICTED_FILES ], with example: WARNING+=Generic author tried to retrospectively withdraw sources. # Maintainer suggest see files/... http://... Allow individual ports Maintainers to indicate status of issues. Allow individual installers to decide their Own take on issues, Not Yours ! - Ports wrappers belong to FreeBSD, not generic authors. - Sources once published can't be unpublished. (IMO No need of a new project port name to excuse retention). - Distfiles if not on freebsd.org site are not even our problem. portmgr should retain respect by dumping a foolish policy. sticking to technical avoiding programmers guesses fears about laws, or assumptions USA law controls global law or whatever else. Stay technical. The globe has 196 countries with their own legal jurisdictions, individual installers should be able to make their own decision on law risks morality as localy appropriate. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
On 9 April 2012 17:49, Julian H. Stacey j...@berklix.com wrote: From: Chris Rees cr...@freebsd.org Well, whatever he says, he can't revoke the license of what's already been distributed. # Copyright (c) 2008 Rick Sanders rfs9...@earthlink.net # # # # Permission to use, copy, modify, and distribute this software for any # # purpose with or without fee is hereby granted, provided that the above # # copyright notice and this permission notice appear in all copies. # ... Exactly ! From: Mark Linimon lini...@lonesome.com portmgr's policy is to honor removal requests, no matter the circumstances. Irresponsible. Real 'Managers' shoulder responsibility. So ... In /usr/ports/Mk/bsd.port.mk, define a warning variable after NO_CDROM, NO_PACKAGE, [ RESTRICTED_FILES ], with example: WARNING+=Generic author tried to retrospectively withdraw sources. # Maintainer suggest see files/... http://... Allow individual ports Maintainers to indicate status of issues. Allow individual installers to decide their Own take on issues, Not Yours ! - Ports wrappers belong to FreeBSD, not generic authors. - Sources once published can't be unpublished. (IMO No need of a new project port name to excuse retention). - Distfiles if not on freebsd.org site are not even our problem. portmgr should retain respect by dumping a foolish policy. sticking to technical avoiding programmers guesses fears about laws, or assumptions USA law controls global law or whatever else. Stay technical. The globe has 196 countries with their own legal jurisdictions, individual installers should be able to make their own decision on law risks morality as localy appropriate. Hi Julian, I understand your viewpoint, but given the horrible experiences certain people had on this kind of thing (you were around then, too), I think that the 'make a fork and port that instead' is perfectly reasonable. At least then the software has a maintainer. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
On 9 April 2012 17:49, Julian H. Stacey j...@berklix.com wrote: portmgr's policy is to honor removal requests, no matter the circumstances. Irresponsible. Real 'Managers' shoulder responsibility. So ... Real managers get paid. Real managers get paid by companies. Real managers get paid by companies with legal departments who will defend them from frivolous lawsuits, and pay them during the period of time while the frivolous lawsuit works its way through the US court system. I have given thousands of hours of free work to this project. I'm damned sure not going to incur any legal liability on top of that, even if due to someone wanting to take an unreasonable position. Perhaps the legal system in Germany is less broken than the US. I certainly hope so. But until you sit in my seat, and have been threatened with lawsuits in the past for equally unreasonable situations, you simply don't know what you're talking about. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Time to kill php4, who stands up to save it?
Hi, Apparently we are still sheaping php4 and his friends, which is EOLed by upstream since 2008. on the ports tree we have two consumer of php4, once which seems to be able to run with php5 according to upstream website and the second which already have a newer version using php5 in the ports tree. So if you really have reason to save php4, please stand up. regards, Bapt pgpIpJBMnRqS2.pgp Description: PGP signature
Re: mail/imaptools: port removal at Monday April 9th
On 04/10/12 03:49, Julian H. Stacey wrote: From: Chris Reescr...@freebsd.org Well, whatever he says, he can't revoke the license of what's already been distributed. # Copyright (c) 2008 Rick Sandersrfs9...@earthlink.net # # # # Permission to use, copy, modify, and distribute this software for any# # purpose with or without fee is hereby granted, provided that the above # # copyright notice and this permission notice appear in all copies.# ... Exactly ! From: Mark Linimonlini...@lonesome.com portmgr's policy is to honor removal requests, no matter the circumstances. Irresponsible. Real 'Managers' shoulder responsibility. So ... In /usr/ports/Mk/bsd.port.mk, define a warning variable after NO_CDROM, NO_PACKAGE, [ RESTRICTED_FILES ], with example: WARNING+=Generic author tried to retrospectively withdraw sources. #Maintainer suggest see files/... http://... Allow individual ports Maintainers to indicate status of issues. Allow individual installers to decide their Own take on issues, Not Yours ! - Ports wrappers belong to FreeBSD, not generic authors. - Sources once published can't be unpublished. (IMO No need of a new project port name to excuse retention). - Distfiles if not on freebsd.org site are not even our problem. portmgr should retain respect by dumping a foolish policy. sticking to technical avoiding programmers guesses fears about laws, or assumptions USA law controls global law or whatever else. Stay technical. The globe has 196 countries with their own legal jurisdictions, individual installers should be able to make their own decision on law risks morality as localy appropriate. To stick my nose where it probably doesn't belong: indeed. This is one area where linux annoys the most for that very reason. Let the user decide and bear the responsibility. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[HEADSUP]: Ports tree unfrozen
With the final builds starting for 8.3-RELEASE, the feature freeze has been lifted. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpWcaWRtDn78.pgp Description: PGP signature
Re: mail/imaptools: port removal at Monday April 9th
On 04/09/2012 15:21, Da Rock wrote: To stick my nose where it probably doesn't belong: indeed. This is one area where linux annoys the most for that very reason. Let the user decide and bear the responsibility. If you want to put up a server with all the encumbered software and let people download it, go right ahead. Meanwhile, the project has chosen (wisely) not to run the risk of legal entanglements. ... not to mention the common courtesy of following the wishes of those who created the software in the first place. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
On 04/10/12 08:30, Doug Barton wrote: On 04/09/2012 15:21, Da Rock wrote: To stick my nose where it probably doesn't belong: indeed. This is one area where linux annoys the most for that very reason. Let the user decide and bear the responsibility. If you want to put up a server with all the encumbered software and let people download it, go right ahead. Meanwhile, the project has chosen (wisely) not to run the risk of legal entanglements. ... not to mention the common courtesy of following the wishes of those who created the software in the first place. Part of the beauty of FreeBSD is ports, so that the user downloads from the source (or somewhere appropriate) and _not_ the project's servers. The only possible area for the 'entanglement' is the fact the framework lists where to download from. As for the wishes of the author... plain english is plain english- when you relinquish a right you can't un-relinquish it (if that is actually a word). Even the legal system has trouble (or simply cannot do it) with putting the cat back in the bag, unbolting the horse, etc, when there is a legal right to do so; to say nothing about this case. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
I think it's great that you have thoughts and ideas about this topic. Feel free to put them into practice. Meanwhile, the FreeBSD project has different thoughts and ideas about this topic, and is overwhelmingly unlikely to change them. So, time to move on. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 04/08/12 09:59, Da Rock wrote: On 04/08/12 00:02, Chris Rees wrote: On 7 April 2012 13:51, Da Rockfreebsd-po...@herveybayaustralia.com.au wrote: On 04/06/12 13:20, Timur I. Bakeyev wrote: Hi! Can you show the build output? Port should't directly dipend from anything like this. Sorry, it was on a clients system and I couldn't get the info across. I can only say for sure that installing libnet fixed the issue. The build error was an undeclared function or const (most likely const) that was supplied by libnet. Sorry I can't tell you any more information; I emailed this to notify of the fix, and for others if they come across the issue in the future. Googling was what put me on to this fix as well. If you could give some idea of the site that advised this, that could probably help too. Again, my apologies. Let me try this again and see if I can be a little more organised with my description. This was a clean, fresh install on an amd64 (Atom cpu, although I did try on a real cpu too). I tried 3.6 first, it didn't build. Then I tried 3.5, when that didn't work (same error) I looked at the handbook and it was still on 3.4, and during my googling I noticed that there could be an issue with incompatibility with the libsmbclient; so I reverted to 3.4. It didn't build either, and they all had the same error. So I googled some more on this error, but there wasn't much on it at all. I did notice a lot of comments on samba, tdb, and libnet, and there was a clue in the error of a libnet dependency (sorry I just can't remember, so much has happened in the 24 hr period); so I tried installing libnet and then built samba 3.4 (to avoid further issues and conflicts) and presto! it all built. That was the day prior to my post, and I figured someone could run a clean build and find this as well; failing that, someone would come across this again in the future. As you can see it wasn't anything in particular that set me on this, just a hunch I followed and lucked out on a resolution, but it worked :) I hope that helps someone... To drag this up again, I was thinking about the number of cases I've found like this recently, and I was considering what the most appropriate action to take here. This one is obviously controversial, and I didn't have the time to do more or test further, but for future reference I'd like some clarification. I'd say a PR is not really appropriate as a response to an issue such as this (unless the maintainer offers no response at all), but should I create a patch to assist the maintainer? Or is that over doing it? If I were to create a patch, what is the correct (usable) procedure? And for something like this it would be an adjustment to BUILD_DEPENDS, correct? Thanks for the clarification guys. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
Hi-- On Apr 9, 2012, at 4:01 PM, Da Rock wrote: To drag this up again, I was thinking about the number of cases I've found like this recently, and I was considering what the most appropriate action to take here. This one is obviously controversial, and I didn't have the time to do more or test further, but for future reference I'd like some clarification. I'd say a PR is not really appropriate as a response to an issue such as this (unless the maintainer offers no response at all), but should I create a patch to assist the maintainer? Or is that over doing it? If I were to create a patch, what is the correct (usable) procedure? And for something like this it would be an adjustment to BUILD_DEPENDS, correct? If you think there is a missing dependency, then doing send-pr with the fix is a reasonable procedure. However, you might first want to look into what was different in your case from pointyhat, since the builds of samba-3.x worked fine: http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba34-3.4.14.log http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba35-3.5.11.log http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba36-3.6.3.log Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 04/10/12 09:12, Chuck Swiger wrote: Hi-- On Apr 9, 2012, at 4:01 PM, Da Rock wrote: To drag this up again, I was thinking about the number of cases I've found like this recently, and I was considering what the most appropriate action to take here. This one is obviously controversial, and I didn't have the time to do more or test further, but for future reference I'd like some clarification. I'd say a PR is not really appropriate as a response to an issue such as this (unless the maintainer offers no response at all), but should I create a patch to assist the maintainer? Or is that over doing it? If I were to create a patch, what is the correct (usable) procedure? And for something like this it would be an adjustment to BUILD_DEPENDS, correct? If you think there is a missing dependency, then doing send-pr with the fix is a reasonable procedure. I was only thinking the maintainer might want to know and fix and test themselves before commit. I know I would as a maintainer. However, you might first want to look into what was different in your case from pointyhat, since the builds of samba-3.x worked fine: http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba34-3.4.14.log http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba35-3.5.11.log http://pointyhat.freebsd.org/errorlogs/amd64-9-latest-logs/samba36-3.6.3.log Hmmm. You're right. I can narrow it down to the SWAT or AIO option (most likely given the obvious network connection there), but it could be ADS, ACL, or FAM; but I doubt that very much. You have me intrigued now, I have to look into it to know :) So what should the patch look like? Am I correct in my understanding of the BUILD_DEPENDS, or have I chased a goose on that one? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
autodetecting dependencies
So suppose we are building port A. It turns out that the configure in port A autodetects whether package B is present or not. It will build either way. But if built with package B, it will not operate without it. So suppose I build port A on machine X which has package B installed. Then I create a package from A, and copy the package to machine Y. Machine Y does not have package B installed, and so when package A is installed, it doesn't work on machine Y. What are the accepted ways of handling this? 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. (Sometimes this can be done using a suitable CONFIGURE_ARGS, but not in my particular situation.) I prefer the answer (1). But I am interested in other people's opinions. One problem with (2) or (3) is that the creator of the port might never find out which packages could be autodetected by port A's configure without performing an exhaustive search of the source code of A. Thanks, Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autodetecting dependencies
On 4/10/2012 04:02, Stephen Montgomery-Smith wrote: 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. (Sometimes this can be done using a suitable CONFIGURE_ARGS, but not in my particular situation.) 4. Add OPTION PACKAGE_B. And cripple configure through EXTRA_PATCH if set to off. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 4/10/2012 02:26, Da Rock wrote: So what should the patch look like? Am I correct in my understanding of the BUILD_DEPENDS, or have I chased a goose on that one? I'd like to divert your attention to the libnet source directory in samba distribution. It's built by default and integrated into pretty much every binary through libnetapi. Your focus should shift to the compilation error itself, your solution of installing the port libnet masked the actual problem. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Time to kill php4, who stands up to save it?
In message 20120409220442.ge90...@azathoth.lan, Baptiste Daroussin writes: Hi, Apparently we are still sheaping php4 and his friends, which is EOLed by upstream since 2008. on the ports tree we have two consumer of php4, once which seems to be able t o run with php5 according to upstream website and the second which already have a newer version using php5 in the ports tree. So if you really have reason to save php4, please stand up. I see no reason to keep php4. On a tangential issue, php52 should probably be kept around, at least for now. I know of at least one port (www/gallery) which breaks under the latest PHP due to deprecated function calls which make a mess of websites using the port (warning messages that should go to a logfile are displayed on the webpage itself). I think these ports should be deprecated, giving users ample time to migrate to newer ports (e.g. migration of gallery to gallery3 is somewhat involved). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 04/10/12 13:14, Mel Flynn wrote: On 4/10/2012 02:26, Da Rock wrote: So what should the patch look like? Am I correct in my understanding of the BUILD_DEPENDS, or have I chased a goose on that one? I'd like to divert your attention to the libnet source directory in samba distribution. It's built by default and integrated into pretty much every binary through libnetapi. Your focus should shift to the compilation error itself, your solution of installing the port libnet masked the actual problem. I'll look into it then. I'm still trying to determine what sets it off. I'm fairly sure ADS is a major factor, though simply disabling it merely grows another failure elsewhere... :/ I'll start posting the logs soon. Is there a particular reason why a dependency on libnet is an issue? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
