Re: diff and submissions
Le 05/05/2017 à 08:16, Franco Fichtner a écrit : >> On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: >> >> If you went as far as being able to create a pull request, you can do a >> git show HEAD or git diff origin/trunk...HEAD and submit that in the >> FreeBSD PR as well. > It's pretty easy to extract the diff from a PR on GitHub, just append > ".diff", and ".patch" works too, but gives the full git commit history: > > https://github.com/freebsd/freebsd-ports/pull/62.diff Yes, I am aware of that, the problem with github pull requests is that they are outside of the FreeBSD bug report process, they do not get assigned to maintainers, nobody notices them, they just stay there, and get obsolete. There have been 61 before, yes, I closed a lot because they were obsolete because it is outside of our process and nobody noticed them, and for the rest either asked the submitter to open a PR on our bugzilla, or opened one myself. -- Mathieu Arnold ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: diff and submissions
On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote: > Le 05/05/2017 à 08:16, Franco Fichtner a écrit : > >> On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: > >> > >> If you went as far as being able to create a pull request, you can do a > >> git show HEAD or git diff origin/trunk...HEAD and submit that in the > >> FreeBSD PR as well. > > It's pretty easy to extract the diff from a PR on GitHub, just append > > ".diff", and ".patch" works too, but gives the full git commit history: > > > > https://github.com/freebsd/freebsd-ports/pull/62.diff > > Yes, I am aware of that, the problem with github pull requests is that > they are outside of the FreeBSD bug report process, they do not get > assigned to maintainers, nobody notices them, they just stay there, and > get obsolete. > There have been 61 before, yes, I closed a lot because they were > obsolete because it is outside of our process and nobody noticed them, > and for the rest either asked the submitter to open a PR on our > bugzilla, or opened one myself. > I made a script which is a few lines of shell that converts pull requests to phabricator reviews automatically. I have handed it to some of the phabricator admins, I hope it will be progress soon. Bapt signature.asc Description: PGP signature
Re: diff and submissions
Le 05/05/2017 à 12:20, Baptiste Daroussin a écrit : > On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote: >> Le 05/05/2017 à 08:16, Franco Fichtner a écrit : On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: If you went as far as being able to create a pull request, you can do a git show HEAD or git diff origin/trunk...HEAD and submit that in the FreeBSD PR as well. >>> It's pretty easy to extract the diff from a PR on GitHub, just append >>> ".diff", and ".patch" works too, but gives the full git commit history: >>> >>> https://github.com/freebsd/freebsd-ports/pull/62.diff >> Yes, I am aware of that, the problem with github pull requests is that >> they are outside of the FreeBSD bug report process, they do not get >> assigned to maintainers, nobody notices them, they just stay there, and >> get obsolete. >> There have been 61 before, yes, I closed a lot because they were >> obsolete because it is outside of our process and nobody noticed them, >> and for the rest either asked the submitter to open a PR on our >> bugzilla, or opened one myself. >> > I made a script which is a few lines of shell that converts pull requests to > phabricator reviews automatically. > > I have handed it to some of the phabricator admins, I hope it will be progress > soon. Please, do not do that. Phabricator is for code review, not bug reports. It all ends up in our repository, but Phabricator does not have any maintainer notification like Bugzilla has. robak@ has a script that does pull-request -> bugzilla, and it has been waiting for months for someone with access to do something about it. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: diff and submissions
On Fri, May 05, 2017 at 12:27:13PM +0200, Mathieu Arnold wrote: > Le 05/05/2017 à 12:20, Baptiste Daroussin a écrit : > > On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote: > >> Le 05/05/2017 à 08:16, Franco Fichtner a écrit : > On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: > > If you went as far as being able to create a pull request, you can do a > git show HEAD or git diff origin/trunk...HEAD and submit that in the > FreeBSD PR as well. > >>> It's pretty easy to extract the diff from a PR on GitHub, just append > >>> ".diff", and ".patch" works too, but gives the full git commit history: > >>> > >>> https://github.com/freebsd/freebsd-ports/pull/62.diff > >> Yes, I am aware of that, the problem with github pull requests is that > >> they are outside of the FreeBSD bug report process, they do not get > >> assigned to maintainers, nobody notices them, they just stay there, and > >> get obsolete. > >> There have been 61 before, yes, I closed a lot because they were > >> obsolete because it is outside of our process and nobody noticed them, > >> and for the rest either asked the submitter to open a PR on our > >> bugzilla, or opened one myself. > >> > > I made a script which is a few lines of shell that converts pull requests to > > phabricator reviews automatically. > > > > I have handed it to some of the phabricator admins, I hope it will be > > progress > > soon. > > > Please, do not do that. > > Phabricator is for code review, not bug reports. It all ends up in our > repository, but Phabricator does not have any maintainer notification > like Bugzilla has. > robak@ has a script that does pull-request -> bugzilla, and it has been > waiting for months for someone with access to do something about it. > Pull request are for code submissions and phabricator is the equivalent for that Bapt signature.asc Description: PGP signature
Re: diff and submissions
On 05/05/2017 11:27, Mathieu Arnold wrote: Le 05/05/2017 à 12:20, Baptiste Daroussin a écrit : On Fri, May 05, 2017 at 12:17:06PM +0200, Mathieu Arnold wrote: Le 05/05/2017 à 08:16, Franco Fichtner a écrit : On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: If you went as far as being able to create a pull request, you can do a git show HEAD or git diff origin/trunk...HEAD and submit that in the FreeBSD PR as well. It's pretty easy to extract the diff from a PR on GitHub, just append ".diff", and ".patch" works too, but gives the full git commit history: https://github.com/freebsd/freebsd-ports/pull/62.diff Yes, I am aware of that, the problem with github pull requests is that they are outside of the FreeBSD bug report process, they do not get assigned to maintainers, nobody notices them, they just stay there, and get obsolete. There have been 61 before, yes, I closed a lot because they were obsolete because it is outside of our process and nobody noticed them, and for the rest either asked the submitter to open a PR on our bugzilla, or opened one myself. I made a script which is a few lines of shell that converts pull requests to phabricator reviews automatically. I have handed it to some of the phabricator admins, I hope it will be progress soon. Please, do not do that. Phabricator is for code review, not bug reports. It all ends up in our repository, but Phabricator does not have any maintainer notification like Bugzilla has. robak@ has a script that does pull-request -> bugzilla, and it has been waiting for months for someone with access to do something about it. Pull requests are not bug reports, that would issues. IMO PR -> phabricator would be best match. Regards Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: diff and submissions
On 5/5/17 8:17pm, Mathieu Arnold wrote: > Le 05/05/2017 à 08:16, Franco Fichtner a écrit : >>> On 4. May 2017, at 10:20 AM, Mathieu Arnold wrote: >>> >>> If you went as far as being able to create a pull request, you can do a >>> git show HEAD or git diff origin/trunk...HEAD and submit that in the >>> FreeBSD PR as well. >> It's pretty easy to extract the diff from a PR on GitHub, just append >> ".diff", and ".patch" works too, but gives the full git commit history: >> >> https://github.com/freebsd/freebsd-ports/pull/62.diff > > Yes, I am aware of that, the problem with github pull requests is that > they are outside of the FreeBSD bug report process, they do not get > assigned to maintainers, nobody notices them, they just stay there, and > get obsolete. > There have been 61 before, yes, I closed a lot because they were > obsolete because it is outside of our process and nobody noticed them, > and for the rest either asked the submitter to open a PR on our > bugzilla, or opened one myself. > A simple short term workaround might be: 1. Create a pull request template in github [1] 2. Include in it links to bugzilla and instructions for people to create a parallel bug report with a link back to github The main reason I like github is that it is trivial to fork the repository, copy in my patched port files and add comments to the commit. It is considerably more different to remember to create .orig files and then diff them all, bundle it into a shar format and attach to bugzilla. This is all from the perspective of someone who makes a submission once every 3-6 months. Obviously if I had svn commit rights or had even checked out the ports tree from svn then I'd have other options. Most people like me use portsnap so they don't have an svn checkout. Cheers Ari [1] https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/ -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: diff and submissions
Le 05/05/2017 à 12:37, Baptiste Daroussin a écrit : > On Fri, May 05, 2017 at 12:27:13PM +0200, Mathieu Arnold wrote: >> Le 05/05/2017 à 12:20, Baptiste Daroussin a écrit : >>> I made a script which is a few lines of shell that converts pull >>> requests to >>> phabricator reviews automatically. >>> >>> I have handed it to some of the phabricator admins, I hope it will be >>> progress >>> soon. >> Please, do not do that. >> >> Phabricator is for code review, not bug reports. It all ends up in our >> repository, but Phabricator does not have any maintainer notification >> like Bugzilla has. >> robak@ has a script that does pull-request -> bugzilla, and it has been >> waiting for months for someone with access to do something about it. >> > Pull request are for code submissions and phabricator is the equivalent for > that It is great to review code, yes, but it will not notify maintainers that they have a patch for one of their ports, it adds more work for the ports committers that will have to go and review the code, and maybe notice it came from github, and then maybe notice that someone need to notify the maintainer of the port in question, so that they can accept, or not, the patch. It is mostly going to end up having code review that are not handled by anyone because they are not code review, they came from github, and the submitter on github is not aware that there has been some review and they need to update their code, or that they need to submit it to bugzilla afterwards so that it gets reviewed by the maintainer. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
ICU Portupdate faulty
Can you tell me how to solve this when trying to update the icu port? I updated my ports before processing. ===> icu-58.2_2,1 has known vulnerabilities: icu-58.2_2,1 is vulnerable: icu -- multiple vulnerabilities CVE: CVE-2017-7868 CVE: CVE-2017-7867 WWW: https://vuxml.FreeBSD.org/freebsd/607f8b57-7454-42c6-a88a-8706f327076d.html 1 problem(s) in the installed packages found. => Please update your ports tree and try again. => Note: Vulnerable ports are marked as such even if there is no update available. => If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes' *** Error code 1 Stop. make: stopped in /usr/ports/devel/icu Thanks, Jos Chrispijn ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
It seems the port has known vulnerabilities. If you are sure about what you are doing, run the make command with "DISABLE_VULNERABILITIES=yes" option as it suggests. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RPI2, www/firefox, error: "NEON support not enabled"
In trying to compile www/firefox on RPI2 running -current the build now stops with error: "NEON support not enabled" The port at www/neon is compiled and installed. Thanks for reading, any guidance appreciated. bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
I am really not a fan of that. Better would be to solve the 'vulneratbilities' issue. /Jos Op 5-5-2017 om 17:24 schreef mokhi: It seems the port has known vulnerabilities. If you are sure about what you are doing, run the make command with "DISABLE_VULNERABILITIES=yes" option as it suggests. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
Hello, On 05/05/2017 11:37 AM, Jos Chrispijn wrote: I am really not a fan of that. Better would be to solve the 'vulneratbilities' issue. /Jos The vulnerabilites are outlined in http://www.vuxml.org/freebsd/607f8b57-7454-42c6-a88a-8706f327076d.html and appear to be patched in devel/icu 58.2_2,1 committed yesterday. See https://svnweb.freebsd.org/ports?view=revision&revision=440117. Op 5-5-2017 om 17:24 schreef mokhi: It seems the port has known vulnerabilities. If you are sure about what you are doing, run the make command with "DISABLE_VULNERABILITIES=yes" option as it suggests. -- Jim Ohlstein ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
Well, as I can see here < http://www.freshports.org/devel/icu/ > an older version of this port is vulnerable not current version. Maybe by updating your tree your problem will be solved :-] ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
> On 5 May, 2017, at 9:48, mokhi wrote: > > Well, as I can see here < http://www.freshports.org/devel/icu/ > an > older version of this port is vulnerable not current version. > Maybe by updating your tree your problem will be solved :-] Yes, this is the correct answer. After icu got patched, the VuXML entry was lowered to mark 58.2_2,1 as non-vulnerable. Jos, it sounds like your ports tree is after the icu update but before the VuXML modification. Update your ports tree to bring in the new VuXML file and you should be good. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
Yes I noticed as well. Point is that after updating my tree, the issue still exists allthough I have th correct portupdate in my ports. Let me check what is going wrong here. Thanks, Jos Op 5-5-2017 om 17:48 schreef mokhi: Well, as I can see here < http://www.freshports.org/devel/icu/ > an older version of this port is vulnerable not current version. Maybe by updating your tree your problem will be solved :-] ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On 2017-May-5, at 8:13 AM, bob prohaska wrote: > In trying to compile www/firefox on RPI2 running -current the build now stops > with > > error: "NEON support not enabled" > > The port at www/neon is compiled and installed. Wrong neon. > Thanks for reading, any guidance appreciated. https://developer.arm.com/technologies/neon says: ARM NEON technology is an advanced SIMD (single instruction multiple data) architecture extension for the ARM Cortex-A series and Cortex-R52 processors. NEON technology was introduced to the ARMv7-A and ARMv7-R profiles. It is also now an extension to the ARMv8-A and ARMv8-R profiles. So here NEON is a subset of the instruction set. Its purpose is (again quoting that page): NEON technology is intended to improve the multimedia user experience by accelerating audio and video encoding/decoding, user interface, 2D/3D graphics or gaming. NEON can also accelerate signal processing algorithms and functions to speed up applications such as audio and video processing, voice and facial recognition, computer vision and deep learning. === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
Op 5-5-2017 om 18:05 schreef Adam Weinberger: On 5 May, 2017, at 9:48, mokhi wrote: Well, as I can see here < http://www.freshports.org/devel/icu/ > an older version of this port is vulnerable not current version. Maybe by updating your tree your problem will be solved :-] Yes, this is the correct answer. After icu got patched, the VuXML entry was lowered to mark 58.2_2,1 as non-vulnerable. Jos, it sounds like your ports tree is after the icu update but before the VuXML modification. Update your ports tree to bring in the new VuXML file and you should be good. Adam, perhaps I am missing the clue here: - I had the correct updated version in my ports collection - Updating the vulnerable installed icu version with that version should not provide the Vulnerability message as that version is updates with the correct version in my icu port. In my case, Jim's suggestion to use "DISABLE_VULNERABILITIES=yes" was the only way of getting my faulty icu version updated to the version that is in my port. Kind of confused, Jos ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
On Fri, May 05, 2017 at 10:05:05AM -0600 I heard the voice of Adam Weinberger, and lo! it spake thus: > > Yes, this is the correct answer. After icu got patched, the VuXML > entry was lowered to mark 58.2_2,1 as non-vulnerable. Jos, it sounds > like your ports tree is after the icu update but before the VuXML > modification. Update your ports tree to bring in the new VuXML file > and you should be good. No, it's not looking at the vuxml file right in ports. It'll be using the audit file downloaded nightly as part of /usr/local/etc/periodic/security/410.pkg-audit, so it'll always be ~a day out of date. Run `pkg audit -F` manually to kick a refetch of the latest. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
On Fri, May 5, 2017 at 6:37 AM, Jos Chrispijn wrote: > > Op 5-5-2017 om 18:05 schreef Adam Weinberger: > >> On 5 May, 2017, at 9:48, mokhi wrote: >>> >>> Well, as I can see here < http://www.freshports.org/devel/icu/ > an >>> older version of this port is vulnerable not current version. >>> Maybe by updating your tree your problem will be solved :-] >>> >> Yes, this is the correct answer. After icu got patched, the VuXML entry >> was lowered to mark 58.2_2,1 as non-vulnerable. Jos, it sounds like your >> ports tree is after the icu update but before the VuXML modification. >> Update your ports tree to bring in the new VuXML file and you should be >> good. >> > Adam, perhaps I am missing the clue here: > > - I had the correct updated version in my ports collection > - Updating the vulnerable installed icu version with that version should > not provide the Vulnerability message as that version is updates with the > correct version in my icu port. > > In my case, Jim's suggestion to use "DISABLE_VULNERABILITIES=yes" was the > only way of getting my faulty icu version updated to the version that is in > my port. > > Kind of confused, > Jos The VuXML DB is not a part of the ports tree. It is usually updated by the nightly periodic script, but you can manually fetch it with "pkg audit -F -q". -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ICU Portupdate faulty
> On 5 May, 2017, at 11:13, Matthew D. Fuller wrote: > > On Fri, May 05, 2017 at 10:05:05AM -0600 I heard the voice of > Adam Weinberger, and lo! it spake thus: >> >> Yes, this is the correct answer. After icu got patched, the VuXML >> entry was lowered to mark 58.2_2,1 as non-vulnerable. Jos, it sounds >> like your ports tree is after the icu update but before the VuXML >> modification. Update your ports tree to bring in the new VuXML file >> and you should be good. > > No, it's not looking at the vuxml file right in ports. It'll be using > the audit file downloaded nightly as part of > /usr/local/etc/periodic/security/410.pkg-audit, so it'll always be ~a > day out of date. Run `pkg audit -F` manually to kick a refetch of the > latest. Ah! You and Kevin are completely right. Thank you for giving Jos the right answer. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On Fri, May 05, 2017 at 09:30:39AM -0700, Mark Millard wrote: > > Wrong neon. > > Ahh, what I feared 8-) > https://developer.arm.com/technologies/neon says: > I did find that page, but harbored a faint (and apparently misguided) hope that the port might in some fashion implement the vector instruction set. Evidently not. Thanks for clearing up the confusion. Is this an issue which must be addressed by the clang/llvm developers? 8-( bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On 2017-May-5, at 11:28 AM, bob prohaska wrote: > On Fri, May 05, 2017 at 09:30:39AM -0700, Mark Millard wrote: >> >> Wrong neon. >> >> > Ahh, what I feared 8-) > > >> https://developer.arm.com/technologies/neon says: >> > > I did find that page, but harbored a faint (and apparently > misguided) hope that the port might in some fashion implement > the vector instruction set. Evidently not. Freshports web page for it ( https://www.freshports.org/www/neon/ ) reports: Neon is an HTTP and WebDAV client library for Unix systems, with a C interface. > Thanks for clearing up the confusion. Is this an issue which > must be addressed by the clang/llvm developers? An rpi2 has Cortex-A7 (armv7-A) cores that have NEON but armv6 does not. There is some possibility that with something like -mcpu=cortex-a7 in use as a compiler option that NEON would be used. But I warn that there is an on-going bugzilla item for FreeBSD's support of things like NEON for arm: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 (VFP and NEON are related by the registers used.) So there could be other problems with NEON enabled code until it is all resolved. (And head gets the work before stable/11 gets the result.) === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On 2017-05-04, scratch65...@att.net wrote: > I can't imagine what code could possibly be in thunar and > samba that the xfce desktop would need, (...) Thunar is used to display the icons on the XFCE desktop. It depends on gvfs, which is used for accessing remote file systems and the trash inside Thunar. gvfs in turn depends on samba44 in order to access CIFS/SMB shares. Strictly speaking some of these features might be optional. But as far I know pkg currently doesn't have a concept of optional dependencies. So it's an all or nothing decision, when building the packages. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote: > > An rpi2 has Cortex-A7 (armv7-A) cores that have NEON > but armv6 does not. > > There is some possibility that with something like > -mcpu=cortex-a7 in use as a compiler option that > NEON would be used. What's the simplest way to try it on a self-hosted RPI2 running -current? At this point I'm just using make -DBATCH in /usr/ports/www/firefox and following my nose. There's nothing valuable on the system, it's only for testing. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 > > (VFP and NEON are related by the registers used.) > > So there could be other problems with NEON enabled code > until it is all resolved. (And head gets the work before > stable/11 gets the result.) > Most of the discussion in the thread is beyond me, but it is appreciated that the problem isn't simple. Thanks for writing! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On 2017-May-5, at 4:01 PM, bob prohaska wrote: > On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote: >> >> An rpi2 has Cortex-A7 (armv7-A) cores that have NEON >> but armv6 does not. >> >> There is some possibility that with something like >> -mcpu=cortex-a7 in use as a compiler option that >> NEON would be used. > > What's the simplest way to try it on a self-hosted RPI2 running > -current? At this point I'm just using make -DBATCH in > /usr/ports/www/firefox and following my nose. There's nothing > valuable on the system, it's only for testing. I've never built firefox for anything. The only place I have set up a (fairly minimal) x11 environment is on amd64 virtual machine guests, again no firefox or anything else major, just lumina and xterm (local use, not internet use). So it would be a research project for me to get a special/non-default firefox build done on a rpi2. (There are some fairly general, but not universal, techniques for supplying compiler options to ports. I've no clue were firefox lands for such properties.) >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 >> >> (VFP and NEON are related by the registers used.) >> >> So there could be other problems with NEON enabled code >> until it is all resolved. (And head gets the work before >> stable/11 gets the result.) >> > > Most of the discussion in the thread is beyond me, but it > is appreciated that the problem isn't simple. The overall effect: you may get odd results from corrupted NEON register values when NEON is put to use. (I do not know the detailed status of what is working vs. not for NEON/VFP at this point.) === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RPI2, www/firefox, error: "NEON support not enabled"
On Fri, May 05, 2017 at 05:44:16PM -0700, Mark Millard wrote: > > (There are some fairly general, but not universal, > techniques for supplying compiler options to ports. > I've no clue were firefox lands for such > properties.) > It appears that using make CFLAGS='-mcpu=cortex-a7' is sufficient to get past the NEON not enabled error. Thanks for your help! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
