Re: Please test your commits
On 02/17/2012 10:22, Mark Linimon wrote: On Sun, Feb 12, 2012 at 08:35:05PM +, Michael Scheidell wrote: Public flogging seems to be more enjoyable than a private email to the developer, the maintainer, and a committer. I know we are all a little frustrated with some of the local commits, but remember: praise in public, criticize in private. I agree that praise in public is a maxim. I think we can also agree that all forms of $person has had a lot of 'issues,' can portmgr assign some remediation here? should be private. Where I think reasonable minds can differ are (appropriate) responses of the form, This was not done properly, here is how it can/should be done (better). IMO those should *always* be public in order to help others who are paying attention to the same topic. By not making these things public all we do is create a cycle developer after developer doing it wrong because the right way was never made obvious to them. (And no, good documentation is not enough. Just look at how many times I've had to repeat the same (basic) points about rc.d scripts.) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Please test your commits
On Sat, Feb 18, 2012 at 03:59:37PM -0800, Doug Barton wrote: Where I think reasonable minds can differ are (appropriate) responses of the form, This was not done properly, here is how it can/should be done (better). IMO those should *always* be public in order to help others who are paying attention to the same topic. Fair enough. Perhaps I should have been more clear about the distinction I make between constructive criticism (this code would be more effectively stated xyz) vs. non-constructive criticism (your mother smells of elderberries.) I was thinking more of the latter when I replied, perhaps after wincing at some recent threads. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On 02/18/2012 19:03, Mark Linimon wrote: On Sat, Feb 18, 2012 at 03:59:37PM -0800, Doug Barton wrote: Where I think reasonable minds can differ are (appropriate) responses of the form, This was not done properly, here is how it can/should be done (better). IMO those should *always* be public in order to help others who are paying attention to the same topic. Fair enough. Perhaps I should have been more clear about the distinction I make between constructive criticism (this code would be more effectively stated xyz) vs. non-constructive criticism (your mother smells of elderberries.) I thought it went without saying that those messages just shouldn't be sent. Doug (typed out maybe, but not sent) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Please test your commits
On Sun, Feb 12, 2012 at 08:35:05PM +, Michael Scheidell wrote: Public flogging seems to be more enjoyable than a private email to the developer, the maintainer, and a committer. I know we are all a little frustrated with some of the local commits, but remember: praise in public, criticize in private. This is a good management dictum. I try to follow it and though I often fail, I try. Let's all keep in mind that the only reward most ports maintainers/committers do indeed get is the occasional bit of praise. Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On Sun, Feb 12, 2012 at 03:22:38PM -0600, Stephen Montgomery-Smith wrote: Also, if everyone starts using [redports], isn't the backlog going to become huge? We're working on getting more hardware. Having something become too successful is a problem we should be happy to have :) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. There is nothing strange about them: they just indicate errors arising from invalid choices of OPTIONS. The build is more likely to be broken by MANUAL_PACKAGE_BUILD, which uses IGNORE. math/atlas is a port that -- except in a few cases -- must be built on the host machine in a dedicated build. If you have a port that has a dependency on math/atlas, then it will not be easy to test that port via a system like Redports. With regard to the larger issue, ghostscript is a somewhat awkward port to check, because: it has many dependencies; it has many options that are used by a considerable number of people; it is maintained by a group (although Hiroki usually works on it); and it is widely-used. Even with a reasonable amount of testing (and Hiroki is usually careful), it is probable that there will be some occasional problems, at least when ghostscript is not built in a clean sandbox -- and it isn't on the live systems of many users. So while it is reasonable to send a message about a port like this to the list, the message should also be dispatched directly to doceng, and those making reports or complaints should be patient, and provide as much useful information as possible. b. ___ 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: Please test your commits
On 02/14/12 08:40, b. f. wrote: On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. There is nothing strange about them: they just indicate errors arising from invalid choices of OPTIONS. The build is more likely to be broken by MANUAL_PACKAGE_BUILD, which uses IGNORE. That would explain the problems I am having. I'll quit trying to test sage on redports. ___ 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: Please test your commits
On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. Although, it also didn't work on report when I asked for an amd64 build. So it still didn't help me testing math/sage. I ended up relying on another user who politely informed me of build errors on his system, and was kind enough to try my patches. No objections from my side. You did the best you could and have some logfiles that prove that. So it is also a bit my fault for not implementing to show the exact IGNORE line but I have added it to my todo and will fix that. http://redports.org/buildarchive/20120208022438-13714/ Also, if everyone starts using it, isn't the backlog going to become huge? I'll let the redports team worry about this :-) Fair enough. A huge backlog is usually not a problem because there are build priorities and an somewhat intelligent scheduler so you won't end up waiting a day until the first build is finished. Also right now on very busy days the backend catches up during the night so build capacity is not too underpowered right now. I'm still working on getting more machines but that takes some time. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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
Please test your commits
Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/ghostscript9/Makefile Committed 75 minutes ago. laptop:root[202] cd /usr/ports/print/ghostscript9 laptop:root[203] make In file included from openjpeg/libopenjpeg/bio.c:32: openjpeg/libopenjpeg/opj_includes.h:80:6: warning: __STDC_VERSION__ is not defined In file included from openjpeg/libopenjpeg/opj_malloc.h:89, from openjpeg/libopenjpeg/opj_includes.h:108, from openjpeg/libopenjpeg/bio.c:32: /usr/include/malloc.h:3:2: error: #error malloc.h has been replaced by stdlib.h gmake[2]: *** [soobj/opj_bio.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 *** Error code 1 Stop in /usr/ports/print/ghostscript9. *** Error code 1 -- Steve ___ 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: Please test your commits
On 12 Feb 2012 19:39, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? Could this not have gone directly to the 'offending' developer? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On Sun, Feb 12, 2012 at 08:03:28PM +, Chris Rees wrote: On 12 Feb 2012 19:39, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? Could this not have gone directly to the 'offending' developer? You seem to have the faulty belief that this is the first occurence of this type of issue? portmgr should immediately revert the commit. In fact, after changing the source code to avoid the malloc.h issue, one runs into cp ./soobj/openjpeg_0.dev ./soobj/openjpeg.dev cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -march=native -fno-strict-aliasing -g -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE=unsigned long long -O2 -pipe -march=native -fno-strict-aliasing -DUSE_LIBICONV_GNU -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\/usr/local/lib/ghostscript/9.05\ -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this function) gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 -- Steve ___ 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: Please test your commits
on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) -- Andriy Gapon ___ 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: Please test your commits
On 02/12/2012 01:39 PM, Steve Kargl wrote: Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/ghostscript9/Makefile You should report which version of FreeBSD you are using. It might have tested OK for the committer, but not for you. By the way, I didn't get the error you reported in your first message, but I did get the error reported in your later message. I am using FreeBSD 8.2 STABLE on the amd64. You seem to have the faulty belief that this is the first occurrence of this type of issue? The same committer? Or someone else. If it is a repeat offense, I can see why you would want to blow off some steam. However as a committer myself, I do like it when someone politely points out my error, and gives me a chance to correct myself. For example, I recently had a very pleasant exchange with someone who helped me fix my math/sage port for FreeBSD 9. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
Public flogging seems to be more enjoyable than a private email to the developer, the maintainer, and a committer. But I suppose it beats doing a backup of your envirement first. -- Michael Scheidell, CTO |SECNAP Network Security -Original message- From: Andriy Gapon a...@freebsd.org To: Steve Kargl s...@troutmask.apl.washington.edu Cc: freebsd-ports@FreeBSD.org freebsd-ports@FreeBSD.org, Chris Rees utis...@gmail.com Sent: Sun, Feb 12, 2012 20:28:23 GMT+00:00 Subject: Re: Please test your commits on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) -- Andriy Gapon ___ 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: Please test your commits
On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. -- Steve ___ 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: Please test your commits
On 12 Feb 2012 20:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. uname -a? Please do this the proper way; as a developer yourself you should know better. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On Sun, Feb 12, 2012 at 08:44:11PM +, Chris Rees wrote: On 12 Feb 2012 20:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. uname -a? Please do this the proper way; as a developer yourself you should know better. laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 -- Steve ___ 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: Please test your commits
On 02/12/2012 02:41 PM, Steve Kargl wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. Except I didn't get the malloc.h error when I tried compiling it. So merely noting the age of malloc.h doesn't prove that the committer didn't test it. ___ 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: Please test your commits
on 12/02/2012 22:41 Steve Kargl said the following: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. Right, of course, sure. Modern software projects all consist of a handful of C files and a trivial makefile. No autotools or other makefile generators. No bugs in them, etc. -- Andriy Gapon ___ 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: Please test your commits
On Sun, 12 Feb 2012 20:35:05 + Michael Scheidell articulated: Public flogging seems to be more enjoyable than a private email to the developer, the maintainer, and a committer. But I suppose it beats doing a backup of your envirement first. I put it right up there with Top Posting myself in terms of arrogance. In any case, I might suggest (which assures it will never come to pass) that the submitter of a port list somewhere, perhaps a separate file, a list of all the environments that the port was actually tested under. If a port was never tested under amd 64 for instance, it might be helpful for a potential user to know that prior to attempting to use said port. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On 12 Feb 2012 20:45, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Feb 12, 2012 at 08:44:11PM +, Chris Rees wrote: On 12 Feb 2012 20:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. uname -a? Please do this the proper way; as a developer yourself you should know better. laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 Well, that immediately shows that this is a 10.0 error, which means it's almost certainly due to freebsd1* being matched in some configure script. This was not a case of zero testing, so please submit a PR. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
on 12/02/2012 22:45 Stephen Montgomery-Smith said the following: On 02/12/2012 02:41 PM, Steve Kargl wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. Except I didn't get the malloc.h error when I tried compiling it. So merely noting the age of malloc.h doesn't prove that the committer didn't test it. Today I became another user of redports.org. I can definitely recommend it. -- Andriy Gapon ___ 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: Please test your commits
On Sun, Feb 12, 2012 at 08:52:56PM +, Chris Rees wrote: On 12 Feb 2012 20:45, Steve Kargl s...@troutmask.apl.washington.edu wrote: laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 Well, that immediately shows that this is a 10.0 error, which means it's almost certainly due to freebsd1* being matched in some configure script. Empirical evidence suggests that ghostscript9 developers are using a newer version of the autotools. laptop:root[262] find . -name configure | xargs grep -i freebsd\[1 | more ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure: freebsd[12].*) ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./freetype/builds/unix/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure: freebsd[12].*) ./lcms2/configure:freebsd[123].*) objformat=aout ;; laptop:root[263] find . -name configure | xargs grep -i freebsd1 | more ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) The malloc issue will not appear on amd64 because the problematic code is #elif !defined(__amd64__) !defined(__APPLE__) #define HAVE_MEMALIGN #include malloc.h #endif with the obvious fix #elif !defined(__amd64__) !defined(__APPLE__) !defined(__FreeBSD__) #define HAVE_MEMALIGN #include malloc.h #endif But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. -- Steve ___ 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: Please test your commits
On Sun, 12 Feb 2012, Stephen Montgomery-Smith wrote: You should report which version of FreeBSD you are using. It might have tested OK for the committer, but not for you. I'm watching a tinderbox run right now and it seems to fail on i386 only; amd64 looks ok. I just sent a full log to the maintainer. -- jimmy ___ 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: Please test your commits
On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. Also, if everyone starts using it, isn't the backlog going to become huge? ___ 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: Please test your commits
On 02/12/2012 03:17 PM, Steve Kargl wrote: On Sun, Feb 12, 2012 at 08:52:56PM +, Chris Rees wrote: On 12 Feb 2012 20:45, Steve Kargls...@troutmask.apl.washington.edu wrote: laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 Well, that immediately shows that this is a 10.0 error, which means it's almost certainly due to freebsd1* being matched in some configure script. Empirical evidence suggests that ghostscript9 developers are using a newer version of the autotools. laptop:root[262] find . -name configure | xargs grep -i freebsd\[1 | more ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure: freebsd[12].*) ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./freetype/builds/unix/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure: freebsd[12].*) ./lcms2/configure:freebsd[123].*) objformat=aout ;; laptop:root[263] find . -name configure | xargs grep -i freebsd1 | more ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) The malloc issue will not appear on amd64 because the problematic code is #elif !defined(__amd64__) !defined(__APPLE__) #define HAVE_MEMALIGN #includemalloc.h #endif with the obvious fix #elif !defined(__amd64__) !defined(__APPLE__) !defined(__FreeBSD__) #define HAVE_MEMALIGN #includemalloc.h #endif But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. Yes. But the issue isn't whether someone else was correct in why the port might or might not have built in a particular environment. The issue is whether you were too hasty in your initial accusation that the committer didn't test their commit. And another issue is whether you should apologize to them for attempting to publicly humiliate them. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Also, if everyone starts using it, isn't the backlog going to become huge? I'll let the redports team worry about this :-) -- Andriy Gapon ___ 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: Please test your commits
on 12/02/2012 23:17 Steve Kargl said the following: Empirical evidence suggests that ghostscript9 developers are using a newer version of the autotools. laptop:root[262] find . -name configure | xargs grep -i freebsd\[1 | more ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure: freebsd[12].*) ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./freetype/builds/unix/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure: freebsd[12].*) ./lcms2/configure:freebsd[123].*) objformat=aout ;; laptop:root[263] find . -name configure | xargs grep -i freebsd1 | more ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) The malloc issue will not appear on amd64 because the problematic code is #elif !defined(__amd64__) !defined(__APPLE__) #define HAVE_MEMALIGN #include malloc.h #endif with the obvious fix #elif !defined(__amd64__) !defined(__APPLE__) !defined(__FreeBSD__) #define HAVE_MEMALIGN #include malloc.h #endif But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. BTW, I've just built the port here (FreeBSD 10.0-CURRENT #225 r231019 amd64) without running into any problems. make showconfig output: === The following configuration options are available for ghostscript9-9.05: A4SIZE=on Set A4 (not Letter) as a default paper size CUPS=on Enable CUPS support FONTCONFIG=on fontconfig support GTK=off GTK frontend X11=on X11 support GS_x11=on D: X Window System version 11 GS_x11alpha=on D: X Window System masquer. alpha capability GS_x11cmyk=on D: X Window System masquer. 1bit/plane CMYK GS_x11cmyk2=on D: X Window System 2-bit-per-plane CMYK GS_x11cmyk4=on D: X Window System 4-bit-per-plane CMYK GS_x11cmyk8=on D: X Window System 8-bit-per-plane CMYK GS_x11gray2=on D: X Window System 2-bit gray-scale GS_x11gray4=on D: X Window System 4-bit gray-scale GS_x11mono=on D: X Window System masquer. black-and-white GS_x11rg16x=on D: X Window System G5/B5/R6 pixel layout GS_x11rg32x=on D: X Window System G11/B10/R11 pixel layout GS_lvga256=off D: SVGAlib, 256-color VGA modes GS_vgalib=off D: SVGAlib, 16-color VGA modes GS_oprp=on D: OpenPrinting Raster driver interface GS_opvp=on D: OpenPrinting Vecter driver interface GS_cups=on D: CUPS driver GS_display=on D: display device for GS shared library GS_omni=on D: Omni driver GS_md2k=on D: ALPS MD-2000/2010/4000/1300/1500/5000 GS_md5k=on D: ALPS MD-5000 Eco Mode GS_md50Mono=on D: ALPS MD-5000 Monochrome GS_md50Eco=on D: ALPS MD-5000 Eco Mode GS_md1xMono=on D: ALPS MD-1x00 Monochrome GS_appledmp=on D: Apple Dot Matrix Printer/Imagewriter GS_iwhi=on D: Apple Imagewriter, high-resolution mode GS_iwlo=on D: Apple Imagewriter, low-resolution mode GS_iwlq=on D: Apple Imagewriter LQ in 320x216dpi mode GS_hl7x0=on D: Brother HL-720/730/760(=PCL), MFC6550MC GS_hl1240=on D: Brother HL-1030/1240 GS_hl1250=on D: Brother HL-1050/1070/1250/1270N GS_bj10e=on D: Canon BJ-10e GS_bj10v=on D: Canon BJ-10v GS_bj10vh=on D: Canon BJ-10v, high-mergin GS_bj200=on D: Canon BJ-200/BJC-240(mono) GS_bjc600=on D: Canon BJC-600/4xxx/70, StyleWriter 2x00 GS_bjc800=on D: Canon BJC-240/800 GS_bjccmyk=on D: Canon BJC-210/240/250/265/1000 GS_bjccolor=on D: Canon BJC-210/240/250/265/1000 truecolor GS_bjcgray=on D: Canon BJC-210/240/250/265/1000 grayscale GS_bjcmono=on D: Canon BJC-210/240/250/265/1000 monochrome GS_lbp8=on D: Canon LBP-8II GS_lbp310=on D: Canon LBP-310 GS_lbp320=on D: Canon LBP-320 Pro/LBP-350 GS_lips2p=on D: Canon LIPS II+ GS_lips3=on D: Canon LIPS III GS_lips4=on D: Canon LIPS IV GS_bjc880j=on D: Canon LIPS IVc, BJC-680J/880J GS_lips4v=on D: Canon LIPS IV, vector output mode GS_m8510=on D: C.Itoh M8510 printer GS_coslw2p=on D: CoStar LabelWriter II II/Plus GS_coslwxl=on D: CoStar LabelWriter XL GS_uniprint=on D: Configurable ESC/P,ESC/P2,HP-RTL/PCL,P2X GS_dmprt=on D: Configurable dot matrix printer driver GS_dl2100=on D: DEC DL2100 GS_la50=on D: DEC LA50 GS_la70=on D: DEC LA70 GS_la75=on D: DEC LA75
Re: Please test your commits
On Sun, Feb 12, 2012 at 03:32:52PM -0600, Stephen Montgomery-Smith wrote: But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. Yes. But the issue isn't whether someone else was correct in why the port might or might not have built in a particular environment. The issue is whether you were too hasty in your initial accusation that the committer didn't test their commit. And another issue is whether you should apologize to them for attempting to publicly humiliate them. I've now tested on i386 and amd64, and the port fails to build on both architectures. Given the code for the malloc.h failure, this port will fail on all non-amd64 platforms that freebsd runs (dating back FreeBSD 5.0). The evidence suggests that this commit was not tested. -- Steve ___ 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: Please test your commits
On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= Although, it also didn't work on report when I asked for an amd64 build. So it still didn't help me testing math/sage. I ended up relying on another user who politely informed me of build errors on his system, and was kind enough to try my patches. Also, if everyone starts using it, isn't the backlog going to become huge? I'll let the redports team worry about this :-) Fair enough. ___ 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: Please test your commits
On 12 Feb 2012 21:37, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Feb 12, 2012 at 03:32:52PM -0600, Stephen Montgomery-Smith wrote: But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. Yes. But the issue isn't whether someone else was correct in why the port might or might not have built in a particular environment. The issue is whether you were too hasty in your initial accusation that the committer didn't test their commit. And another issue is whether you should apologize to them for attempting to publicly humiliate them. I've now tested on i386 and amd64, and the port fails to build on both architectures. Given the code for the malloc.h failure, this port will fail on all non-amd64 platforms that freebsd runs (dating back FreeBSD 5.0). The evidence suggests that this commit was not tested. Whatever. Others have pointed out that they can't reproduce your error, so save the posturing, and get a PR in. Thank you. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On Sun, 12 Feb 2012 21:48:57 +0100 (CET) Jimmy Olgeni articulated: On Sun, 12 Feb 2012, Stephen Montgomery-Smith wrote: You should report which version of FreeBSD you are using. It might have tested OK for the committer, but not for you. I'm watching a tinderbox run right now and it seems to fail on i386 only; amd64 looks ok. I just sent a full log to the maintainer. I can confirm that it fails on a FreeBSD 8.2-STABLE amd64 machine. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
