FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-zip broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-zip portname: audio/ruby-audiofile broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-audiofile portname: audio/ruby-mp3tag broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-mp3tag portname: databases/rubygem-bdb1 broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-bdb1 portname: databases/rubygem-memcache broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-memcache portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph portname: graphics/rubyphoto broken because: No public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=rubyphoto If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-zip broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-zip portname: audio/ruby-audiofile broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-audiofile portname: audio/ruby-mp3tag broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-mp3tag portname: databases/rubygem-bdb1 broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-bdb1 portname: databases/rubygem-memcache broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-memcache portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph portname: graphics/rubyphoto broken because: No public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=rubyphoto portname: science/rubygem-netcdf broken because: Does not build with new devel/ruby-gems build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=scienceportname=rubygem-netcdf If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha portname: archivers/ruby-zip broken because: Does not build with Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-zip portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. One common problem is that recent versions of FreeBSD use clang instead of gcc by default. Another common problem is that the compiles succeed on the i386 and amd64 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 8.x/9.x/10.x/-current with target architecture'.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha portname: devel/rubygem-igraph broken because: does not build with igraph-0.7.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-igraph If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-lha broken because: Does not build with Ruby 2.0 or Ruby 2.1 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-lha portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: devel/rubygem-sidekiq broken because: Infinite loop during install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-sidekiq portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-rmagick broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: print/ruby-panda broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=printportname=ruby-panda portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: databases/ruby-msql broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-msql portname: devel/ruby-amstd broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-amstd portname: devel/ruby-avl broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-avl portname: devel/ruby-robjectteam broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-robjectteam portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-rmagick broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: japanese/rbnamazu broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rbnamazu portname: japanese/rskkserv broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rskkserv portname: print/ruby-panda broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=printportname=ruby-panda portname: textproc/eruby broken because: broken with ruby1.9 threads build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=eruby portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff portname: textproc/ruby-html-fillinform broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-fillinform portname: textproc/ruby-html-template broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-template portname: www/mod_ruby broken because: broken with ruby1.9 threads build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=mod_ruby portname: www/ruby-div
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: databases/ruby-msql broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-msql portname: devel/ruby-amstd broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-amstd portname: devel/ruby-avl broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-avl portname: devel/ruby-robjectteam broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-robjectteam portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-rmagick broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: japanese/rbnamazu broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rbnamazu portname: japanese/rskkserv broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rskkserv portname: print/ruby-panda broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=printportname=ruby-panda portname: textproc/eruby broken because: broken with ruby1.9 threads build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=eruby portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff portname: textproc/ruby-html-fillinform broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-fillinform portname: textproc/ruby-html-template broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-template portname: www/mod_ruby broken because: broken with ruby1.9 threads build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=mod_ruby portname: www/ruby-div
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: databases/ruby-msql broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-msql portname: devel/ruby-amstd broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-amstd portname: devel/ruby-avl broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-avl portname: devel/ruby-robjectteam broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-robjectteam portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-rmagick broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: japanese/rbnamazu broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rbnamazu portname: japanese/rskkserv broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rskkserv portname: print/ruby-panda broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=printportname=ruby-panda portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff portname: textproc/ruby-html-fillinform broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-fillinform portname: textproc/ruby-html-template broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-template portname: www/ruby-div broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=ruby-div If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: databases/ruby-msql broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-msql portname: devel/ruby-amstd broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-amstd portname: devel/ruby-avl broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-avl portname: devel/ruby-robjectteam broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-robjectteam portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-rmagick broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: graphics/ruby-tgif broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: japanese/rbnamazu broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rbnamazu portname: japanese/rskkserv broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rskkserv portname: lang/ruby-doc-stdlib broken because: Checksum and size mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=langportname=ruby-doc-stdlib portname: print/ruby-panda broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=printportname=ruby-panda portname: textproc/ruby-diff broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-diff portname: textproc/ruby-html-fillinform broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-fillinform portname: textproc/ruby-html-template broken because: Not stage friendly, no more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=ruby-html-template portname: www/ruby-div broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=ruby-div If these errors are ones that you are
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: devel/rubygem-dep_selector broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-dep_selector portname: graphics/ruby-tgif broken because: Does not compile build errors: http://beefy1.isc.freebsd.org/bulk/10-release-i386-RELENG10_0/latest/logs/errors/ruby19-tgif-20010408_12.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-tgif portname: lang/ruby-doc-stdlib broken because: Checksum and size mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=langportname=ruby-doc-stdlib If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/ruby-esound broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: sysutils/rubygem-chef-solr broken because: fails to install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=rubygem-chef-solr If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: sysutils/rubygem-chef-solr broken because: fails to install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=rubygem-chef-solr If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: devel/ruby-io-reactor broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-io-reactor portname: devel/rubygem-linecache broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-linecache portname: graphics/ruby-opengl broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-opengl portname: sysutils/rubygem-chef-expander broken because: fails to install build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20131001065611.pointyhat/rubygem-chef-expander-10.24.0.log (Sep 2 12:14:37 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=rubygem-chef-expander portname: sysutils/rubygem-chef-solr broken because: fails to install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=rubygem-chef-solr portname: www/rubygem-mongrel broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=rubygem-mongrel portname: x11-toolkits/ruby-gtk broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: devel/ruby-fam broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-fam portname: devel/ruby-io-reactor broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-io-reactor portname: devel/ruby-jttui broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-jttui portname: devel/ruby-racc broken because: Builds but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-racc portname: devel/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-slang portname: devel/rubygem-linecache broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-linecache portname: devel/rubygem-ncurses broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ncurses portname: devel/rubygem-parsetree broken because: Builds with ruby 1.9, but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-parsetree portname: devel/rubygem-rparsec broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-rparsec portname: devel/rubygem-sdl broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-sdl portname: games/ruby-exmars broken because: does not build with ruby 1.9 build errors: none. overview:
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: devel/ruby-fam broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-fam portname: devel/ruby-io-reactor broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-io-reactor portname: devel/ruby-jttui broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-jttui portname: devel/ruby-racc broken because: Builds but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-racc portname: devel/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-slang portname: devel/rubygem-linecache broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-linecache portname: devel/rubygem-ncurses broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ncurses portname: devel/rubygem-parsetree broken because: Builds with ruby 1.9, but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-parsetree portname: devel/rubygem-pry broken because: fails to resolve dependencies build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.20130903111716.pointyhat/rubygem-pry-0.9.12.2.log (Sep 4 01:22:22 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-pry portname: devel/rubygem-rparsec broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-rparsec portname: devel/rubygem-sdl broken because: does not work with
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: devel/ruby-fam broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-fam portname: devel/ruby-io-reactor broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-io-reactor portname: devel/ruby-jttui broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-jttui portname: devel/ruby-racc broken because: Builds but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-racc portname: devel/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-slang portname: devel/rubygem-linecache broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-linecache portname: devel/rubygem-ncurses broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ncurses portname: devel/rubygem-parsetree broken because: Builds with ruby 1.9, but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-parsetree portname: devel/rubygem-rparsec broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-rparsec portname: devel/rubygem-sdl broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-sdl portname: games/ruby-exmars broken because: does not build with ruby 1.9 build errors: none. overview:
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: devel/ruby-fam broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-fam portname: devel/ruby-io-reactor broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-io-reactor portname: devel/ruby-jttui broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-jttui portname: devel/ruby-racc broken because: Builds but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-racc portname: devel/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-slang portname: devel/rubygem-linecache broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-linecache portname: devel/rubygem-parsetree broken because: Builds with ruby 1.9, but does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-parsetree portname: devel/rubygem-rparsec broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-rparsec portname: devel/rubygem-sdl broken because: does not work with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-sdl portname: games/ruby-exmars broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=ruby-exmars portname: graphics/ruby-opengl broken because: does not build with ruby 1.9 build errors: none. overview:
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: japanese/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-slang portname: x11-toolkits/ruby-gtk broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: japanese/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-slang portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema portname: x11-toolkits/ruby-gtk broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: japanese/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-slang portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema portname: x11-toolkits/ruby-gtk broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: devel/rubygem-celluloid broken because: does not build with ruby 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-celluloid portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema portname: x11-toolkits/ruby-gtk broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: devel/rubygem-celluloid broken because: does not build with ruby 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-celluloid portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema portname: x11-toolkits/ruby-gtk broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=ruby-gtk If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120910204647/rubygem-dm-core-1.2.0.log (_Aug_18_17:45:00_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20120830224141/rubygem-dm-core-1.2.0.log (_Aug_10_14:37:37_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.8.20120812220927/ja-rubygem-myrurema-0.3.0.log (_Aug_19_05:48:13_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-core broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20120823191909/rubygem-dm-core-1.2.0.log (_Aug_10_14:37:37_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-core portname: japanese/rubygem-myrurema broken because: unable to resolve dependencies build errors: http://pointyhat.FreeBSD.org/errorlogs/i386-errorlogs/e.7.20120816063236/ja-rubygem-myrurema-0.3.0.log (_Aug_18_17:54:21_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=rubygem-myrurema If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: graphics/ruby-rmagick broken because: does not configure build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.8.20120618070605/ruby18-rmagick-2.13.1_3.log (_Jun_19_10:27:09_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: graphics/ruby-rmagick broken because: does not configure build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.8.20120618070605/ruby18-rmagick-2.13.1_3.log (_Jun_19_10:27:09_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-rmagick portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: converters/ruby-lv broken because: has not patched in quite some time build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=ruby-lv portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: converters/ruby-lv broken because: has not patched in quite some time build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=ruby-lv portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: devel/rubygem-ruby-debug-ide broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.9.20120118054720/rubygem-ruby-debug-ide-0.4.16.log (_Jan_14_19:22:40_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ruby-debug-ide portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: converters/ruby-lv broken because: has not patched in quite some time build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20120224133819/ruby18-lv-0.12.log (_Feb_27_21:49:46_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=ruby-lv portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: databases/rubygem-delayed_job_data_mapper broken because: delayed_job_data_mapper requires delayed_job (~ 2.1) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-delayed_job_data_mapper portname: databases/rubygem-dm-active_model broken because: dm-active_model requires activemodel (~ 3.1.0) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=rubygem-dm-active_model portname: devel/rubygem-ruby-debug-ide broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.9.20120118054720/rubygem-ruby-debug-ide-0.4.16.log (_Jan_14_19:22:40_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ruby-debug-ide portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: devel/rubygem-ruby-debug-ide broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.9.20111228135944/rubygem-ruby-debug-ide-0.4.16.log (_Jan_14_19:22:40_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ruby-debug-ide portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: databases/ruby-kyotocabinet broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-kyotocabinet portname: devel/rubygem-ruby-debug-ide broken because: incomplete plist build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.8.20120117102223/rubygem-ruby-debug-ide-0.4.16.log (_Dec_30_03:49:07_UTC_2011) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-ruby-debug-ide portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: japanese/ruby-refe broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-refe portname: www/redmine broken because: Does not work with RubyGems 1.8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=redmine If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: japanese/ruby-refe broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-refe If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: japanese/ruby-refe broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-refe If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/ruby-rbbr broken because: does not package build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20110830071000/ruby18-rbbr-0.6.0_8.log (_Sep__3_17:26:10_UTC_2011) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ruby-rbbr portname: japanese/ruby-refe broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-refe If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: japanese/ruby-refe broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-refe portname: japanese/ruby-slang broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=ruby-slang If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: devel/rubygem-newgem broken because: Depends on broken devel/rubygem-rubigen build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-newgem portname: devel/rubygem-rubigen broken because: Depends on exact vesion of activesupport 2.3.5 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-rubigen portname: graphics/ruby-redact broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=ruby-redact If these errors are ones that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Every effort has been made to make sure that these error reports really do correspond to a port that you maintain. However, due to the fact that this is an automated process, it may indeed generate false matches. If one of these errors fits that description, please forward this email to the author of this software, Mark Linimon lini...@freebsd.org, so that he can attempt to fix the problem in the future. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to freebsd-ruby-unsubscr...@freebsd.org
