[FreeBSD-Ports-Announce] Blanket approval to modernize the Ports Tree
In years gone by, and I am thinking of FreeBSD 7.0 specifically, portmgr@ gave some latitude to *ALL* committers to just fix things to get a port into shape. In the case of 7.0, it was making ports build for gcc4. What we have laying ahead of us is a ports tree in various states of modern preparedness (new style USES=, stagefication, etc) and the old way of doing ports (boo!). We would like committers, and contributors to generate a PR and/or just fix the old ports to update them to the new way of doing things regardless of maintainership. We are looking for fixes in the following areas - Convert to LIB_DEPENDS - stagify ports - convert things like USE_GMAKE - USES=gmake USE_DOS2unix - USES=dos2unix etc. This can be done with implicit portmgr@ blanket approval, and without maintainer approval. Please, however, respect some boundaries, do not change ports belonging to kde@, gnome@ or x11@. These teams work in private repos that may have changes pending. Also, cross reference GNATS, to see if a port has an open PR that you can factor into the fix. It is important to stress here that we *DO NOT* want to invalidate existing patches that a maintainer has offered up or already approved. If the change is very trivial AND has been tested, just fix it. One of the strengths of the Ports Collection is it's volunteer maintainers, if you make a change, regardless of how trivial, just send a courtesy email to the maintainer. http://blogs.freebsdish.org/portmgr/2014/01/07/blanket-approval-to-modernize-the-ports-tree/ ___ freebsd-ports-announce@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports-announce To unsubscribe, send any mail to freebsd-ports-announce-unsubscr...@freebsd.org
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/185526weechat problem after upgrading to ncurses-5.9.2013122 f ports/185522science/paraview build failure: TK/Utilities/vtkmetaio o ports/185518emulators/generator-cbiere: Fix build with clang o ports/185517net/net6: Fix build on -current o ports/185515audio/bmp-mac: Fix build with clang o ports/185514graphics/lfview: Fix build on -current o ports/185512audio/bmp-flac: Fix build with clang o ports/185509net/mknbi: Support CC/CFLAGS properly o ports/185508emulators/generator: Fix build with clang o ports/185507net/latd: Fix build with clang o ports/185506net/netmap: Fix build with clang o ports/185503textproc/soothsayer: Update MASTER_SITES and WWW: line o ports/185502games/typespeed: Support CC properly o ports/185501net/aget: Support CC/CFLAGS properly o ports/185500emulators/xbraitenberg: Fix build with clang o ports/185499audio/calf: Fix build with clang f ports/185492astro/qlandkartegt : update to 1.7.5 f ports/185491audio/libmikmod : update to 3.1.15 o ports/185484[MAINTAINER] databases/tcl-sqlite3: update to 3.8.2 o ports/185483[NEW PORT] databases/pgrouting f ports/185482[patch] ports/mail/qpopper fails to install o ports/185479[new port] games/tome4 f ports/185475multimedia/xbmc: patch to add XRANDR knob f ports/185467[PATCH] net-mgmt/zabbix22-frontend: permit building wi o ports/185466[maintainer update] update multimedia/xbmc to 13.0 alp o ports/185462[PATCH] graphics/ImageMagick update to 6.8.8-1 f ports/185460sysutils/tarsnap: support staging o ports/185459New port: net-p2p/namecoin (ver Q.3.72) o ports/185458[NEW PORT] devel/llnextgen parser generator o ports/185455[PATCH] security/bro: Fix pkg-fallout issue, f ports/185452[PATCH] security/maia: lots of fixes o ports/185444[NEW PORT] revive port games/wesnoth-devel f ports/185439security/openvpn-auth-radius: Fix build with clang o ports/185412net-mgmt/zabbix22-server: update f ports/185407[Patch] devel/codeblocks requires GCC f ports/185405[Patch] sysutils/fonteditfs fix build when no GCC inst f ports/185398Fix comms/xmorse build with Clang o ports/185394sysutils/ldap-account-manager version update; fixed NO o ports/185363[NEW PORT] revive port devel/thistest o ports/185362[NEW PORT] emulators/petitecloud (resubmittal after ma o ports/185358graphics/jbig2dec TESTS option missing dependency f ports/185354[PATCH] sysutils/xmbmon: fix binary strip o ports/185350graphics/xmms-blursk: Fix build with clang o ports/185349misc/gkrellmlaunch2: Support CC properly o ports/185347misc/najitool: Support CC/CFLAGS properly o ports/185346graphics/gkrellkam2: Support CC properly o ports/185345graphics/xmms-dancingparticles: Fix build with clang o ports/185341games/tornado: Update MASTER_SITES and WWW: line o ports/185340audio/xmms-wma: Fix build with clang o ports/185339security/poly1305aes: Fix build with clang o ports/185337graphics/xmms-fishmatic: Fix build with clang o ports/185335mail/bbmail: Fix build with clang o ports/185334emulators/hugo: Fix build with clang o ports/185333sysutils/kdirstat: Fix build with clang o ports/185332games/species: Fix build with clang o ports/185330multimedia/xmms-status-plugin: Fix build with clang o ports/185328audio/xmms-modplug: Fix build with clang o ports/185327audio/last.fm: Fix build with clang o ports/185322emulators/cpmemu: Fix build with clang o ports/185320misc/libutf: Prevent stripping symbols from static lib o ports/185319net-im/jabber: Fix build o ports/185318graphics/ipe: Fix build with clang o ports/185317net-p2p/minder: Fix build o ports/185316audio/mixxx: Fix build with clang o ports/185313graphics/xmms-gdancer: Fix build with clang o ports/185312irc/darkbot: Support CC/CFLAGS properly o ports/185311x11-clocks/wmtime: Fix build with clang o ports/185310emulators/tuxnes:
RE: Request for strongSwan and Poptop (pptpd) ports update
Hi Dewayne Those vulnerabilities is fixed in version 5.1.1 for which the patch is already submitted, but have not yet been applied. I will submit a new patch now with high availability feature removed since this is not working correctly when I performed further testing on the port. I was still waiting for a committer to submit the changes to the ports tree. Kind regards Francois ten Krooden From: Dewayne Geraghty [dewayne.gerag...@heuristicsystems.com.au] Sent: Monday, January 06, 2014 8:21 AM To: dycuo123; strongswan Cc: po...@freebsd.org Subject: Re: Request for strongSwan and Poptop (pptpd) ports update On 5/01/2014 6:08 AM, dycuo123 wrote: Hi,there Do you guys have some time to update these two? Many thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Its probably better if you direct your request to the maintainer of the port, ideally using http://www.freebsd.org/send-pr.html, identifying the upgrade benefits and further details to pique their interest. For example, strongswan: Current ports version is 5.0.4 and released version by strongswan is 5.1.1 (version 5.1.2 is scheduled for February) Reasons for the request are: 1. Rectification of security vulnerabilities allowing Denial of Service: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6075 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6076 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5018 2. Rectification of security vulnerabilities allowing user impersonation and bypassing access restrictions CVE-2013-6075 (above) 3. Refer to change log http://wiki.strongswan.org/projects/strongswan/wiki/Changelog51, specifically ... But of course the first thing to do is to use http://www.freebsd.org/cgi/query-pr-summary.cgi to check if the request has already been made. And in this instance it has! Please refer to http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/183688 And given the outstanding CVEs I'd suggest that you apply the patches, if you're going to use this port; pending maintainer's availability. Francois, I've included you, as the CVE's should push this update from a low priority/non-critical category to a medium given that it can be DOS'ed via the network without authentication. (And unfortunately IKEv1 is required for iPhone clients using IPSEC) Regards, Dewayne. Important Notice: This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at: http://www.nanoteq.com/AboutUs/EmailDisclaimer.aspx ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
CFT for cairo 1.12 and 8.x survey
This is a resent with additional CC of the stable@ ML. This was done to get more exposure, because the first mail didn't get much reaction. When replying please only reply to freebsd-x11@, freebsd-ports@ and freebsd-stable@ are only used to get this a bigger audience. Greetings! This is a weird call for testers. First off before the real CFT. We are interested if people are still using 8.x for there desktop. Is there a specific reason for not updating to 9.x or 10.x? So in our quest for push Xorg on FreeBSD further, we are looking for people to test cairo 1.12 primarily with the old Xorg stack. We know that the graphics with the 2.7.1 intel driver are horribly broken (lots of artifacts) so people don't need to test that, but what is the state of the other xorg video drivers with cairo 1.12? If problems arise after the update, a screenshot and details about installed ports and your hardware should be enough. But if your using the intel driver with old xorg please chime in too, this will give us a beter idea about the user base. While this CFT is focused on the non-WITH_NEW_XORG that should not stop people that are using WITH_NEW_XORG from trying it out. The Intel/Radeon KMS drivers shouldn't have any problem with cairo 1.12. To apply the patch do the following: Download the patch from [1]. cd /usr/ports patch -p0 /path/to/cairo-1.12.16.diff rebuild cairo -Koop [1] http://people.freebsd.org/~kwm/cairo-1.12.16.diff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
calling Maintainer timeout
Hi, I'd like to call for maintainer timeout on some PRs I filed. These PRs are part of the preparations for upgrading lang/gcc to gcc 4.7, which I'm helping gerald@ with. All PRs were filed on 2013-12-07 (and most of that batch have already been comitted), but to move things forward - these are the open PRs: ports/184565 cad/meshlab : fix build with GCC 4.7, unbreak ports/184571 math/abacus : fix build with gcc47 ports/184574 lang/ratfor : fix build with gcc47 ports/184575 textproc/ctpp2 : fix build with gcc47 Regards, Christoph -- Spare Space ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Problem with ports after upgrade of Perl to 5.16.3_6 - overload arg '..' is invalid at Math/BigInt.pm line 153.
Kurt Jaeger wrote: Hi! After this upgrade, each port using Math/BigInt.pm shows warning: # service sqlgrey restart Stopping sqlgrey. Waiting for PIDS: 986. Starting sqlgrey. overload arg '..' is invalid at /usr/local/lib/perl5/site_perl/5.16/Math/BigInt.pm line 153. [...] Is it known problem? I have seen it before. Fix: Comment out the line 153 in /usr/local/lib/perl5/site_perl/5.16/Math/BigInt.pm. Root cause is in math/p5-Math-BigInt: It overloads lots of operations, one of them isn't even in perl yet 8-} # not supported by Perl yet '..'= \_pointpoint, Should I file a PR? Yes, please. Thank you for your explanation. I filed a PR ports/185541 http://www.freebsd.org/cgi/query-pr.cgi?pr=185541 Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Blanket approval to modernize the Ports Tree
In years gone by, and I am thinking of FreeBSD 7.0 specifically, portmgr@ gave some latitude to *ALL* committers to just fix things to get a port into shape. In the case of 7.0, it was making ports build for gcc4. What we have laying ahead of us is a ports tree in various states of modern preparedness (new style USES=, stagefication, etc) and the old way of doing ports (boo!). We would like committers, and contributors to generate a PR and/or just fix the old ports to update them to the new way of doing things regardless of maintainership. We are looking for fixes in the following areas - Convert to LIB_DEPENDS - stagify ports - convert things like USE_GMAKE - USES=gmake USE_DOS2unix - USES=dos2unix etc. This can be done with implicit portmgr@ blanket approval, and without maintainer approval. Please, however, respect some boundaries, do not change ports belonging to kde@, gnome@ or x11@. These teams work in private repos that may have changes pending. Also, cross reference GNATS, to see if a port has an open PR that you can factor into the fix. It is important to stress here that we *DO NOT* want to invalidate existing patches that a maintainer has offered up or already approved. If the change is very trivial AND has been tested, just fix it. One of the strengths of the Ports Collection is it's volunteer maintainers, if you make a change, regardless of how trivial, just send a courtesy email to the maintainer. http://blogs.freebsdish.org/portmgr/2014/01/07/blanket-approval-to-modernize-the-ports-tree/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: CFT for cairo 1.12 and 8.x survey
On Mon, 06 Jan 2014 17:28:58 +0100 Koop Mast k...@rainbow-runner.nl wrote: Greetings! This is a weird call for testers. First off before the real CFT. We are interested if people are still using 8.x for there desktop. Is there a specific reason for not updating to 9.x or 10.x? So in our quest for push Xorg on FreeBSD further, we are looking for people to test cairo 1.12 primarily with the old Xorg stack. We know that the graphics with the 2.7.1 intel driver are horribly broken (lots of artifacts) so people don't need to test that, but what is the state of the other xorg video drivers with cairo 1.12? If problems arise after the update, a screenshot and details about installed ports and your hardware should be enough. But if your using the intel driver with old xorg please chime in too, this will give us a beter idea about the user base. I'm using 8.4-STABLE on a box which has the on-board intel graphics and uses the xorg-7.7 / xf86-video-intel-2.7.1_6 driver. It seems to work reasonably for a fluxbox desktop although I do see occasional artifacts. I never expect much from on-board video. The information at http://bsdstats.org/bt/releases.html might be helpful since it shows quite a few 8.x users. I was a little surprised that the intel driver usage was among the higher numbers (512) for drivers being reported ( http://bsdstats.org/ports.php?category=93 ). I'm dragging my feet on updating to 10.x because of the large block of time needed to rebuild everything or to do a new install. There's still some time left before EOL of 8.x ( June 30, 2015 ) so I suspect that there will be others that are slow to update. It was only the EOL of 6.x that pushed me to 8.x. I tend to live on the trailing-edge ;-) Randy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Advice about /usr/ports/math/gmp
We are about to release GMP 5.2. We have been forced to add three FreeBSD-related items to the releases notes: * This release will not work on FreeBSD/amd64 7.x, 8.x or 9 series before 9.3 with a Haswell CPU or any other CPU which supports the BMI2 instructions. The reason is that the FreeBSD m4 command is not correctly implemented. (Workaround: Use an older GMP release, or install GNU m4 from /usr/ports and tell GMP to use it.) * This release will not work on FreeBSD/amd64 before version 10 using the 32-bit ABI. The reason is broken limits.h and broken dynamic linking. (Workaround: Use an older GMP release if using the 32-bit ABI on these FreeBSD releases is important.) * This release will not work on FreeBSD/amd64 10.0 using the 32-bit ABI. The reason is bugs in the compiler 'clang'. (Workaround: Compiling gcc from /usr/ports might work, except that gcc depends on GMP; we have not been able to test that workaround since FreeBSD/i386 10.0 does not work for us under KVM or Xen.) The first item is a show-stopper. It would be possible to implement a workaround in GMP. We choose not to do that since (1) we adviced the FreeBSD project two years ago the m4 bug, and FreeBSD chose to make 4 releases without fixing m4, and (2) the fix is ugly, and (3) our use of m4 which triggers the bug is actually part of a workaround for a broken assembler (to much complexity to maintain workarounds for workarounds). The second item should not affect /usr/ports builds since they would use the default 64-bit ABI on amd64 machines. The third item is a show-stopper until clang is fixed. We have not been able to isolate this problem due to lack of time and due to a deeply malfunctioning filesystem of FreeBSD/i386 under KVM and Xen+NetBSD. We don't have any more information about these bugs. We do not plan to implement workarounds for the above bugs for GMP 5.2.x for any x. I would advice that you stick with GMP 5.1.3. Torbjörn Please encrypt, key id 0xC8601622 So, being that you have provided essentially zero information on the alleged bugs, what is the advice you are purporting to provide? The subject is advice about gmp but the only thing I see that would qualify as advice is don't upgrade. I do have a bit of advice for you: learn the difference between the words advise (verb) and advice (noun). Twice in the body you use advice where only advise makes sense. Advice is what you give, advise is the process of giving it. Being that advice is a noun, adviced isn't even a valid word. Yet another related word is advisory, which means to provide notification but not necessary advice. The subject line would be congruent with the content if it were advisory about gmp. Yes this reply is a total waste of time as was the original. Just replying in kind dear troll. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Advice about /usr/ports/math/gmp
On 1/7/2014 01:02, Matthew Rezny wrote: We are about to release GMP 5.2. We have been forced to add three FreeBSD-related items to the releases notes: * This release will not work on FreeBSD/amd64 7.x, 8.x or 9 series before 9.3 with a Haswell CPU or any other CPU which supports the BMI2 instructions. The reason is that the FreeBSD m4 command is not correctly implemented. (Workaround: Use an older GMP release, or install GNU m4 from /usr/ports and tell GMP to use it.) * This release will not work on FreeBSD/amd64 before version 10 using the 32-bit ABI. The reason is broken limits.h and broken dynamic linking. (Workaround: Use an older GMP release if using the 32-bit ABI on these FreeBSD releases is important.) * This release will not work on FreeBSD/amd64 10.0 using the 32-bit ABI. The reason is bugs in the compiler 'clang'. (Workaround: Compiling gcc from /usr/ports might work, except that gcc depends on GMP; we have not been able to test that workaround since FreeBSD/i386 10.0 does not work for us under KVM or Xen.) The first item is a show-stopper. It would be possible to implement a workaround in GMP. We choose not to do that since (1) we adviced the FreeBSD project two years ago the m4 bug, and FreeBSD chose to make 4 releases without fixing m4, and (2) the fix is ugly, and (3) our use of m4 which triggers the bug is actually part of a workaround for a broken assembler (to much complexity to maintain workarounds for workarounds). The second item should not affect /usr/ports builds since they would use the default 64-bit ABI on amd64 machines. The third item is a show-stopper until clang is fixed. We have not been able to isolate this problem due to lack of time and due to a deeply malfunctioning filesystem of FreeBSD/i386 under KVM and Xen+NetBSD. We don't have any more information about these bugs. We do not plan to implement workarounds for the above bugs for GMP 5.2.x for any x. I would advice that you stick with GMP 5.1.3. Torbjörn Please encrypt, key id 0xC8601622 So, being that you have provided essentially zero information on the alleged bugs, what is the advice you are purporting to provide? The subject is advice about gmp but the only thing I see that would qualify as advice is don't upgrade. I do have a bit of advice for you: learn the difference between the words advise (verb) and advice (noun). Twice in the body you use advice where only advise makes sense. Advice is what you give, advise is the process of giving it. Being that advice is a noun, adviced isn't even a valid word. Yet another related word is advisory, which means to provide notification but not necessary advice. The subject line would be congruent with the content if it were advisory about gmp. Yes this reply is a total waste of time as was the original. Just replying in kind dear troll. whoa - this is pretty harsh if you assume Torbjorn was sincere to begin with, and I haven't seen anything that indicates he wasn't. It's pretty much the definition of no good deed goes unpunished. Yes, the criticism of well, what exactly is wrong? is valid, but the guy did write a couple of PRs, so calling him a troll is way out of line. If it was planning on providing more information, I don't expect he will now. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Advice about /usr/ports/math/gmp
On Tue, 07 Jan 2014 03:11:28 +0100 John Marino freebsd.cont...@marino.st wrote: On 1/7/2014 01:02, Matthew Rezny wrote: We are about to release GMP 5.2. We have been forced to add three FreeBSD-related items to the releases notes: * This release will not work on FreeBSD/amd64 7.x, 8.x or 9 series before 9.3 with a Haswell CPU or any other CPU which supports the BMI2 instructions. The reason is that the FreeBSD m4 command is not correctly implemented. (Workaround: Use an older GMP release, or install GNU m4 from /usr/ports and tell GMP to use it.) * This release will not work on FreeBSD/amd64 before version 10 using the 32-bit ABI. The reason is broken limits.h and broken dynamic linking. (Workaround: Use an older GMP release if using the 32-bit ABI on these FreeBSD releases is important.) * This release will not work on FreeBSD/amd64 10.0 using the 32-bit ABI. The reason is bugs in the compiler 'clang'. (Workaround: Compiling gcc from /usr/ports might work, except that gcc depends on GMP; we have not been able to test that workaround since FreeBSD/i386 10.0 does not work for us under KVM or Xen.) The first item is a show-stopper. It would be possible to implement a workaround in GMP. We choose not to do that since (1) we adviced the FreeBSD project two years ago the m4 bug, and FreeBSD chose to make 4 releases without fixing m4, and (2) the fix is ugly, and (3) our use of m4 which triggers the bug is actually part of a workaround for a broken assembler (to much complexity to maintain workarounds for workarounds). The second item should not affect /usr/ports builds since they would use the default 64-bit ABI on amd64 machines. The third item is a show-stopper until clang is fixed. We have not been able to isolate this problem due to lack of time and due to a deeply malfunctioning filesystem of FreeBSD/i386 under KVM and Xen+NetBSD. We don't have any more information about these bugs. We do not plan to implement workarounds for the above bugs for GMP 5.2.x for any x. I would advice that you stick with GMP 5.1.3. Torbjörn Please encrypt, key id 0xC8601622 So, being that you have provided essentially zero information on the alleged bugs, what is the advice you are purporting to provide? The subject is advice about gmp but the only thing I see that would qualify as advice is don't upgrade. I do have a bit of advice for you: learn the difference between the words advise (verb) and advice (noun). Twice in the body you use advice where only advise makes sense. Advice is what you give, advise is the process of giving it. Being that advice is a noun, adviced isn't even a valid word. Yet another related word is advisory, which means to provide notification but not necessary advice. The subject line would be congruent with the content if it were advisory about gmp. Yes this reply is a total waste of time as was the original. Just replying in kind dear troll. whoa - this is pretty harsh if you assume Torbjorn was sincere to begin with, and I haven't seen anything that indicates he wasn't. It's pretty much the definition of no good deed goes unpunished. Yes, the criticism of well, what exactly is wrong? is valid, but the guy did write a couple of PRs, so calling him a troll is way out of line. If it was planning on providing more information, I don't expect he will now. John I'm aware of the applicable PR only because Tijl mentioned it later in the thread. It is actually the PR that earned Torbjörn the troll label in my mind. Specifically this: I was about to fix it, but found that the license of the code in question was unacceptable to me. I only contribute to Free Software, not to Open Source code bearing a license analogous to a law system that permits people to sell themselves as slaves. From his email, he is simply unhelpful. Essentially just you're different from GNU/Linux so you're broken but I won't bother to say how. Great, so helpful. It's when I get to the PR and see the bit of I could fix it but I won't because you use the wrong license that my troll alarm goes off. I could go on about how hypocritical it is to claim our m4 isn't Free Software when his project uses a far more onerous and vastly less-free license, but I'd just be preaching to the choir. Rather than call him out on the license crap, I opted to take a shortcut and simply troll him back with a bit of the ol' Learn2English. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Advice about /usr/ports/math/gmp
On 1/7/2014 04:25, Matthew Rezny wrote: On Tue, 07 Jan 2014 03:11:28 +0100 John Marino freebsd.cont...@marino.st wrote: whoa - this is pretty harsh if you assume Torbjorn was sincere to begin with, and I haven't seen anything that indicates he wasn't. It's pretty much the definition of no good deed goes unpunished. Yes, the criticism of well, what exactly is wrong? is valid, but the guy did write a couple of PRs, so calling him a troll is way out of line. If it was planning on providing more information, I don't expect he will now. John I'm aware of the applicable PR only because Tijl mentioned it later in the thread. It is actually the PR that earned Torbjörn the troll label in my mind. Specifically this: I was about to fix it, but found that the license of the code in question was unacceptable to me. I only contribute to Free Software, not to Open Source code bearing a license analogous to a law system that permits people to sell themselves as slaves. Yes, if that's an accurate quote, it doesn't reflect well on Torbjorn. However, if somebody read your post without the background information, it could be interpreted that FreeBSD has harsh mail lists where devs jump all over people trying to help. (or manipulated by a BSD-hater to make it look that way) From his email, he is simply unhelpful. Essentially just you're different from GNU/Linux so you're broken but I won't bother to say how. Great, so helpful. It's when I get to the PR and see the bit of I could fix it but I won't because you use the wrong license that my troll alarm goes off. I could go on about how hypocritical it is to claim our m4 isn't Free Software when his project uses a far more onerous and vastly less-free license, but I'd just be preaching to the choir. Rather than call him out on the license crap, I opted to take a shortcut and simply troll him back with a bit of the ol' Learn2English. Okay, so let's say he's correct and FreeBSD's base m4 can't build the latest gmp. Even if he won't tell us what the problem is, at least he told us there is a problem which could be easily reproduced. Granted, he has the power to save us that time, but something is better than nothing. I still don't believe that his intent was to troll, even if that is basically the end result. At least, I'm still willing to give him the benefit of the doubt (despite the uncool license preaching in the PR.) John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Advice about /usr/ports/math/gmp
On 2014-Jan-07 03:11:28 +0100, John Marino freebsd.cont...@marino.st wrote: Yes, the criticism of well, what exactly is wrong? is valid, but the guy did write a couple of PRs, Well, he claims to have written a couple of PRs but has so far refused to divulge any details. Tijl found one but we have no information on the other one. On 2014-Jan-07 04:25:27 +0100, Matthew Rezny mre...@hexaneinc.com wrote: in my mind. Specifically this: I was about to fix it, but found that the license of the code in question was unacceptable to me. I only contribute to Free Software, not to Open Source code bearing a license analogous to a law system that permits people to sell themselves as slaves. I liked that wording and made a note that next time I wanted to send a bug report regarding some GPL'd code, I should state: I was about to fix it, but could not understand the license of the code in question. I only contribute to Free Software, not to possibly Open Source code bearing a license that requires a law degree to understand. From his email, he is simply unhelpful. Essentially just you're different from GNU/Linux so you're broken but I won't bother to say how. Great, so helpful. I agree. And, since he's posting from using a GMP Project address, I presume this is official GMP policy. I guess the approved mechanism for reporting bugs in GMP is to include a vague GMP is broken statement, with an ambiguous explanation, in the release notes of software that uses or is used by GMP. If pressed, you should state that you can't be bothered to do anything further. On 2014-Jan-07 04:37:02 +0100, John Marino freebsd.cont...@marino.st wrote: Yes, if that's an accurate quote, it doesn't reflect well on Torbjorn. It was. Okay, so let's say he's correct and FreeBSD's base m4 can't build the latest gmp. Even if he won't tell us what the problem is, at least he told us there is a problem which could be easily reproduced. That's one problem. The other problems he mentions are: : * This release will not work on FreeBSD/amd64 before version 10 using :the 32-bit ABI. The reason is broken limits.h and broken dynamic :linking. There's no indication of what will not work means. It's not clear whether he's talking about compiling (which wasn't supported before 10.x) or running GMP. : * This release will not work on FreeBSD/amd64 10.0 using the 32-bit :ABI. The reason is bugs in the compiler 'clang'. Again, there's no indication of what will not work means. :FreeBSD/i386 10.0 does not work for us under KVM or Xen.) That's hardly a recipe for reproducing a problem. -- Peter Jeremy pgpgSmbSLo5QW.pgp Description: PGP signature
lang/ruby19 distfile not found (ruby-1.9.3-p484.tar.bz2)
While building ports-mgmt/portupgrade, I'm trying to build ruby19 on a new system (9.2-RELEASE), portsnapped up to five minutes ago. I'm unable to find ruby-1.9.3-p484.tar.bz2 on any of the FreeBSD mirrors that ports tries. I thought this might be a new development (recently updated port, not enough time for the distfile to make it everywhere) except that the Makefile shows the last update as 2013-12-13 02:17:30Z. I also don't see anything recent about it in gnats[1], so I have to assume this has been broken for a few weeks. This is my make.conf .. otherwise this is a pristine system. # cat /etc/make.conf WITHOUT_X11=yes MAKEFLAGS=-j2 It shouldn't matter, but this box is v6-only (hence a few network not reachable and timeout errors for some fetch attempts). I've FTP'd into a handful of the v6 enabled hosts and manually looked for the distfile, just to verify that I should be able to reach it somewhere via v6. Any thoughts or suggestions? [1] http://www.freebsd.org/cgi/query-pr-summary.cgi?category=portstext=ruby19sort=noneclosedtoo=on root@tinder:/usr/ports/ports-mgmt/portupgrade # make install === License BSD accepted by the user === Found saved configuration for portupgrade-2.4.12,2 === Fetching all distfiles required by portupgrade-2.4.12,2 for building === Extracting for portupgrade-2.4.12,2 = SHA256 Checksum OK for portupgrade/pkgtools-2.4.12.tar.bz2. === portupgrade-2.4.12,2 depends on file: /usr/local/bin/ruby19 - not found ===Verifying install for /usr/local/bin/ruby19 in /usr/ports/lang/ruby19 === License BSD2CLAUSE RUBY accepted by the user === Found saved configuration for ruby-1.9.3.484,1 = ruby-1.9.3-p484.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/ruby. = Attempting to fetch ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch ftp://ftp.SpringDaemons.com/pub/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.SpringDaemons.com/pub/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch http://www.ibiblio.org/pub/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: http://www.ibiblio.org/pub/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Forbidden = Attempting to fetch ftp://xyz.lcs.mit.edu/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://xyz.lcs.mit.edu/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch http://ring.nict.go.jp/archives/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: http://ring.nict.go.jp/archives/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch ftp://ftp.fu-berlin.de/unix/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.fu-berlin.de/unix/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch ftp://ftp.easynet.be/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.easynet.be/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2: File unavailable (e.g., file not found, no access) = Attempting to fetch ftp://ftp.ntua.gr/pub/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.ntua.gr/pub/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch ftp://ftp.kr.FreeBSD.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.kr.FreeBSD.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch http://mirrors.sunsite.dk/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: http://mirrors.sunsite.dk/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Not Found = Attempting to fetch ftp://ftp.iDaemons.org/pub/mirror/ftp.ruby-lang.org/ruby/1.9/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.iDaemons.org/pub/mirror/ftp.ruby-lang.org/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is unreachable = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ruby/ruby-1.9.3-p484.tar.bz2 fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ruby/ruby-1.9.3-p484.tar.bz2: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ruby and try again. *** [do-fetch] Error code 1 Stop in /usr/ports/lang/ruby19. *** [install] Error code 1 Stop in /usr/ports/lang/ruby19. *** [extract-depends] Error code 1 Stop in /usr/ports/ports-mgmt/portupgrade. *** [install] Error code 1 Stop in /usr/ports/ports-mgmt/portupgrade. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
