Re: No working IDE in FreeBSD!
On 2/26/2012 11:48 AM, O. Hartmann wrote: On 02/23/12 14:38, Eduardo Morras wrote: At 12:22 23/02/2012, O. Hartmann wrote: Several time ago I tried to do some development within an IDE, not even for lectural and educational purposes. Since most of our software is written in C/C++ and OpenCL, I highly prefered ANJUTA, since this IDE was highly customizable, flexible and even FreeBSD's ancient outdated version in the ports suited our needs. Anjuta does not compile anymore for a long time. I do not know why, I filed a PR (ports/161494). So I was looking for an alternative. I looked for some alternatives. The IDE should be configurable to use CLANG. ECLIPSE is to large and it does not fit my purpose. I tried devel/CodeBlocks, but CodeBlocks is narrowminded in terms of configuration of an alternative compiler and I find it really hard and not intuitiv to reconfigure the usage of CLANG. devel/anjuta is broken, so no chance. I also tried KDevelop, since many of our Linux based scientists feel good having this very popular IDE, but it is marked "broken" on FreeBSD. Before I waste more time on searching for a suitable IDE apart ANJUTA, I'd like to ask people here what alternative they would suggest if the focus is devel/anjuta. Eclipse is no way, KDevelop is broken, CodeBlocks is incapable of being easily adapted to CLANG. Befor people tend to start a flame war: yes, I'm fine with vi and I'm also fine with vim/gvim, but our students need to have the opportunity to work with an IDE and our projects are partially that large, so an IDE is needed. Thanks a lot for your patience and recommendations in advance. Codelite, i use it and works fine (Freebsd 8.2) with Clang. Version on ports is 3.0 not 3.5. On the webpage you have information about how to configure for use with clang/llvm. Codelite looks nice. But why is codelite setup in editors/codelite and not in devel/codelite as other IDEs? By the way, do all IDEs supported by FreeBSD suffer from being outdated and aged eons? CodeLite 3.5 is at this very moment the most recent version and claims to provide a much better LLVM/CLANG support. Not all IDEs on FreeBSD are outdated. The GNAT Programming Studio in FreeBSD is at version 5.0.1, which is the latest that can be built with an Ada-enabled version of gcc 4.6. http://www.freshports.org/devel/gps home page: http://www.adacore.com/home/products/gnatpro/toolsuite/gps/ It's multi-language. The languages with graphical support by default are Ada, C, and C++. You can add support for any other language by added xml configuration files (see documentation). I haven't tried, but I suspect the configuration can be set to use clang for the C/C++ languages. It deserves a look by those seeking a language IDEs. John ___ 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"
Steps to prune and add Ada ports?
Before opening an Problem Reports, I thought I'd run what I'd like to do by the FreeBSD ports mailing list. The following five ports need to be deleted: lang/gnat-doc-html lang/gnat-doc-info lang/gnat-doc-ps lang/gnat-doc-texi lang/gnat-doc-tex Reason: These provide documentation for GNAT 3.15p, which was deleted from the ports tree more than 5 years ago. Should I submit a PR to get this done? There is no maintainer listed for them. Secondly, I've been working for months to bring GNAT, the GNAT Programming Studio (GPS), the Ada Web Server (AWS), and other packages to all four major BSDs. The website tracking the progress of this work is http://www.dragonlace.net I've already developed seven FreeBSD ports for the following: GNAT-AUX (based on GCC 4.6) GPS 5.0 AWS 2.10w GPRBuild-AUX GnatPython GTKAda 2.22 XML/Ada 4.1w The last six ports on the list don't currently exist in the tree. "GNAT AUX" is a significantly patched version of GNAT that passes all tests (~3200) on both AMD64 and i386. It should replace the gnat-gcc44 port which doesn't produce a usable AMD64 GNAT (The port maintainer agreed on IRC #Ada). Additionally, gnat-gcc42 should be pruned because it doesn't build on FreeBSD 8. The other FSF GNAT port is gnat-gcc43. It builds on FreeBSD 7 and 8, but only for the i386 platform. I don't know how well it passes the regression testsuite. There could be a debate if there's value in having gnat-gcc43 in the tree once GNAT-AUX is available. Some of the proposed ports require "GPRBuild" to build, and the version of GPRBuild I'm providing requires GNAT AUX. It will not build on GNAT GPL or any gnat-gcc both due to changes in the compiler and hardcoded executable names. This would also be a reason to prune the older GNAT ports as they would not be able to build many (or any?) of the Ada software in the ports tree anyway. What's the best approach to add these 7 Ada ports (again, already developed) and start removing the useless ones? I'm willing to maintain the all the ports that I submit. Regards, John ___ 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: Steps to prune and add Ada ports?
Thanks Wen, I submitted PR 153676 to delete the old gnat doc ports. Regarding the seven new ports, should I write one PR to cover all seven, or seven individual PRs? Some are dependencies of others, so it kind of makes sense to submit them together. John wen heping wrote: Better to send PRs to add or remove these ports. I am intersting to take. wen 2011/1/4 John Marino : Before opening an Problem Reports, I thought I'd run what I'd like to do by the FreeBSD ports mailing list. The following five ports need to be deleted: lang/gnat-doc-html lang/gnat-doc-info lang/gnat-doc-ps lang/gnat-doc-texi lang/gnat-doc-tex Reason: These provide documentation for GNAT 3.15p, which was deleted from the ports tree more than 5 years ago. Should I submit a PR to get this done? There is no maintainer listed for them. Secondly, I've been working for months to bring GNAT, the GNAT Programming Studio (GPS), the Ada Web Server (AWS), and other packages to all four major BSDs. The website tracking the progress of this work is http://www.dragonlace.net I've already developed seven FreeBSD ports for the following: GNAT-AUX (based on GCC 4.6) GPS 5.0 AWS 2.10w GPRBuild-AUX GnatPython GTKAda 2.22 XML/Ada 4.1w The last six ports on the list don't currently exist in the tree. "GNAT AUX" is a significantly patched version of GNAT that passes all tests (~3200) on both AMD64 and i386. It should replace the gnat-gcc44 port which doesn't produce a usable AMD64 GNAT (The port maintainer agreed on IRC #Ada). Additionally, gnat-gcc42 should be pruned because it doesn't build on FreeBSD 8. The other FSF GNAT port is gnat-gcc43. It builds on FreeBSD 7 and 8, but only for the i386 platform. I don't know how well it passes the regression testsuite. There could be a debate if there's value in having gnat-gcc43 in the tree once GNAT-AUX is available. Some of the proposed ports require "GPRBuild" to build, and the version of GPRBuild I'm providing requires GNAT AUX. It will not build on GNAT GPL or any gnat-gcc both due to changes in the compiler and hardcoded executable names. This would also be a reason to prune the older GNAT ports as they would not be able to build many (or any?) of the Ada software in the ports tree anyway. What's the best approach to add these 7 Ada ports (again, already developed) and start removing the useless ones? I'm willing to maintain the all the ports that I submit. Regards, John ___ 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: Steps to prune and add Ada ports?
So I will submit all 7 ports at once. My intention is just to attach a compressed tarball to the PR that contain all 7 ports inside. Is that alright? Thanks, John On 1/5/2011 12:53 AM, wen heping wrote: 2011/1/4 John Marino: Thanks Wen, I submitted PR 153676 to delete the old gnat doc ports. Regarding the seven new ports, should I write one PR to cover all seven, or seven individual PRs? Some are dependencies of others, so it kind of makes Both OK. wen sense to submit them together. John wen heping wrote: Better to send PRs to add or remove these ports. I am intersting to take. wen 2011/1/4 John Marino: Before opening an Problem Reports, I thought I'd run what I'd like to do by the FreeBSD ports mailing list. The following five ports need to be deleted: lang/gnat-doc-html lang/gnat-doc-info lang/gnat-doc-ps lang/gnat-doc-texi lang/gnat-doc-tex Reason: These provide documentation for GNAT 3.15p, which was deleted from the ports tree more than 5 years ago. Should I submit a PR to get this done? There is no maintainer listed for them. Secondly, I've been working for months to bring GNAT, the GNAT Programming Studio (GPS), the Ada Web Server (AWS), and other packages to all four major BSDs. The website tracking the progress of this work is http://www.dragonlace.net I've already developed seven FreeBSD ports for the following: GNAT-AUX (based on GCC 4.6) GPS 5.0 AWS 2.10w GPRBuild-AUX GnatPython GTKAda 2.22 XML/Ada 4.1w The last six ports on the list don't currently exist in the tree. "GNAT AUX" is a significantly patched version of GNAT that passes all tests (~3200) on both AMD64 and i386. It should replace the gnat-gcc44 port which doesn't produce a usable AMD64 GNAT (The port maintainer agreed on IRC #Ada). Additionally, gnat-gcc42 should be pruned because it doesn't build on FreeBSD 8. The other FSF GNAT port is gnat-gcc43. It builds on FreeBSD 7 and 8, but only for the i386 platform. I don't know how well it passes the regression testsuite. There could be a debate if there's value in having gnat-gcc43 in the tree once GNAT-AUX is available. Some of the proposed ports require "GPRBuild" to build, and the version of GPRBuild I'm providing requires GNAT AUX. It will not build on GNAT GPL or any gnat-gcc both due to changes in the compiler and hardcoded executable names. This would also be a reason to prune the older GNAT ports as they would not be able to build many (or any?) of the Ada software in the ports tree anyway. What's the best approach to add these 7 Ada ports (again, already developed) and start removing the useless ones? I'm willing to maintain the all the ports that I submit. Regards, John ___ 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" ___ 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: Steps to prune and add Ada ports?
Okay, I'll figure out how to do that. Now, would it be one shar per port? as opposed to one shar to cover all 7 ports? John On 1/9/2011 6:43 PM, jhelf...@experts-exchange.com wrote: Customarily, new ports should have a shell archive, or shar, attached to the PR. -jgh So I will submit all 7 ports at once. My intention is just to attach a compressed tarball to the PR that contain all 7 ports inside. Is that alright? Thanks, John On 1/5/2011 12:53 AM, wen heping wrote: 2011/1/4 John Marino: Thanks Wen, I submitted PR 153676 to delete the old gnat doc ports. Regarding the seven new ports, should I write one PR to cover all seven, or seven individual PRs? Some are dependencies of others, so it kind of makes Both OK. wen sense to submit them together. John wen heping wrote: Better to send PRs to add or remove these ports. I am intersting to take. wen 2011/1/4 John Marino: Before opening an Problem Reports, I thought I'd run what I'd like to do by the FreeBSD ports mailing list. The following five ports need to be deleted: lang/gnat-doc-html lang/gnat-doc-info lang/gnat-doc-ps lang/gnat-doc-texi lang/gnat-doc-tex Reason: These provide documentation for GNAT 3.15p, which was deleted from the ports tree more than 5 years ago. Should I submit a PR to get this done? There is no maintainer listed for them. Secondly, I've been working for months to bring GNAT, the GNAT Programming Studio (GPS), the Ada Web Server (AWS), and other packages to all four major BSDs. The website tracking the progress of this work is http://www.dragonlace.net I've already developed seven FreeBSD ports for the following: GNAT-AUX (based on GCC 4.6) GPS 5.0 AWS 2.10w GPRBuild-AUX GnatPython GTKAda 2.22 XML/Ada 4.1w The last six ports on the list don't currently exist in the tree. "GNAT AUX" is a significantly patched version of GNAT that passes all tests (~3200) on both AMD64 and i386. It should replace the gnat-gcc44 port which doesn't produce a usable AMD64 GNAT (The port maintainer agreed on IRC #Ada). Additionally, gnat-gcc42 should be pruned because it doesn't build on FreeBSD 8. The other FSF GNAT port is gnat-gcc43. It builds on FreeBSD 7 and 8, but only for the i386 platform. I don't know how well it passes the regression testsuite. There could be a debate if there's value in having gnat-gcc43 in the tree once GNAT-AUX is available. Some of the proposed ports require "GPRBuild" to build, and the version of GPRBuild I'm providing requires GNAT AUX. It will not build on GNAT GPL or any gnat-gcc both due to changes in the compiler and hardcoded executable names. This would also be a reason to prune the older GNAT ports as they would not be able to build many (or any?) of the Ada software in the ports tree anyway. What's the best approach to add these 7 Ada ports (again, already developed) and start removing the useless ones? I'm willing to maintain the all the ports that I submit. Regards, John ___ 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" ___ 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" ___ 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: Steps to prune and add Ada ports?
Disregard. I am creating 7 separate shar files. On 1/9/2011 7:05 PM, John Marino wrote: Okay, I'll figure out how to do that. Now, would it be one shar per port? as opposed to one shar to cover all 7 ports? John On 1/9/2011 6:43 PM, jhelf...@experts-exchange.com wrote: Customarily, new ports should have a shell archive, or shar, attached to the PR. -jgh ___ 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: multimedia/libxine (libxine-1.1.19_1) (fetch error)
I'm new to this mailing list. Just so I understand what just happened... 1) David Southwell found a problem with the libxine port missing a source file 2) He posted what he found here, expecting it to be fixed (presumably immediately) Wouldn't the proper procedure be to document this in a problem report so it can go through the established process? What I can't get a feel for is how long it actually takes to process a PR. So is what David did ok for this type of problem, or he is just circumventing the process? Serious question. Thanks, John On 1/16/2011 11:30 AM, David Southwell wrote: Thanks in advance for a fix for: ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for libxine-1.1.19_2 => xine-vdpau.bz2 doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from LOCAL/makc. fetch: LOCAL/makcxine-vdpau.bz2: Invalid URL scheme => Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/xine-vdpau.bz2: File unavailable (e.g., file not found, no access) => Couldn't fetch it - please try to retrieve this => port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/ports/multimedia/libxine. *** Error code 1 Stop in /usr/ports/multimedia/libxine. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20110116-17387-2evu20-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=libxine-1.1.19_1 UPGRADE_PORT_VER=1.1.19_1 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! multimedia/libxine (libxine-1.1.19_1) (fetch error) Photographic Artist Permanent Installations& Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography& Official Portraiture Combined darkroom& digital creations & Systems Adminstrator for the vizion2000.net network ___ 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: multimedia/libxine (libxine-1.1.19_1) (fetch error)
On 1/16/2011 12:18 PM, David Southwell wrote: Please do not top post Initially reporting to list and getting feedback ensures that PRs are not filed unecessarily David Oh sorry. I interpreted "Thanks in advance for a fix for:" as the equivalent of an imperative statement to "fix it." rather than an interrogative one asking for feedback about what to do. ___ 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"
How are [MAINTAINER] patches handled and why aren't PRs FIFO?
Since we're already in the mood to discuss FreeBSD ports issues, maybe somebody can clear something up for me. Several days ago, I submitted a patch for a port I maintain: ports/156541 "[MAINTAINER] Upgrade lang/gnat-aux to release version and add C++" Nobody has touched it, but many other PRs after that submission have been assigned, etc. So I have two questions: 1) What's involved with processing a patch from a maintainer? Is it simply a committer commits it on behalf of the maintainer (iow very easy?). Or is it the other end of the spectrum where it has to go through Tinderbox? I would assume the maintainer is trusted and the patch is applied without testing. 2) I have very well aware that people dedicate their own time, etc, and I think that explains why the PRs are getting cherry picked. But seriously, shouldn't there be a policy to process these PRs in order? I'm sure it's been like this for years, but it doesn't seem like the best approach to me. Or at least the fairest. Maybe if an interesting PR is submitted it will give extra incentive to process the waiting PRs to get to it. -- John ___ 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: Dropping maintainership of my ports
On 4/27/2011 8:09 AM, Charlie Kester wrote: I've been told that we shouldn't be looking for reasons to save any unmaintained port, and I was specifically told this in response to my efforts to identify ports that have a lot of users. So I don't think current policy supports the conclusion that "we need to find someone to take them soon." There, in a nutshell, you have the philosophical disagreement which led to my decision to be done with ports. I skimmed the entire conversation this morning. The summary is you have an opinion that apparently nobody else shares. I maintain 7 ports. The majority of these ports had already been deleted years ago, or should have already been deprecated. So after years, somebody (me) showed up with enough motivation to resurrect the ports. That's all people are saying: If the port is important enough, somebody will step up to save it or resurrect it. If that doesn't happen, then it doesn't deserve to be in the tree once it doesn't build anymore. If the powers-that-be want to deprecate all of these and lighten the load on the system and themselves, I no longer care. I know how to download a tarball and run through the configure/make/install routine, so I'll still be able to run the software I need. I thought I'd lend a hand to those who don't have those skills, but it doesn't seem that this contribution is welcomed or appreciated. "There are too many ports!" (Sorry if I'm ranting, I am still very angry about all this.) Obviously the maintenance of ports is appreciated and welcomed. You're just sulking because your idea of identifying popular ports wasn't met with enthusiasm. If the port really is popular, somebody will take it over, I'm sure. I don't know you, or your history of contributions, etc, so all I can judge is what I read today. I don't think this reaction shows a lot of character. Anyway, I'm sure your wish of returning all the ports to nobody will be granted and life will go on. As a FreeBSD user, thanks for effort that you did in the past. Regards, John ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 4/27/2011 4:12 PM, Jerry wrote: On Wed, 27 Apr 2011 15:48:36 +0200 Erik Trulsson articulated: On Wed, Apr 27, 2011 at 09:32:58AM -0400, Jerry wrote: Very simple. A particular committer during one particular period of time maybe only 45 minutes of free time to spend on handling PRs. If the committer estimates that one large submitted PR would take at least two hours to review, test, and commit, while another, smaller, PR would only take 30 minutes to handle. Then the committer in question would have two choices: Don't handle either submission, or handling the smaller submission, while skipping the large one and hoping that some other committer with more free time will pick up that one. I see no reason to prefer the first of these choices. If the committer cannot finish the project in their allotted time frame they simply stop and pick up from that point in their next session. I have literally hundreds of projects that I cannot complete in one day; however, I don't simply shrug them off. If I did nothing would ever get accomplished, or at best only the easiest assignments. One of the basic fallacies in your analysis is that someone else will pick up the slack. Unfortunately, our society has become over run by those who are always ready to blame others or expect others to do our job for us. Quite honestly, I find that pathetic. I seemed to have kicked off quite a dialog! First of all, I want to thank Frederic Culot for committing my patch today. Basically, I'm in complete agreement with Jerry with regards to FIFO. The proposal was made that given a short amount a time, a committer should choose the simpler project and bypass the first one simply based on time/complexity. I couldn't disagree more. As soon as it's possible to skip valid ports, then that's what is going to happen. If people can physically cherry-pick, then they'll exercise their ability to do that and immediately you sink into the current situation. Unfortunately, a FIFO setup requires that all the requests go through a single entity who then assigns them. I don't really buy the joe-the-font-guy with mary-the-network-gal mismatch. Nobody said the PRs have to be assigned as round-robin. And then that changes the dynamic since the PR is assigned rather than chosen. This entity can't just assign a PR without knowing the committer's timeline, availability, etc, so there are clearly implementation details to work out. Maybe a compromise would be to keep the current system in place with the addition of having somebody do these assignments if the new PRs are unclaimed for more than 3-7 days. Yes, it means a new job for someone, but if one believes that FIFO is the fair and respectful approach, the extra effort should be worth it. -- John ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
On 4/28/2011 12:18 AM, Erik Trulsson wrote: And if the committers can't choose what they are going to work on, you are likely going find yourself with a lot fewer committers fairly soon. As you notice, I never said they are limited what they work on. The order of the work is the focus. And who is going to do all that extra work? You volunteering? If finding a volunteer is the only thing holding a reform back, then we have nothing to worry about. Details indeed, and the devil is in the details as the saying goes. First of all there is no entity that knows about the timeline, availability, etc. of the various committers. The only way to get that information would be if committers were to report it at regular intervals which they don't have any reason to do. I thought it was clear that I was saying that wouldn't work. There is also the question of what to do if a committer doesn't like all the proposed extra rules and bureacracy and simply ignores a PR he has been assigned. There isn't really any way force a given committer to work on something he doesn't want to work on. The only sanction available is to remove the commit bit at which point you have one committer less, and that work still isn't done. I was working the assumption that he agrees to the port up front or voluntarily picks up the next task. However, if someone has a repeated history of refusals or only wants to do a very narrow set of tasks, then maybe commit bit removal isn't that dramatic. Worth it for who? Hardly to the guy who is going to do the extra work. As for "fair" you haven't convinced me why it should be a requirement. I don't consider it extra work. I consider it doing the job correctly. And if I need to convince you that "fair" is correct, then basically I just wasted 5 minutes answering this post. Jerry pretty much outlined why it's correct to process these things in order, or at some semblance of order. Look, your mind is made up. You like the status quo. Everything is fine and no effort should be made to improve. I'm not interested in a long, drawn out discussion. I just wanted to give my opinion which I did, so I'm done. John ___ 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: maintainer timeout for FreeBSD commiters
On 7/17/2012 23:39, Mark Linimon wrote: On Tue, Jul 17, 2012 at 07:54:59AM -0400, Michael Scheidell wrote: We *are* making progress in cutting through the backlog though. ports have about 900 open PR. Why it does not have more port commiters? Its difficult to recruit new person? The answer to that is very complex. And, for each PR, maybe a different answer. This is true, but to address the previous question ... It is somewhat difficult to recruit new people who are willing to work within guidelines (both technical and social) and who seem to want to stay for the long-term. portmgr does screen candidates to try to make sure that the quality of the Ports Collection doesn't decline. Each vote is a judgement call. Having said that, we add new committers all the time. OTOH we add new ports all the time, and due to this the backlog seems to remain constant. And again, as scheidell notes, some PRs are more equal than others. mcl Hi Mark, I think that's a reasonable assessment about how the backlog seems about the same and how processes just naturally work. But I think it could work better. Let's take my case. I'm a maintainer of several Ada ports and compilers. I'm also a pkgsrc committer, but not a FreeBSD ports committer. I have the same packages in both trees, but the pkgsrc packages (ports) are more current. That's obviously because I can commit to one tree at will but I have to submit PR and get in line for each update at FreeBSD (A quick shout out of appreciation to Frederic who has been tremendously gracious to me over these months). I was thinking about this - I really like how FreeBSD ports enforces to the best of its ability that every port have a maintainer. My name is on several ports and I have pride in my work. Would it be so bad if all my submitted patches (as a recognized quality contributor with history) just got committed as a passthrough? Obviously you might be reluctant to do this on ports that 200 packages depend on, but if you created a tier of contributors below committer but above PR submitter, I think a lot of ports would be maintained more often and there wouldn't be so much of a backlog. The worst case scenario is a contributor turns out to be a little sloppy, doesn't bother to use Tinderbox, etc, and after a couple of incidents you pull his privileges. The benefit you gain from the others would outweigh the incidents. I've seen the response that the committer is responsible for everything he or she commits, but if the community gave them immunity from consequences of maintainer patches, it shouldn't be a problem. I don't expect anything to come of this suggestion, but I've always wondered why more responsibility wasn't given to port maintainers who don't have commit privileges. John ___ 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: maintainer timeout for FreeBSD commiters
On 7/18/2012 00:43, Mark Linimon wrote: On Wed, Jul 18, 2012 at 12:09:50AM +0200, John Marino wrote: Would it be so bad if all my submitted patches (as a recognized quality contributor with history) just got committed as a passthrough? This has been explored on the mailing lists before, however, we don't technically have a way to do either of the following: - let people commit to "just some" ports - have any patches be autocommitted No one has ever tackled the former problem. The latter problem just seems to me to open up ways for people to abuse the system. It makes me nervous. Well, between the two I would suggest a combination of "let people autocommit patches to "just some" ports". Reasons - Don't have to hassle with the logistics of giving a limited commit bit, risk getting the permissions wrong, and removing it after the maintainer retires. You'd have to create an automatic system that could verify the patches apply cleanly (or maybe just accept file replacements), and that the files came from maintainer. A public/private key system should do that. All you'd need to do is is map keys to ports and not accept any files outside of the allowed area. Removing that mapping is a lot easier than tweaking commit privileges. Yes, somebody would have to set that up but it would pay big dividend I think. John ___ 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: maintainer timeout for FreeBSD commiters
On 7/18/2012 12:19, Chris Rees wrote: On 18 Jul 2012 07:44, "John Marino" wrote: Yes, somebody would have to set that up but it would pay big dividend I think. It also does away with the QA aspect that committers currently provide. I'd like to repeat that people sufficiently familiar with the ports system to QA patches generally ends up with a commit bit fairly quickly. Chris I wouldn't assume people that become this proficient necessarily want a commit bit. The whole point of my proposal is give and take. Yes, you take away "QA" responsibility from an entire pool of committers and make it the primary responsibility of this new class of maintainer on a per port basis (and not nearly all ports either). I was proposing that your gains (much less PRs, more often maintained ports) far outweigh the liabilities. I would be selective who gets assigned to this new class. They should have a body of work that instills confidence that they can handle QA. You don't get something for nothing and it's not hard to revoke the privilege if a person can't handle it. John ___ 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: maintainer timeout for FreeBSD commiters
On 7/18/2012 12:40, Chris Rees wrote: You are making a good point, but I'm trying to explain that the 'body of work' for proposing a new developer is no greater than the standard you suggest. We do have developers who only commit to their own ports; while it's generally hoped that they work on PRs too, it's not a requirement. These would fall under the category of 'super maintainers' if you like. For further reading, Google 'Solutions for the PR load problem'. A very interesting read and essentially addresses the topic I started, with a different implementation. You've been consistent in your concern, but maybe what I'm getting at is that these "super maintainers" don't need to be held to the same standard as someone with a commit bit. Hopefully they are every bit as capable as a committer, but if they are only interested in maintaining say < 10 ports and those ports aren't in the critical path of more important ports, what's the harm in handing the reins to a slightly less experienced person that wants to do it esp. with a large PR backlog? If it passes lint and tinderbox checks, it's got to have some (acceptable) quality level. Over time and with experience the maintainer will improve anyway, especially if he/she is also directly any PRs against the port. That's another topic -- these super maintainers should be able to close PRs as well on their ports. Speaking for myself, I think I'd make a good super-maintainer and I think the quality would be very high on my ports. I know I'm not alone. John ___ 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: something had broken in *.mk?
You're building with bmake and not make.
bmake uses :tu and :tl where make uses :U and :L, among other things.
It's the :L modifier that's causing your errors.
use the FreeBSD version of make instead.
John
On 10/17/2012 09:59, Ruslan Mahmatkhanov wrote:
Hi,
I got this whenever check any port with porlint -AC:
"""
[rm@smeshariki4 ~/py-pysha3]> portlint -AC
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
FATAL: breaks INDEX (make: "/usr/ports/Mk/bsd.python.mk" line 348:
warning: Couldn't read shell's output for
"(/nonexistentlocal/bin/python2.7 -c 'import sys;
print(sys.version.split()[0].replace("b",".b"))' 2> /dev/null) |
/usr/bin/tail -1" make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning:
duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5118:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5118:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here).
1 fatal error and 0 warnings found.
"""
What is wrong here?
___
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: something had broken in *.mk?
You're building with bmake and not make.
bmake uses :tu and :tl where make uses :U and :L, among other things.
It's the :L modifier that's causing your errors.
use the FreeBSD version of make instead.
John
On 10/17/2012 09:59, Ruslan Mahmatkhanov wrote:
Hi,
I got this whenever check any port with porlint -AC:
"""
[rm@smeshariki4 ~/py-pysha3]> portlint -AC
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script
for target "-depends" ignored
make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous
script for "-depends" defined here
FATAL: breaks INDEX (make: "/usr/ports/Mk/bsd.python.mk" line 348:
warning: Couldn't read shell's output for
"(/nonexistentlocal/bin/python2.7 -c 'import sys;
print(sys.version.split()[0].replace("b",".b"))' 2> /dev/null) |
/usr/bin/tail -1" make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning:
duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5118:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5118:
warning: duplicate script for target "-depends" ignored make:
"/usr/ports/Mk/bsd.port.mk" line 5121: warning: using previous script
for "-depends" defined here).
1 fatal error and 0 warnings found.
"""
What is wrong here?
___
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: something had broken in *.mk?
On 10/17/2012 14:30, Baptiste Daroussin wrote: I don't know much about this, I just know that current is going to use bmake, and the only incompatibility I have spotted so far from our make to bmake is the :L becoming :tl and :U becoming :tu Once 8.3 and 9.0 are EOLed all version of freebsd make support both syntax, so the ports could safely use both bmake and make (once we change in the ports tree all the :U and :L occurence.) which means everything should just continue working ootb for everyone on supported version of FreeBSD :) regards, Bapt The incompatible "-V" switch causes problems too. There is quite a few uses of -V in bsd.*.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"
Re: graphics/OpenEXR & gcc 4.6.3 ISSUE error: 'memset' was not declared in this scope
On 1/6/2013 16:03, awarecons wrote: `/usr/ports/graphics/OpenEXR/work/openexr-1.7.0/IlmImf' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. *** Error code 1 Stop in /usr/ports/graphics/OpenEXR. Gcc 4.2+ works, but graphics/ilmbase should be compiled with 4.2+ either. ___ We've fixed this in DPorts, like many others: https://github.com/jrmarino/DPorts/blob/master/graphics/OpenEXR/dragonfly/patch-IlmImf_ImfAutoArray.h You need this one too: https://github.com/jrmarino/DPorts/blob/master/graphics/OpenEXR/dragonfly/patch-exrenvmap_blurImage.cpp John ___ 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: graphics/libmng gcc 4.6.3 ISSUE undefined reference to `__stack_chk_fail_local'
On 1/7/2013 14:06, awarecons wrote: libmng_chunk_descr.So: In function `mng_pplt_entries': libmng_chunk_descr.c:(.text+0x1f41): undefined reference to `__stack_chk_fail_local' libmng_pixels.So: In function `.L1180': libmng_pixels.c:(.text+0xa1da): undefined reference to `__stack_chk_fail_local' libmng_pixels.So: In function `mng_retrieve_g8': libmng_pixels.c:(.text+0xa5ff): undefined reference to `__stack_chk_fail_local' collect2: ld returned 1 exit status *** Error code 1 This is a common problem for amd64 that affects both FreeBSD and DragonFly. We ended up patching the base compilers (two, gcc 4.4 and gcc 4.7) to bypass it. http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5dd34005fbf5509736906dc6aa56d3e77f6a3dcb I suspect that all your ports gcc compilers could use a similar patch. John ___ 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: Why delete KDE3 ports?
On 1/7/2013 15:22, Mikhail T. wrote: On 07.01.2013 03:33, freebsd-ports-requ...@freebsd.org wrote: portname: accessibility/kdeaccessibility description: Accessibility applications for KDE maintainer:po...@freebsd.org deprecated because: Depends on QT3; unmaintained expiration date: 2013-07-01 build errors: none. overview:http://portsmon.FreeBSD.org/portoverview.py?category=accessibility&portname=kdeaccessibility Once again a working port (no build errors) is scheduled for deletion on the grounds of simply being "unmaintained". Please, reconsider deleting this and other KDE-3 ports. I don't normally agree with Mikhail's rants to save old ports, but in the case of KDE-3, I am inclined to share his view. Are KDE-3 ports causing any problems? I don't know if KDE-3 is still be developed upstream, but if it's not it doesn't really need much maintenance. John ___ 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: Why delete KDE3 ports?
On 1/7/2013 16:04, Mikhail T. wrote: On 07.01.2013 09:54, Kimmo Paasiala wrote: Are you willing to step up as the maintainer of the KDE3 ports? Or anyone else reading this? The situation with ports like KDE3 is that they are lots of work to keep up in shape and if no one wants to maintain them they succumb to what is called "bitrot" very quickly when something changes in dependent ports or in the base system. When/if that happens, we can renew the conversation. For the time being there are no build errors. I agree with this. Simple bitrot can be patched pretty quickly even w/o a maintainer and if nobody is willing to do that then sure, kill it. FYI I already maintain a number of ports and I intend to add more Ada ports in the future, so I can't pick up KDE3 myself. John ___ 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: graphics/libmng gcc 4.6.3 ISSUE undefined reference to `__stack_chk_fail_local'
On 1/7/2013 18:55, awarecons wrote: Thank you. As you could notice from the lines (...gcc46 -fpic -DPIC -O2 -pipe -march=pentium4 -mtune=pentium4...) it raised, when compiling for i386 arch and, yes, it's not on amd64 platform, but i386. Right, sorry about that. I caught the error after I sent the email when I reviewed the commit diff. So replace amd64 with i386. I described it wrong. John ___ 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: Why delete KDE3 ports?
On 1/7/2013 19:40, Beat Gaetzi wrote: On 01/07/13 15:22, Mikhail T. wrote: Once again a working port (no build errors) is scheduled for deletion on the grounds of simply being "unmaintained". QT 3.3.8 was released in 2007 and KDE 3.5.10 in 2008 and both are no longer maintained upstream nor in the ports tree. They possibly contain security vulnerabilities and they likely will break in the future if a build or lib dependency gets updated as they assume a 5 year old environment. The deprecation period was set to 6 month to give someone the opportunity to update QT3 and KDE3 to the Trinity fork and I'm happy to offer exp-runs (once the clusters are back) if someone has patches but I don't see a reason why we should keep pointyhat busy (during exp-runs and frequent QA runs) with something that is outdated and mostly unmaintained for years now, prone to break and possibly insecure. Here's the issue I think some folks have: "Outdated": debatable. If outdated means a newer release is available, then yes. If "outdated" means it outlived its usefulness, I'd say no. This term seems subjectively used here. "prone to break": Perhaps, but it's not broken now. "possibly insecure": I think this needs to be "known insecure" rather than holding it's last release date against it. So currently it's not broken, not known to be insecure, and it's probably still useful. I know I'd feel better if this discussion were taking place after a breakage due to a updated dependency or a realistically unpatchable vulnerability was discovered. John ___ 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: deskutils/superkaramba clang3.1 issue 'too few args'
On 1/7/2013 19:47, awarecons wrote: deskutils/superkaramba[4.84.4]: karamba.cpp, meter.cpp ... : multiple errors 'too few args' with clang3.1, gcc46 - fine. ___ Shouldn't all these notices be introduced in a PR rather than serially on a mail list? Are there more coming? ___ 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: Why delete KDE3 ports?
On 1/8/2013 21:14, Raphael Kubo da Costa wrote: Adam Vande More writes: On Mon, Jan 7, 2013 at 12:53 PM, John Marino wrote: "possibly insecure": I think this needs to be "known insecure" rather than holding it's last release date against it. http://www.kde.org/info/security/advisory-20100413-1.txt Probably other security issues as well. I didn't have to look very long. In a codebase as large as KDE's, it seems a very slim chance indeed years could go by without maintenance and still maintain security. Additionally, I'd argue that it is hard for it to be "known insecure" since upstream does not maintain it even for security vulnerabilities anymore, so security problems have nowhere to be reported and vulnerabilities common to KDE3 and KDE4 only get published and fixed in the latter. This doesn't count? http://cve.mitre.org/cve/ http://web.nvd.nist.gov/view/vuln/search?execution=e2s1 It seems to be there is somewhere to report them... ___ 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: security/libssh ISSUE undefined reference to `__stack_chk_fail_local'
It is pointless to post about every instance of __stack_chk_fail_local. The problem, as I mentioned before, is really with every gcc compiler in ports (with the possible exception of gcc-aux, it may or may not be patched yet). If the compiler is patched, all the __stack_chk_fail_local failures disappear. I still think these posts belong in a PR, not on a mail list. We are all aware a PR takes some time to write and it takes 10 seconds to blast out an email. But the PR system exists for a reason. John On 1/9/2013 19:04, awarecons wrote: FreeBSD 9.0-Release i386 for i386 GCC 4.6.3: Linking C shared library libssh.so CMakeFiles/ssh_shared.dir/agent.c.o: In function `agent_talk': agent.c:(.text+0x3c9): undefined reference to `__stack_chk_fail_local' CMakeFiles/ssh_shared.dir/channels.c.o: In function `ssh_channel_request_x11': channels.c:(.text+0x3638): undefined reference to `__stack_chk_fail_local' CMakeFiles/ssh_shared.dir/channels.c.o: In function `channel_read_buffer': channels.c:(.text+0x44d3): undefined reference to `__stack_chk_fail_local' CMakeFiles/ssh_shared.dir/client.c.o: In function `ssh_send_banner': client.c:(.text+0x590): undefined reference to `__stack_chk_fail_local' CMakeFiles/ssh_shared.dir/config.c.o: In function `.L46': config.c:(.text+0x8c7): undefined reference to `__stack_chk_fail_local' CMakeFiles/ssh_shared.dir/connect.c.o:connect.c:(.text+0xf7): more undefined references to `__stack_chk_fail_local' follow collect2: ld returned 1 exit status *** Error code 1 1 error *** Error code 2 [100%] Building C object src/CMakeFiles/ssh.dir/bind.c.o Linking C static library libssh.a [100%] Built target ssh 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/security/libssh. *** Error code 1 Stop in /usr/ports/security/libssh. GCC 4.2: fine. ___ 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: can't find pkgng command
pkg which On 1/17/2013 15:08, Robert Huff wrote: Under the old package system "pkg_info -W' would tell me what port a file belonged to. Perhaps due to not enough sleep, I have read the man page twice but am unable to construct an equivalent. Will someone please help me not have to re-invent the wheel? Respectfully, Robert Huff ___ 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: WITH_BMAKE: make: "/usr/ports/Mk/bsd.port.mk" line 5137: warning: using previous script for "-depends" defined here
Using bmake requires several edits to bsd.port.mk. DragonFly's DPorts (based on ports) uses BMake and we had to edit several lines. https://github.com/jrmarino/DeltaPorts/blob/master/special/Mk/diffs/bsd.port.mk.diff See line 654. It's caused by the :L modifier. It's one of many issues with bmake and bsd.*.mk. You can't fix them until all supported versions of FreeBSD understand these modifiers (legacy make understands :tl, etc., I mean) John On 2/20/2013 11:20, O. Hartmann wrote: Well, I'm brave and switched several "beta switches" on my FreeBSD 10.0-CUR systems on and I realize, that I receive a lot of make: "/usr/ports/Mk/bsd.port.mk" line 5137: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5140: warning: duplicate script for target "-depends" ignored messages when doing updates with portmaster or installing ports. I think this is "BETA-normal", but a re there serious implications apart from some performance issues at the moment using bmake as the replacement for the oldish make in FreeBSD? I'm just curious, so feel free to answer if you like. Oliver ___ 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: WITH_BMAKE: make: "/usr/ports/Mk/bsd.port.mk" line 5137: warning: using previous script for "-depends" defined here
On 2/20/2013 12:46, Chris Rees wrote: Simon Gerraty has cleverly written some sed magic that makes the ports tree work with bmake. Hopefully it'll be ready at some point, but major testing will be required, since the ports tree has other weird behaviours of pmake that it relies on. I'm sure he'll announce when it's ready and we can get testing, but for the meantime I honestly wouldn't try it unless you enjoy debugging very weird errors! In the meantime you should keep me involved because we've hit bmake-involved errors that I am quite sure sed won't address. Sure, you'll get most of them (we basically did this too, translating the problem modifiers during the copy from FreeBSD). We still had a few problems. DPorts has the solutions in the repository. John ___ 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: libxdg-basedir-1.2.0.tar.gz unavailable
On 3/11/2013 20:43, Florent Peterschmitt wrote: Hello, I'm a user of x11-wm/awesome and on a fresh install, I can't build it because libxdg-basedir-1.2.0 sources are not available. But I found a tarball from OpenBSD distfiles that worked out of the box after fetched in /usr/ports/distfiles directory. Here is the link : http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//libxdg-basedir-1.2.0.tar.gz If someone could import it on FreeBSD's disfiles repos, I think it would not be bad :) http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176779 A good resource to check first... John ___ 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: Gnustep group
On 3/17/2013 22:58, Chris Petrik wrote: Yes, after review I notice the GNUstep ports are totally not working.. it doesn't work with base clang. However, clang in ports works, and all the GNUstep modules build from svn without issue.. so it really should be a piece of cake to build some new GNUstep ports.. if there's interest. Here are my notes so far. FWIW - All the GNUstep ports build fine in DPorts (ports on DragonFly). However, the compiler uses is the base compiler, which is GCC 4.7 with ObjC built-in. That would imply setting USE_GCC=4.6+ would "fix" gnustep on ports, no? John ___ 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: How to see errors with poudriere?
On 3/22/2013 18:51, J David wrote: We are rapidly converting all of our ports-building infrastructure to poudriere, which is a fantastic tool and has been a huge improvement for us. However, I do run across the occasional stubborn ports that refuse to build (example: lang/ghc) under poudriere, and I'm not sure how to debug this. I am pretty sure this is possible/easy and I'm just being stupid. If anyone would mind giving me a shove in the right direction, I would really appreciate it. I wouldn't be so quick to blame poudriere. There are many ports that won't build in poudriere due to problems with the port makefiles. In fact, I've only seen one legitimate case of a port that was fine but poudriere erroneously didn't build it. The rest were problems that poudriere flagged. You have to look at the log and see what the problem is, then report the problem via PR. e.g. look in /usr/local/poudriere/data/logs/ John ___ 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: py-qt maintenance
On 3/24/2013 18:40, Brian McKeon wrote: I have a need for py-qt to ultimately get to a native salome 6.5. I see it is not maintained presently, and am interested in taking ownership. I've been using FreeBSD for so long I figure I should start helping out where I can. I know the latest version of py-qt (4.10) builds against my current system, so I do not think it would be hard to get going considering the old version is about to expire. I do not know what I would need to do to become a maintainer but I figure this is the first step. I will read the docs more in depth though. Not sure if it would be possible to have an @freebsd.org email address, but that would be cool. I'd be interested in helping out other places of the organization too, but I'm not much of a coder. This is a skill I very much need to learn though. I've been using the system since 5.4 as my main OS, and have gotten good at making it work without much help. Love me some beastie, want to help make it keep going. Let me know if I can help. Hi Brian, I fixed py-qt a few days ago in DragonFly Ports. The patches are here: https://github.com/jrmarino/DeltaPorts/commit/7cf2d3f44950fa3929d9d1d9fb3d1fb9dc4edf8a I guess I should submit a PR on it John ___ 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: poudriere builds all dependencies, even if packages have already been built
On 4/3/2013 11:17, Stefan Bethke wrote: Firstly, is there a better mailing list to discuss poudriere? I'm just getting my feet wet with poudriere, and are a bit surprised that all dependencies for a port are built, instead of installing the packages that got built earlier already. Is this intentional? Is there a configuration option to have the requisite packages installed before building a port? That's not normal behavior. When I saw something like that, it turned out to be a bug in the bsd.port.mk but that should not apply for you. There's a #poudriere channel at freenode IRC. John ___ 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: poudriere sillieness re audio/libsamplerate & glib20
On 4/9/2013 10:33, Beeblebrox wrote: How do you know it's supposed to be glib20 and not _glib20? I don't, but what I DO know is that after the 2 corrections (star1 and 2 from post #2), the error messages in the form of 'Unknown component _glib20' cleared out and the dependent ports got built by poudriere. So that was Makefile related. If not, suggest how it is to be fixed so that the error no longer occurs. Evenmore you haven't shown anything that would point to a problem in poudriere itself. a. First item in post #1? I asked if there is a way to get libsamplerate in poudriere b. My thread is not limited to problems with 2 ports, since there are a good number of problems which I am posting as fast as much as I can gather the details. c. As posted in #2: colord-0.1.20_1, libsoup-2.42.0, wxgtk2-common-2.8.12 get built on host but not in poudriere. As shown, the errors are trivial (like 'cannot find sqlite3' when the sqlite3.txz is in fact located in the repo) and furthermore, packages built manually and placed in the common repo are summarily deleted by poudriere at repo-check stage. What more does one need before referring to all of this as "sillieness"? I do not know where the source problem lies exactly, so I am reporting my findings. I am regularly building every port in bulk in poudriere, and I don't see these errors. I suspect if you start with a clean slate and the latest ports tree in poudriere, you won't see them either. ___ 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: [PR] Checksum error in Makefile for graphics/epdfview
On 4/9/2013 10:54, Beeblebrox wrote: well, once you run a '# make checksum', the checksum error is going to obviously disappear :) Why would it disappear if the distinfo really doesn't match the port checksum? I suspect you are thinking about "make makesum" in which case the distinfo is rewritten? ___ 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: emulators/visualboyadvance-m fails to build
On 4/10/2013 08:59, David Demelier wrote: Hello, On a very recent ports tree I could not build visualboyadvance-m, it fails with the following error : /wrkdirs/usr/ports/emulators/visualboyadvance-m/work/visualboyadvance-m-1.8.0r1001/fex/fex/Data_Reader.cpp:750: error: initializing argument 1 of 'const char* convert_gz_error(gzFile_s*)' /wrkdirs/usr/ports/emulators/visualboyadvance-m/work/visualboyadvance-m-1.8.0r1001/fex/fex/Data_Reader.cpp: In member function 'void Gzip_File_Reader::close()': /wrkdirs/usr/ports/emulators/visualboyadvance-m/work/visualboyadvance-m-1.8.0r1001/fex/fex/Data_Reader.cpp:759: error: invalid conversion from 'void*' to 'gzFile_s*' /wrkdirs/usr/ports/emulators/visualboyadvance-m/work/visualboyadvance-m-1.8.0r1001/fex/fex/Data_Reader.cpp:759: Here is the full error log : http://packages.malikania.fr/logs/Melon/latest/logs/errors/visualboyadvance-m-1.8.0r1001_3.log Does anyone has the same issue? I've seen that type of error a 100 times in other packages. It's caused by using zlib 1.26 or greater with software that mis-implemented the zlib interface. At version 1.26 a typedef change made the past error apparent. So some zlib must have been upgraded (base?). There's going to be a lot of fallout from that upgrade. DragonFly saw this very thing a few months ago when the base zlib was updated to 1.27 and suddenly pkgsrc packages started failing to build. John ___ 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: databases/mongodb 2.4.3 File size mismatch
On 4/27/2013 18:29, Lowell Gilbert wrote: klaasdem...@gmail.com writes: something is wrong with mongodb port, make reports a mismatched file size. => Attempting to fetch http://downloads.mongodb.org/src/mongodb-src-r2.4.3.tar.gz fetch: http://downloads.mongodb.org/src/mongodb-src-r2.4.3.tar.gz: size mismatch: expected 14108201, actual 14108398 Looks like the distfile got re-rolled under the same name. In which case it would be safe to just update the distinfo and go ahead with the build. I'm CC'ing the maintainer to update the port and double-check my (very quick) analysis of the security issues. The pkgsrc guys make it a point to contact the party responsible for the re-roll and polite ask to never, ever do that again because all the repositories (ports, pkgsrc, apt, arch, rest of linux, etc) are depending on a hash and rerolling breaks all of them. Sometimes upstream just doesn't realize the consequences and they'll not do it again once informed. Something they just don't care and it keeps happening. I am a bit surprised that a database developer that should understand issues with data integrity pulls a stunt like that though. John ___ 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: graphics/rawtherapee 4.0.10 issue
On 4/27/2013 22:31, Waitman Gobble wrote: I have updated the port for rawtherapee 4.0.10, the new version is totally awesome.. There is one issue that I do not understand how to address in my port. Since rawtherapee uses OpenMP / libgomp it links to /usr/lib/libgomp.so which is from base gcc, and too old. even if gcc4.6 is specified in the port it seems to link to gomp in /usr/lib.. SO the question is, how do I address this issue in the port Makefile?? using USE_GCC=4.6 does not seem to get it to link to the gcc4.6 libraries for some reason, I'm missing something. From a conceptual point of view, rawtherapee needs to set the runpath of the executables (e.g. -Wl,-R) to gcc46 library path during linking. And then remove any ldconfig directives in the makefile. You may be able to set this in LDFLAGS in the makefile, or you may have to patch the rawtherepee makefile with a variable that the rawtherepee makefile can substitute later with REINPLACE_CMD. Obviously it needs to work with gcc47, 48, etc. as well. (Sorry, I didn't actually look at any files, I'm just talking about approaches and concepts.) John ___ 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: Fwd: qt-mysql-plugin-3.3.8_10 failed on amd64 8
On 5/10/2013 08:52, Martin Wilke wrote: ===> Configuring for qt-mysql-plugin-3.3.8_10 ===> Building for qt-mysql-plugin-3.3.8_10 Warning: Object directory not changed from original /work/a/ports/databases/qt-mysql-plugin/work/qt-x11-free-3.3.8 c++ -fpic -DPIC -O2 -pipe -fno-strict-aliasing -Iplugins/src/sqldrivers/mysql -Isrc/sql/drivers/mysql -I/usr/local/include/mysql -I/usr/local/include -DQT_THREAD_SUPPORT -c src/sql/drivers/mysql/qsql_mysql.cpp -o qsql_mysql.So make: don't know how to make main.cpp. Stop *** Error code 1 Stop in /a/ports/databases/qt-mysql-plugin. Yes, I've seen this too. I actually told Baptiste about it last night. It's nice to have this confirmed as a generic issue and not a DragonFly one. John ___ 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: Fwd: qt-mysql-plugin-3.3.8_10 failed on amd64 8
On 5/10/2013 08:59, John Marino wrote:
On 5/10/2013 08:52, Martin Wilke wrote:
===> Configuring for qt-mysql-plugin-3.3.8_10
===> Building for qt-mysql-plugin-3.3.8_10
Warning: Object directory not changed from original
/work/a/ports/databases/qt-mysql-plugin/work/qt-x11-free-3.3.8
c++ -fpic -DPIC -O2 -pipe -fno-strict-aliasing
-Iplugins/src/sqldrivers/mysql -Isrc/sql/drivers/mysql
-I/usr/local/include/mysql -I/usr/local/include -DQT_THREAD_SUPPORT
-c src/sql/drivers/mysql/qsql_mysql.cpp -o qsql_mysql.So
make: don't know how to make main.cpp. Stop
*** Error code 1
Stop in /a/ports/databases/qt-mysql-plugin.
Yes, I've seen this too.
I actually told Baptiste about it last night.
It's nice to have this confirmed as a generic issue and not a DragonFly
one.
I have attached a patch that fixes the problem. It was related to the
extraction cleanup. Can somebody commit it?
John
--- Makefile.orig 2013-04-29 08:57:12.0 +
+++ Makefile
@@ -23,7 +23,8 @@ USE_MYSQL=yes
USE_BZIP2= yes
PLUGIN=plugins/src/sqldrivers/${DB}
DRIVER=src/sql/drivers/${DB}
-EXTRACT_AFTER_ARGS?= ${DISTNAME}/${DRIVER} ${DISTNAME}/src/sql/drivers/cache
+EXTRACT_AFTER_ARGS?= ${DISTNAME}/${PLUGIN} ${DISTNAME}/${DRIVER} \
+ ${DISTNAME}/src/sql/drivers/cache
MAKEFILE= ${FILESDIR}/Makefile.bsd
MAKE_ENV+= DB="${DB}" DRIVER="${DRIVER}" PLUGIN="${PLUGIN}" \
PTHREAD_CFLAGS="${PTHREAD_CFLAGS}" \
___
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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
On 5/21/2013 22:03, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim Hi Jung-uk Kim, I brought flex 2.5.37 into DragonFly and yes, it caused quite a few ports to break. However, in many cases I added patches to dports to restore their building. The first place people should check when trying to fix breakage is dports in case that I already came up with a fix. Regards, John ___ 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: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
On 5/21/2013 23:05, Jung-uk Kim wrote: Can you please explain the most common incompatibilities you experienced from dports? FYI, I have added these two shims for FreeBSD: http://svnweb.freebsd.org/changeset/base/250877 http://svnweb.freebsd.org/changeset/base/250878 With these two shims, I was able to build older FreeBSD source trees just fine. Without them, I needed patches like this: http://svnweb.freebsd.org/changeset/base/250227 Yes, we had serious circular dependency issues because M4 was updated at the same time, and they require each other to build. In the end, not only did we make the same sort of changes seen in your r250227, we also had to pregenerate one of the M4 source files to break the circular dependency. After that it was possible to built older trees with the new M4/Flex. But we didn't add the shims. You're going to find additional problems beyond those shims. Such as: - YY_PROTO no longer defined - yyleng data type redefined from int to size_t - yyget_leng now predefined - yylineno is now predefined - upstream patches needed for non-trivial fixes etc. John ___ 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: Proposal: do not show up the dialog(1) by default?
On 5/23/2013 11:10, Ilya A. Arkhipov wrote: I think it is not good idea, because if user don't know regarding options in ports he should do a make config and if it not exist should do a make install in this case we have two action.. Maybe other way for fix these frequent "popping" add needed options to make.conf I like the suggestion that if the dialog consists only of globally set options (NLS, DOC, etc) then it shouldn't appear by default. I also think Ilya has a point in general -- how does one know that there are options available to set in the case of default is "no pop?". There would have to be some sort of announcement that along the lines of "no configuration found, using default settings" so the user would have some sign. Even if the configuration is found, it would still be nice to be informed that a port has options (maybe part of pre-configure?) John ___ 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: Proposal: do not show up the dialog(1) by default?
On 5/23/2013 11:25, Vitaly Magerya wrote: I think it is not good idea, because if user don't know regarding options in ports he should do a make config and if it not exist should do a make install in this case we have two action.. Maybe other way for fix these frequent "popping" add needed options to make.conf I like the suggestion that if the dialog consists only of globally set options (NLS, DOC, etc) then it shouldn't appear by default. Except the cases when those options pull in additional dependencies. In those cases either the dialog should be shown, or the options should be disabled by default. The issue is that _by definition_ these options are enabled by default. I'm not sure I agree that an always-enabled option should trigger a dialog just because it has dependencies. Doesn't NLS have dependencies? That would already negate the benefit greatly if this suggestion were followed. ___ 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: The vim port needs a refresh
On 5/25/2013 00:29, Kimmo Paasiala wrote: P.S. we're now at 7.3.1011 - the port could use a normal update as well. - kenta As far as I know FreeBSD does not roll custom distfiles because of very obvious issues with authenticity of the files. If you create a custom distfile from let's say editors/vim as you suggest then who is going to trust you to provide authentic sources of someone else's work? Now when everything is separate and downloadable and verifiable individually from the upstream vendor there's no problem with authenticity. Supposedly the current patch level is approaching 1000 patches and vim 7.4 is supposed to come out before that happens. That will reset to number of patches to zero, so at least it won't continually get worse. ___ 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: The vim port needs a refresh
On 5/25/2013 03:32, Jimmy wrote: Perhaps one might ask the VIM developers themselves to provide a tarball/zip of the patches along with the individual patches in their distributions, pointing out the huge number of patches that piled up for this particular VIM release and the problems it caused trying to download them individually... (if they're going to wait for another 2 1/2 years / 1000+ patches for their next release, they might consider it) As I previously mentioned, Bram Moolenaar said on 9 May that the patch level for 7.3 will not exceed 1000 patches. ( https://groups.google.com/forum/#!topic/vim_announce/ZWWgK9aXQ2Y ) Seeing how they apparently refuse to have normal releases and think 900 patches is normally, I don't see how Vim developers would ever create a special tarball. If they were willing to do that, they'd just do normal releases, right? This suggestion to talk to Vim is destined to go down in flames, especially as version 7.4 is imminent (beta scheduled for end of May). ___ 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: The vim port needs a refresh
On 5/25/2013 13:24, Chris Rees wrote: On 25 May 2013 11:54, Niclas Zeising wrote: On 05/25/13 10:50, Chris Rees wrote: Alternatively, perhaps we need an editors/vim-options port Just for the record, editors/vim was (and shells/bash) was converted to optionsNG not too long ago. Ah, that's at least some good news. I notice that it was on yet another maintainer timeout, so that criticism stands. It appears that David is no longer interested. FWIW, the default on the vim port have taken the dports users by surprise. I've gotten several complaints about the boatload of ports that get sucked in (and the amount of bandwidth it requires) by vim. They didn't know vim-lite existed. I agree the default should be "light" and the kitchen sink version should be explicitly requested (if two ports are indeed needed for pre-built binary reasons). John ___ 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: The vim port needs a refresh
On 5/27/2013 16:34, RW wrote: It would hurt people with a slow connections who would end-up having to download most of the patches twice. I've a lot more sympathy with people in that situation than with someone who doesn't cache and then complains it's slow. Trust me. If you get the wrong mirror, it is horrifically slow. Like 4 patches per minute slow. You have no sympathy for somebody that has to download all 900+ patches from the beginning? The "trick", of course, is to override MASTER_SITES in the environment, e.g. "make MASTER_SITES= fetch" and then force fetching from FreeBSD. Then it gets all the patches pretty quickly. But most users wouldn't figure that out (and I'm sure you don't want it broadcast either). The "slow" complaint is not trivial, it's very, very real. Saying you haven't seen it doesn't make it less real, you probably just didn't sit there and watch it from patch#1. John ___ 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: The vim port needs a refresh
On 5/27/2013 18:36, RW wrote: Like 4 patches per minute slow. You have no sympathy for somebody that has to download all 900+ patches from the beginning? A little if it's the first time they've ever built vim on FreeBSD, and they have have genuine good reason for not being able to wait an extra minute. 900 patches /4 patches/min = 225 minutes = 3.75 hours hardly an "extra minute" The "slow" complaint is not trivial, it's very, very real. Saying you haven't seen it doesn't make it less real, you probably just didn't sit there and watch it from patch#1. No, it's because I've been using FreeBSD since before August 2010 when that patch was created. I've been using FreeBSD since version 4.10, but that doesn't imply that I've every downloaded vim patches before. I just tried deleting all the patches and refetching and it took 74 seconds, it's scarcely a major problem. Great. With the previous mirror I had it would have taken well over an hour back when the patch count was 700. That is a major problem for others, despite the fact that it's not a problem for you. It's obviously true since multiple users are seeing it. (the whole 1080 movie analogy, remember?) John ___ 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: The vim port needs a refresh
On 5/27/2013 19:36, RW wrote: On Mon, 27 May 2013 18:44:55 +0200 John Marino wrote: Great. With the previous mirror I had it would have taken well over an hour back when the patch count was 700. By default it should be the same mirror if you tested it this year. Slow and dead mirrors were removed at the beginning of January. And you still haven't said whether you have any make.conf settings that affect the order. I didn't change any settings. It may have been an FTP site rather than an HTTP site. I seem to recall some work to move HTTP over FTP fairly recently. It's obviously true since multiple users are seeing it. (the whole 1080 movie analogy, remember?) It not obviously true that you aren't all either making this problem with your make.conf settings or referring to a problem that existed last year. It was THIS year and it wasn't that long ago. January in the worst case. But now you're explicitly telling multiple users that they didn't in fact experience this? ___ 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: The vim port needs a refresh
On 5/27/2013 22:09, RW wrote: On Mon, 27 May 2013 20:38:11 +0200 John Marino wrote: No, that's something you just made up. It is however vague and anecdotal. We have only one data point that we know is from this year and not self-inflicted, even if the others are, for all we know it could still be fast most of the time. Some monitoring would be useful. However you slice it, a distinfo file with 1000+ entries is completely absurd. 95% of the blame goes to Vim developers. However, it is within the realm of feasibility to pre-package patches in batches of 100 (or conversely 1 tarball of patches rolled for every time patch count hits multiple of 100). At the very, very least maybe only HTTP hosts are listed for VIM (I just checked bsd.sites.mk, the ftp sites are all at the end of the list now) It looks like some of this was addressed in January though: Revision 309899 - (view) (download) (annotate) - [select for diffs] Modified Thu Jan 3 17:38:30 2013 UTC (4 months, 3 weeks ago) by rm File length: 63730 byte(s) Diff to previous 309846 - sync list of vim mirrors with official list on http://www.vim.org/mirrors.php - remove dead vim sites - remove vim sites with missing files - remove slow vim sites (> 10 seconds to serve a file) after repeated complaints by blakkheim (I'm not sure what's that) PR: 174875 Submitted by: 4...@hushmail.com I may have still been on the old bsd.sites.mk with a site > 10 seconds per file. (this is yet another data point) so maybe the situation is much better now. ___ 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: The vim port needs a refresh
On 5/28/2013 01:05, RW wrote: On Mon, 27 May 2013 22:33:53 +0200 John Marino wrote: On 5/27/2013 22:09, RW wrote: On Mon, 27 May 2013 20:38:11 +0200 John Marino wrote: No, that's something you just made up. It is however vague and anecdotal. We have only one data point that we know is from this year and not self-inflicted, even if the others are, for all we know it could still be fast most of the time. Some monitoring would be useful. However you slice it, a distinfo file with 1000+ entries is completely absurd. 95% of the blame goes to Vim developers. However, it is within the realm of feasibility to pre-package patches in batches of 100 (or conversely 1 tarball of patches rolled for every time patch count hits multiple of 100). In other words downloading every patch twice. No. That's not what those words mean. Please stop assuming that somebody builds Vim repeatedly and start assuming it's built for the very first time. Also, given these patches are a couple of kilobytes at most, a compressed tarball of 100 patches (or even 700 patches) is negligible. Even if somebody with a cache downloaded it twice, so what? It's not even noticeable. At the very, very least maybe only HTTP hosts are listed for VIM (I just checked bsd.sites.mk, the ftp sites are all at the end of the list now) All 13 http links would have to fail before the ftp links are tried. So what's the point of having them on the list? Isn't 13 mirrors enough? I may have still been on the old bsd.sites.mk with a site> 10 seconds per file. (this is yet another data point) We already knew that it was slow before January, so that's irrelevant. It validated my story as more than anecdotal. ___ 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: The vim port needs a refresh
On 5/28/2013 01:48, RW wrote: On Tue, 28 May 2013 01:13:43 +0200 No. That's not what those words mean. Please stop assuming that somebody builds Vim repeatedly and start assuming it's built for the very first time. Why wouldn't I? Are you seriously suggesting that it's the norm to build a port once and then never build it again? 1. Yes, that can happen. I'm working on some servers with 1600 days uptime (should be 2300 days but the data center relocated them a few years ago) and most of the software on them is from 2007. 2. Every software built from source is built "the first time" on each server. 3. It is nice to cater to new users. 4. It's good practice to target the lowest common denominator They add up to 3 MB which is noticeable to someone on dialup even when compressed. Ordinarily, it wouldn't matter, but as I said before VIM is something that could be part of a very minimal build - something that might be maintained even over very slow dial-up. If you are going to use dialup as an example, then it's much, much worse to download them all individually. Unless you're building vim repeatedly and often, the opportunity for double-downloads isn't that high. If it's a real worry then the 100-patch rollups would be better than the full aggregates. Some people may find ftp faster or more reliable - it depends on your circumstances. That's not my experience but for the sake of argument I'll accept the point. It still seems like overkill though. It validated my story as more than anecdotal. No it didn't because I already told you that there unreliable servers then. That doesn't invalidate what I said. You can't assume everyone portsnaps daily. A commit in January might not trickle down for months. All you can say is, "yes, that was the case but a PR was written against it and since closed, please try again with a current port tree". Plus I think you said it after I told the story. ___ 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: The vim port needs a refresh
On 5/28/2013 02:44, Martin Wilke wrote: On the first note, complain about the patches to the upstream, not to us. This patches problem has been around since forever and so long the upstream is not changing anything about it, nor do we. Hi Martin, This statement is hand-waives the entire discussion, which took as a *given* that upstream is the problem who crazy policies will not change. I already said that "95%" of the blame (probably more) should get allocated there. The whole discussion started because upstream will clearly not change. About rolling your own distfile, I completely disagree because we do not know what the maintaner has changed, and seeing it from the security view, I prefer to get all my patches from the original mirrors. 1. Yes, some amount of trust is necessary but hopefully we don't have maintainers that aren't trusted. 2. A trivial script can verify the roll-up contains only official patches, which could be executed by the committer prior to committing changes to distfile. That's a pretty easy "security" issue to address. I get your point but that issue could be solved. John ___ 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: The vim port needs a refresh
On 5/28/2013 14:09, Mark Felder wrote: On Fri, 24 May 2013 16:23:18 -0500, Kenta Suzumoto wrote: - It fetches almost 700 patches from what seems like a dial-up connection in AUSTRALIA. Australia's deploying fiber, so joke's on you! But honestly this is horrible. I'm sitting at my desk at a well-peered ISP with plenty of bandwidth and low, low latency and these patches are taking forever. Someone should just add a pre-fetch routine that downloads the first 1000 patches in a tarball, puts them in distfiles, and they well all be verified and the remaining few be fetched normally. Someone should teach upstream a serious lesson about versioning. Maybe someone just needs to fork vim and tag releases on github so we can actually have a sane upstream. Good grief! Well Mark, haven't you realized yet that there's actually no problem and this is "almost completely about (your) laziness"[1]? All patches only take 74 seconds to download[2] so there is no sympathy for your obviously single data point anecdote, you're clearly doing something wrong. You need to stop complaining and start think about folks with slow connections[3] who also rebuild Vim frequently. Your prefetch/fork idea is obviously unworkable because the security issues can't be solved.[4] [1]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083880.html [2]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083849.html [3]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083844.html [4]http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083882.html Regards, John P.S. Hopefully it's obvious this is tongue in cheek. ___ 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: The vim port needs a refresh
On 5/29/2013 21:28, Jeremy Messenger wrote: Fix the OPTIONS first and I will accept it in my ports. Pretty simple. Since I don't like OPTIONS, so I am not required to fix it. If you do really want OPTIONS to be added in my port then please fix it. Although, I have lost in track of which bugs have been fixed in OPTIONS. I know one important bug is: http://lists.freebsd.org/pipermail/freebsd-ports/2013-April/083035.html Do any of your ports defer setting of PKGNAMEPREFIX? In other words, is your stance on principle or does this bug actually affect you? As same as with the LICENSE. I will not add in my ports until he writes document of it. But I will accept the patch of it though. Well, again, I might be out of date but I seem still can't find it in the porter handbook as today. I thought LICENSE was totally optional anyway John ___ 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: shells/bash: Options slightly confusing
On 5/30/2013 13:27, Michael Gmelin wrote: I assume there are better ways to make this clear. It might even make sense to have a basic distinction on the ports system level - options that provide additional features vs. options that change the (default) behavior of the port. Isn't this implicit in the option default selection? In other words, the fact that it's pre-selected indicates the default behavior of the port, right? Even in the case of a dialog showing where it didn't before isn't a logical reason to think pre-selected options are changes in default behavior, at least not to me. John ___ 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: Change when using gcc48
On 6/4/2013 13:26, Shane Ambler wrote: As the port maintainer of graphics/openimageio I have come across a change when building with gcc48. The current version of openimageio compiles fine with clang gcc and gcc46, but when compiled with gcc48 the unlink function is not defined. The simple solution is to add #include to the source file but why is this only needed for gcc48? Is this an intended change? I'm pretty sure this is not new for gcc48. This behavior is seen with gcc47 too. unistd.h is a big culprit, string.h, , etc, also frequently need to be added to older codebases. Yeah, I don't think it's accidental. :) John ___ 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/alpine: make: "/usr/ports/mail/alpine/Makefile" line 108: Malformed conditional
On 6/7/2013 08:53, O. Hartmann wrote:
I get this while running portmaster on a most recently updated ports
tree:
make: Unknown modifier ')'
make: "/usr/ports/mail/alpine/Makefile" line 108: Malformed conditional
(${PORT_OPTIONS:MQUOTA) || defined(WITH_MAILDIR})
make: Fatal errors encountered -- cannot continue===>>> Launching child
to update fricas-1.1.8_5 to fricas-1.1.8_6
In inside brackets are inverted, that indicates it was edited with sed
during the optionng conversion.
Somebody should probably scan for this particular problem repo wide.
When it happens once, there could be others.
John
___
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"
GNATS - error 503 for a while
I know GNATS isn't exclusive to use for ports, but is anyone working to restore GNATS service? Time estimated to restore? It's return error 503 right now, and has been for at least an hour. Thanks, John ___ 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: Suggesting a new experimental fork for ports tree
On 6/12/2013 20:04, Jože Zobec wrote: I have a suggestion, which may help decrease the time needed for certain ports to enter into the ports tree. Do you have an example handy of the type of ports that would benefit from this? Like the names of specific ports or proposed ports? Currently there are more than 150 new ports waiting to be accepted into the ports tree (those PRs still remain open). Some of them are awaiting confirmation even from 2010. I'm not a committer, I contribute and maintain ports from time to time. So as somebody on your team, I'd guess that many of those 150 new ports have been glanced at and have something wrong with them. I've had some just flat out not get claimed, but a single ping to the mail list after a few weeks took care of it for me. I think it's generally a problem and I even started off a nice discussion about processing ports in order, but there are ways to move the ports along if the port itself isn't immediately appealing. I suggest an experimental fork of the ports tree, which would include volatile ports, that wouldn't necessarily build (or even if they did, building them could have a serious impact on the system), and people who would be checking out this fork could help debug them. Also, restrictions to get your port committed in this ports tree would be lesser -- it would be pretty easy for even a bad port to get inside, but until the port issues are resolved, the port would stay there (potentially indefinitely, unless the norms are met). I have a good deal of experience with pkgsrc. In fact, I have commit privileges for it. They have a "sandbox" called WIP (work in progress) which is a similar idea. The problem is that in my opinion, it's a liability and doesn't work. Too many ports get left to rot, the ports that are there are generally pretty terrible quality. If somebody wants to get credibility, I recommend getting a redports account instead. So for the record, I absolutely oppose the idea of an experiemental tree. It seems like a good idea, but in practice it's a distraction and a waste of time. There are other ways to learn the ropes. Regards, John ___ 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: Rebuild all ports for perl minor version update?
On 6/14/2013 10:12, Thomas Mueller wrote: Since this is only (?) a minor-version update, why should it be necessary to upgrade all ports that depend on perl? In that case, why didn't they go to perl 5.18? According to OpenBSD's Marc Espie on a pkgsrc list, a lot of established scripts will break on perl 5.18. Apparently it is not highly backwards compatible. A large % of the perl packages would cease to build if they just moved to 5.18. A minor upgrade is definitely better. John ___ 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: Rebuild all ports for perl minor version update?
On 6/14/2013 12:40, Jerry wrote: Just so I am understanding this correctly, the problem is not with Perl-5.18, but rather applications that were written for earlier versions that may not have in fact been written in tight compliance with the specifications of the earlier versions and those problems seem to reside on *BSD platforms more readily than other OSs. Is that a fair statement? I don't think that's a fair statement. First, where is your support your statement that the broken applications didn't have "tight compliance with the specifications"? That sounds like conjecture. I also don't see how you make the leap that BSD has more problems than other architectures. In my opinion, rather than just issuing a blanket embargo of the newer version, I would think that issuing a warning of its potential problems, (and I do stress the use of POTENTIAL as opposed to GUARANTEED ramifications) to be a more suitable solution to the situation. Users would be free to make their own decisions. Unless the intent is to lock *.BSD into versions < 5.18 ad infinitum, at some point the action must be taken anyway. I despise languages that aren't backwards compatible, so if 5.18 actually broke compatibility intentionally then I for one would vote for staying on 5.16 for a long, long time. I am reserving judgement for the full story. John ___ 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: Rebuild all ports for perl minor version update?
On 6/14/2013 13:21, John Marino wrote: I despise languages that aren't backwards compatible, so if 5.18 actually broke compatibility intentionally then I for one would vote for staying on 5.16 for a long, long time. I am reserving judgement for the full story. I just realize that Perl default is still 5.14, I was thinking it was 5.16 based on how the topic started. John ___ 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: gccmakedep fix - 20130619
On 6/19/2013 01:00, Oliver Pinter wrote: Hi all! Attached a fix to gccmakedep. So 1) There's already multiple PRs on this, including one I just submitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=179571 2) Your patch adds an ".endif" which is already there 3) Is not it better to submit via PR (GNATS) rather than a mailing list? That's what PRs are for... John ___ 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: ports && 10-CURRENT
On 6/19/2013 20:52, Cy Schubert wrote: The point is, why install software permanently when you don't need to? Or, go through the exercise of uninstalling build software post-install? That's not pertinent for binary packages. The build depends aren't tied to the final products. It's just a build-for-source issue, and then you might as well leave them in place for the next port that needs that build dependency. I don't really see the problem here. John ___ 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: make: /usr/ports/Mk/bsd.port.mk line 1638: warning: Couldn't read shell's output for if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null 2>&1; then echo YES; fi
On 6/21/2013 16:42, Anton Shterenlikht wrote: On ia64 r252055 with ports at r321471 make issues lots of warnings like: # make -C /usr/ports/ fetchindex make: "/usr/ports/Mk/bsd.port.subdir.mk" line 101: warning: Couldn't read shell's output for "if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null 2>&1; then echo YES; fi" make: "/usr/ports/Mk/bsd.port.mk" line 1638: warning: Couldn't read shell's output for "if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null 2>&1; then echo YES; fi" *and many more idencal ones* That looks like bmake output. There should be an "else" part of the conditional that returns TRUE or echo. bmake shell commands don't like null output. The bsd.port.subdir.mk needs to be tweaked for bmake. John ___ 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"
suboptimal fetch behavior [was: No valid mirrors for mysql56?
On 7/18/2013 01:29, John Marshall wrote: >> Seems odd that the ports system wouldn't catch this and delete >> the bad original before trying to re-download or forcing an overwrite >> on download. > > So, the tarball had changed since the last time you downloaded it (using > an earlier version of the port). The ports system did catch it and > complain that your downloaded tarball didn't match the (new) expected > tarball for the same release, but the ports system didn't assume > responsibility for deleting the existing file. This behavior has personally burned me numerous times. As I am often building the entire tree, this behavior not only causes false positives on bad builds, but it prevents all the ports that depend on it from building as well which hurts builds meant to produce official packages. I think the behavior is sub-optimal and needs to be improved. Something along the lines of downloading it to a temporary file, and if that file matches the hash then replacing the current distfile with new one. Yeah, I definitely think this should be looked at. The other thing: This doesn't affect pkgsrc often because when a package gets rerolled they immediately switch to a unique SUBDIR scheme so that the new distfile never clashes with the old one. That's a policy change on how to handle re-rolls but it does work. John ___ 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: py-avahi
On 7/25/2013 12:19, Wolfgang Riegler wrote: > Hello, > > I have problems with the port net/py-avahi. I'm using FreeBSD 9.1-r4 amd64 > and try to package the port with poudriere but it fails. Below is the > complete build log from poudriere. > > Maybe someone can help me. Thanks in advance It's not just you, we're seeing the same error on DragonFly DPorts. John ___ 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: Ocaml ports needs love
On 7/28/2013 15:41, Michael wrote: >> Let me know about the URL of the project once it is accepted and activated. > https://forge.ocamlcore.org/projects/ocaml-freebsd/ anonymous users can't access this site. > I started to port opam to FreeBSD, if you download my Makefile, you will > be able to downlaod and maybe build it — but the build system needs to > be patched. I will spend a few hours on this today and commit my changes. Is not opam already in ports? http://www.freshports.org/devel/ocaml-opam/ John ___ 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: Cacti vulnerable?
On 8/28/2013 10:27, Florent Peterschmitt wrote: > Le 28/08/2013 10:10, Rodrigo OSORIO a écrit : >> Hi, >> >> Not really, according to cve, releases before 0.8.8b are affected, >> and we have 0.8.8a. >> >> - rodrigo > > And before 0.8.8b there is 0.8.8a. Or I missed something? You are agreeing with Rodrigo. He is saying the ports tree version is 0.8.8a and thus not safe, the response to the question "is the port tree version safe?" John ___ 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: License framework
On 9/3/2013 13:42, Bryan Drewery wrote: >> >> My stand on it is that I don't care enough to be a beta-tester for >> it and that I'll pick up the practice, once it's described in the >> Porters' Handbook. Which it isn't. Why is that? >> > > A lot of things are not. It's not due to the status of a feature, just > time. We're all volunteers. > In the case of licensing, it is more than this. There is no policy on it at all, or even declared intent. And it's apparently not fully implemented. It does need some official direction. It's more than just "not written down yet". ___ 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: Berkeley DB 4.1
On 9/12/2013 13:09, Matthew D. Fuller wrote: > On Thu, Sep 12, 2013 at 12:57:06PM +0200 I heard the voice of > Ivan Voras, and lo! it spake thus: >> >> And while the argument seems valid, it also doesn't have an estimate >> of which / how many ports will break with a more recent bdb. > > FWIW, I've manually pushed all the systems I've managed to higher > versions than 4.2 for years. I remember having 4.6 around a lot. In > a quick look around now, I see 4.8 on everything but one system that's > running 4.7, servers and a couple workstations. I can't recall _ever_ > seeing a breakage. If it helps the discussion, dports set the db version default to 4.8 since the beginning of dports. We found a couple of ports that misadvertised their compatibility but for the most part, it's been smooth for us (DragonFly). John ___ 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: textproc/hunspell build failure following 20130904
On 9/12/2013 22:36, Anton Shterenlikht wrote:
> /usr/bin/ld: -: invalid DSO for symbol `cbreak' definition
> /usr/local/lib/libtinfow.so.5.9: could not read symbols: Bad value
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [hunspell] Error code 1
>
> make[4]: stopped in /usr/ports/textproc/hunspell/work/hunspell-1.3.2/src/tools
>
> I've rebuilt ncurses and readline successfully already.
What library does the cbreak symbol belong to?
you need to add it to the linker flags. (e.g. LDFLAGS+=
-L${LOCALBASE}/lib -lmylib )
Invalid DSO normally means the symbol is in another library and the
linker is not going to recursively search for it.
John
___
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: tcl changes break deskutils/ical
On 10/1/2013 23:32, Bryan Drewery wrote: > On Tue, Oct 01, 2013 at 10:41:54AM -0700, Steve Kargl wrote: >> After recent tcl change that seems to have touched >> every Makefile under /usr/ports, deskutils/ical no longer >> functions. > > Which TCL port are you using? > > What version of TCL and ical do you have installed? If it helps, deskutils/ical has not been building in dports+poudriere for a while. http://pkgbox64.dragonflybsd.org/mega/ical-2.2_4.log John ___ 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: multimedia/dirac compilation fails with gcc46
On 10/2/2013 08:39, Andriy Gapon wrote: > parseunit_byteio.cpp:127:23: error: variable 'next_parse_code' set but not > used > [-Werror=unused-but-set-variable] > parseunit_byteio.cpp:131:13: error: variable 'next_unit_next_parse_offset' set > but not used [-Werror=unused-but-set-variable] This post is just an excerpt of a log. I can conjecture that you want somebody to fix multimedia/dirac. So it would be more appropriate to "Sumbit a FreeBSD problem report" (http://www.freebsd.org/send-pr.html) right? And ideally with a patch to fix it. In any case, the port is maintained by multime...@freebsd.org so opening a PR is the best way to alert those responsible about a problem. John P.S. The fix is likely trivial: Remove -Werror from the compiler flags. P.P.S. I and others are slowly fixing ports that don't build on recent gcc and clang/libc++ already. ___ 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: trouble with poudriere and recent ports tree
On 10/8/2013 12:51, Alfred Bartsch wrote: > Hi all, > after updating my ports tree to a more recent version (svn revision: > 329714), > I'm no longer able to build most of my ports with poudriere, as I was > before (some weeks ago). > For now, I'm lost. Am I missing something? > Is there someone, who is able to give any hints? Did you update poudriere to the latest version 3.0.9 before attempting these builds? John ___ 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: trouble with poudriere and recent ports tree
On 10/8/2013 14:14, Alfred Bartsch wrote: > Am 08.10.2013 13:23, schrieb Bryan Drewery: > >> NO_STAGE is not a user variable. Do NOT put it in your make.conf. >> This will break a lot. > > > Then I need some advice, how to actually build ports-mgmt/poudriere or > devel/libSM (and some more) without this entry in > /usr/local/etc/poudriere.d/make.conf. Build poudriere straight from /usr/ports and install it. If you need to build poudriere inside poudriere after that, you can. > > Does this NO_STAGE entry break the build of my failed ports list? NO_STAGE is not a user variable, so why discuss it further? Just remove it. Regards, John ___ 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: Undelivered Mail: ho...@freebsd.org
On 10/8/2013 15:21, Carmel wrote: > I attempted to contact the maintainer of the > "deskutils/horde-groupware" port, , but I received > the following notification: > > : Host or domain name not found. Name service error > for > name=freebsdnorth.com type=: Host found but no data record of > requested > type > > Has anyone else experienced this problem? Is there a change in the > maintainers address that is not reflected in the port? > Yes, I experienced this months ago. The address horde@ points to has been bogus, it's not a new thing. And yes, something should probably be done. John ___ 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: Undelivered Mail: ho...@freebsd.org
On 10/9/2013 12:31, Carmel wrote: > On Tue, 8 Oct 2013 21:01:06 -0400 > Sahil Tandon articulated: > >> Did you, by chance, report this to postmas...@freebsd.org? >> >> We'll look into it. > > No I didn't because: > > A) I was not sure if it was a local problem; ie, only me > > B) Who to actually report it to > > Since it is not a local problem, I am glad that you are looking into it. > I suspect that question was addressed to me. I reported it on irc #bsdports. We figured it would return at some port, nobody felt it was necessary to disable horde@ and potentially return all the horde ports to the pool at the time... John ___ 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: llvm33 update
On 10/17/2013 11:57, Ajtim wrote: > Hi! > > I tried to update llvm33-3.3_4 to llvm33-3.3_5 on FreeBSD 10.0-BETA1 but > I got an error: (snip) known: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/183045 John ___ 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: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 04:33, Stan Gammons wrote:
> On 18/10/13 09:04, s_gamm...@charter.net wrote:
>>
>> I was trying to install sguil-server on Release 9.2 and received the
>> following error. I get the same unassociated shell command when I
>> goto /usr/src/security/sguil-server and try make install clean. Any
>> ideas what the problem is?
>>
>>
>
> It appears as though the problem is in line 45 of the makefile in
> /usr/ports/security/sguil-server. The original line was .if
> ${PORT_OPTIONS:MMYSQL} changing it to .if ${PORT_OPTIONS:MYSQL} seems
> to have fixed the problem. Although I haven't started over from scratch
> then changed the Makefile to confirm.
That is a completely incorrectly thing to do. "MMYSQL" is correct,
"MYSQL" is not. the first "M" means "Match". So you ready the line as,
"If there is any option in the option list that matches "MYSQL", do the
following. All you did was change it to look for "YSQL" which in
effect, is the same as not selecting the MYSQL option from the options
dialog.
Your error is line 46 where it tries to run, "cd
${PORTSDIR}/databases/mysqltcl && ${MAKE} -V PORTVERSION".
While running "make" on another port is horrible, it's not the actually
problem either.
First, make sure ports tree is up to date.
Then run, "cd /usr/ports/databases/mysqltcl && make-V PORTVERSION"
And see if you have an error message.
If not, try sguil-server again after restoring it.
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 15:15, s_gamm...@charter.net wrote:
> I started from scratch. Reinstalled the OS, updated the ports tree then
> changed to /usr/ports/databases/mysqltcl and ran "make -V PORTVERSION"
> That resulted in 3.052 being returned. Changing to
> /usr/ports/security/sguil-server and running "make install" starts the
> build process and I get the prompt to build with MYSQL. When I select
> MYSQL option, it bombs with the same error.
>
> What I tried before was install all of the depends with portmaster, then
> tried to install sguil-server by going to
> /usr/ports/security/sguil-server and running "make install". I got the
> same unassociated shell command error. Modifying the Makefile by
> removing the M allowed the build process to continue. I had to stop the
> build process before it completed since that machine was getting really
> hot from being run so hard all day. So, I don't know if the build would
> have completed. I can try it again, but I'd like to find out what's
> causing this to fail.
>
> Any other ideas?
"other ideas"?
The line I mentioned is the one returning the error. That is still
true, it's not getting "3.052" when building security/sguil-server.
You need to forget about removing the "M", that's a red herring. By
removing the "M", you skipped the line that is failing, but that also
means MYSQL isn't built in either.
If you just want the thing to build (and not care if that sguil-server
makefile is busted), then try this:
1) Remove line 46 completely.
2) On line 47, replace "${MYSQLTCL_VER}" with "3.052"
I feel that the makefile could be reworked to avoid calling make on
databases/mysqltcl in a number of different ways, but that is for the
maintainer to decide (i.e. open a PR so it's fixed permanently).
Regards,
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 16:15, s_gamm...@charter.net wrote:
> I modified like so, and it still bombs... Guess I'll have to file a PR
> or build it manually like I talked about before.
>
> .if ${PORT_OPTIONS:MMYSQL}
> # @${ECHO_CMD} $$(${MYSQLTCL_CMDS})
> RUN_DEPENDS+=
> ${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
> .endif
Ah, try removing the "tab" before RUN_DEPENDS, so that the "R" is on the
first column (iow, remove the indent).
you can test it my "make -V RUN_DEPENDS" and verifying mysqltcl is in
the result (and that there is no shell error)
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 16:32, s_gamm...@charter.net wrote:
>
> Looks like that fixed it. It's building now.
>
> Should the tab be removed before @${ECHO_CMD} $$(${MYSQLTCL_CMDS}) ?
>
No, I think that line is broken too, in at least two different ways.
The MYSQL option is busted. It doesn't appear to me that it was ever
tested; I can't see how it ever worked.
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/20/2013 03:49, Paul Schmehl wrote:
>>
>> You should create a PR on sguil-server and document all this there and
>> request the maintainer fix it properly. Personally I don't think any
>> shell commands are needed at all, certainly not to specify a
>> RUN_DEPENDS. it's all messed up.
>>
>
> I'm the maintainer, and I can assure you I tested it thoroughly. The
> port has built without error on many machines before this came up. I've
> personally built and tested it numerous times.
With the MYSQL option set on? The default is off, so building the
default configuration numerous times would not have hit this.
>
> Nevertheless, I will take a look at what you've discussed and attempt to
> determine what the problem is. It appears that something may have
> changed in 9.2 that is causing the problem. Unfortunately I don't have
> a 9.2 install, so I'll have to set one up before I can test it.
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition. That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port. Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl && ${MAKE} -V
PORTVERSION
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 00:47, Paul Schmehl wrote:
> --On October 20, 2013 9:34:36 AM +0200 John Marino
>> It is not a mystery what is wrong.
>> The RUN_DEPENDS is being executed as a shell command, not a make
>> definition.
>
> You're wrong. The RUN_DEPENDS does not have a shell command embedded in
> it anywhere.
When you indent, it executes the command in the shell. Notice that only
make targets are indented.
>> That was never correct, and the new bmake makes this much
>> more obvious. Secondly, I'm pretty sure you can specify
>> databases/mysqltcl without having to execute a make command on that
>> port.
>
> You're pretty sure? Rather than hard code a version, which would break
> the port the moment mysqltcl was updated, I chose to use the existing
> port version, which would work no matter what version was current on any
> particular box.
Yes, I am sure. You can tell it that the port is the dependency
regardless of version. If you absolutely wanted to specify a file, you
can specify a different one that the file name doesn't change. Yes, you
can a RUN_DEPENDS without that line in ways that are robust.
>
>> Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
>
> Yes, and that is a problem. I noticed that last night when I was
> looking at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
> $$(${MYSQLTCL_CMDS}).
Again, completely unnecessary. Specify the *NON-INDENTED* RUN_DEPENDS
in a better way.
>
> It looks like that port has changed, however, because it no longer
> appends the version number to the name of the port, so I can probably
> drop that entirely. I won't know until I test it.
>
>> Apparently line 46 was intended to define it but does not. Lastly, if
>> you were to use a shell command (which I highly discourage), it should
>> be something like this (not indented, and definitely not hardcoded to
>> ${PORTSDIR}):
>> MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl && ${MAKE} -V
>> PORTVERSION
>>
>
> What do you suggest it be hardcoded to? ${PORTSDIR} can be set to
> anything on an individual system. Using your construction forces it to
> be in /usr/ports. Although that's the default, it's by no means
> guaranteed that the ports tree will exist there on any given system.
> That's why we use macros in Makefiles - to avoid forcing users to stick
> to the default structure.
I just showed you. Replace ${PORTSDIR} with ${.CURDIR}/../../
I know you haven't believed a thing I've said so far, but using
${PORTSDIR} can break the build in specific configurations. And yes,
we've been replacing it with .CURDIR in other ports.
>
>> So that's like 4 or 5 errors right off the bat, problems that were
>> always present. I suspect the legacy make simply didn't define
>> RUN_DEPENDS and continued building, so mysqltcl was never specified in
>> the package.
>>
>
> Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should
> fail. It didn't. I can't explain why. (I've slept since I last worked
> on that port.) I can assure you I tested the port with the option
> enabled and it built and ran fine.
So you state previously that it *HAD* to be defined for RUN_DEPENDS to
work, and now state that it wasn't defined but RUN_DEPENDS did work?
Doubtful and easily verifiable. Find an old platform where it "worked"
and type "make -V RUN_DEPENDS" and see if mysqltcl is in the list. I
believe it simply wasn't defined which didn't prevent this build from
building (it was indented, remember?). I think the error was masked
with the previous version of make.
>
> But I doubt seriously that has anything to do with the error that the OP
> reported. It's probably related to the change to bmake, which I will
> have to investigate, if I have to continue to define the port version
> for mysqltcl. It looks like I might not have to any more.
>
> I'll also have to update the port to use the new STAGE syntax, so this
> will take a little while.
>
> In the future, I would appreciate it if you adopt a less smug attitude
> about somebody else's work. Or take over the port if you think you're
> so much better. There's three sguil ports. You're welcome to take over
> maintainership if you think you're God's gift to port building.
I guess you still feel this way after what I just wrote?
What did I do, beside help one of the port's users get going and point
out the problems with it and telling the user to write a PR?
You know, you could have just said, "Thank you" as I've spent a
considerable time on this topic when nobody else did.
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 18:15, Paul Schmehl wrote:
> --On October 21, 2013 7:48:59 AM +0200 John Marino
>
> The dependency is mysqltcl. That port installs two files in
> ${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/. How do you reference those
> files without using the portversion?
Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html
Something like this should work:
RUN_DEPENDS+= mysqltcl>3:${PORTSDIR}/databases/mysqltcl
With that line, you can forgot the shell command above. It means, use
any version of mysqltcl 3.0 or greater.
> When I work on my ports I create a new directory ${PORTNAME}-update.
> Then I svn the port into that directory, which creates a subdirectory
> named ${PORTNAME}. With ${.CURDIR}../../../ the build will not descend
> to /usr/ports but to /usr/ports/security and the build will break. I
> fail to see how that can be correct. If I build ports anywhere other
> than the default location, the build will break.
it would be ${.CURDIR}/../../
(notice slash immediate following ${.CURDIR} and only two "../". Really
only one is needed since since the port is in the same category. But
this is unnecessary if you make the change above.
>
> Is this information documented somewhere? And how do I overcome this
> obvious problem?
I don't know if it's documented or not. The more common occurrence is
trying to include a file from another port, rather than trying to "make"
a port (which has forked bombed me when it ran into an unexpected error
which is why I hate make in a shell so much).
> There are multiple ways to point out problems. One way is to point to
> the problem and say, "Look - you screwed up here." That's your way, and
> I can assure you it doesn't lend to a sense of cooperation and learning.
If you want to get pedantic, I never addressed you directly or by name.
I said the option wasn't properly tested (obviously true) and that
there were multiple problems with it (again true). I told the user to
open a PR and document it, and let the maintainer deal with it. I'm a
bit perplexed about why you are so sensitive about it. It's a honest
mistake, I think you learned from it, move on. Nobody thinks less, this
kind of thing is discovered all the time.
>
>> You know, you could have just said, "Thank you" as I've spent a
>> considerable time on this topic when nobody else did.
>>
>
> Yes, and you could have been a lot more pleasant. Don't forget, port
> maintainers are volunteers.
What do you think I am?
> maintainers are volunteers. I spend my personal time working on these
> problems, and the thanks I get from you is, hey, you screwed this up,
> you screwed that up, in fact, I can see five or six problems just from a
> brief look at your port instead of here's what the problem is, and
> here's a way to fix it.
1. I can't stress enough that you were never addressed directly or by name.
2. I only stated the truth
3. Do you really think I should do this for you? Or spoon-feed you? I
believe I gave you more than enough information to both understand the
problem and figure out the solution. that's how people learn.
>
> It's not an attitude that makes me want to get to work on fixing the
> problems.
>
How about pride in a job well done?
Again, I think you should accept this in the spirit it was given. If
you found it "unpleasant", I'm sorry but that wasn't the intention.
John
___
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: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 20:40, Paul Schmehl wrote:
> --On October 21, 2013 7:09:06 PM +0200 John Marino
>>
>> Look at section 5.8.9 of the Porters Handbook:
>> http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html
>>
>> Something like this should work:
>> RUN_DEPENDS+= mysqltcl>3:${PORTSDIR}/databases/mysqltcl
>>
> No, it won't. You can't use that construction on libraries, which is
> what mysqltcl is.
Are you as certain about that as you were about the RUN_DEPENDS line not
being a shell command before? As the handbook clearly states, you can
use that construction on RUN_DEPENDS. The fact that you want a library
out of the port is not relevant. It would install everything in the
mysqltcl port, including the library you desire.
The rest of your post doesn't merit a response.
John
___
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: www/w3m broken after update
On 10/22/2013 03:40, Kenta Suzumoto wrote:
> Maintainer has ignored emails. Any ideas what's causing this to fail?
>
> config.status: creating config.h
> config.status: executing po-directories commands
> config.status: creating po/POTFILES
> config.status: creating po/Makefile
> ===> Building for w3m-0.5.3_2
> (echo '#define DEFUN(x,y,z) x y'; sed -ne '/^DEFUN/{p;n;/^[ ]/p;}'
> ./main.c ./menu.c) | clang-cpp - | awk '$1 ~ /^[_A-Za-z]/ { for
> (i=2;i<=NF;i++) { print $i, $1} }' > funcname.tab.tmp
> funcname.tab updated
> sort funcname.tab | /usr/bin/awk -f ./funcname1.awk > funcname1.h
> clang -I. -I. -O2 -pipe -Qunused-parameter -Qunused-arguments
> -fno-strict-aliasing -I./libwc -I/usr/include/openssl -I/usr/local/include
> -I/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\"/usr/local/libexec/w3m\"
> -DCGIBIN_DIR=\"/usr/local/libexec/w3m/cgi-bin\"
> -DHELP_DIR=\"/usr/local/share/w3m\" -DETC_DIR=\"/usr/local/etc\"
> -DCONF_DIR=\"/usr/local/etc/w3m\" -DRC_DIR=\"~/.w3m\"
> -DLOCALEDIR=\"/usr/local/share/locale\" -c main.c
> main.c:836:23: error: assigning to 'GC_warn_proc' (aka 'void (*)(char *,
> GC_word)') from incompatible type 'void'
> orig_GC_warn_proc = GC_set_warn_proc(wrap_GC_warn_proc);
> ^ ~~~
> main.c:2264:37: warning: incompatible pointer types passing 'char **' to
> parameter of type 'wc_uchar **' (aka 'unsigned char **')
> [-Wincompatible-pointer-types]
> return wc_any_to_ucs(wtf_parse1(&p));
> ^~
> ./libwc/wtf.h:71:41: note: passing argument to parameter 'p' here
> extern wc_wchar_t wtf_parse1(wc_uchar **p);
> ^
> 1 warning and 1 error generated.
> *** [main.o] Error code 1
>
Yeah, I hit this in dports and patched it. I didn't realize it was
broken in ports too. Here's the patch I used to fix it:
http://gitweb.dragonflybsd.org/dports.git/blob_plain/HEAD:/www/w3m/dragonfly/patch-main.c
Regards,
John
___
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"
recent perl "mach/auto" not found error
I'm getting this error: find: /wrkdirs/devel/bzapi/work/stage/usr/local/lib/perl5/site_perl/5.14/mach/auto: No such file or directory On the following ports: devel/bzapi www/p5-RT-Authen-ExternalAuth www/p5-RT-Extension-LDAPImport www/p5-RT-Extension-MandatoryOnTransition www/p5-RT-Extension-SLA www/p5-RTx-Calendar It seems to come from r330925 (sunpoet) on Mk/Uses/perl5.mk (~line 265) Is anyone else seeing this? Is perl5.mk wrong to assume "auto" directory exists? John ___ 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: NO_STAGE: Bump PORTREVISION ? Pr class 'change' or 'update' ?
On 10/24/2013 10:05, Marco Steinbach wrote: > Hi, > > the 'FAQ on PORTREVISION' discussion found at [1] seems to suggest, that > enabling staging does not require a PORTREVISION bump. > > On the other hand, enabling staging seems to be a change in packaging, > although from a users perspective the packaged files don't change. And > a change in packaging is said to require a bump in PORTREVISION, > according to the referenced thread. Are you referring to man pages? I believe those were getting added to the plist internally before, so the final difference in plist before and after staging is zero (if man pages are the only item in question). > When enabling staging, is a maintainer supposed to bump PORTREVISION ? I don't see many PORTREVISION bumps as result of stage conversion (only). So I think not. > Is this then of class '[maintainer-]update' or just 'change' ? I think maintainer-updates only means the maintainer wrote the PR, so if that's the case, mark it maintainer-update. John ___ 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: State of the Porters' Handbook
On 10/28/2013 09:53, Dominic Fandrey wrote: > On 28/10/2013 09:47, Łukasz Wąsikowski wrote: >> W dniu 2013-10-28 09:41, Dominic Fandrey pisze: >> >>> Neither staging nor license management are described in the Porters' >>> Handbook. >>> >>> Why again should we bother to support it? >>> >>> What happened to "the feature that is not documented doesn't exist"? >> >> Lack of good documentation is real problem for me to convert ports to >> staging. Porter's Handbook is seriously lagging behind recent changes - >> staging, license management, shabang fixes, etc. > > If it was up for a vote, I'd vote for a feature stop until the PH > is back in a decent condition. > > Kudos to the people who documented the new options framework. > For all intents and purposes - licensing "feature" doesn't exist. The same issues you are raising have been raised before. Apparently the full licensing infrastructure is still lacking so it's in some kind of limbo. However, converting to stagedir is reasonably documented here: https://wiki.freebsd.org/ports/StageDir You don't have a choice with supporting stage -- new ports without stage aren't accepted. So that's why you have to bother. :) John ___ 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: State of the Porters' Handbook
On 10/28/2013 10:29, Dominic Fandrey wrote: > On 28/10/2013 09:58, John Marino wrote: >> On 10/28/2013 09:53, Dominic Fandrey wrote: >> However, converting to stagedir is reasonably documented here: >> https://wiki.freebsd.org/ports/StageDir > > That's a handfull. What about installers that hard-code directories > during install? They can hardcode into the stage directory. Anywhere else is wrong and has to be fixed. >> You don't have a choice with supporting stage -- new ports without stage >> aren't accepted. So that's why you have to bother. :) > > That doesn't sound acceptable, considering the feature isn't even > mentioned in the Porters' Handbook. Bapt has made several calls for help to document this in the Porters Handbook. He's said it's on his plate but he's behind and has asked for the help. Maybe you could help him out? John ___ 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: State of the Porters' Handbook
On 10/28/2013 10:54, Dominic Fandrey wrote: > On 28/10/2013 10:34, John Marino wrote: >> On 10/28/2013 10:29, Dominic Fandrey wrote: >>> >>> That's a handfull. What about installers that hard-code directories >>> during install? >> >> They can hardcode into the stage directory. Anywhere else is wrong and >> has to be fixed. > > But then they won't be usable once installed into /usr/local. If there are files in those directories, they'll be on the plist and stage handles them. I'd have to look up how to create empty directories properly. > >>>> You don't have a choice with supporting stage -- new ports without stage >>>> aren't accepted. So that's why you have to bother. :) >>> >>> That doesn't sound acceptable, considering the feature isn't even >>> mentioned in the Porters' Handbook. >> >> Bapt has made several calls for help to document this in the Porters >> Handbook. He's said it's on his plate but he's behind and has asked for >> the help. Maybe you could help him out? > > So far I see stage as a problem, not something I want to advance. I don't know how to respond to this. 1. It indicates that don't understand the benefits, nor that it's 5 years overdue, nor that its sorely needed 2. Stage is not going away. There is not another option. 3. You've been given a source of documentation. It's not in the handbook, but it does exist in some form. What more do you need to progress? John ___ 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: State of the Porters' Handbook
On 10/28/2013 11:16, Dominic Fandrey wrote: > On 28/10/2013 11:03, John Marino wrote: >> If there are files in those directories, they'll be on the plist and >> stage handles them. I'd have to look up how to create empty directories >> properly. > > Stage replaceses strings in installed files? No, the port does that kind of thing in the stage directory. After everything is installed there in the stage directory, they are packaged or installed into the $PREFIX > I can see the benefits for less error prone package building. But right now > it's just additional work coming my way. You really need to get a better grasp of the concept. There are several emails from bapt that may help. For new ports it's not "additional" work and for existing ports, yes there is a conversion but the benefits are worth it. >> 2. Stage is not going away. There is not another option. >> 3. You've been given a source of documentation. It's not in the >> handbook, but it does exist in some form. What more do you need to >> progress? > > There is a procedure. Stuff belongs into the handbook. Stick to it. Fine, but it's a huge topic that somebody has to write and validate. You're willing to criticize (justified) but unwilling to help rectify the problem. If you only want to complain, I think you've made your point (a point that everyone is already aware of). FYI, I have no dog in the hunt other than I believe stage is a welcome update to ports. John ___ 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: recent perl "mach/auto" not found error
On 10/26/2013 14:15, Matthew Seaman wrote:
> On 25/10/2013 09:09, Sunpoet Po-Chuan Hsieh wrote:
>> I've committed r331562. I forgot to add trailing "|| ${TRUE}".
>> It should *really* be fixed now.
>> I could build these ports successfully in tinderbox.
>> Please try again.
>
> That all seems to be working fine now. Thank you.
The ports that I reported as broken now build.
However, two new issues cropped up and it looks related.
databases/p5-Dancer-Plugin-Redis
> ===
> ===> Building package for p5-Dancer-Plugin-Redis-0.7
> pkg-static:
> lstat(/wrkdirs/databases/p5-Dancer-Plugin-Redis/work/stage/usr/local/lib/perl5/site_perl/5.16/mach/auto/Dancer/Plugin/):
> No such file or directory
> pkg-static:
> lstat(/wrkdirs/databases/p5-Dancer-Plugin-Redis/work/stage/usr/local/lib/perl5/site_perl/5.16/mach/auto/Dancer/):
> No such file or directory
> *** Error code 1
www/p5-Dancer-Termplate-Xslate
> ===
> ===> Building package for p5-Dancer-Template-Xslate-0.03
> pkg-static:
> lstat(/wrkdirs/www/p5-Dancer-Template-Xslate/work/stage/usr/local/lib/perl5/site_perl/5.16/mach/auto/Dancer/):
> No such file or directory
> *** Error code 1
Regards,
John
___
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"
