Re: FreeBSD Port: samba34-3.4.14
On Apr 9, 2012, at 5:26 PM, Da Rock wrote: [ ... ] 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. Sure-- a PR with a change to a port will be assigned to the maintainer to test and approve. 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? Don't know-- I don't recall having a build of Samba fail for me any time recently, but if you can confirm that a specific option causes the build failure, that would help reproduce. Note that I'd gotten the impression that you had installed libnet separately, which would be a library and not just a build dependency... 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: Time to kill php4, who stands up to save it?
On 10 Apr 2012 04:50, Cy Schubert cy.schub...@komquats.com wrote: 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. The PHP maintainer disagreed on this point last week-ish. Chris 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 ___ 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 16:30, Chuck Swiger wrote: On Apr 9, 2012, at 5:26 PM, Da Rock wrote: [ ... ] 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. Sure-- a PR with a change to a port will be assigned to the maintainer to test and approve. Ah. I wasn't aware that was the case, especially if the maintainer cannot specifically commit. 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? Don't know-- I don't recall having a build of Samba fail for me any time recently, but if you can confirm that a specific option causes the build failure, that would help reproduce. So far all the options are causing _a_ failure- swat, ads, aio, acl, fam. I'm still going, but I think thats all of them. Note that I'd gotten the impression that you had installed libnet separately, which would be a library and not just a build dependency... I am still looking into it as time permits, but I'm not sure I understand the difference? I had to install libnet separately in order to build. How does that fit in your comment? I'm still a very newbie developer so I'm not always accurately understanding the terms, I think. If I start getting these terms right I think I might just get better at this stuff in the makefiles :) ___ 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 Tue, Apr 10, 2012 at 9:57 AM, Da Rock freebsd-po...@herveybayaustralia.com.au wrote: On 04/10/12 16:30, Chuck Swiger wrote: On Apr 9, 2012, at 5:26 PM, Da Rock wrote: [ ... ] 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. Sure-- a PR with a change to a port will be assigned to the maintainer to test and approve. Ah. I wasn't aware that was the case, especially if the maintainer cannot specifically commit. Note that I'd gotten the impression that you had installed libnet separately, which would be a library and not just a build dependency... I am still looking into it as time permits, but I'm not sure I understand the difference? I had to install libnet separately in order to build. How does that fit in your comment? I'm still a very newbie developer so I'm not always accurately understanding the terms, I think. I'm not sure, which libnet you are referring to. None of the Sambas should really depend from anything called libnet. At least - externally. Also, please show the content of your /etc/make.conf, it could be that you are mangling include flags. With regards, Timur Bakeyev. ___ 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
.if ARCH / BROKEN, or 'NOT_FOR_ARCH'?
I believe there was a discussion a while back, and if you used this:
.if ${ARCH} == sparc64
BROKEN= does not compile on sparc64: assertion failed
.endif
it is POSSIBLE that cluster runs that test broken ports could fix them
(accidentally), but, wasn't the opinion that you might as well use '
NOT_FOR_ARCH(s)? '
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
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
Mikhail Tsatsenko wrote: On 08.04.2012 05:25, Mark Linimon wrote: portmgr's policy is to honor removal requests, no matter the circumstances. If someone wants to fork the last free release and host it somewhere, I would be less concerned in that case. mcl I'd like to create a fork, but I didn't find last distfile anywhere. Author removed it from his website and ftp.FreeBSD.org hosts only previous version 1.133. Does anybody have 1.135 distfile? http://ftp2.uk.freebsd.org/sites/ftp.freebsd.org/pub/FreeBSD/distfiles/%5Bpage=123%5D I just downloaded a copy for security as its a mirror 108952 bytes MD5 (imap_tools_V1.135.tar.gz) = a7c34141b7512bff69f6ea86952c83bb I will private mail you a copy. 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: FreeBSD Port: samba34-3.4.14
On 04/10/12 18:06, Timur I. Bakeyev wrote: On Tue, Apr 10, 2012 at 9:57 AM, Da Rock freebsd-po...@herveybayaustralia.com.au wrote: On 04/10/12 16:30, Chuck Swiger wrote: On Apr 9, 2012, at 5:26 PM, Da Rock wrote: [ ... ] 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. Sure-- a PR with a change to a port will be assigned to the maintainer to test and approve. Ah. I wasn't aware that was the case, especially if the maintainer cannot specifically commit. Note that I'd gotten the impression that you had installed libnet separately, which would be a library and not just a build dependency... I am still looking into it as time permits, but I'm not sure I understand the difference? I had to install libnet separately in order to build. How does that fit in your comment? I'm still a very newbie developer so I'm not always accurately understanding the terms, I think. I'm not sure, which libnet you are referring to. None of the Sambas should really depend from anything called libnet. At least - externally. Thats what I'm trying to figure out now, well, as my time permits anyway :) Also, please show the content of your /etc/make.conf, it could be that you are mangling include flags. make.conf: end of make.conf ;) Well thats not entirely accurate, I only have a USE_OPENSSL_BASE and the usual perl stuff and thats all. I get a bit of a kick out of that when someone asks if there's something in the make.conf- I only use some of the kerberos options on occasion when called for (not lately), but I learnt my lesson a long time ago: don't touch the make.conf! I created some issues in the past doing that... :) ___ 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: .if ARCH / BROKEN, or 'NOT_FOR_ARCH'?
On 4/10/12 5:16 AM, Erwin Lansing wrote:
maintainer that something is wrong.
There are quite a few large grey areas between those, but that's the
general outline.
so, if the maintainer knows something, and knows it won't ever get
fixed, then 'NOT_FOR_ARCHS' is best,
if its an unknown/ maybe osversion, something the maintainer didn't know
about, portmgr might mark it broken wrapped in a .if ${ARCH}.
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
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: .if ARCH / BROKEN, or 'NOT_FOR_ARCH'?
On 10 Apr 2012 10:33, Michael Scheidell scheid...@freebsd.org wrote:
On 4/10/12 5:16 AM, Erwin Lansing wrote:
maintainer that something is wrong.
There are quite a few large grey areas between those, but that's the
general outline.
so, if the maintainer knows something, and knows it won't ever get fixed,
then 'NOT_FOR_ARCHS' is best,
if its an unknown/ maybe osversion, something the maintainer didn't know
about, portmgr might mark it broken wrapped in a .if ${ARCH}.
Yes. Bsd.port.options.mk is required beforehand of course.
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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
I have strong opinions against this, at least for ports with an active maintainer. I really see these deprecation campaigns as treading on somebody's toes. I really like linimon's periodic emails FreeBSD ports that you maintain which are currently marked broken, which I see as a reminder that there are ports of mine that require action, but going further than that and deprecate a port that I maintain without even informing me in an official way is not what I consider collaboration. Even more so because I don't see any advantage in moving a port from BROKEN to DEPRECATED state. If a user has a working version of the port installed, he will stick to that, otherwise, installation will be frown upon anyway. I and bapt have already exchanged opinions on this subject more than once, and I would now like to see what other people (other maintainers in particular) think about it. Can we please stop this? On 2012-Apr-09, 23:51, Baptiste Daroussin wrote: bapt2012-04-09 23:51:44 UTC FreeBSD ports repository Modified files: games/8kingdoms Makefile misc/airoflash Makefile graphics/autopano-sift Makefile x11/avant-window-navigator-xfce4 Makefile lang/boo Makefile x11/cl-clx-sbcl Makefile palm/coldsyncMakefile print/cups-magicolor Makefile deskutils/doodle Makefile games/flightgear-atlas Makefile games/freeorion Makefile net-p2p/gnunet Makefile audio/gstreamer-plugins-flite Makefile x11-themes/gtk-qt-engine Makefile science/hdf Makefile databases/hypertable Makefile www/kazehakase Makefile x11-themes/kde-icons-amaranth Makefile x11-themes/kde-icons-amaranth-althaea Makefile x11-themes/kde-icons-krystaline Makefile x11-themes/kde-icons-realistic Makefile misc/kde3-i18n-hsb Makefile misc/kde3-i18n-mtMakefile misc/kde3-i18n-nso Makefile editors/komodo-edit Makefile graphics/linux-ac3d Makefile sysutils/linux-megamgr Makefile mail/lmtpd Makefile graphics/long-exposure-tools Makefile multimedia/moonlight Makefile devel/nana Makefile databases/ocaml-pgocaml Makefile math/octave-develMakefile multimedia/p5-Video-Info Makefile security/pantera Makefile databases/pear-MDB2_Driver_ibase Makefile net/perldap Makefile math/petsc Makefile math/petsc-mpich Makefile databases/pg_filedump Makefile net-im/pino Makefile chinese/cxterm Makefile net-p2p/py-bittorrent Makefile net-p2p/py-bittorrent-core Makefile games/rigsofrods Makefile databases/ruby-kyotocabinet Makefile devel/rubygem-vmcMakefile cad/salome-gui Makefile math/scilab-toolbox-sivp Makefile games/secretmaryochronicles Makefile games/sfbol Makefile graphics/solang Makefile net/spnetkit Makefile databases/sqlrelay Makefile devel/subcommander2 Makefile sysutils/thunar-volman-plugin Makefile games/wesnoth-devel Makefile x11/x3270Makefile games/xchadance Makefile x11-drivers/xf86-video-rdc Makefile deskutils/xfce4-volstatus-icon Makefile multimedia/xfmedia-remote-plugin Makefile x11-toolkits/xforms-i18n Makefile Log: Mark as deprecated and set expiration to 2012-05-10 for ports that are mark as broken for more than 6 month Revision ChangesPath 1.3 +3 -0 ports/audio/gstreamer-plugins-flite/Makefile 1.6 +3 -0 ports/cad/salome-gui/Makefile 1.35 +3 -0 ports/chinese/cxterm/Makefile 1.8 +3 -0 ports/databases/hypertable/Makefile 1.6 +3 -0 ports/databases/ocaml-pgocaml/Makefile 1.7 +3 -0 ports/databases/pear-MDB2_Driver_ibase/Makefile 1.6 +3 -0 ports/databases/pg_filedump/Makefile 1.14 +3 -0 ports/databases/ruby-kyotocabinet/Makefile 1.70 +3 -0 ports/databases/sqlrelay/Makefile 1.23 +3 -0 ports/deskutils/doodle/Makefile 1.4 +3 -0 ports/deskutils/xfce4-volstatus-icon/Makefile 1.13 +3 -0 ports/devel/nana/Makefile 1.5 +3 -0 ports/devel/rubygem-vmc/Makefile 1.26 +3 -0 ports/devel/subcommander2/Makefile 1.18 +3 -0 ports/editors/komodo-edit/Makefile 1.12 +3 -0 ports/games/8kingdoms/Makefile 1.32 +3 -0 ports/games/flightgear-atlas/Makefile 1.31 +3 -0 ports/games/freeorion/Makefile 1.16 +3 -0 ports/games/rigsofrods/Makefile 1.25 +3 -0 ports/games/secretmaryochronicles/Makefile 1.15 +3 -0 ports/games/sfbol/Makefile 1.101 +3 -0 ports/games/wesnoth-devel/Makefile 1.20 +3 -0
Re: FreeBSD Port: samba34-3.4.14
On Tue, 10 Apr 2012 19:31:13 +1000 Da Rock articulated: Also, please show the content of your /etc/make.conf, it could be that you are mangling include flags. make.conf: end of make.conf ;) Well thats not entirely accurate, I only have a USE_OPENSSL_BASE and the usual perl stuff and thats all. I get a bit of a kick out of that when someone asks if there's something in the make.conf- I only use some of the kerberos options on occasion when called for (not lately), but I learnt my lesson a long time ago: don't touch the make.conf! I created some issues in the past doing that... :) You have effectively shown us nothing. If you don't want to reveal the contents of your make.conf file, then simply say so. This poppycock nonsense about the usual perl stuff is useless. I checked, and I have exactly two lines that reference perl: # added by use.perl 2012-03-08 19:17:29 PERL_VERSION=5.14.2 Are these the usual perl stuff you are referencing? If so, then your make.conf file consists of only three lines; two if you don't count comments. Is that a correct statement? I have samba34-3.4.14 installed and it works fine and I did not have to mangle the Makefile or install additional software in order to accomplish that feat. Since you, according to you, appear to be the only user afflicted by this condition, it is readily apparent that the problem exists on your end. Your unwillingness to supply unredacted information and documentation raises doubts as to the validity of your claims. For grins, have you tried doing a make rmconfig-recursive in the samba port and then running something like: portmanager net/samba34 -f -l which would effectively rebuild samba and all of the ports it depends on? You should probably remove libnet or what ever extraneous port you installed to get samba to install in the first place first. While you are at it, move your /etc/make.conf file out of the way and have the port build with a truly empty file. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 4/10/2012 06:14, Da Rock wrote: 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? If you'd just post the error message and the compilation line that caused it, there'd be a lot of info there that can narrow things down. -- 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
I have strong opinions against this, at least for ports with an active maintainer. I really see these deprecation campaigns as treading on somebody's toes. I really like linimon's periodic emails FreeBSD ports that you maintain which are currently marked broken, which I see as a reminder that there are ports of mine that require action, but going further than that and deprecate a port that I maintain without even informing me in an official way is not what I consider collaboration. Even more so because I don't see any advantage in moving a port from BROKEN to DEPRECATED state. If a user has a working version of the port installed, he will stick to that, otherwise, installation will be frown upon anyway. I and bapt have already exchanged opinions on this subject more than once, and I would now like to see what other people (other maintainers in particular) think about it. Can we please stop this? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp As you inquire people's opinion, I would say that I find this way of proceeding a bit pushy and I consider it a good example of closed communication as I find it: - non-caring: such a commit is a detached and impersonal way to give the information to a maintainer that has not unbroken his port for a long time - dogmatic: it looks like an unwillingness to accept the maintainer's point of view or at least to hear about his work on maintaining the port - superior: deprecating without prior communication with the maintainer stresses differences in status between portmgr/committer and maintainers Hence I am not surprised when you say you feel someone is treading on your toes, and more generally I fear this does not do any good to maintainer's motivation and commitment to the project. On the other hand I also believe those deprecation actions are necessary and I thank bapt for his work on this. To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: 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 marked as broken for a period of at least six months. As a maintainer of one of those ports, feel free to remove the deprecate status if you need more time to fix the breakage and do not hesitate to contact portmgr@ if you need additional information on this policy. I hope this brings something to the discussion. -- Frederic Culot cu...@freebsd.org pgpx1R7qscdc8.pgp Description: PGP signature
Re: .if ARCH / BROKEN, or 'NOT_FOR_ARCH'?
On Tue, Apr 10, 2012 at 11:16:19AM +0200, Erwin Lansing wrote: BROKEN is for less permanent or unknown breakage, like errors on pointyhat where the one analyzing the logs doesn't have detailed knownledge of each port and its breakage, and is used as a warning to users, so they don't try to build a port and get disappointed after installing all its dependencies, and as a message to the maintainer that something is wrong. As a further clarification, we have a switch that we can throw on pointyhat to try to build things with BROKEN: '-trybroken'. We don't often do this, but should probably start doing so more often now that we have the hardware. Once something is marked with ARCHS it will not be attempted on pointyhat no matter what. 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
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. 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
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 06:56, Mark Linimon wrote: On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. That's exactly my point: maintainers are very likely to know the situation by the time these deprecation campaigns set off, and committing to their ports without prior approval is in contrast with our policy. I still do not see the necessity to deprecate maintained ports, even though a port might be maintained as broken for a long period of time. The maintainer might be waiting for something to happen either upstream or in our infrastructure, which could release the port from brokenness. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpWY2RVMXgYc.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Mark Linimon lini...@lonesome.com On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. I strongly agree with the bapt's action to set some ports that are often broken to deprecated or even some of them that are broken for a long time to deprecated. There is nothing more frustrating than try to install a port an it doesn't fetch or doesn't build. Also to avoid some problems with fetch, we can use public distfile or even mirror the tarball/zipball(or whatever it is) in a fashion way. And in my opinion a bunch of new emails with some warnings could be useful just in the beggining, after while those ports maybe will have still problem to be fetch. Maybe something that might work would be something quite similar like the QAT provided by itetcu a long time ago, send some message to the developers@ list and wait for someone to fix that. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
Hi Chris, 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 OK, if people will repack rather than loosing; though creating replacement ports wrappers with new names will be hastle not only for freebsd.org, but also for FreeBSD users who may have their own overlay trees of eg ports/*/Makefile.local with SUBDIR+= a port. (hastle of variant SUBDIR += needing to be maintained for different uname -r bases for various local hosts). When a generic author causes trouble, trying to unpublish published sources, I suggest FreeBSD insures itself against more trouble by adding a list of people prepared to witness they saw the published sources with attached licence, at which URL, on what date. Witnesses need not be users of a port, nor programmers (so a wider pool). If some witnesses are non users of a port, it may be seen as more independent. Maintainer of mail/imaptools (Boris) is welcome to add me to a list of witnesses: Distfile:\ SIZE:\ MD5:\ URL:\ WITNESS:\ CONTACT:\ DATE imap_tools_V1.135.tar.gz:\ 108952:\ a7c34141b7512bff69f6ea86952c83bb:\ http://ftp7.freebsd.org/sites/ftp.freebsd.org/pub/FreeBSD/ports/distfiles/%5Bpage=123%5D \ - \ http://ftp7.freebsd.org/sites/ftp.freebsd.org/pub/FreeBSD/ports/distfiles/imap_tools_V1.135.tar.gz\ Julian H. Stacey:\ http://berklix.com/~jhs/contact/:\ Tue Apr 10 14:30:17 CEST 2012 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 02:21:42PM +0200, Pietro Cerutti wrote: The maintainer might be waiting for something to happen either upstream or in our infrastructure, which could release the port from brokenness. Putting a comment about that in the Makefile might go a long way to minimizing frustration all around. 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
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 09:32:47AM -0300, Marcelo Araujo wrote: There is nothing more frustrating than try to install a port and it doesn't fetch or doesn't build. That's been my main point of worry all along (more personally than as portmgr), and why I think the deprecation campaigns do more good than harm. Obviously some folks do not agree :-/ We'll have to agree to disagree on that point. I'll also note that not every port that gets deprecated actually gets removed. In English we have this saying the carrot and the stick. I'd certainly rather use the carrot than the stick, but sometimes the stick (setting DEPRECATED) is effective. Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. 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
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 09:32, Marcelo Araujo wrote: 2012/4/10 Mark Linimon lini...@lonesome.com On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. I strongly agree with the bapt's action to set some ports that are often broken to deprecated or even some of them that are broken for a long time to deprecated. There is nothing more frustrating than try to install a port an it doesn't fetch or doesn't build. I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpbmPvdVo2NB.pgp Description: PGP signature
Re: mail/imaptools: port removal at Monday April 9th
On 10.04.2012 16:34, Julian H. Stacey wrote: Maintainer of mail/imaptools (Boris) is welcome to add me to a list of witnesses: Thanks for your help but there is no need at the particular case. The port was fixed yesterday and the distfile is at FreeBSD distfile server. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/imaptools: port removal at Monday April 9th
Boris Samorodov wrote: On 10.04.2012 16:34, Julian H. Stacey wrote: Maintainer of mail/imaptools (Boris) is welcome to add me to a list of witnesses: Thanks for your help but there is no need at the particular case. The port was fixed yesterday and the distfile is at FreeBSD distfile server. OK, thanks. 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 14:44, Pietro Cerutti wrote: I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In theory, it tickles administrators to look for alternatives if they depend on the port or fork a working copy of the port in their local infrastructure and provides a deadline for this to action to be completed. BROKEN is supposed to be a temporary state, leading to a fix. DEPRECATED is a temporary state leading to removal. -- 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 CADLo839aXhhAM-uf-eUvEaQpc7b=vTkJt3diLSMn9CY+Wv5saQ@mail.gmail.c om , Chris Rees writes: --0015174c427a04100904bd4d714b Content-Type: text/plain; charset=ISO-8859-1 On 10 Apr 2012 04:50, Cy Schubert cy.schub...@komquats.com wrote: 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. The PHP maintainer disagreed on this point last week-ish. Then ports which break should be removed as well. One of my websites broke when I upgraded PHP from 5.3 to 5.5. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. This is awkward. We're not supposed to spend our time rolling back unwanted commits. We're supposed to make sure that a commit made to someone else's port is wanted in the first place. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Well, as I see it, marking a port as DEPRECATED is kind of a final decision. I.e., I'll start to look at alternatives and forget about it. If you mark a port as DEPRECATED and 12 hours later I back off your chance with a comment I'm working on it, a really unconsistent and confused message will pass. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpW8cZ2RQyFm.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 09:04, Jerry wrote: On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. For the record, the port in question was fetchable / buildable / runnable. For some reason, some python class sometimes doesn't get byte-compiled, resulting in packaging (PLIST) errors. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgppnRkZc7urK.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Pietro Cerutti g...@freebsd.org On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. That is a very good point, if someone send a PR, nobody need to make it DEPRECATED, but unfortunately, sometimes it doesn’t happens. And as I can see, almost all ports that switch from BROKEN to DEPRECATED, is because no one send a PR. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. This is awkward. We're not supposed to spend our time rolling back unwanted commits. We're supposed to make sure that a commit made to someone else's port is wanted in the first place. I agree with you, maybe there is another better way. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Well, as I see it, marking a port as DEPRECATED is kind of a final decision. I.e., I'll start to look at alternatives and forget about it. If you mark a port as DEPRECATED and 12 hours later I back off your chance with a comment I'm working on it, a really unconsistent and confused message will pass. Here depends! Usually when I need a port that is set as DEPRECATED, first I take a look why it is set like this, and then, I start to looking for an alternative in case I can’t fix that port or it is really obsolete because the software is dead for some reason. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 16:47, Pietro Cerutti wrote: On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. Not to discredit your work in any way, but 6 months of being BROKEN can be classified as maintainer timeout in the general case. Also given the error you're seeing it sounds like a very specific case that shouldn't affect the generally solid deprecation policy that is in effect - the bulk of the deprecation cases are upstream abandonware with an equally absent maintainer. I check the list of deprecated ports regularly when I feel nostalgic for blink, java-based rollover menus and News from the previous millennium. On a more constructive note - why don't you mention the specific port? Maybe some of us on the list can help you figure out why some files sometimes don't get byte compiled or provide you with a work-around solution (dynamically generated plist comes to mind). -- 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 10 April 2012 14:56, Pietro Cerutti g...@freebsd.org wrote: On 2012-Apr-10, 09:04, Jerry wrote: On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. For the record, the port in question was fetchable / buildable / runnable. For some reason, some python class sometimes doesn't get byte-compiled, resulting in packaging (PLIST) errors. BUILD_ENV= PYTHONDONTWRITEBYTECODE=yes usually helps. 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 17:17, Mel Flynn wrote:
On 4/10/2012 16:47, Pietro Cerutti wrote:
On 2012-Apr-10, 11:20, Marcelo Araujo wrote:
2012/4/10 Pietro Cerutti g...@freebsd.org
I might agree on that. But how is a DEPRECATED port better than a BROKEN
one in this regard?
In my point of view, no make sense have a bunch of ports that actually
doesn't works or because there is a fetch problem or even it is set as
BROKEN. Who never was upset when need and find a port but it is BROKEN for
some reason, In my view, have a port BROKEN or haven't it, is the same. Of
course, I mean when a port is BROKEN for all plataforms as well as for all
FreeBSD version.
I agree on that.
I believe set it as DEPRECATED is a good way to make the maintainer take
attention to fix it soon as possible, due he has put effort to insert this
software on the ports tree in the past.
What about submitting a PR, as we usually do for anything else? If it's
ok to wait 15 days (maintainer timeout) to commit an update to a port
that brings in important features, it is even more so to wait to
deprecate one.
Not to discredit your work in any way, but 6 months of being BROKEN can
be classified as maintainer timeout in the general case.
That's your opinion, and while I agree on the general idea that six
months is a lot, I would like actions / behavior to be based on policies
previously agreed upon and documented.
15 days -- implicit approval (maintainer timeout) is documented
6 months -- implicit deprecation of broken ports is not
On a more constructive note - why don't you mention the specific port?
Maybe some of us on the list can help you figure out why some files
sometimes don't get byte compiled or provide you with a work-around
solution (dynamically generated plist comes to mind).
The port is editors/komodo-edit. sbz@ gave me a hint about forcing
byte-compilation of all the python classes using
post-install:
@${PYTHON_CMD} -O -m compileall -q ${DATADIR} || true
@${PYTHON_CMD} -m compileall -q ${DATADIR} || true
but I never got to commit that. I'm testing it right now and unbreak the
port very soon. Thank you!
--
Pietro Cerutti
The FreeBSD Project
g...@freebsd.org
PGP Public Key:
http://gahr.ch/pgp
pgp8vdcN6uHEQ.pgp
Description: PGP signature
FreeBSD Port: chromium-18.0.1025.151
Hi, this mail is from Japan.
I tried to portupgrade
from 'chromium-17.0.963.79' to 'chromium-18.0.1025.151',
only to fail.
OS : FreeBSD/amd64 8.2-RELEASE-p6
hiroshi@freud~% uname -a
FreeBSD freud.jp-media-lab.com.local 8.2-RELEASE-p6 FreeBSD
8.2-RELEASE-p6 #8: Tue Jan 31 01:34:38 JST 2012
hiro...@freud.jp-media-lab.com.local:/usr/obj/usr/src/sys/GENERIC amd64
Options for chromium 18.0.1025.151 is like that:
CODECS
Compile and enable patented codecs like H.264 X
GCONF
Use GConf2 for preferences X
PULSEAUDIO
Enable Pulse Audio support X
CLANG
Build Chromium with Clang
GCC46
Build Chromium with GCC 4.6+X
DEBUG
Compile with debug symbols and verbose output
For compiler, gcc46 and clang show the same error.
gcc46 :
In file included from ./base/memory/weak_ptr.h:63:0,
from ./media/audio/pulse/pulse_output.h:25,
from media/audio/pulse/pulse_output.cc:5:
./base/logging.h: In function 'std::string* logging::CheckEQImpl(const
t1, const t2, const char*) [with t1 =
scoped_refptrbase::MessageLoopProxy, t2 = MessageLoop*, std::string =
std::basi
c_stringchar]':
media/audio/pulse/pulse_output.cc:129:3: instantiated from here
./base/logging.h:555:1: error: no match for 'operator==' in 'v1 == v2'
./base/logging.h:555:1: note: candidates are:
./base/logging.h:555:1: note: operator==(MessageLoop*, MessageLoop*)
built-in
./base/logging.h:555:1: note: no known conversion for argument 1 from
'const scoped_refptrbase::MessageLoopProxy' to 'MessageLoop*'
./base/logging.h:555:1: note: operator==(base::MessageLoopProxy*,
base::MessageLoopProxy*) built-in
./base/logging.h:555:1: note: no known conversion for argument 2 from
'MessageLoop* const' to 'base::MessageLoopProxy*'
./base/memory/scoped_ptr.h:224:6: note: templateclass C bool
operator==(C*, const scoped_ptrC)
./base/memory/scoped_ptr.h:336:6: note: templateclass C bool
operator==(C*, const scoped_arrayC)
./base/memory/scoped_ptr.h:462:6: note: templateclass C, class FP bool
operator==(C*, const scoped_ptr_mallocC, FP)
./base/logging.h:555:1: warning: control reaches end of non-void
function [-Wreturn-type]
gmake: ***
[out/Release/obj.target/media/media/audio/pulse/pulse_output.o] エラー 1
gmake: *** 未完了のジョブを待っています
*** Error code 1
Stop in /usr/ports/www/chromium.
*** Error code 1
clang :
DEFINE_CHECK_OP_IMPL(EQ, ==)
^[[0;1;32m~^~~
^[[0m./base/logging.h:548:12: note: expanded from:
if (v1 op v2) return NULL; \
^[[0;1;32m~~ ^ ~~
^[[0m^[[1mmedia/audio/pulse/pulse_output.cc:129:3: ^[[0m^[[0;1;30mnote:
^[[0min instantiation of function template specialization
'logging::CheckEQImplscoped_refptrbase::MessageLoopProxy, M
essageLoop *' requested here^[[0m
DCHECK_EQ(stream-manager_-GetMessageLoop(), MessageLoop::current());
^[[0;1;32m ^
^[[0m./base/logging.h:744:31: note: expanded from:
#define DCHECK_EQ(val1, val2) DCHECK_OP(EQ, ==, val1, val2)
^[[0;1;32m ^
^[[0m./base/logging.h:719:9: note: expanded from:
logging::Check##name##Impl((val1), (val2), \
^[[0;1;32m^
^[[0m^[[1m./base/memory/scoped_ptr.h:224:6: ^[[0m^[[0;1;30mnote:
^[[0mcandidate template ignored: failed template argument deduction^[[0m
bool operator==(C* p1, const scoped_ptrC p2) {
^[[0;1;32m ^
^[[0m^[[1m./base/memory/scoped_ptr.h:336:6: ^[[0m^[[0;1;30mnote:
^[[0mcandidate template ignored: failed template argument deduction^[[0m
bool operator==(C* p1, const scoped_arrayC p2) {
^[[0;1;32m ^
^[[0m^[[1m./base/memory/scoped_ptr.h:462:6: ^[[0m^[[0;1;30mnote:
^[[0mcandidate template ignored: failed template argument deduction^[[0m
bool operator==(C* p, const scoped_ptr_mallocC, FP b) {
^[[0;1;32m ^
^[[0m1 error generated.
gmake: ***
[out/Release/obj.target/media/media/audio/pulse/pulse_output.o] エラー 1
gmake: *** 未完了のジョブを待っています
*** Error code 1
Stop in /usr/ports/www/chromium.
*** Error code 1
In my environment, pulseaudio is newest.
pulseaudio-0.9.23 Sound server for UNIX
Please fix.
Yours sincerely,
Hiroshi Saeki.
___
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
Hi, Mark Linimon wrote: 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. OK Perhaps the legal system in Germany is less broken than the US. I certainly hope so. I believe Britain ( maybe Germany) have a lower percentage of lawyers than USA. 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. Been there, Done that, Got the T shirt ;-) I've been personaly legaly threatened even just managing a company's law suit against a Canadian debtor. Learnt: Their game: intimidation, their message: Our lawyer is richer than your lawyer I've sued ( won) for debt: Learnt: Even trivial law cases can take Years. I've helped head a club with events with risk to life, Learnt: Insurance! Have you enquired for FreeBSD if the Foundation could afford insurance for key named central staff ? It's something companies that donate might relate to, if added to Foundation web, might attract extra donations. I've helped run a club that left volunteers in office too long till they felt the club owed them, some got fractious some burnt out. Learnt: That's why boards of directors have compulsory resignation by rotation. (with option to stand for re-election) The name 'Manager' asserts both authority responsibility. As portsmgr can't take decisions with risk of responsibility, ... Change portmgr@ to match reality, (port-adm@ maybe ?). 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: autodetecting dependencies
On 04/09/12 21:56, Mel Flynn wrote: 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. Package B doesn't seem to offer any extra functionality to port A. I ended up going with option 3, because it turned out to be easier than I thought it would be. ___ 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
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. Also not to mention the uncommon dis-courtesy of someone publishing code free to the world, gaining users, then retracting code [to go commercial]. 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
upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
I updated my stable/8 slice before upgrading the installed ports on my laptop, so when I ran portmaster, it was running: FreeBSD g1-227.catwhisker.org 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #360 234093M: Tue Apr 10 04:22:16 PDT 2012 r...@g1-227.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY i386 There were no whines from portmaster that I can see. (I did the upgrade within script, and can provide the typescript to interested folks.) But now, if I run svnversion, I see: d134(8.3-P)[33] /usr/local/bin/svnversion /usr/src/ svn: E200030: sqlite: callback requested query abort svn: E200030: sqlite: callback requested query abort d134(8.3-P)[34] svn appears to generally be working, otherwise. Should I rebuild the subversion port? Is there an ABI change that may require a corresponding change in subversion? The phase of the moon jsut the wrong color? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpTRxFMqnhlm.pgp Description: PGP signature
Re: upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
On 4/10/2012 18:11, David Wolfskill wrote: svn: E200030: sqlite: callback requested query abort Does svn cleanup in /usr/src fix the issue? -- 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: upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
On Tue, Apr 10, 2012 at 06:22:24PM +0200, Mel Flynn wrote: On 4/10/2012 18:11, David Wolfskill wrote: svn: E200030: sqlite: callback requested query abort Does svn cleanup in /usr/src fix the issue? ... Huh -- it seems to do precisely that -- thanks! Is this something that should be done ... often? Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpVjy9ezcpxv.pgp Description: PGP signature
Re: upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
On 4/10/2012 18:26, David Wolfskill wrote: On Tue, Apr 10, 2012 at 06:22:24PM +0200, Mel Flynn wrote: On 4/10/2012 18:11, David Wolfskill wrote: svn: E200030: sqlite: callback requested query abort Does svn cleanup in /usr/src fix the issue? ... Huh -- it seems to do precisely that -- thanks! Is this something that should be done ... often? I suspect this is something that svn upgrade should have taken care of as I've only seen the issue with working directories checked out with pre-1.7 subversion and subsequently upgraded to the new format. But I don't have enough data points or insight into subversion code to make that definitive. -- 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: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 04:47:41PM +0200, Pietro Cerutti wrote: On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. That is a good option, next time I'll do that for maintained ports that are mark as BROKEN. I didn't intend to be disrespectful on other's work, I'm sorry if that is the fealing some could get, next time, I'll be more careful about this and send the deprecation stuff as PR. regards, Bapt pgpm1695GMUu0.pgp Description: PGP signature
Re: autodetecting dependencies
Stephen Montgomery-Smith wrote:
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
In my opinion, it's best to use the OPTIONS framework and to avoid automatic
detection entirely. Consider this problem:
http://docs.freebsd.org/cgi/mid.cgi?20120304190922.GA58789
For your example, I would add this line to port A's Makefile:
OPTIONS=PORT_B Enable Port B off
I would then replace the automatic detection part of port A's Makefile with
something like this:
.if defined(WITH_PORT_B) !defined(WITHOUT_PORT_B)
RUN_DEPENDS+= portb-1.0:${PORTSDIR}/category/portb
.endif
So, if you don't want port A built with package B as a dependency, you'd use the default on port
A's OPTIONS dialog screen, otherwise, you'd put a check beside PORT_B.
--
A.J. Kehoe IV (Nanoman) | /\ ASCII Ribbon Campaign
Nanoman's Company | \ / - No HTML/RTF in E-mail
E-mail: nano...@nanoman.ca | X- No proprietary attachments
WWW: http://www.nanoman.ca/ | / \ - Respect for open standards
smime.p7s
Description: S/MIME cryptographic signature
I found this great article on Jobhawk.com
Hi freebsd-ports@freebsd.org I found the article How To Save On Electricity Bills http://payspree.com/6702/jhakz I thought may interest you. You can find it at [1]http://www.jobhawk.com/blank.php http://payspree.com/6702/jhakz References 1. http://www.jobhawk.com/blank.php ___ 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
Memory leak in xfce4-netload-plugin and xfce4-systemload-plugin - only on FreeBSD?
I see a memory leak (or something like that) in the ports sysutils/xfce4-netload-plugin sysutils/xfce4-systemload-plugin The ports start out using less than 100M of memory (taken from the SIZE column in top), but over a short time (about a week or two) grows to almost 1000M. An example is my workstation, which has been up for about three days now: tingo@kg-v2$ uname -a FreeBSD kg-v2.kg4.no 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #5: Fri Apr 6 21:35:20 CEST 2012 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 tingo@kg-v2$ uptime 8:49PM up 3 days, 22:19, 20 users, load averages: 0.12, 0.21, 0.23 xfce4-netload-plugin is now at 670M and xfce4-systemload-plugin is at 509M Ports on the machine are updated: root@kg-v2# pv | grep netload xfce4-netload-plugin-1.1.0 = up-to-date with port root@kg-v2# pv | grep systemload xfce4-systemload-plugin-1.0.0_2 = up-to-date with port Does anyone else see this? I reported it originally in the Forums[1] , but didn't get any response. And how can I diagnose the problem further, so that I can provide a better error report References: 1) http://forums.freebsd.org/showthread.php?t=28698 -- Regards, Torfinn Ingolfsen ___ 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
Completely offtopic, but we have a nice unauthenticated remote root here: http://www.samba.org/samba/security/CVE-2012-1182 -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg version -Xs foo shows all ports, not just foo
BUZI pkg version -Xs Image CalculiX-2.4 = GraphicsMagick-1.1.15_3,1 = ImageMagick-6.7.5.10 = ORBit2-2.14.19 = OpenEXR-1.6.1_3= R-2.14.2 = ^C BUZI The man page seems to indicate that the above options should only show ImageMagick. What am I doing wrong? Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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 9 April 2012 22:02, Stephen Montgomery-Smith step...@missouri.edu wrote: 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.) The current answer for automagical dependencies is to fix (not cripple) the configure option to not autodetect for package B. Any port which currently has automatic detection is buggy and should be fixed. You can use the OPTIONS framework to enable or disable the option. -- Eitan Adler ___ 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
Memory leak in xfce4-netload-plugin and xfce4-systemload-plugin - only on FreeBSD?
Reason for resending: It doesn't look like the ports@ address works. -- Forwarded message -- From: Torfinn Ingolfsen tin...@gmail.com Date: Tue, Apr 10, 2012 at 9:05 PM Subject: Memory leak in xfce4-netload-plugin and xfce4-systemload-plugin - only on FreeBSD? To: FreeBSD Ports po...@freebsd.org Cc: de...@freebsd.org, thorsten.grei...@web.de I see a memory leak (or something like that) in the ports sysutils/xfce4-netload-plugin sysutils/xfce4-systemload-plugin The ports start out using less than 100M of memory (taken from the SIZE column in top), but over a short time (about a week or two) grows to almost 1000M. An example is my workstation, which has been up for about three days now: tingo@kg-v2$ uname -a FreeBSD kg-v2.kg4.no 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #5: Fri Apr 6 21:35:20 CEST 2012 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 tingo@kg-v2$ uptime 8:49PM up 3 days, 22:19, 20 users, load averages: 0.12, 0.21, 0.23 xfce4-netload-plugin is now at 670M and xfce4-systemload-plugin is at 509M Ports on the machine are updated: root@kg-v2# pv | grep netload xfce4-netload-plugin-1.1.0 = up-to-date with port root@kg-v2# pv | grep systemload xfce4-systemload-plugin-1.0.0_2 = up-to-date with port Does anyone else see this? I reported it originally in the Forums[1] , but didn't get any response. And how can I diagnose the problem further, so that I can provide a better error report References: 1) http://forums.freebsd.org/showthread.php?t=28698 -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg version -Xs foo shows all ports, not just foo
On Tue, Apr 10, 2012 at 08:55:41PM +0100, Anton Shterenlikht wrote: BUZI pkg version -Xs Image CalculiX-2.4 = GraphicsMagick-1.1.15_3,1 = ImageMagick-6.7.5.10 = ORBit2-2.14.19 = OpenEXR-1.6.1_3= R-2.14.2 = ^C BUZI The man page seems to indicate that the above options should only show ImageMagick. What am I doing wrong? I'm not sure if it's a bug or a feature, but pkg_version seems to want the arguments separately. $ pkg_version -X -s Image ImageMagick = $ Although in this particular case, 'pkg_version -s Image' (without the '-X') seems to do just fine, as well. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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
octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
Hi Stephen, and ports@
I would like to ask you the final check of our patch against
octave and octave-forge-* port. I also e-mail to port@ since
it is a sweeping commit.
Now ports tree has been unfrozen.
Octave 3.6.1 is out and I would like to update with attached patch.
Since this is an API change to octave, it seemed appropriate to me to
bump the portrevision of every single octave-forge port. But a few of
the ports needed further patches to make them work: ad,
communications, parallel, odepkg. es package doesn't build so we switched off.
Sorry, we are not sure all octave-forge-* ports will run without problems.
Thanks
Nakata Maho
From: Erwin Lansing er...@freebsd.org
Subject: [HEADSUP]: Ports tree unfrozen
Date: Tue, 10 Apr 2012 00:26:53 +0200
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
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt
? ports/math/octave-forge-ad/files
? ports/math/octave-forge-odepkg/files
? ports/math/octave-forge-parallel/files/patch-configure
Index: ports/benchmarks/octave-forge-benchmark/Makefile
===
RCS file: /home/pcvs/ports/benchmarks/octave-forge-benchmark/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- ports/benchmarks/octave-forge-benchmark/Makefile30 Jun 2011 20:55:39
- 1.9
+++ ports/benchmarks/octave-forge-benchmark/Makefile11 Apr 2012 01:43:39
-
@@ -7,7 +7,7 @@
PORTNAME= octave-forge-benchmark
PORTVERSION= 1.1.1
-PORTREVISION= 5
+PORTREVISION= 6
CATEGORIES=benchmarks math
MAINTAINER=step...@freebsd.org
Index: ports/math/octave/Makefile
===
RCS file: /home/pcvs/ports/math/octave/Makefile,v
retrieving revision 1.137
diff -u -r1.137 Makefile
--- ports/math/octave/Makefile 14 Feb 2012 12:45:24 - 1.137
+++ ports/math/octave/Makefile 11 Apr 2012 01:43:39 -
@@ -6,8 +6,7 @@
#
PORTNAME= octave
-PORTVERSION= 3.4.3
-PORTREVISION= 2
+PORTVERSION= 3.6.1
CATEGORIES=math
MASTER_SITES= ftp://ftp.gnu.org/gnu/octave/ \
ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/
@@ -126,7 +125,7 @@
@${FIND} -s $d -type d -depth | \
${SED} -e 's,^${PREFIX}/,@dirrm ,' ${WRKDIR}/PLIST
.endfor
-.for d in ${PREFIX}/libexec/octave/${OCTAVE_VERSION}
${PREFIX}/libexec/octave/api-v45+ ${PREFIX}/libexec/octave/site
${PREFIX}/lib/octave/site
+.for d in ${PREFIX}/libexec/octave/${OCTAVE_VERSION}
${PREFIX}/libexec/octave/api-v45+ ${PREFIX}/libexec/octave/api-v48+
${PREFIX}/libexec/octave/site ${PREFIX}/lib/octave/site
@${FIND} -s $d -type d -empty | \
${SED} -e 's,^${PREFIX}/,@exec ${MKDIR} %D/,' \
-e 's,$$, 2/dev/null || true,' ${WRKDIR}/PLIST
Index: ports/math/octave/distinfo
===
RCS file: /home/pcvs/ports/math/octave/distinfo,v
retrieving revision 1.35
diff -u -r1.35 distinfo
--- ports/math/octave/distinfo 8 Nov 2011 09:28:31 - 1.35
+++ ports/math/octave/distinfo 11 Apr 2012 01:43:39 -
@@ -1,2 +1,2 @@
-SHA256 (octave-3.4.3.tar.bz2) =
94d119cc93a38465e9c00dd36b9cc063abbda7ae8cb39407cf88a2bddc9dc148
-SIZE (octave-3.4.3.tar.bz2) = 15085117
+SHA256 (octave-3.6.1.tar.bz2) =
f8073ee7570d8ff78864868027ef1e08409a78e0798d8800fac67e7e714eadf6
+SIZE (octave-3.6.1.tar.bz2) = 15387369
Index: ports/math/octave-forge/Makefile
===
RCS file: /home/pcvs/ports/math/octave-forge/Makefile,v
retrieving revision 1.53
diff -u -r1.53 Makefile
--- ports/math/octave-forge/Makefile16 Feb 2012 15:57:02 - 1.53
+++ ports/math/octave-forge/Makefile11 Apr 2012 01:43:39 -
@@ -7,7 +7,7 @@
PORTNAME= octave-forge
PORTVERSION= 20120206
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES=math
MASTER_SITES= #none
DISTFILES= #none
@@ -32,7 +32,7 @@
DICOM Install package: dicom On \
ECONOMETRICS Install package: econometrics On \
ENGINE Install package: engine On \
- ES Install package: es On \
+ ES Install package: es Off \
FENV Install package: fenv On \
FITS Install package: fits On \
FINANCIAL Install package: financial On \
Index: ports/math/octave-forge-actuarial/Makefile
===
RCS file: /home/pcvs/ports/math/octave-forge-actuarial/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- ports/math/octave-forge-actuarial/Makefile 21 Nov 2011 01:17:33 -
1.5
+++
Re: FreeBSD Port: samba34-3.4.14
On Tue, Apr 10, 2012 at 11:35:46PM +0400, Ruslan Mahmatkhanov wrote: Completely offtopic, but we have a nice unauthenticated remote root here: http://www.samba.org/samba/security/CVE-2012-1182 It looks like the ports have just been updated. Please let the update mirror out and then update quickly! This one is particularly nasty. -- WXS ___ 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: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
On 04/10/2012 08:51 PM, Maho NAKATA wrote: Hi Stephen, and ports@ I would like to ask you the final check of our patch against octave and octave-forge-* port. I also e-mail to port@ since it is a sweeping commit. Now ports tree has been unfrozen. Octave 3.6.1 is out and I would like to update with attached patch. Let me add that after this patch has been committed by Maho, I will update quite a few of the octave-forge ports: anything dated on or after 2012-03-01 on http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The reason I am delaying these updates until octave-3.6.1 is installed is that these updates only seem to work with octave-3.6.0 and later. The reason I am telling people this is that when the octave port has been updated, you might like to wait a short while before rebuilding the octave-forge ports until I have committed these later updates. 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: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
Hi Stephen, Done from my side, now it's your turn! Best Nakata Maho From: Stephen Montgomery-Smith step...@missouri.edu Subject: Re: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly. Date: Tue, 10 Apr 2012 21:31:28 -0500 On 04/10/2012 08:51 PM, Maho NAKATA wrote: Hi Stephen, and ports@ I would like to ask you the final check of our patch against octave and octave-forge-* port. I also e-mail to port@ since it is a sweeping commit. Now ports tree has been unfrozen. Octave 3.6.1 is out and I would like to update with attached patch. Let me add that after this patch has been committed by Maho, I will update quite a few of the octave-forge ports: anything dated on or after 2012-03-01 on http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The reason I am delaying these updates until octave-3.6.1 is installed is that these updates only seem to work with octave-3.6.0 and later. The reason I am telling people this is that when the octave port has been updated, you might like to wait a short while before rebuilding the octave-forge ports until I have committed these later updates. 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: FreeBSD Port: samba34-3.4.14
Wesley Shields wrote on 11.04.2012 06:05: On Tue, Apr 10, 2012 at 11:35:46PM +0400, Ruslan Mahmatkhanov wrote: Completely offtopic, but we have a nice unauthenticated remote root here: http://www.samba.org/samba/security/CVE-2012-1182 It looks like the ports have just been updated. Please let the update mirror out and then update quickly! This one is particularly nasty. -- WXS Yes, that was extremely quick update. Thank you Xin Li! But at least for samba34 I was forced to fetch tarball manually because of Moved permanently messages. Some MASTER_SITE_SUBDIR updates should be done to make it work. Thanks. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
I'm now done as well. On 04/10/2012 10:05 PM, Maho NAKATA wrote: Hi Stephen, Done from my side, now it's your turn! Best Nakata Maho From: Stephen Montgomery-Smithstep...@missouri.edu Subject: Re: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly. Date: Tue, 10 Apr 2012 21:31:28 -0500 On 04/10/2012 08:51 PM, Maho NAKATA wrote: Hi Stephen, and ports@ I would like to ask you the final check of our patch against octave and octave-forge-* port. I also e-mail to port@ since it is a sweeping commit. Now ports tree has been unfrozen. Octave 3.6.1 is out and I would like to update with attached patch. Let me add that after this patch has been committed by Maho, I will update quite a few of the octave-forge ports: anything dated on or after 2012-03-01 on http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The reason I am delaying these updates until octave-3.6.1 is installed is that these updates only seem to work with octave-3.6.0 and later. The reason I am telling people this is that when the octave port has been updated, you might like to wait a short while before rebuilding the octave-forge ports until I have committed these later updates. 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
